通过“原子访问防护”或“中断防护”强制对与 ISR 共享的易失性变量进行原子访问的标准技术,特别是在运行没有操作系统的裸机、单线程协作多任务应用程序时< /strong>,如下:
// 1. save interrupt state
// 2. disable only the interrupts necessary
// You get atomic access to volatile variables shared with ISRs here,
// since ISRs are the only other "context" or running "thread" which
// might attempt to modify a shared memory block or variable.
// 3. restore interrupt state
另请参阅我在这里详细描述的地方,包括最佳实践(在短时间内保持中断关闭)和如何在不先禁用中断的情况下进行原子读取,通过我的doAtomicRead()
重复读取循环函数:读取由 ISR 更新的 64 位变量。
我之前已经记录过如何对 AVR 微控制器/Arduino 执行此操作:如何在 Atmel AVR mcus/Arduino 中强制原子性? 。
但是,我该如何为 STM32 微控制器做到这一点呢?我知道有很多方法。
请介绍以下技术:
- 通过 ARM 核 CMSIS:
- 用于全局中断
- 针对特定 IRQ(中断请求)
- 通过 STM32 HAL(硬件抽象层)
- 通过 FreeRTOS
这个答案是相关的,但不够: How can我禁用stm32f103的外部中断后重新启用它?
The standard technique to enforce atomic access to volatile variables shared with ISRs, via "atomic access guards" or "interrupt guards", in particular when running a bare metal, single-threaded cooperative multi-tasking application with no operating system, is as follows:
// 1. save interrupt state
// 2. disable only the interrupts necessary
// You get atomic access to volatile variables shared with ISRs here,
// since ISRs are the only other "context" or running "thread" which
// might attempt to modify a shared memory block or variable.
// 3. restore interrupt state
See also where I describe this in detail here, including best practices (keep interrupts off for short period of time) and how to do atomic reads withOUT disabling interrupts first, via my doAtomicRead()
repeat-read-loop function: Reading a 64 bit variable that is updated by an ISR.
I have previously documented how to do this for AVR microcontrollers/Arduino: How do I force atomicity in Atmel AVR mcus/Arduino?.
But, how do I do this for STM32 microcontrollers? I know there are a lot of ways.
Please cover the following techniques:
- Via ARM-core CMSIS:
- for global interrupts
- for specific IRQs (Interrupt Requests)
- Via STM32 HAL (Hardware Abstraction Layer)
- Via FreeRTOS
This answer is related, but insufficient: How can I re-enable the stm32f103's external interrupt after I disable it?
发布评论
评论(3)
2023 年 5 月 10 日更新:我学习这些东西的主要动机之一与我在 7 年前的 2016 年编写的第一个环形缓冲区实现有关,导致 这个调试问题让我在 2 天内损失了 25 个小时的调试工作。我最终编写了一个非常好的环形缓冲区实现,当在任何支持 C11 或 C++11 原子类型的系统上使用时,它是无锁的。这是我写过的最好的实现,也是我见过的最好的实现。它解决了其他实现的许多问题。完整的详细信息位于文件顶部。它可以在 C 和 C++ 中运行。您可以在此处查看完整的实现:containers_ring_buffer_FIFO_GREAT.c我的eRCaGuy_hello_world 存储库。
在 STM32 MCU 中启用/禁用中断的多种方法
...以启用原子访问(关键部分)防护:
1. 通过 ARM 核心 CMSIS:
1.A.对于全局中断
有关这些函数的定义,请参见:
要保存和恢复中断状态,请使用
__get_PRIMASK()
,例如this:处理全局中断时,这是裸机、非 FreeRTOS 代码的最佳方法!
我认为该技术还与所有 ARM 核 MCU 交叉兼容,而不仅仅是 STM32。
我首先从 Tilen Majerle 那里学到了这项技术,在这里:https://stm32f4-discovery.net/2015/06/how-to-properly-enabledisable-interrupts-in-arm-cortex-m/。他为澄清这些超级混乱的事情所做的工作和贡献是无限有价值和值得赞赏的!
他的例子:
1.B.对于特定 IRQ(中断请求)
如果可能,最好避免禁用全局中断,并仅禁用可能数量最少的特定中断实现特定代码的原子性。因此,使用这些函数可以让您仅启用或禁用您需要的特定中断!
启用或禁用特定类型的中断:
NVIC 代表“嵌套向量中断控制器”。 嵌套中断(意思是:更高优先级的中断仍然可以在 ISR 内触发)在 STM32 微控制器上默认启用。每种中断类型都分配有一个优先级,数字越低优先级越高,当 ISR 正在处理较低优先级时,可以触发较高优先级的中断。优先中断。有关 STM32 NVIC 的更多信息,请参阅此处: https://stm32f4-discovery.net/2014/05/stm32f4-stm32f429-nvic-or-nested-vector-interrupt-controller/。
将此与 AVR 微控制器(例如:ATMega328 / Arduino Uno)进行对比,后者没有基于优先级的中断,因此默认情况下,当任何 ISR 正在处理时,当程序进入 ISR 时,所有中断(即全局中断)都会自动禁用。请注意,即使在 AVR MCU 上,如果您愿意,您仍然可以手动启用嵌套中断/ISR,通过手动重新启用 ISR 内的全局中断="https://stackoverflow.com/a/39693278/4561887">在 Arduino 上调用
interrupts()
或原始 AVR 上的sei()
(设置中断)。我相信,每个 ARM 核微控制器制造商(包括 STM32 类型)都必须定义和创建自己的 IRQn_Type 中断请求类型列表,因此请参阅下面有关其 STM32 的详细信息为每个 MCU 定义的特定中断类型。
2. 通过 STM32 HAL(硬件抽象层)库
启用或禁用特定类型的中断:
请参阅,例如:“stm/stm32f2xx/st_hal_v1.1.3/STM32F2xx_HAL_Driver/Src/stm32f2xx_hal_cortex.c/.h " - 上述函数的定义位于这些文件中。在线查看它们:
以下是
HAL_NVIC_EnableIRQ() 和
HAL_NVIC_DisableIRQ()
。请注意,它们只是检查以确保您的 IRQn 有效,然后将输入参数传递给 ARM 核心 CMSIS NVIC_EnableIRQ() 和 NVIC_DisableIRQ()<上面的 /code> 功能!:对于
IRQn_Type
:请参阅适合您的特定板的相应定义文件!这些是制造商为您的主板提供的特定于主板的定义。例如,以下是 STM32 F2xx 系列中的所有板: https://github.com/STMicroElectronics/STM32CubeF2/tree/master/Drivers/CMSIS/Device/ST/STM32F2xx/Include。让我们具体看一下stm32f217xx.h
文件:从这个文件中,我们可以看到
typedef
定义,即“STM32F2XX 中断号定义”。它看起来像这样:IRQn_Type
的 enum2.A.使用 STM32 HAL 的示例用法:
获得
USART1
的独占访问权限(例如,确保以原子方式打印字符串),以通过以下方式打印调试字符基于 HAL 的阻塞(轮询)模式(即:通过HAL_UART_Transmit()
),您需要通过执行以下操作来禁用USART1_IRQn
的所有中断。 (这保证您获得对此设备的原子访问):3. 通过 FreeRTOS:
FreeRTOS 原子访问保护/中断相关函数列在内核控制 API 的“模块”部分下:内核控制:
重要!:
来源: https://www.freertos.org/Documentation/02-Kernel/04-API-references/04-RTOS-kernel-control/01-taskENTER_CRITICAL_taskEXIT_CRITICAL
另请参阅我的自述文件,其中包含潜在列表FreeRTOS 关键部分中允许和不允许其中的调用:https://github.com/ElectricRCAaircraftGuy/eRCaGuy_Engineering/tree/ main/FreeRTOS#freertos-ritic-section-calls
3.A.高级宏:
这些是首选使用的宏,也是 freertos 推荐的宏!
这些都支持嵌套调用,并且最终都会调用
portDISABLE_INTERRUPTS()
,这是较低级别taskDISABLE_INTERRUPTS()
的端口实现,如下所示。关于嵌套:来自:https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html:
<块引用>
对
taskENTER_CRITICAL()
和taskEXIT_CRITICAL()
的调用旨在嵌套。因此,只有当之前每次调用taskENTER_CRITICAL()
都执行了一次taskEXIT_CRITICAL()
调用时,才会退出临界区。其他限制:
<块引用>
关键部分必须保持非常短,否则将对中断响应时间产生不利影响。对
taskENTER_CRITICAL()
的每次调用都必须与对taskEXIT_CRITICAL()
的调用紧密配对。不得从关键部分调用 FreeRTOS API 函数。
来自:https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html
来自: <一href="https://www.freertos.org/taskENTER_CRITICAL_FROM_ISR_taskEXIT_CRITICAL_FROM_ISR.html" rel="nofollow noreferrer">https://www.freertos.org/taskENTER_CRITICAL_FROM_ISR_taskEXIT_CRITICAL_FROM_ISR.html
3.B.较低级别的宏:
这些不支持嵌套调用!
有关它们的官方文档位于“内核控制”主页上:
注释和限制:
taskDISABLE_INTERRUPTS()
在上面的链接中指出:<块引用>
通常不会直接调用此宏,应使用
taskENTER_CRITICAL()
和taskEXIT_CRITICAL()
代替它。taskENABLE_INTERRUPTS()
在上面的链接中指出:<块引用>
通常不会直接调用此宏,应使用
taskENTER_CRITICAL()
和taskEXIT_CRITICAL()
代替它。taskDISABLE_INTERRUPTS()
的使用被演示为用于在configASSERT()
的示例宏定义中发生恐慌的技术。taskDISABLE_INTERRUPTS()
可能比taskENTER_CRITICAL()
更好,因为没有大量的调用一旦调用taskDISABLE_INTERRUPTS()
,来自另一个线程的taskEXIT_CRITICAL()
将重新启用中断 [I想想!?]——相反,我们必须显式地(并且意外地)调用taskENABLE_INTERRUPTS()
(例如:从另一个线程)来重新启用中断一次taskDISABLE_INTERRUPTS()
> 已被调用。换句话说,这里使用低级taskDISABLE_INTERRUPTS()
调用是合适的,因为它确实会根据需要导致系统陷入循环,而taskENTER_CRITICAL()
不会。3.C.互斥体和其他支持 OS(操作系统)的同步原语
除了上面的示例之外,您还可以使用 FreeRTOS 队列(它们是线程安全的,与 C++ 中的所有容器不同) std 库)、互斥体、信号量、任务通知和其他同步原语(在可能且适当的情况下),以保护共享的某些数据之间FreeRTOS 任务(线程),假设您正在运行 FreeRTOS。
请在此处查看这些工具的列表:https://www.freertos.org/a00106.html,并在单击该链接后出现在左侧导航菜单中。
4. TODO:互斥原语:通过原子
set_and_test()
(读取、修改、写入)指令实现原始、与操作系统无关的自旋锁添加原子
test_and_set()
(我认为,set_and_test()
或read_modify_write()
作为函数名称确实更有意义)使用 ARM 核心的演示CMSIS 函数、汇编或任何必要的方式,以演示在 STM32 中编写自旋锁。我还不知道如何做到这一点,因此需要找到正确的函数或操作来使用。请参阅此处: https://en.wikipedia.org/wiki/Test -and-set#Pseudo-C_implementation_of_a_spin_lock:这是我在 C11 中使用
_Atomic
类型实现的自旋锁。它也应该适用于 STM32,并且可能编译为使用底层专有的 STREX / LDREX 操作来存储(写入)和读取(加载),但我' d 必须通过查看装配来检查这一点。此外,还需要修改此实现以添加安全防死锁机制,例如自动延迟、超时和重试,以防止死锁。请参阅我的注释:在 C11、C++11 中添加基本互斥锁(锁)和自旋锁实现、AVR和STM325. 另请参阅:
doAtomicRead()
函数,它确保原子访问不带OUT关闭中断对于 Microchip PIC32 微控制器
请参阅我的问题的参考部分:如何正确计数定时器溢出以转换 32-位高分辨率定时器转换为 64 位高分辨率定时器:
Update 10 May 2023: one of my primary motivating factors in learning this stuff was related to my first ever ring buffer implementation I wrote 7 years ago in 2016, leading to this debugging problem where I lost 25 hours of debugging work in 2 days. I finally wrote a really good ring buffer implementation that is lock-free when used on any system which supports C11 or C++11 atomic types. It is the best implementation I've ever written, and also the best I've ever seen. It solves a lot of the problems of other implementations. Full details are in the top of the file. It runs in both C and C++. You can see the full implementation here: containers_ring_buffer_FIFO_GREAT.c in my eRCaGuy_hello_world repo.
Multiple ways to enable/disable interrupts in STM32 mcus
...to enable atomic access (critical section) guards:
1. Via ARM-core CMSIS:
1.A. For global interrupts
For the definition of these functions, see:
To save and restore the interrupt state, use
__get_PRIMASK()
, like this:When dealing with global interrupts, this is the best way for bare-metal, non-FreeRTOS code!
I think this technique is also cross-compatible with ALL ARM-core mcus, not just STM32.
I first learned this technique from Tilen Majerle, here: https://stm32f4-discovery.net/2015/06/how-to-properly-enabledisable-interrupts-in-arm-cortex-m/. His work and contributions to clear up this super-obfuscated stuff are infinitely valuable and appreciated!
His example:
1.B. For specific IRQs (Interrupt Requests)
It is best to avoid disabling global interrupts, if possible, and disable only the fewest number of specific interrupts possible to achieve atomicity for your specific code. So, using these functions allows you to enable or disable only the specific interrupts you need to!
Enable or disable specific types of interrupts:
NVIC stands for "Nested Vector Interrupt Controller". Nested interrupts (meaning: a higher-priority interrupt can still fire within an ISR) are enabled by default on STM32 microcontrollers. Each interrupt type has a priority assigned to it, with lower numbers being higher priority, and higher-priority interrupts are able to fire while an ISR is being processed for a lower-priority interrupt. See here for a little more information on the STM32 NVIC: https://stm32f4-discovery.net/2014/05/stm32f4-stm32f429-nvic-or-nested-vector-interrupt-controller/.
Contrast this to AVR microcontrollers (ex: ATMega328 / Arduino Uno), which do not have priority-based interrupts, so by default, when any ISR is being processed, all interrupts (ie: global interrupts) are automatically disabled as the program enters the ISR. Note that even on AVR mcus, however, you can still manually enable nested interrupts / ISRs if you like by manually re-enabling global interrupts inside your ISR, via a call to
interrupts()
on Arduino orsei()
(set interrupts) on raw AVR.Each ARM-core microcontroller manufacturer, I believe, including STM32 types, must define and create its own list of
IRQn_Type
interrupt request types, so see below for the STM32 details on their specific interrupt types defined for each mcu.2. Via STM32 HAL (Hardware Abstraction Layer) libraries
Enable or disable specific types of interrupts:
See, for example: "stm/stm32f2xx/st_hal_v1.1.3/STM32F2xx_HAL_Driver/Src/stm32f2xx_hal_cortex.c/.h" - definitions for those functions above are in those files. See them online:
Here are the definitions of
HAL_NVIC_EnableIRQ()
andHAL_NVIC_DisableIRQ()
. Notice that they just check to ensure yourIRQn
is valid, then they pass the input argument on to the ARM-core CMSISNVIC_EnableIRQ()
andNVIC_DisableIRQ()
functions above!:For
IRQn_Type
s: see the appropriate definition file for your specific board! These are board-specific definitions, for your board from your manufacturer. Here are all of the boards in the STM32 F2xx line, for instance: https://github.com/STMicroelectronics/STM32CubeF2/tree/master/Drivers/CMSIS/Device/ST/STM32F2xx/Include. Let's look at thestm32f217xx.h
file specifically:From this file, we can see the
typedef enum
definition for theIRQn_Type
, which is the "STM32F2XX Interrupt Number Definition". Here is what it looks like:2.A. Example usage using STM32 HAL:
To get exclusive access (to ensure strings are atomically printed, for instance) to the
USART1
for printing debug chars via a HAL-based blocking (polled) mode (ie: viaHAL_UART_Transmit()
), you need to disable all interrupts forUSART1_IRQn
by doing the following. (This guarantees you get atomic access to this device):3. Via FreeRTOS:
The FreeRTOS atomic-access-guard / interrupt-related functions are listed under the "Modules" section of the Kernel Control API here: Kernel Control:
Important!:
Source: https://www.freertos.org/Documentation/02-Kernel/04-API-references/04-RTOS-kernel-control/01-taskENTER_CRITICAL_taskEXIT_CRITICAL
See also my README here, with a potential list of which calls are and are not allowed within FreeRTOS critical sections: https://github.com/ElectricRCAircraftGuy/eRCaGuy_Engineering/tree/main/FreeRTOS#freertos-critical-section-calls
3.A. Higher-level macros:
These are the preferred macros to use, and are the freertos-recommended ones!
These all support nested calls, and end up calling
portDISABLE_INTERRUPTS()
anyway, which is the port implementation of the lower-leveltaskDISABLE_INTERRUPTS()
, shown below.About nesting: from: https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html:
Other limitations:
From: https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html
From: https://www.freertos.org/taskENTER_CRITICAL_FROM_ISR_taskEXIT_CRITICAL_FROM_ISR.html
3.B. Lower-level macros:
These do NOT support nested calls!
Official documentation on them is on the main "Kernel Control" page:
Notes and limiatations:
taskDISABLE_INTERRUPTS()
at the link above states:taskENABLE_INTERRUPTS()
at the link above states:taskDISABLE_INTERRUPTS()
is demonstrated as the technique used to panic inside an example macro definition forconfigASSERT()
.taskDISABLE_INTERRUPTS()
might be preferred overtaskENTER_CRITICAL()
because no amount of callingtaskEXIT_CRITICAL()
from another thread will re-enable interrupts oncetaskDISABLE_INTERRUPTS()
has been called [I think!?]--rather, one would have to explicitly (and accidentally) calltaskENABLE_INTERRUPTS()
(ex: from another thread) to re-enable interrupts oncetaskDISABLE_INTERRUPTS()
has been called. In other words, using the low-leveltaskDISABLE_INTERRUPTS()
call is appropriate here because it will truly cause the system to sit in a loop, as desired, whereastaskENTER_CRITICAL()
would not.3.C. Mutexes and other OS (Operating System)-enabled synchronization primitives
Beyond the examples above, you can also use FreeRTOS queues (which are thread-safe, unlike all containers in the C++ std library), mutexes, semaphores, task notifications, and other synchronization primitives, where able and where appropriate, to protect certain data which is shared between FreeRTOS tasks (threads), assuming you are running FreeRTOS.
See the list of these tools here: https://www.freertos.org/a00106.html, and in the left-hand navigation menus once you click on that link.
4. TODO: mutex primitives: raw, OS-free spin locks via atomic
set_and_test()
(read, modify, write) instructionsAdd an atomic
test_and_set()
(set_and_test()
orread_modify_write()
really makes more sense as a function name for this, I think) demo using ARM-core CMSIS functions, or assembly, or whatever means necessary, to demonstrate writing a spin lock in STM32. I don't know how to do this yet so it will require finding the right function or operation to use. See here: https://en.wikipedia.org/wiki/Test-and-set#Pseudo-C_implementation_of_a_spin_lock:Here is a spin lock implementation I did in C11 using
_Atomic
types. It should work just fine for STM32 as well, and probably compiles to use the underlying exclusiveSTREX
/LDREX
operations to store (write) and read (load), but I'd have to check that by looking at the assembly. Additionally, this implementation would need to be modified to add safety anti-deadlock mechanisms such as automatic deferral, timeout, and retry, to prevent deadlock. See my notes here: Add basic mutex (lock) and spin lock implementations in C11, C++11, AVR, and STM325. See also:
doAtomicRead()
func which ensures atomic access withOUT turning interrupts offFor Microchip PIC32 microcontrollers
See the References section of my question here: How to properly count timer overflows to convert a 32-bit high-resolution timer into a 64-bit high-resolution timer:
对共享变量的原子访问只能通过在没有更现代的替代方案可用的情况下关闭中断来实现,或者有时在性能和延迟不成问题的非常简单的项目中。
禁用中断会以难以预测的方式增加系统延迟,应尽可能避免。
在 ARMv7M 及更高版本的内核(包括所有 STM32F1xx、STM32F2xx、STM32F3xx、STM32F4xx、STM32F7xx、STM32H7xx、STM32G4xx、STM32L1xx、STM32L4xx、SRM32L5xx、STM32U5xx)上,应使用 LDREX/STREX 独占访问指令实现原子访问。复杂的消息队列和信号量系统可以基于这些原语构建,而无需禁用中断。有关示例,请查看 mbed-os 中的信号量实现。
STM32 系列的其他成员(STM32F0xx、STM32G0xx 和 STM32L0xx)可以使用
NVIC_EnableIRQ
/NVIC_EnableIRQ
关闭各个中断,或者作为最后的手段使用关闭所有中断__disable_irq()
/__enable_irq()
。Atomic access to shared variables should only be achieved by turning interrupts off where more modern alternatives are not available, or sometimes in very simple projects where performance and latency are not an issue.
Disabling interrupts increases the latency of the system in ways which are difficult to predict, and should be avoided wherever possible.
On ARMv7M and higher cores (including all STM32F1xx, STM32F2xx, STM32F3xx, STM32F4xx, STM32F7xx, STM32H7xx, STM32G4xx, STM32L1xx, STM32L4xx, SRM32L5xx, STM32U5xx) atomic access should be achieved using LDREX/STREX exclusive access instructions. Complex message queues and semaphore systems can be built upon these primitives which do not ever require to disable interrupts. For an example look at the semaphore implementation in mbed-os.
The other members of the STM32 family (STM32F0xx, STM32G0xx and STM32L0xx) may turn individual interrupts off using
NVIC_EnableIRQ
/NVIC_EnableIRQ
or as a last resort turn all interrupts off with__disable_irq()
/__enable_irq()
.另一种选择是使用 __get_PRIMASK() 和 __set_PRIMASK() ,如下所示:
“这看起来可能有竞争条件,但实际上没有。如果启用了中断,并且有东西在 __get_PRIMASK() 和 __disable_irq() 之间打断了您并禁用IRQ 本身,它会在完成之前恢复它们,因此您的“old_primask”变量仍然有效。” 来源< /a>
“对于短操作(几个到数百条指令,具体取决于您的延迟要求),禁用中断很好,对于非常短的操作通常是最有效的方法。对于非常长的操作或任何其他操作甚至有可能阻塞 RTOS 操作,因此需要互斥锁。” 来源
Another option is to use __get_PRIMASK() and __set_PRIMASK() like so:
"This looks like it might have a race condition but doesn't. If interrupts were enabled and something interrupts you between the __get_PRIMASK() and the __disable_irq() and disables IRQs itself, it will restore them before it finishes so your 'old_primask' variable will still be valid." Source
"For short operations (a few to hundreds of instructions depending on your latency requirements), disabling interrupts is fine and for very short operations usually the most efficient way to do it. For very long operations or anything that has even a chance of blocking on an RTOS operation, a mutex is required." Source