当前位置：首页 > news >正文

第 11 章：HSEM 硬件信号量与无锁队列——解决优先级反转

news 2026/5/12 9:22:37

在第 10 章中，我们实现了基于 OpenAMP 的标准通讯。但在工业级实时控制中，OpenAMP 的包处理机制（Buffer 拷贝、中断路由、协议栈封装）在高频数据传输下会占用不少 M33 的 CPU 周期。

如果你需要以10kHz的速率同步 IMU 数据，或者在 M33 写入数据时绝不希望被 A35 侧的逻辑“卡住”（即避免优先级反转），我们就需要动用 MP257 的硬件利器：HSEM (Hardware Semaphore)。

11.1 为什么需要硬件信号量？

在多核共享内存（DDR）时，如果 M33 正在写数据，A35 同时读，就会导致数据错乱。

传统互斥锁的问题：如果 A35 抢占了锁但因为 Linux 内核调度延迟没释放，M33 就会在原地自旋（Spinlock）等待，失去了实时性。
HSEM 的优势：它是总线级别的硬件仲裁。M33 尝试Take锁，如果失败可以立即跳过执行其他逻辑，或者通过硬件状态位瞬时判断，不产生任何软件开销。

11.2 实战：HSEM 的原子操作

在 M33 侧，我们使用 HSEM 来保护关键的“写指针”。

#include "stm32mp2xx_hal.h"

#define IMU_HSEM_ID 0 // 使用第 0 号硬件信号量

uint8_t Try_Lock_Shared_Resource(void) {
/* 尝试获取信号量：单次非阻塞尝试 */
/* MasterID 为 1 (M33), ProcessID 设为 0 */
if (HAL_HSEM_Take(IMU_HSEM_ID, 0) == HAL_OK) {
return 1; // 锁定成功
}
return 0; // 锁定失败，被 A35 占用中
}

void Unlock_Shared_Resource(void) {
HAL_HSEM_Release(IMU_HSEM_ID, 0);
}

11.3 深度实战：无锁环形队列 (Lock-free SPSC Queue)

为了追求极致性能，我们通常采用单生产者单消费者 (SPSC)模型。

生产者 (M33)：只负责更新Head指针。
消费者 (A35)：只负责更新Tail指针。
原理：由于指针更新是原子操作，且双方只写自己的指针，因此在单向传输 IMU 数据时，甚至可以完全不需要加锁。

1. 共享内存结构定义

/* 映射到第 7 章定义的 0x90000000 区域 */
typedef struct {
volatile uint32_t head; // M33 更新
volatile uint32_t tail; // A35 更新
IMU_RawData_t data[256]; // 环形缓冲区
} LockFreeQueue_t;

LockFreeQueue_t *imu_queue = (LockFreeQueue_t *)0x90000000;

2. M33 极致推流代码

void Push_IMU_Data_Fast(IMU_RawData_t *new_data) {
uint32_t next_head = (imu_queue->head + 1) % 256;

/* 检查队列是否已满 */
if (next_head != imu_queue->tail) {
// 直接写入 DDR
imu_queue->data[imu_queue->head] = *new_data;

/* 内存屏障：确保数据写入完成后再更新指针 */
__DSB();

imu_queue->head = next_head;

/* 触发一次 IPCC 通知 A35 有新数据 (可选，或让 A35 轮询) */
}
}