直接用std::atomic切换指针会丢数据，因指针切换不保证内容可见性与完整性；需配合memory_order_release/acquire内存序及fence屏障，且缓冲区须cache line对齐、状态用atomic_flag单次触发管理。
为什么直接用 std::atomic 切换指针还不够
很多开发者一上来就写：std::atomic<uint8_t> current_buffer{buffer_a}</uint8_t>，收完一帧就 current_buffer.store(buffer_b)。这看似“无锁”，但实际会丢数据或读到半写状态。根本原因在于：指针切换只是表层动作，真正危险的是缓冲区内容的可见性与完整性。CPU 可能重排写入指令，编译器可能把 buffer_b 的填充过程优化成非顺序写，而读线程看到指针已切，却读到未填完、甚至全零的内存块。必须配合 std::atomic_thread_fence(std::memory_order_release) 在写完后加一道屏障，再用 std::memory_order_acquire 在读前确保看到全部写入结果。
std::atomic_flag 管理缓冲区状态比布尔标志更可靠
用 volatile bool buffer_a_ready 或 std::atomic<bool></bool> 表示“Buffer A 已就绪”看似简单，但在多核环境下存在竞态窗口：写线程刚设为 true，读线程还没来得及读取，写线程又开始清空 Buffer A —— 状态被覆盖。正确做法是用 std::atomic_flag 模拟单次触发信号：
- 每个缓冲区配一个独立的
std::atomic_flag ready_flag{ATOMIC_FLAG_INIT} - 写线程完成填充后调用
ready_flag.test_and_set(std::memory_order_release)，仅当返回false时才算首次置位成功 - 读线程用
ready_flag.test(std::memory_order_acquire)轮询，成功后才开始读；读完立即ready_flag.clear(std::memory_order_relaxed)
这样避免了“重复置位丢失”和“误判未就绪”两类典型问题。
缓冲区大小必须对齐且禁止跨 cache line 拆分
在 Cortex-M4/M7 或 RISC-V 嵌入式平台，若 BUFFER_SIZE 是 1024 字节但起始地址是 0x20001003，那它会横跨两个 cache line（通常 32 字节）。DMA 写入时可能只刷了前半行 cache，CPU 读取后半行就拿到旧数据。解决方案只有两个：
立即学习“C++免费学习笔记（深入）”；
- 用
alignas(32)强制缓冲区按 cache line 对齐：alignas(32) uint8_t buffer_a[BUFFER_SIZE]; - 确保
BUFFER_SIZE是 cache line 长度的整数倍，例如 1024、2048，而非 1000 或 1536
不满足这两点，哪怕 fence 和 flag 全对，也大概率在实机跑出间歇性数据错乱。
FreeRTOS 下别碰 std::thread，改用任务句柄 + 队列通知
C++11 的 std::thread 在裸机或 FreeRTOS 上不可用，硬链接会失败。正确路径是：写线程绑定到 HAL 的 DMA 中断回调（如 HAL_ADC_ConvCpltCallback），读线程是一个优先级更高的 FreeRTOS 任务。两者通信不能靠共享变量轮询，而应使用 xQueueSendFromISR 向队列发通知消息（比如发送 static_cast<void>(buffer_a)</void>），读任务用 xQueueReceive 阻塞等待。这样既避开轮询功耗，又规避了中断上下文里调用复杂 C++ 对象的风险。
最易被忽略的一点：缓冲区切换不是原子操作，而是“写完成 → 发通知 → 读开始 → 清状态”四步链。任何一步被中断打断都可能卡死，所以每步之间必须有明确的状态检查和超时保护，而不是依赖“应该很快”。
