FreeRtos——5、资源模型：临界区与共享资源
前言
在掌握了“数据流”和“控制流”之后，我们来到了嵌入式开发中最容易发生“翻车”的地带：资源竞争。
如果你的代码在任务 A 里正在通过 I2C 发送 10 个字节，发到一半，任务 B（高优先级）强行插入并抢走 I2C 的控制权，去读取另一个传感器，那么 I2C 总线上的波形就会彻底崩掉。
1. 为什么你的 I2C/SPI 总线会无故死锁？
重入冲突：外设驱动（如 HAL 库）内部通常有状态机，不能在未完成时被重入调用。
优先级反转：任务 C（低）占着串口，任务 A（高）死等串口，结果任务 B（中）跑出来把任务 C 抢占了，导致 A 实际上在等 B。
效率低下：频繁开关中断会导致系统失去实时性。
2. 知识点：保护资源的三种境界
第一重：原子操作与关中断（最硬核的锁）
应用：修改一个简单的全局标志位或计数器。
手段：
taskENTER_CRITICAL()。它直接关闭所有可屏蔽中断。代价：整个世界都停了。如果这里逻辑太长，你的系统时钟滴答都会丢失。
第二重：互斥锁（Mutex）
应用：保护硬件外设（I2C/SPI/文件系统）。
手段：
osMutexAcquire。它支持优先级继承，是 RTOS 中保护资源的正规军。
第三重：守护任务模式（Gatekeeper） —— 老鸟的首选
理念：“既然大家都要抢，那就谁也别直接碰，找个管家管起来”。
优点：资源操作被完全串行化，不存在竞争，且方便添加缓存逻辑。
3. 实操：构建一个串口“守护任务”
场景：我们不再让每个任务都去调用HAL_UART_Transmit，而是建立一个PrintServer任务。
3.1 守护任务的实现
/* 定义日志消息结构 */ typedef struct { char *str; uint32_t value; } LogEntry_t; osMessageQueueId_t LogQueueHandle; //消息队列ID void StartLogGatekeeperTask(void *argument) { LogEntry_t log; LogQueueHandle = osMessageQueueNew(16, sizeof(LogEntry_t), NULL); //创建消息队列 for(;;) { // 阻塞等待：只有有人要打印时，管家才干活 if (osMessageQueueGet(LogQueueHandle, &log, NULL, osWaitForever) == osOK) { // 在这里统一操作硬件，不存在竞争 printf("[LOG] %s: %d\r\n", log.str, log.value); } } }3.2 客户端任务的调用
void StartAppTask(void *argument) { LogEntry_t myLog = {"Temp", 25}; for(;;) { // 投递即走，不阻塞自己的逻辑去等串口发送，将要打印的Log写入队列 osMessageQueuePut(LogQueueHandle, &myLog, 0, 0); osDelay(1000); } }4. 进阶：互斥锁保护 SPI 总线
如果你必须在多个任务里直接操作外设（比如复杂的屏驱），请使用互斥锁。
osMutexId_t SpiMutexHandle; void Init_Resources(void) { // 互斥锁必须在任务开始前创建 SpiMutexHandle = osMutexNew(NULL); } void Access_Spi_Device(void) { // 1. 拿钥匙 if (osMutexAcquire(SpiMutexHandle, osWaitForever) == osOK) { // 2. 独占操作硬件 // HAL_SPI_Transmit(&hspi1, data, size, 100); // 3. 还钥匙 osMutexRelease(SpiMutexHandle); } }5. 思考：读写锁模型
有时候我们允许多个任务“读”参数（如配置信息），但只允许一个任务“写”。
实操技巧：这种场景可以用计数信号量（Counting Semaphore）模拟，或者使用互斥锁保护一个读计数器。
原则：写者必须拿到最高权限，读者可以并存。