STM32嵌入式控制平台V1：FreeRTOS与CAN总线整合实战

1. 项目缘起与整体设计思路1.1 为什么会有这个V1项目这个V1项目说白了就是一个基于STM32的综合性嵌入式控制平台核心任务是把几个平时分散在不同demo里的功能模块——FreeRTOS任务调度、CAN总线通信、Flash参数存储、PI闭环控制——整合到一个能跑、能维护、能扩展的工程框架里。做这个项目的直接动机很简单之前每个功能都是单独验证的单独跑都稳一旦合到一起就各种打架任务优先级冲突、CAN中断抢占导致PI计算周期抖动、Flash写入时任务阻塞……这些问题不解决后面根本没法往上叠功能。所以V1的目标不是做多炫的功能而是把地基打牢。它适合谁参考如果你正在做基于STM32的毕业设计、工控板卡、电机控制或者车载节点需要一套能直接抄作业的工程骨架那这个总结对你有用。如果你只是点个灯跑个串口那可能用不上但里面关于FreeRTOS和CAN配合的坑看看也不亏。1.2 整体架构是怎么定的架构定下来之前我纠结了很久核心矛盾在于裸机跑还是上RTOS。裸机的好处是时序确定、没有任务切换开销但坏处是随着功能增加主循环会变成一锅粥PI控制、CAN收发、Flash存储全挤在一起任何一个环节耗时长了都会拖累其他环节。上FreeRTOS的好处是解耦每个功能一个任务优先级明确坏处是引入了调度开销和资源竞争问题。最终选FreeRTOS理由有三个。第一PI控制需要严格周期用vTaskDelayUntil能保证周期稳定裸机靠定时器中断虽然也行但一旦主循环里有Flash写入这种耗时操作周期就崩了。第二CAN接收是异步事件用任务队列的方式处理比中断里直接干活安全得多。第三Flash存储需要在不影响控制的前提下后台进行任务化之后可以放到低优先级慢慢写。整体架构分四层硬件抽象层HAL库封装、驱动层CAN、Flash、定时器、服务层PI控制器、参数管理、应用层任务调度与业务逻辑。这个分层不是摆设后面调试的时候你就知道好处了——换芯片只需要改HAL层PI算法调参不用碰驱动。1.3 关键选型背后的考量为什么用CAN而不是串口CAN的差分信号抗干扰能力强多节点组网方便而且报文自带ID和CRC比串口自己定协议省事。工控和车载场景基本是标配。为什么用PI而不是PID这个项目控制的是温度/速度这类一阶惯性系统D项对噪声极其敏感实际调下来PI就够用加了D反而抖。这不是说PID不好而是要看被控对象。为什么Flash用内部而不是外挂STM32内部的Flash虽然擦写次数有限一般1万次左右但存参数这种低频写入场景完全够用。外挂SPI Flash虽然容量大但增加了硬件成本和驱动复杂度V1阶段没必要。为什么PI周期定在10ms这个是根据被控对象的时间常数来的。被控对象响应时间在百毫秒级别按照采样周期取时间常数的1/10到1/20的经验法则10ms是合理值。太快了CPU浪费太慢了控制品质下降。2. 核心模块的细节拆解与实操要点2.1 FreeRTOS任务划分与优先级设计任务划分是这个项目的骨架划不好后面全是坑。我最终分了五个任务任务名称优先级周期/触发方式栈大小职责ControlTask4最高10ms周期512字PI计算、PWM输出CanRxTask3队列阻塞512字解析CAN报文、更新设定值CanTxTask2100ms周期384字上报状态、心跳ParamTask1事件触发512字Flash读写参数MonitorTask0最低500ms周期384字状态指示、看门狗喂狗优先级设计的原则是周期越短、实时性要求越高的任务优先级越高。ControlTask必须最高因为PI计算延迟直接影响控制品质。CanRxTask次之因为接收到的设定值要尽快生效。ParamTask放低优先级Flash写入慢就慢点不能阻塞控制。这里有个容易踩的坑中断优先级和任务优先级是两码事。CAN接收中断的优先级NVIC里配的必须高于configMAX_SYSCALL_INTERRUPT_PRIORITY否则在中断里调用xQueueSendFromISR会触发断言。我一开始没注意这个CAN一收数据就进HardFault查了半天。// CAN中断优先级配置数值越小优先级越高 HAL_NVIC_SetPriority(CAN1_RX0_IRQn, 5, 0); // FreeRTOSConfig.h中 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 5 // 中断优先级必须 5数值上否则不能在中断里调FreeRTOS API注意STM32的NVIC优先级数值越小优先级越高而FreeRTOS的configMAX_SYSCALL_INTERRUPT_PRIORITY是个阈值中断优先级数值必须大于等于这个阈值才能安全调用FromISR接口。这个逻辑和直觉相反特别容易搞错。2.2 CAN通信的报文设计与过滤CAN通信这块报文ID的设计直接决定了后期扩展性。我用的是扩展帧29位ID拆成几段高8位表示节点地址中间8位表示功能码低13位表示数据索引。这样过滤的时候可以用掩码只匹配功能码不用关心具体节点。// 报文ID定义 #define CAN_ID_SETPOINT 0x01000000 // 设定值下发 #define CAN_ID_STATUS 0x02000000 // 状态上报 #define CAN_ID_PARAM_WR 0x03000000 // 参数写入 #define CAN_ID_PARAM_RD 0x04000000 // 参数读取过滤器配置是另一个坑。STM32的CAN外设有14个过滤器组可以配成掩码模式或列表模式。我只需要接收特定几个ID用掩码模式最省资源CAN_FilterTypeDef filter; filter.FilterBank 0; filter.FilterMode CAN_FILTERMODE_IDMASK; filter.FilterScale CAN_FILTERSCALE_32BIT; filter.FilterIdHigh 0x0100; // 期望ID的高16位 filter.FilterIdLow 0x0000; filter.FilterMaskIdHigh 0xFF00; // 只匹配高8位功能码 filter.FilterMaskIdLow 0x0000; filter.FilterFIFOAssignment CAN_RX_FIFO0; filter.FilterActivation ENABLE;这样配置后只要功能码是0x01的报文都能进来节点地址不关心。后期增加节点不用改过滤器扩展性拉满。CAN接收中断里只做一件事把报文丢进队列然后立刻退出。解析工作放到CanRxTask里做。为什么因为中断里干活时间越长系统响应越差而且解析过程中如果用到浮点运算中断上下文里做浮点操作在某些编译器配置下会出问题。void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; BaseType_t xHigherPriorityTaskWoken pdFALSE; HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, rxData); // 只做入队不做解析 xQueueSendFromISR(canRxQueue, rxHeader, xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }2.3 Flash参数存储的磨损均衡与掉电保护Flash存储这块STM32内部Flash的擦写寿命是个硬约束。F4系列一般标称1万次擦写F1系列也是1万次左右。如果每次参数变化都擦写一次按每天改100次算100天就报废了。所以必须做磨损均衡。我的做法是把Flash的一个扇区比如16KB分成多个页轮流写入。每次写新参数写到下一个空闲页写满整个扇区后再统一擦除。这样擦除次数降低到原来的1/NN是页数。具体实现#define FLASH_SECTOR_ADDR 0x08010000 // 扇区起始地址 #define FLASH_PAGE_SIZE 0x800 // 2KB一页 #define FLASH_PAGE_COUNT 8 // 8页一个扇区 typedef struct { uint32_t magic; // 0x5A5A5A5A表示有效 uint32_t version; ParamStruct params; uint32_t crc; } FlashPage_t; // 写入时找第一个magic无效的页 uint32_t FindFreePage(void) { for (int i 0; i FLASH_PAGE_COUNT; i) { uint32_t addr FLASH_SECTOR_ADDR i * FLASH_PAGE_SIZE; if (*(uint32_t*)addr ! 0x5A5A5A5A) { return addr; } } return 0; // 需要擦除 }掉电保护是另一个重点。参数写入过程中如果掉电可能写到一半下次上电读到的是坏数据。解决办法是双备份CRC校验每次写入前先算好CRC写入后回读校验只有校验通过才更新有效标志。上电时从后往前找第一个CRC正确的页找不到就用默认参数。实操心得Flash写入前必须先擦除而擦除是按扇区的不能按页擦。所以磨损均衡的粒度是页但擦除的粒度是扇区。设计的时候要算好一个扇区能放多少页写满后统一擦。另外擦除期间CPU会阻塞F4系列擦一个16KB扇区大概几百毫秒到一秒这段时间控制任务会停摆。我的做法是把Flash操作放到ParamTask里优先级最低而且擦除前先暂停ControlTask的输出擦完再恢复。2.4 PI控制器的离散化实现与抗积分饱和PI控制器理论公式很简单u(t) Kpe(t) Ki∫e(t)dt。但离散化实现的时候有几个细节决定成败。首先是积分项的离散化方式。我用的是后向差分I(k) I(k-1) KiTe(k)其中T是采样周期。这种方式比前向差分稳定不容易振荡。typedef struct { float Kp; float Ki; float T; // 采样周期单位秒 float integral; // 积分累积 float out_max; // 输出上限 float out_min; // 输出下限 float last_error; } PIController; float PI_Update(PIController *pi, float setpoint, float feedback) { float error setpoint - feedback; // 比例项 float p_term pi-Kp * error; // 积分项先累加 pi-integral pi-Ki * pi-T * error; // 抗积分饱和如果输出超限停止积分累积 float output p_term pi-integral; if (output pi-out_max) { output pi-out_max; pi-integral - pi-Ki * pi-T * error; // 回退积分 } else if (output pi-out_min) { output pi-out_min; pi-integral - pi-Ki * pi-T * error; } pi-last_error error; return output; }抗积分饱和是必须做的。没有这个当设定值突变或者反馈丢失时积分项会一直累积到无穷大等误差反向时输出要很久才能拉回来表现为系统反应迟钝。上面的代码用的是回退法检测到输出饱和就把这次积分增量减掉。参数整定我用的临界比例度法先把Ki设为0Kp从小往大加直到系统出现等幅振荡记下此时的Kp为Ku振荡周期为Tu。然后按经验公式Kp0.45KuKi0.54Ku/Tu。这个方法比试凑法快但要注意振荡不能太剧烈否则可能损坏执行机构。注意PI的采样周期必须和任务周期严格一致。我用vTaskDelayUntil保证10ms周期实测抖动在几十微秒以内。如果用vTaskDelay周期会随任务执行时间漂移PI参数就白整了。3. 实操过程与核心环节实现3.1 工程搭建与FreeRTOS移植工程搭建我用的是STM32CubeMX生成基础框架然后手动加FreeRTOS源码。CubeMX虽然能直接生成FreeRTOS工程但版本往往偏旧而且配置项藏得深不如自己移植可控。移植步骤从FreeRTOS官网下载源码把Source目录下的tasks.c、queue.c、list.c、timers.c、event_groups.c、stream_buffer.c加到工程。把portable/RVDS/ARM_CM4FF4系列或对应内核的端口文件加进来。把FreeRTOSConfig.h放到include路径下逐项配置。FreeRTOSConfig.h的关键配置#define configUSE_PREEMPTION 1 // 抢占式调度 #define configUSE_TIME_SLICING 1 // 同优先级时间片轮转 #define configCPU_CLOCK_HZ 168000000 // F4主频168MHz #define configTICK_RATE_HZ 1000 // 1ms一个tick #define configMAX_PRIORITIES 7 #define configMINIMAL_STACK_SIZE 128 #define configTOTAL_HEAP_SIZE (20 * 1024) // 20KB堆 #define configUSE_MUTEXES 1 #define configUSE_COUNTING_SEMAPHORES 1 #define configCHECK_FOR_STACK_OVERFLOW 2 // 栈溢出检测 #define configUSE_MALLOC_FAILED_HOOK 1 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 5configTICK_RATE_HZ设1000意味着1ms一个tick10ms周期就是10个tick。这个值不能太高否则中断太频繁影响性能也不能太低否则周期精度不够。栈溢出检测我开了级别2会在任务切换时检查栈指针是否越界。配合vApplicationStackOverflowHook回调一旦溢出就打印任务名并停机方便定位。void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { printf(Stack overflow in task: %s\r\n, pcTaskName); taskDISABLE_INTERRUPTS(); for(;;); }3.2 CAN通信的完整收发流程CAN的初始化分几步GPIO配置、CAN外设配置、过滤器配置、启动。F4系列的CAN挂在APB1上时钟是42MHz。void CAN_Init(void) { hcan1.Instance CAN1; hcan1.Init.Prescaler 6; // 42MHz / 6 7MHz hcan1.Init.Mode CAN_MODE_NORMAL; hcan1.Init.SyncJumpWidth CAN_SJW_1TQ; hcan1.Init.TimeSeg1 CAN_BS1_12TQ; // 12个时间单元 hcan1.Init.TimeSeg2 CAN_BS2_2TQ; // 2个时间单元 hcan1.Init.TimeTriggeredMode DISABLE; hcan1.Init.AutoBusOff ENABLE; hcan1.Init.AutoWakeUp DISABLE; hcan1.Init.AutoRetransmission ENABLE; hcan1.Init.ReceiveFifoLocked DISABLE; hcan1.Init.TransmitFifoPriority DISABLE; HAL_CAN_Init(hcan1); // 过滤器配置 CAN_FilterTypeDef filter {0}; filter.FilterBank 0; filter.FilterMode CAN_FILTERMODE_IDMASK; filter.FilterScale CAN_FILTERSCALE_32BIT; filter.FilterIdHigh 0x0100; filter.FilterIdLow 0x0000; filter.FilterMaskIdHigh 0xFF00; filter.FilterMaskIdLow 0x0000; filter.FilterFIFOAssignment CAN_RX_FIFO0; filter.FilterActivation ENABLE; HAL_CAN_ConfigFilter(hcan1, filter); HAL_CAN_Start(hcan1); HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); }波特率计算42MHz / 6 7MHz一个位时间 1 12 2 15个时间单元波特率 7MHz / 15 ≈ 466.7kbps。实际想要500kbps的话Prescaler设542/58.4MHz8.4/15560kbps不对。重新算500kbps需要位时间 42MHz / 500k 84个时钟周期。Prescaler6时间单元7MHz位时间15个单元7M/15466.7k。要精确500kPrescaler5时间单元8.4MHz位时间16.8个单元取17个单元11428.4M/17494kbps接近。或者Prescaler76MHz位时间12个单元1926M/12500kbps正好。发送流程void CAN_SendStatus(uint8_t node_id, uint16_t status) { CAN_TxHeaderTypeDef txHeader; uint8_t txData[8]; uint32_t txMailbox; txHeader.ExtId CAN_ID_STATUS | (node_id 16); txHeader.IDE CAN_ID_EXT; txHeader.RTR CAN_RTR_DATA; txHeader.DLC 2; txHeader.TransmitGlobalTime DISABLE; txData[0] status 8; txData[1] status 0xFF; HAL_CAN_AddTxMessage(hcan1, txHeader, txData, txMailbox); }3.3 PI闭环的调试过程记录PI调试我分了三个阶段开环验证、纯比例、加积分。开环验证先不接反馈手动给固定输出观察被控对象的响应。这一步是为了确认硬件没问题传感器读数正确执行机构能动。我当时的被控对象是个加热片给50%占空比温度从25度升到60度用了大概3分钟说明加热功率和散热基本平衡。纯比例Ki0Kp从0.1开始加。Kp0.1时温度稳定在55度设定60度有稳态误差。Kp0.5时稳定在58度误差缩小。Kp1.0时开始有轻微振荡周期大概20秒。Kp1.5时振荡明显周期15秒。所以临界Kp在1.2左右Ku1.2Tu18秒。加积分按公式Kp0.451.20.54Ki0.541.2/180.036。实际调的时候发现响应偏慢把Kp加到0.8Ki加到0.05响应快了超调大概5%能接受。最终参数Kp0.8Ki0.05T0.01秒。调试过程中用串口把设定值、反馈值、输出值实时打出来用曲线工具看波形。没有曲线工具的话至少要把数据打到串口助手里肉眼观察趋势。实操心得PI调试最忌讳一上来就同时调Kp和Ki两个参数互相影响根本不知道谁在起作用。一定要先把Ki关掉调KpKp差不多了再加Ki。另外积分时间常数TiKp/Ki我最终Ti0.8/0.0516秒和振荡周期18秒接近符合经验。3.4 Flash参数管理的完整实现参数管理模块对外提供三个接口Param_Init、Param_Read、Param_Write。内部维护一个RAM缓存读的时候直接读缓存写的时候先写缓存再异步写Flash。typedef struct { float Kp; float Ki; float setpoint; uint32_t can_node_id; uint32_t can_baudrate; uint8_t reserved[32]; } ParamStruct; static ParamStruct g_params; static uint32_t g_current_page_addr; void Param_Init(void) { // 从Flash加载 for (int i FLASH_PAGE_COUNT - 1; i 0; i--) { uint32_t addr FLASH_SECTOR_ADDR i * FLASH_PAGE_SIZE; FlashPage_t *page (FlashPage_t*)addr; if (page-magic 0x5A5A5A5A) { uint32_t crc CRC32((uint8_t*)page-params, sizeof(ParamStruct)); if (crc page-crc) { memcpy(g_params, page-params, sizeof(ParamStruct)); g_current_page_addr addr; return; } } } // 没有有效页用默认值 Param_LoadDefault(); g_current_page_addr 0; } void Param_Write(ParamStruct *new_params) { memcpy(g_params, new_params, sizeof(ParamStruct)); // 发消息给ParamTask异步写Flash xQueueSend(paramWriteQueue, g_params, 0); }ParamTask收到写请求后void ParamTask(void *argument) { ParamStruct params; for (;;) { if (xQueueReceive(paramWriteQueue, params, portMAX_DELAY) pdTRUE) { uint32_t addr FindFreePage(); if (addr 0) { // 扇区满了擦除 HAL_FLASH_Unlock(); FLASH_Erase_Sector(FLASH_SECTOR_4, VOLTAGE_RANGE_3); HAL_FLASH_Lock(); addr FLASH_SECTOR_ADDR; } FlashPage_t page; page.magic 0x5A5A5A5A; page.version 1; memcpy(page.params, params, sizeof(ParamStruct)); page.crc CRC32((uint8_t*)params, sizeof(ParamStruct)); HAL_FLASH_Unlock(); // 按字写入 uint32_t *src (uint32_t*)page; for (int i 0; i sizeof(FlashPage_t)/4; i) { HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr i*4, src[i]); } HAL_FLASH_Lock(); g_current_page_addr addr; } } }注意STM32的Flash写入必须按半字16位或字32位对齐不能按字节写。而且写入前目标地址必须是擦除状态0xFF否则写入会失败。我一开始没注意对齐写进去的数据全是乱的。4. 常见问题与排查技巧实录4.1 FreeRTOS相关的问题问题一任务创建后不运行现象是xTaskCreate返回pdPASS但任务函数里的打印一句都不出。排查思路先确认调度器启动了vTaskStartScheduler()再确认任务优先级没有超过configMAX_PRIORITIES最后检查栈大小是不是太小导致任务一启动就溢出。我遇到过一次是栈给了128字512字节但任务里有个大数组一进去就溢出触发了溢出钩子函数。问题二中断里调用FreeRTOS API导致HardFault这个前面提过根因是中断优先级配置不对。STM32的NVIC优先级数值越小越高而FreeRTOS要求调用FromISR接口的中断优先级数值必须大于等于configMAX_SYSCALL_INTERRUPT_PRIORITY。我一开始把CAN中断优先级设成1很高结果一收数据就挂。改成5就好了。问题三队列发送失败xQueueSend返回errQUEUE_FULL说明队列满了。要么是消费者任务优先级太低抢不到CPU要么是队列长度设太小。我的CanRxTask优先级是3队列长度设了16正常情况不会满。如果满了说明CAN报文来得太猛需要加大队列或者提高任务优先级。问题现象可能原因排查方法解决方案任务不运行调度器未启动检查vTaskStartScheduler调用启动函数任务不运行栈溢出开栈溢出检测加大栈或优化局部变量中断进HardFault中断优先级错误检查NVIC配置优先级数值≥5队列满消费者太慢看任务优先级提高优先级或加长队列周期抖动大用了vTaskDelay检查延时函数改用vTaskDelayUntil4.2 CAN通信相关的问题问题一CAN发不出去mailbox一直满CAN发送需要等待总线空闲如果总线上没有其他节点应答发送会一直重试。检查AutoRetransmission是不是开了开了的话发不出去会一直重发。另外确认波特率对不对波特率不匹配的话总线上全是错误帧。问题二收不到特定ID的报文过滤器配置问题。STM32的过滤器有14个组但FIFO只有两个。如果多个过滤器组指向同一个FIFO只有第一个生效。我一开始配了两个过滤器组都指向FIFO0结果第二个死活不生效。后来改成FIFO0和FIFO1分开就好了。问题三CAN总线错误计数增长用HAL_CAN_GetError读错误码。如果REC接收错误计数增长说明接收有问题可能是波特率偏差或者终端电阻没接。CAN总线两端必须各接一个120欧姆终端电阻中间节点不接。我调试的时候忘了接终端电阻短距离通信勉强能通一长就全是错误。4.3 Flash与PI相关的问题Flash写入失败最常见的原因是目标地址没擦除。STM32的Flash只能把1写成0不能把0写成1。写入前必须确保地址是0xFF。另外写入过程中不能被打断如果开了中断中断里又操作Flash会冲突。我的做法是Flash操作期间关中断。PI输出振荡先检查采样周期是否稳定用示波器看PWM输出周期。如果周期抖动大先解决周期问题。周期没问题的话降低Kp或者增大Ti。还有一种可能是反馈信号噪声大需要加滤波。我在反馈通道加了个一阶低通滤波截止频率10Hz振荡明显改善。参数保存后重启丢失检查CRC计算是否正确以及写入后有没有回读校验。我遇到过一次是CRC算的时候用了错误的长度导致每次校验都失败上电加载时直接跳过有效页用了默认值。避坑技巧Flash操作前一定要先解锁HAL_FLASH_Unlock()操作完立刻上锁HAL_FLASH_Lock()。忘记上锁的话后续任何Flash操作都会失败。另外擦除和写入之间最好加个延时等Flash内部电荷泵稳定。5. 项目封装与后续扩展方向5.1 代码封装的组织方式V1的代码组织我按功能分目录每个模块一个文件夹对外只暴露一个头文件。比如CAN模块can_driver.c和can_driver.h头文件里只放函数声明和必要的宏内部实现细节全部藏起来。这样做的目的是降低耦合后面换CAN芯片或者改协议只需要改驱动层上层不用动。Project/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── Drivers/ │ ├── STM32F4xx_HAL_Driver/ │ └── CMSIS/ ├── Middlewares/ │ └── FreeRTOS/ ├── App/ │ ├── can_app.c/h │ ├── flash_app.c/h │ ├── pi_app.c/h │ └── task_config.c/h └── Bsp/ ├── bsp_can.c/h ├── bsp_flash.c/h └── bsp_timer.c/hApp层放业务逻辑Bsp层放硬件相关。PI控制器放在App层因为它不依赖具体硬件。CAN和Flash的底层操作放在Bsp层换芯片只改这层。5.2 后续可以扩展的方向V1跑通之后后面可以往上叠的东西不少。第一个方向是加LVGL做本地显示把状态和参数显示在屏幕上用FreeRTOS的任务跑LVGL刷新注意LVGL不是线程安全的要么在同一个任务里刷要么加互斥锁。第二个方向是加网络通信用LWIP或者别的协议栈把数据传到上位机这个对RAM要求高F4系列要外扩SRAM才够。第三个方向是多轴控制把PI控制器实例化多份每个轴一个任务CAN报文里区分轴号。不过这些都是后话V1先把基础打牢。我个人的体会是嵌入式项目最怕的就是地基没打好就往上堆功能堆到后面全是补丁改一个地方崩三个地方。V1花时间把任务划分、优先级、通信协议、参数管理这些基础做扎实后面加功能就是搭积木。最后分享一个小技巧调试的时候在MonitorTask里加一个命令解析通过串口可以实时查看每个任务的栈使用情况、CPU占用率、队列水位。这些数据平时不看一出问题就是救命稻草。void MonitorTask(void *argument) { for (;;) { // 打印各任务栈剩余 printf(ControlTask stack free: %u\r\n, uxTaskGetStackHighWaterMark(controlTaskHandle)); printf(CanRxTask stack free: %u\r\n, uxTaskGetStackHighWaterMark(canRxTaskHandle)); // 打印CPU占用率需要开configGENERATE_RUN_TIME_STATS vTaskDelay(pdMS_TO_TICKS(5000)); } }这个uxTaskGetStackHighWaterMark返回的是任务运行过程中栈剩余的最小值单位是字。如果这个值小于50说明栈快满了得赶紧加。我一开始ControlTask栈给了256字跑起来发现水位只剩20赶紧加到512才稳。