做 STM32 这行久了会发现真正让项目返工的往往不是外设初始化写错寄存器而是几个变量在中断和主循环之间来回撕扯。前阵子有位 A 同学拿着一份代码来找我说他那个统计脉冲个数的变量在定时器中断里自增主循环里读出来总比实际少几个数示波器数得清清楚楚代码就是不对。我扫了一眼就知道问题出在哪counter在 C 语言里是一行编译出来是三条汇编中间任何一次中断插入都会让这次自增变成一次读旧值、写回旧值的覆盖。这就是 STM32 平台上最典型的原子操作问题也是这篇内容要聊的核心。原子操作说白了就是要么全部做完要么一点都不做的操作语义它在 STM32 上的落地方式与桌面平台完全不同——没有操作系统兜底、没有 MMU、没有多核缓存一致性协议大部分型号你手里能用的只有内核指令、中断控制和一个编译器。这篇内容会把 Cortex-M 内核提供的原子原语、四种工程上常用的实现路径、真实代码写法以及我踩过的坑一次讲清楚适合已经能点灯、写过中断服务函数但还没系统梳理过并发安全的嵌入式开发者刚入门的新手也能看懂前半部分的原理后半部分的实操建议直接抄。1. 一条 i 为什么会出错先把原子这件事说透1.1 从三条汇编指令看非原子的本质很多人对原子操作的误解来自 C 语言语法的欺骗性。a、flag 1、if (state READY)这些写法看起来都是一个动作但编译器翻译出来完全不是一回事。以a为例在 Cortex-M 上典型的三条指令是LDR把 a 从内存读进寄存器、ADD在寄存器里加一、STR把结果写回内存。三条指令之间是允许被打断的中断服务程序如果在这个窗口里改动了 a主循环的STR就会把中断的修改直接覆盖掉——这就是所谓的丢失更新。我用一个具体的数字例子说明会更直观。假设 a 初值为 100主循环执行到LDR之后拿到 100此时定时器中断触发中断里执行了一次a内存里 a 变成 101中断返回主循环继续执行ADD得到 101然后STR写回内存a 依然是 101。两次自增结果只加了一次。这个问题在低频中断下出现概率很低测试阶段可能跑一整天都碰不到一旦产品上量、中断频率提高就会变成偶发的数据错乱排查成本极高。这里要强调一个容易被忽略的点出错的根源不是中断里写了同一个变量这件事本身而是读和写这两个动作之间存在可被插入的时间窗口。原子操作的本质就是消灭这个窗口或者让窗口内的冲突被硬件检测出来并重试。理解了这个模型后面所有的实现手段都能归类要么不让别人插进来关中断要么让硬件帮你检测冲突LDREX/STREX要么把读写合并成一条指令位带要么干脆让一个执行者负责写单写者模型。1.2 STM32 上哪些操作天生原子哪些天生不原子判断一个操作是否原子第一看位宽第二看对齐第三看编译器有没有把它拆开。在 Cortex-M 上对 8 位、16 位、32 位变量的单次对齐访问硬件层面是原子的——一条LDR或STR指令完成总线事务不可分割。所以一个uint32_t类型的变量如果只有一个写者比如只有中断写主循环只读那么读和写本身不会撕裂你读到的要么是旧值要么是新值不会是半新半旧。这是很多场景下可以放心使用的基础。但下面这几类就是明确的非原子操作必须小心第一类是读-改-写组合a、a | mask、a ~mask、a a * 2统统不原子第二类是位域bit-field操作struct里定义uint8_t flag : 1;然后赋值编译器会生成读整个字节、改一位、写回整个字节的序列改动某一位会连带影响同字节的其他位如果另一位被中断修改就会互相覆盖第三类是超过 32 位的数据uint64_t、double、float在 M0 上软件浮点更是灾难必然拆成两次 32 位访问第四类是非对齐访问虽然 Cortex-M3/M4/M7 硬件支持非对齐的LDR/STR但硬件内部会把它拆成两次对齐的总线访问原子性就没了所以用#pragma pack压缩过的结构体、或者把uint32_t指针强转到奇地址上都是隐患。注意volatile关键字不提供任何原子性保证。它只告诉编译器这个变量可能被外部改变每次都必须从内存重新读、每次赋值都必须真的写回防止优化器把循环里的读操作提到循环外。它阻拦的是编译器优化不是中断抢占。把volatile当原子用是新手最常见的认知错误。还有一类隐蔽的坑是编译器的聪明优化。比如你在临界区里写flag 1;然后马上flag 0;编译器可能直接把第一条语句删掉又比如你精心构造的关中断、改值、开中断序列编译器完全可以把改值操作挪到关中断之前因为它不知道那几条内联汇编意味着什么。这类问题必须靠编译器屏障来堵后面第 2.3 节会专门讲。2. 内核给你准备的原子武器独占访问与位带2.1 LDREX/STREX 的工作机制与独占监视器Cortex-M3、M4、M7、M23、M33 这些内核都实现了 ARMv7-M 或 ARMv8-M 的独占访问指令LDREX和STREX这是硬件层面最正统的原子原语。工作原理不难理解LDREX除了完成一次普通读取还会在处理器内部的独占监视器上给这块地址打个标记随后执行STREX时硬件先检查这个标记还在不在如果在就完成写入并返回 0 表示成功如果标记已经被清除比如中间发生了异常返回、上下文切换、或者另一条LDREX覆盖了监视器状态就拒绝写入并返回非 0调用者需要重新来一遍。在 CMSIS 里这几个指令被封装成了内建函数用起来比写汇编舒服得多。GCC 版本的cmsis_gcc.h里提供了__LDREXW、__STREXW、__CLREX写一个原子的自增大概长这样static inline uint32_t atomic_inc_u32(volatile uint32_t *p) { uint32_t old, ret; do { old __LDREXW(p); ret __STREXW(old 1, p); } while (ret ! 0); /* 0 表示写入成功非 0 需要重试 */ return old; /* 返回自增前的旧值 */ }这段代码看着不长但有几个细节决定了它能不能用。第一重试循环必须有而且里面不能干耗时的事否则会拉长独占窗口。第二LDREX和STREX之间不能调用任何可能触发异常返回的函数也不能嵌套使用另一对LDREX/STREX因为很多内核只有一个全局的独占监视器嵌套会互相破坏状态。第三也是最容易翻车的一点如果在LDREX和STREX之间被高优先级中断打断中断返回后STREX一定失败于是循环重来如果这个中断频率很高、周期又和循环接近就会出现反复失败、任务饿死的活锁现象。我曾经在一个 20kHz 的 PWM 中断场景里见过这个问题那段原子自增代码看起来完全正确但主循环里的计数器偶尔会卡几十毫秒才更新一次最后是靠临时关中断包住这个循环解决的。还有一点必须提醒Cortex-M0和Cortex-M0是 ARMv6-M 架构没有LDREX/STREX指令。这两个内核在低端 STM32 型号上很常见如果你打算写一套跨型号的原子操作库M0分支必须单独处理通常只能退回到关中断方案。这个差异在选型阶段很容易被忽略等到移植时才发现整个底层要重写。2.2 位带操作把读改写压成一条指令位带bit-band是 Cortex-M3/M4 上一个非常实用的硬件特性它把 SRAM 和外设区的每一个比特映射成一个 32 位字你访问这个 32 位字就等价于访问原来那一位而硬件保证这个读-改-写过程是原子的。计算别名地址的公式是固定的别名地址 别名区基址 (字节偏移 × 32) (位序号 × 4)其中 SRAM 区的别名基址是 0x22000000对应 0x20000000 起的 1MB 空间外设区的别名基址是 0x42000000对应 0x40000000 起的 1MB 空间。写成宏大概是这样#define BITBAND_PERIPH(addr, bit) \ (*(volatile uint32_t *)(0x42000000UL (((uint32_t)(addr) - 0x40000000UL) 5) ((bit) 2))) #define BITBAND_SRAM(addr, bit) \ (*(volatile uint32_t *)(0x22000000UL (((uint32_t)(addr) - 0x20000000UL) 5) ((bit) 2)))用它操作 GPIO 的输出寄存器特别顺手比如BITBAND_PERIPH(GPIOA-ODR, 5) 1;就是一次原子的置位不会像GPIOA-ODR | (1 5)那样先生成一个完整的 32 位读-改-写序列把其他引脚的状态一起带进去。在多任务或者中断里同时操作同组 GPIO 不同引脚的场景下这个差别非常关键——用|写法主循环置 PA5 的同时中断置 PA6很可能丢一个。但位带有个硬性限定必须记牢它存在于 Cortex-M3 和 M4 内核而 Cortex-M7 已经移除了位带别名区所以 STM32F7、H7 这些型号是没有位带的代码里用了位带宏会直接跑飞或者访问到无效地址。另外 Cortex-M0/M0 同样不支持。第二点是位带的原子性只对单一位的访问成立如果你需要同时原子地修改多位比如一次性把一个 8 位字段写进去位带帮不上忙。第三点位带操作的性能并不比普通写快它只是把三条指令变成了一条但对总线的访问次数是一样的别指望它提速。提示位带别名区那 1MB 外设空间只覆盖 0x40000000 到 0x400FFFFF也就是说大部分 APB 外设和 AHB1 上的 GPIO 都在范围内但 AHB 上一些高地址外设比如部分型号的以太网、USB OTG 寄存器落在范围之外不能位带访问。查参考手册的内存映射表确认一下比较稳妥。2.3 内存屏障DMB、DSB 与编译器屏障原子性解决的是操作不被拆开但还有另一个维度的问题顺序性。现代编译器会重排指令Cortex-M7 这种带超标量流水线和写缓冲的内核硬件也可能让内存访问的实际完成顺序和程序顺序不一致。在没有缓存一致性的单核系统里这个问题不像多核那么严重但在两个场景下依然会咬人一是临界区边界的代码被编译器挪出去二是 DMA 与 CPU 共享缓冲区时写缓冲未刷出。先说要区分两种屏障。编译器屏障是__asm volatile( ::: memory);它不生成任何机器指令只是告诉编译器这行之后的内存访问不能提到这行之前之前的也不能压到这行之后用来阻止优化跨越临界区边界。ARM 内核屏障是__DMB()数据内存屏障保证屏障前的内存访问对后续访问可见、__DSB()数据同步屏障等待之前的所有内存访问真正完成、__ISB()指令同步屏障清流水线改完系统控制寄存器后必须用这几个 CMSIS 都有封装。实际写代码时关中断的临界区前后最好都加一条编译器屏障因为你不知道优化器会怎么安排#define ENTER_CRITICAL() do { \ __asm volatile( ::: memory); \ primask_save __get_PRIMASK(); \ __disable_irq(); \ } while (0) #define EXIT_CRITICAL() do { \ __set_PRIMASK(primask_save); \ __asm volatile( ::: memory); \ } while (0)用__get_PRIMASK保存、__set_PRIMASK恢复而不是简单地__enable_irq()是为了支持嵌套。如果你的临界区嵌套在另一个已经关中断的临界区里__enable_irq()会提前打开中断直接破坏外层的保护。这个坑我在不止一个项目里见过表现是偶发丢数据而且只在多层调用时出现极难复现。3. 四种落地手段的对比与选型3.1 关中断最暴力但最不容易出错关中断是所有方案里最土也最可靠的一种一条CPSID i下去中断全灭临界区里的任何操作都成了事实上的原子。它的优点是实现简单、跨内核无差别M0 到 M7 通用、不依赖编译器内建函数而且开销完全可预测——就是关中断和开中断两条指令加上流水线冲刷的时间通常在十几个周期量级。缺点同样明显。第一关中断期间所有中断都被延迟包括那些对时间敏感的串口接收、编码器计数、ADC 采样完成。如果临界区里有函数调用、有浮点运算、有循环关中断时间就会失控表现为通信误码、脉冲丢失。第二它破坏了系统的实时性保证在功能安全相关的设计里中断延迟是一个必须论证的指标不能随便拉长。我的经验是把临界区控制在 10 条指令以内只做最必要的那几个赋值绝不在里面调函数。如果发现临界区包住的代码越来越多那说明数据结构设计有问题应该考虑换成单写者模型或者无锁结构而不是继续加长关中断时间。另外有个细节CMSIS 的__disable_irq()只影响可屏蔽中断NMI 和 HardFault 是关不掉的所以别指望它保护一切只能说保护常规中断。3.2 BASEPRI 精准屏蔽兼顾实时性比关中断更精细的手段是操作BASEPRI寄存器它能让优先级数值大于等于某个阈值的中断被屏蔽而优先级更高的中断照常响应。这正好对应 RTOS 里的临界区需求任务级临界区需要屏蔽那些会调用系统 API 的中断否则会破坏内核数据但希望能让最高优先级的紧急中断继续响应。FreeRTOS 的taskENTER_CRITICAL()在 Cortex-M3/M4/M7 端口上就是用BASEPRI实现的阈值由configMAX_SYSCALL_INTERRUPT_PRIORITY决定。裸机项目里也可以直接用CMSIS 提供了__set_BASEPRI()和__get_BASEPRI()uint32_t basepri_save __get_BASEPRI(); __set_BASEPRI(0x60); /* 屏蔽优先级数值 0x60 的中断数值越大优先级越低 */ /* 临界区代码 */ __set_BASEPRI(basepri_save);这里有个非常容易搞反的点Cortex-M 的优先级是数值越小优先级越高。所以BASEPRI 0x60屏蔽的是数值大于等于 0x60 的那些低优先级中断而数值 0x00 到 0x50 的高优先级中断不受影响。写代码时如果不确定把NVIC_SetPriority的实参和这个阈值对一遍比在调试器里瞎试快得多。注意BASEPRI的生效前提是PRIMASK为 0。如果之前有代码调用了__disable_irq()没恢复BASEPRI设置了也没用整个系统还是全屏蔽状态。这类忘记开中断的 bug现象是外设全部失联但单步调试又一切正常非常典型。3.3 编译器内建原子函数C11 与 __atomicGCC 和基于 Clang 的工具链提供了一套__atomic_*内建函数配合 C11 的stdatomic.h使用写出来最接近现代并发编程的样子#include stdatomic.h atomic_uint g_rx_count; void TIM_ISR(void) { atomic_fetch_add_explicit(g_rx_count, 1, memory_order_relaxed); } uint32_t get_rx_count(void) { return atomic_load_explicit(g_rx_count, memory_order_acquire); }在 Cortex-M3/M4/M7 上工具链会把这几个内建函数展开成LDREX/STREX序列加必要的屏障性能和手写差不多但可读性和正确性都好得多。memory_order参数在单核系统上的实际作用主要是控制编译器重排和是否插入DMBrelaxed最轻、acquire/release用于跨执行单元的同步、seq_cst最重但最省心。日常写中断与主循环通信relaxed配合显式屏障就够用了。但有两个坑必须提前知道。第一Cortex-M0/M0上没有独占指令工具链会退化成调用libatomic库里的__atomic_compare_exchange_4而这个库函数在裸机环境下往往没有实现或者链接不进来编译能过、链接报错或者更糟——链接进来但实现是空的。第二老一些的 ARMCC v5 不完全支持 C11 原子操作需要用__sync_*系列或者自己封__ldrex/__strex。如果项目用的是 AC5先确认工具链版本再决定方案别照着网上的例子抄。3.4 RTOS 临界区与信号量别用错场景上了 RTOS 之后很多人第一反应是有信号量了原子操作不用管了。这个理解只在任务与任务之间成立在任务与中断之间就未必。信号量的take通常在中断里不可用除非用FromISR版本而且一次信号量操作的代价是几十个周期加上可能的上下文切换用它来保护一个 32 位计数器成本高得离谱。我的判断标准很简单保护的是几个字节的数据、操作只有一两条语句、调用方包含中断服务程序——用临界区或者原子指令保护的是一段较长的逻辑比如文件操作、协议栈状态迁移、涉及阻塞等待——用互斥量或信号量。把这两类混用要么性能崩掉要么死锁。还有一个 RTOS 特有的坑taskENTER_CRITICAL()只能在任务上下文里用在中断里必须用taskENTER_CRITICAL_FROM_ISR()而且临界区的嵌套计数保存在任务控制块里中断里调用会读到错误的计数值。这类 API 用错现象是系统跑一段时间后莫名卡死堆栈回溯还看不出问题。3.5 选型对照表把上面几种方案按维度拉平对比选型时直接查表会快很多方案适用内核单次开销实时性影响适用数据规模主要风险关中断PRIMASK全系列低十几周期大屏蔽全部1~8 字节临界区过长导致丢中断BASEPRI 屏蔽M3/M4/M7/M33低中按优先级分层1~8 字节优先级数值方向搞反LDREX/STREXM3/M4/M7/M23/M33中可能重试无1~4 字节高中断率下活锁位带操作M3/M4极低无单比特M7/M0 不支持C11 原子取决于工具链中无1~8 字节M0 上链接失败信号量/互斥量全系列需 RTOS高含调度无任意中断中误用、优先级反转表格里适用数据规模这一列要特别留意超过 32 位的数据除了用 RTOS 互斥量或者双缓冲加序号校验没有特别优雅的办法第 4.4 节会讲具体做法。4. 工程实操把原子操作写进真实代码4.1 编译环境与选项准备动手之前先把工具链确认清楚这一步能省掉后面一半的调试时间。用 GCC 的话-stdgnu11或-stdc11打开 C11 支持如果要使用stdatomic.h需要确认 newlib 版本足够新用__atomic_*内建函数则不需要头文件但要注意-mcpu参数必须和实际内核匹配否则工具链可能生成错误的指令序列。比如-mcpucortex-m4和-mcpucortex-m0生成的原子内建展开结果完全不同。用 AC6基于 Clang的话__atomic_*内建是支持的stdatomic.h也基本可用。用 AC5 的话走__sync_*或者 CMSIS 的__LDREXW/__STREXW更稳妥。这里有个实操技巧写完原子操作代码后用arm-none-eabi-objdump -d把对应的.o文件反汇编出来看一眼确认生成的确实是ldrex/strex而不是一个bl __atomic_fetch_add_4这一步花三十秒能避免上线后才发现链接了空实现。再补一个容易忽略的配置优化等级。-O0下代码不会被重排很多并发问题藏得住开到-O2或-Os之后编译器开始大展拳脚之前能跑的代码可能就挂了。所以原子相关的代码一定要在最终发布的优化等级下测试别在-O0下调通了就以为万事大吉。4.2 计数器与标志位的三种写法计数器是最常见的场景。假设有一个串口接收字节计数的需求中断里自增主循环里读取并清零。写法一关中断static volatile uint32_t s_rx_bytes; static uint32_t s_primask; void USART1_IRQHandler(void) { /* ... 读数据 ... */ __disable_irq(); s_rx_bytes; __enable_irq(); }这个写法在中断里其实没必要关中断中断里不会被同优先级打断除非有更高优先级的中断也会改这个变量。真正的必要性在于主循环的读并清零uint32_t take_rx_bytes(void) { uint32_t v; uint32_t pm __get_PRIMASK(); __disable_irq(); v s_rx_bytes; s_rx_bytes 0; __set_PRIMASK(pm); return v; }如果不加这层保护主循环刚读完s_rx_bytes、还没来得及清零中断又加了一个字节清零操作就会把这个字节的记录抹掉。这类读后清操作是典型的必须原子的复合操作比单纯的自增更容易出错。写法二用__atomic内建static atomic_uint s_rx_bytes; void USART1_IRQHandler(void) { atomic_fetch_add_explicit(s_rx_bytes, 1, memory_order_relaxed); } uint32_t take_rx_bytes(void) { /* 用 exchange 一步完成读旧值并写 0 */ return atomic_exchange_explicit(s_rx_bytes, 0, memory_order_acquire); }atomic_exchange正好对应读并清零这个语义硬件上用LDREX/STREX循环实现比关中断优雅而且不会拉长中断延迟。写法三标志位场景。如果只是一个有新数据的布尔标志其实不需要原子操作——单写者单读者、32 位对齐的情况下读写本身就是原子的加个volatile防止编译器缓存就够了。但如果是置位并检查之前是否已置位这种复合语义就必须用atomic_exchange或者atomic_fetch_or。我见过一个案例中断里判断如果标志已经是 1 就丢弃数据主循环里读标志并清零两边都用普通赋值结果在高负载下会丢包——根因就是判断和置位不是一个原子动作。4.3 单生产者单消费者环形缓冲区串口、SPI、DMA 收数据的场景环形缓冲区几乎必用。如果只有一个生产者比如 DMA 或中断和一个消费者主循环可以做到完全无锁代价是缓冲区大小必须是 2 的幂方便用掩码取模。核心思路是让读写指针各由一个执行者独占写生产者的head只有中断改消费者的tail只有主循环改。判断空满时读对方的指针读到旧值也没关系最坏情况是延迟一拍不会出错。#define BUF_SIZE 256 #define BUF_MASK (BUF_SIZE - 1) static uint8_t s_buf[BUF_SIZE]; static volatile uint32_t s_head; /* 只由生产者写 */ static volatile uint32_t s_tail; /* 只由消费者写 */ /* 生产者中断上下文 */ bool ring_put(uint8_t byte) { uint32_t head s_head; uint32_t next (head 1) BUF_MASK; if (next s_tail) { return false; /* 满了 */ } s_buf[head] byte; __DMB(); /* 保证数据先写入再更新 head */ s_head next; return true; } /* 消费者主循环上下文 */ bool ring_get(uint8_t *out) { uint32_t tail s_tail; if (tail s_head) { return false; /* 空了 */ } __DMB(); /* 保证先看到 head再读数据 */ *out s_buf[tail]; s_tail (tail 1) BUF_MASK; return true; }这段代码的要点在于那两条__DMB()。没有它们编译器可能把s_buf[head] byte挪到s_head next之后消费者就会读到还没写入的数据。在 Cortex-M7 这种带写缓冲的内核上硬件也可能让写操作乱序完成DMB是必须的。用 C11 的话把s_head和s_tail声明成atomic_uint用memory_order_release写、memory_order_acquire读语义等价且更清晰。这个结构有一个前提必须满足真的只有一个生产者、一个消费者。如果两个中断都往同一个缓冲区写s_head就有了两个写者上面的分析全部失效必须加锁。另外s_head和s_tail如果放在同一个缓存行里在带 D-Cache 的 M7 上会互相踢缓存虽然单核不会有假共享的性能问题但 DMA 一致性维护时会被波及把它们分开放或者手动对齐到 32 字节边界是个好习惯。4.4 64 位数据与结构体的原子化封装32 位内核处理 64 位数据比如编码器累计计数、时间戳、累计流量时读写必然是两次 32 位访问中间可能被插入。atomic_ullong在 M3/M4 上会用LDREX/STREX对实现但那要求内存里有一个额外的锁变量而且并发性能一般。工程上更常见的做法是序号校验typedef struct { volatile uint32_t seq; /* 奇数表示正在写偶数表示稳定 */ uint32_t lo; uint32_t hi; } safe_u64_t; void set_u64(safe_u64_t *s, uint64_t v) { s-seq; /* 变奇数 */ __DMB(); s-lo (uint32_t)v; s-hi (uint32_t)(v 32); __DMB(); s-seq; /* 变偶数 */ } uint64_t get_u64(safe_u64_t *s) { uint32_t seq1, seq2; uint64_t v; do { seq1 s-seq; if (seq1 1u) continue; /* 正在写重试 */ __DMB(); v ((uint64_t)s-hi 32) | s-lo; __DMB(); seq2 s-seq; } while (seq1 ! seq2); return v; }这个模式叫序列锁优点是不需要关中断、写者不会阻塞读者、读者重试概率极低缺点是写者必须单写而且读者在极端情况下可能一直重试概率很小但理论上存在。适合一次写、多次读的场景比如系统运行时间、累计里程这种。如果数据结构是普通的struct多个字段要一起更新而且更新频率不高我的建议反而是老老实实关中断或者用双缓冲加指针交换。为了追求无锁而把代码写得别人看不懂维护成本远超那点性能收益。4.5 DMA 与 Cache 场景的额外注意事项用 DMA 搬运数据的型号比如带以太网、SDMMC、大容量 ADC 的上原子操作和 DMA 之间还有一层关系要理清。DMA 是独立的总线主设备它访问内存不受 CPU 的LDREX/STREX约束也不受中断屏蔽影响。所以指望用原子操作去和 DMA 抢同一个缓冲区是行不通的必须靠协议设计要么让 DMA 和 CPU 操作不同的缓冲区双缓冲要么用 DMA 的传输完成中断作为同步点。带 D-Cache 的型号如 Cortex-M7 系列更麻烦。CPU 写完描述符、启动 DMA 之前必须把 Cache 里的数据清出去SCB_CleanDCache_by_Addr否则 DMA 读到的是内存里的旧数据DMA 接收完成后CPU 读数据之前必须把对应 Cache 行无效化SCB_InvalidateDCache_by_Addr否则读到的是 Cache 里的旧值。这两个调用前后要有__DSB()保证内存访问真正完成。我在一个高速采集项目上就因为漏了清理这一步现象是 DMA 收到的数据前几十个字节永远是对的后面全是上一次的残留——查了两天才定位到 Cache。提示如果 DMA 缓冲区和普通变量放在同一块 SRAM 区域Cache 无效化操作可能把邻近变量的未写回数据一起丢掉。稳妥的做法是把 DMA 缓冲区单独放到一个按 32 字节对齐的段里并在链接脚本中给它独立的位置。还有一种情况是部分双核型号提供的硬件信号量外设它用寄存器级别的原子读改写给两个核提供互斥用法和普通的软件标志位类似但由硬件保证原子。如果你的型号恰好有用它比软件方案省心没有的话跨主设备的互斥只能靠协议或者外设本身的支持别硬凑。5. 踩坑实录与排查清单5.1 volatile 到底能保证什么关于volatile的误解太多值得单独拎出来说。它能保证三件事每次读都从内存取不从寄存器缓存每次写都真的写回内存不被优化掉多个volatile访问之间不会被编译器重排顺序这条其实也不是完全可靠严格来说 C 标准只保证volatile访问相对于其他volatile访问的顺序。它不能保证操作是原子的中断不会在中间插入多核之间的可见性编译器不会把非volatile变量重排到volatile访问附近。实践中的判断标准是只要这个变量可能被当前执行流之外的东西修改中断、DMA、另一个任务就应该加volatile但只要涉及读-改-写加了volatile之后依然需要原子保护。两个条件互不替代。我见过有人把环形缓冲区的head加了volatile就认为万事大吉结果在多中断写入的场景下依然丢数据——因为他忽略了head有两个写者。5.2 典型故障现象与排查路径把常见问题整理成一张表遇到类似现象时可以快速对照现象可能原因排查方法计数值偶发偏小自增非原子被中断覆盖反汇编看是否三条指令用atomic_fetch_add替换标志位改了但没生效编译器把赋值优化掉或读写顺序错乱加volatile和编译器屏障看反汇编同组 GPIO 其他引脚状态乱跳用|操作 ODR位带或 BSRR 更合适改用BSRR或位带别名位带宏在新型号上跑飞Cortex-M7 无位带别名区查内核型号改用BSRR或普通写临界区嵌套后中断全关用__enable_irq而非恢复PRIMASK改成保存/恢复PRIMASK原子自增代码偶发卡顿高优先级中断频繁打断STREX 反复失败缩短中断周期或改用关中断DMA 数据部分正确D-Cache 未清理或未无效化加CleanDCache/InvalidateDCacheM0 上链接报__atomic_*未定义内核无独占指令libatomic 未提供改用关中断实现排查这类问题的通用套路是三看一看反汇编确认生成的指令和你想的一致二看时序用 GPIO 翻转加示波器把临界区的进入和退出打出来能直观看到关中断时长和中断延迟三看压力把中断频率、任务负载调到极限原子性问题几乎都是被压出来的正常测试跑不出来不代表没有。我一般的做法是在开发阶段就故意把相关中断频率提高五到十倍跑一段时间能提前暴露大部分竞态。5.3 性能开销实测与取舍经验最后聊点实际数字虽然不同型号差异不小但量级上有参考价值。在 168MHz 的 M4 上一次__disable_irq()加__enable_irq()的组合算上流水线冲刷大概十几个周期换算下来不到 0.1 微秒一次LDREX/STREX成功路径大约十几到二十个周期失败重试一次翻倍位带写和普通写开销基本相同一条STR的时间。这意味着什么一个 20kHz 的中断周期 50 微秒如果你在里面加了 0.1 微秒的关中断占用率只有 0.2%完全无感。但如果临界区里有函数调用、有除法、有内存拷贝很容易拉长到几微秒占用率就上到 10% 以上通信误码开始出现。所以我的原则是能确定临界区不超过 10 条指令就放心用关中断超过就换方案别抱侥幸心理。还有一条经验不要为了零开销过度设计。我见过一个项目为了实现无锁队列写了三百多行带内存序的代码最后性能反而不如关中断版本因为LDREX/STREX的重试在高中断率下把收益吃光了还引入了两个难以复现的 bug。原子操作是工具不是信仰单核 MCU 上关中断 极短临界区能解决 90% 的问题剩下 10% 才需要上独占指令或者无锁结构。判断标准是临界区长度和中断频率而不是哪种方案更高级。另外提醒一句关于测试的体会并发问题在实验室里几乎测不出来因为实验室的时序太干净了。真正有效的验证方式是在代码里临时插入随机延时、人为拉长中断处理时间、把优化等级开到最高制造最恶劣的时序环境。我在几个项目里都是这么干的虽然麻烦但比在现场被客户追着问为什么偶尔丢数据要舒服得多。如果后续要扩展这套原子操作的封装其实可以再往上抽一层做成一个统一的osal_atomic.h内部按内核型号用条件编译切换实现M0 走关中断、M3/M4/M7 走独占指令上层业务代码只调atomic_inc、atomic_exchange这些语义化的接口将来换型号或者换工具链只改一个头文件就够了。这个做法我在两个跨型号的产品线上用过移植时确实省了不少事。
技术路径与产业应用分析)
