STM32 FreeRTOS实战：CAN通信、Flash存储与PI控制封装总结

1. 项目缘起与整体设计思路

1.1 为什么会有这个“V1封装”的念头

做嵌入式这行十来年，我经手的STM32项目少说也有几十个。早期做项目基本是“一竿子捅到底”——裸机写while(1)，中断里塞逻辑，全局变量满天飞。这种写法在功能单一的小项目上跑得挺欢，但只要需求稍微复杂一点，比如要同时处理CAN通信、Flash存储、多路传感器采集，代码就会迅速变成一团乱麻。改一个功能，牵动三个模块；加一个任务，时序全乱。V1项目最初也是这个路子，STM32F103加几个外设，裸机跑得还行。但到了后期，需求加上了CAN总线数据交互、参数掉电保存、多路闭环控制，裸机架构明显扛不住了。

于是就有了这个“V1封装与总结”的念头。说白了，就是把V1阶段踩过的坑、验证过的方案、沉淀下来的代码结构，做一次系统性的封装和复盘。核心目标很明确：用FreeRTOS把任务调度管起来，用CAN总线做设备间通信，用Flash存关键参数，用PI控制器做闭环调节，最后把这四块整合成一个可复用的工程框架。这个框架不是给实验室演示用的，是要能直接拿到下一个项目里改改就能跑的。

1.2 整体架构的取舍逻辑

架构设计这块，我纠结最久的是“要不要上RTOS”。裸机加状态机也能实现多任务效果，但状态机嵌套深了之后，调试难度指数级上升。FreeRTOS的好处在于，任务之间通过队列、信号量、事件组通信，逻辑边界清晰，每个任务只管自己的事。坏处也明显：RAM开销上去了，栈空间分配不好容易溢出，中断优先级和任务优先级的关系得捋清楚。权衡下来，V1项目的外设数量和实时性要求已经到了裸机吃力的程度，上FreeRTOS是划算的。

CAN总线这块，STM32自带的bxCAN控制器够用，不需要外挂芯片。CAN的优势在于差分信号抗干扰强，多节点通信天然支持仲裁，适合设备间中等速率的数据交换。Flash存储选的是STM32内部Flash，省去外部存储芯片的成本和布线麻烦，但要注意擦写寿命和扇区对齐问题。PI控制器用在电机转速或者温度闭环上，比纯比例控制稳态误差小，比PID调参简单，适合V1阶段快速验证。

整个V1封装的核心思路就是：任务分层、通信解耦、参数持久化、控制闭环。FreeRTOS负责任务调度和资源管理，CAN负责对外通信，Flash负责参数保存，PI负责执行层面的闭环调节。四者各司其职，通过队列和信号量串联起来。

1.3 适合谁来参考这套方案

这套封装方案适合几类人：一是刚接触STM32和FreeRTOS的开发者，想看看实际项目里任务怎么划分、优先级怎么定；二是做工业控制、车载设备、智能硬件的工程师，需要CAN通信和参数存储的参考实现；三是在做毕业设计或者课程项目的同学，V1这套框架结构清晰，改起来不费劲。如果你还在裸机阶段徘徊，或者FreeRTOS移植完了不知道怎么用，这篇总结应该能帮你省不少时间。

提示：V1封装不是万能模板，它是针对“中等复杂度、多外设、有通信和存储需求”的场景设计的。如果你的项目只是点个灯、读个传感器，裸机反而更合适。

2. FreeRTOS任务划分与优先级设计

2.1 任务划分的底层逻辑

FreeRTOS用起来不难，难的是任务怎么切。切得太细，任务间通信开销大，调度器频繁切换上下文，CPU利用率反而下降；切得太粗，又回到了裸机那种大循环里塞逻辑的老路。V1项目里我最终切了五个任务：系统监控任务、CAN通信任务、Flash存储任务、PI控制任务、人机交互任务。

系统监控任务优先级最低，负责喂狗、统计各任务栈使用情况、监测CPU占用率。这个任务不参与实时控制，但它是整个系统的“体检医生”，一旦发现某个任务栈快满了或者CPU负载异常，能及时报警。CAN通信任务优先级中等偏上，因为CAN报文有实时性要求，接收中断触发后要尽快处理。Flash存储任务优先级最低，因为Flash擦写耗时较长，放在低优先级任务里慢慢做，不阻塞其他任务。PI控制任务优先级最高，闭环控制对时序敏感，必须保证每个控制周期准时执行。人机交互任务优先级中等，处理按键、显示刷新这些对实时性要求不高的操作。

这里有个经验：任务优先级不要照搬理论，要根据实际时序需求来定。我见过有人把串口打印任务设成最高优先级，结果打印一多，控制任务全被挤掉了。V1项目里，PI控制任务的周期是1ms，CAN接收处理要求在2ms内完成，Flash写入可以容忍100ms的延迟。优先级排序就是按这个容忍度来的。

2.2 任务间通信的三种方式

FreeRTOS提供了队列、信号量、事件组、任务通知等多种通信机制。V1项目里主要用了三种：队列传数据、二值信号量同步中断、互斥量保护共享资源。

队列用得最多。CAN任务收到报文后，解析出控制指令，通过队列发给PI控制任务。PI控制任务算完输出后，通过另一个队列把状态数据发给CAN任务，由CAN任务打包发送。队列的好处是自带阻塞机制，发送方和接收方不需要忙等，CPU利用率高。队列长度要估算好，太短了容易丢数据，太长了占RAM。V1项目里CAN接收队列设了16个元素，每个元素是一个结构体，包含CAN ID、数据长度、数据内容，总共占不了多少RAM。

二值信号量主要用在中断和任务之间同步。CAN接收中断里释放信号量，CAN任务里获取信号量，这样中断服务程序尽量短，耗时的解析和处理放到任务里做。这里要注意：中断里只能调用带FromISR后缀的API，比如xSemaphoreGiveFromISR，普通版本在中断里调用会出问题。

互斥量用来保护共享资源，比如Flash操作。Flash存储任务在写Flash时，其他任务不能同时读写同一块区域。互斥量确保同一时间只有一个任务能操作Flash。互斥量和二值信号量的区别在于，互斥量有优先级继承机制，能减少优先级翻转的影响。

2.3 栈空间分配与溢出检测

FreeRTOS任务栈空间分配是个容易踩坑的地方。栈给少了，任务跑着跑着就HardFault；栈给多了，RAM不够用。V1项目里我的做法是：先给一个保守值，跑起来后用uxTaskGetStackHighWaterMark查剩余栈空间，再逐步调整。

具体来说，PI控制任务因为要做浮点运算和调用数学库，栈给了512字（注意FreeRTOS里栈的单位是字，不是字节，STM32上是4字节）。CAN通信任务栈给了256字。Flash存储任务因为要调用Flash擦写函数，栈给了384字。系统监控任务和人机交互任务各给了256字。跑稳定后查HighWaterMark，发现PI控制任务还剩100多字，说明512字够用但不算宽裕，后续加功能要留意。

栈溢出检测在FreeRTOSConfig.h里配置。V1项目里开了configCHECK_FOR_STACK_OVERFLOW=2，这个级别会在任务切换时检查栈指针是否越界，比级别1更严格。检测到溢出后会调用vApplicationStackOverflowHook，在这个钩子函数里可以点亮错误灯或者记录日志。实测下来，级别2对性能影响很小，建议都开上。

注意：栈溢出检测只能检测到“栈指针越界”，不能检测到“栈使用接近上限但还没越界”的情况。所以HighWaterMark的定期检查不能省。

2.4 中断优先级与任务优先级的配合

STM32的中断优先级和FreeRTOS的任务优先级是两套体系，搞混了会出大问题。Cortex-M内核的中断优先级数值越小优先级越高，FreeRTOS的任务优先级数值越大优先级越高。更关键的是，FreeRTOS的临界区保护依赖于BASEPRI寄存器，如果某个中断的优先级高于configMAX_SYSCALL_INTERRUPT_PRIORITY，那么这个中断里不能调用任何FreeRTOS的API。

V1项目里，CAN接收中断的优先级设成了5（数值），configMAX_SYSCALL_INTERRUPT_PRIORITY设成了5。这意味着CAN中断的优先级等于阈值，可以调用FromISR版本的API。SysTick中断优先级设成最低（15），因为SysTick只负责任务调度，不需要抢占其他中断。串口中断优先级设成6，高于阈值，所以串口中断里不能调用FreeRTOS API，只能做纯数据搬运。

这里有个口诀：中断里要调FreeRTOS API，优先级数值必须大于等于configMAX_SYSCALL_INTERRUPT_PRIORITY。记不住的话，就把所有中断优先级都设成比阈值大，虽然牺牲了一点实时性，但不会出玄学问题。

3. CAN总线通信的封装与实现

3.1 CAN协议栈的裁剪与配置

STM32的bxCAN控制器功能很全，但V1项目里用不到那么多。我裁剪后的配置是：波特率500kbps、正常模式、自动重传开启、接收过滤器用标识符列表模式。500kbps在40米以内的双绞线上跑很稳，再高就要考虑线材和终端电阻了。自动重传开启是因为V1项目对可靠性要求高，丢一帧可能影响控制效果。接收过滤器用列表模式，只接收特定ID的报文，减少CPU中断次数。

CAN初始化的步骤：先使能GPIO和CAN时钟，配置GPIO为复用推挽输出（CAN_TX）和浮空输入（CAN_RX），然后配置CAN_Mode、CAN_SJW、CAN_BS1、CAN_BS2、CAN_Prescaler这些参数。波特率计算公式是：波特率 = APB1时钟 / (Prescaler * (1 + BS1 + BS2))。V1项目里APB1是36MHz，Prescaler设4，BS1设15，BS2设2，算下来36M / (4 * (1+15+2)) = 500kbps。SJW设1，同步跳转宽度为1个时间单元。

过滤器配置这块，V1项目用了两个过滤器组。过滤器组0接收ID为0x100到0x103的标准帧，映射到FIFO0；过滤器组1接收ID为0x200的扩展帧，映射到FIFO1。FIFO0的中断优先级高于FIFO1，因为0x100系列是控制指令，0x200是状态查询，实时性要求不同。

3.2 报文收发与队列对接

CAN报文的收发在V1项目里封装成了两个函数：CAN_SendMessage和CAN_ReceiveHandler。发送函数接收CAN ID、数据指针、长度，填充发送邮箱后等待发送完成。接收处理函数在中断里调用，从FIFO读取报文，释放信号量通知CAN任务。

CAN任务的主体是一个无限循环，等待接收信号量，然后从FIFO读取报文，解析后根据ID分发。ID为0x100的报文是速度设定值，解析后通过队列发给PI控制任务；ID为0x101是参数配置报文，解析后通过队列发给Flash存储任务；ID为0x200是状态查询，CAN任务直接组装状态数据回复。

这里有个细节：CAN报文的字节序要统一。V1项目里所有多字节数据都用小端模式，和STM32的内存布局一致，解析时直接memcpy就行，不用做字节序转换。如果和上位机通信，上位机那边也要按小端解析，否则数据会错乱。

队列对接这块，CAN任务和PI控制任务之间用了两个队列：一个发设定值，一个回状态值。队列元素是结构体，包含时间戳、数据类型、数值。时间戳用于计算通信延迟，调试时很有用。队列满时，发送方可以选择阻塞等待或者直接丢弃。V1项目里设定值队列满了就覆盖最旧的数据，因为最新的设定值才是有效的；状态值队列满了就丢弃，因为状态数据丢一帧不影响控制。

3.3 错误处理与总线恢复

CAN总线出问题的时候，排查起来比串口麻烦。V1项目里我加了错误处理和总线恢复机制。CAN控制器有三种错误状态：错误主动、错误被动、总线关闭。错误主动时正常通信，错误被动时发送会延迟，总线关闭时完全不能通信。

总线关闭的恢复流程：检测到CAN_ESR寄存器的BOFF位被置位后，先清除BOFF位，然后等待128次11个隐性位的时间，再重新初始化CAN控制器。V1项目里把这个流程放在系统监控任务里，每100ms检查一次CAN状态，发现总线关闭就执行恢复。实测下来，总线关闭多半是接线问题或者终端电阻缺失，恢复机制只能救急，根本解决还得查硬件。

错误计数器的监控也很重要。CAN_ESR里的TEC和REC分别记录发送和接收错误计数。TEC超过255时进入总线关闭，REC超过127时进入错误被动。V1项目里在调试阶段把TEC和REC打印出来，发现TEC涨得快说明发送有问题，通常是ACK错误或者位填充错误；REC涨得快说明接收有问题，可能是波特率不匹配或者干扰太大。

实操心得：CAN总线两端必须各接一个120欧姆终端电阻，中间节点不要接。我见过有人每个节点都焊了终端电阻，结果总线负载太重，通信距离大幅缩短。

4. Flash参数存储的封装与寿命管理

4.1 内部Flash的扇区规划

STM32F103的内部Flash按页擦除，每页1KB或2KB（根据型号不同）。V1项目用的是STM32F103C8T6，64KB Flash，每页1KB。程序代码占用了前48KB，剩下的16KB用来存参数。我把这16KB分成两个区域：参数区A和参数区B，各8KB。参数区A存当前有效参数，参数区B存备份参数。写入时先擦除备份区，写入新参数，验证成功后更新有效区标志。这样即使写入过程中断电，至少有一个区的数据是完整的。

参数结构体设计成固定长度，包含魔数、版本号、参数数组、CRC校验值。魔数用来判断Flash是否被擦除过（擦除后全是0xFF），版本号用于参数升级时的兼容处理，CRC校验确保数据完整性。V1项目里参数结构体总共256字节，8KB的扇区能存32份，但我只用了前两份做A/B备份，剩下的空间预留给后续扩展。

4.2 擦写流程与掉电保护

Flash写入的流程是：解锁、擦除、写入、上锁。擦除前要确保目标扇区没有正在执行的代码，否则会HardFault。V1项目里Flash操作全部放在Flash存储任务里，这个任务优先级最低，不会打断其他任务。擦除一页1KB大约需要20ms到40ms，这段时间CPU可以调度其他任务，但Flash存储任务本身会阻塞。

掉电保护是Flash存储的难点。V1项目里的做法是：先写备份区，再写有效标志。具体流程是：擦除备份区，写入新参数到备份区，读取备份区数据做CRC校验，校验通过后在有效区写入一个“备份有效”标志，最后擦除有效区并写入新参数。如果任何一步断电，上电后检查有效区和备份区的标志和CRC，选择完整的那份数据恢复。

这个流程听起来繁琐，但实测下来很稳。我做过断电测试，在写入过程中随机断电100次，参数没有丢失过。代价是写入耗时增加了一倍，但参数保存不是高频操作，这点开销可以接受。

4.3 磨损均衡与寿命估算

STM32内部Flash的擦写寿命是10000次。如果参数每分钟保存一次，一天1440次，不到一周就写坏了。V1项目里参数保存不是定时触发的，而是事件触发：只有在参数真正改变时才保存，比如用户通过CAN修改了设定值。正常使用下，一天可能就保存几次，寿命完全够用。

如果确实需要高频保存，可以用磨损均衡：把参数区当成环形缓冲区，每次写入下一个扇区，记录写入位置。V1项目里预留了这个机制，但实际没用上。因为参数保存频率低，而且Flash写坏之前，设备可能早就因为其他原因退役了。

注意：Flash擦除后数据是0xFF，写入只能把1变成0，不能把0变成1。所以写入前必须先擦除。如果忘记擦除直接写，写入的数据会是旧数据和新数据的按位与，结果不可预测。

5. PI控制器的参数整定与实现

5.1 PI控制的基本原理与离散化

PI控制器由比例项和积分项组成。比例项响应当前误差，积分项消除稳态误差。连续域的PI公式是：u(t) = Kp * e(t) + Ki * ∫e(t)dt。在数字控制器里，积分项用累加实现，离散化后的公式是：u(k) = Kp * e(k) + Ki * Ts * Σe(j)，其中Ts是控制周期。

V1项目里控制周期是1ms，Ts=0.001。Kp和Ki的整定用了试凑法：先把Ki设0，逐渐增大Kp直到系统开始振荡，然后取振荡时Kp的60%作为最终Kp；再逐渐增大Ki，直到稳态误差在可接受范围内。实测下来，电机转速控制的Kp=2.5，Ki=0.8效果不错，超调量小于5%，调节时间约200ms。

积分饱和是PI控制常见的问题。当误差持续存在时，积分项会一直累加，导致输出超出执行机构范围。V1项目里加了积分限幅：积分项累加值限制在[-1000, 1000]之间，对应输出限幅的±10%。这样即使误差很大，积分项也不会无限增长，退出饱和时不会有过大的超调。

5.2 定点数与浮点数的选择

STM32F103没有硬件浮点单元，浮点运算靠软件模拟，速度慢。V1项目里PI控制器最初用浮点实现，1ms的控制周期里浮点运算占了600us，CPU负载偏高。后来改成定点数实现，用Q15格式（1位符号位，15位小数位），运算速度提升了3倍多，控制周期里PI运算只占180us。

Q15格式的乘法要注意溢出：两个Q15数相乘结果是Q30，需要右移15位变回Q15。右移时要做饱和处理，防止溢出。V1项目里封装了Q15的乘加函数，用STM32的SMULL指令做64位中间结果，然后饱和到32位。实测下来，定点数PI的控制效果和浮点数几乎没差别，但CPU负载低了很多。

如果控制精度要求不高，也可以用Q10或Q12格式，整数部分留更多位，防止大数值溢出。V1项目里误差范围是±1000，Q15格式的整数部分只有1位，不够用，所以实际用的是Q12格式（3位整数，12位小数），范围±8，精度0.0002，够用了。

5.3 控制周期的保障与抖动处理

PI控制对周期稳定性要求高，周期抖动会导致积分项计算不准。V1项目里PI控制任务用vTaskDelayUntil实现精确周期。vTaskDelayUntil和vTaskDelay的区别在于：vTaskDelay是“延迟指定时间”，实际周期是“延迟时间+任务执行时间”；vTaskDelayUntil是“延迟到指定时刻”，周期严格等于设定值。

实测下来，vTaskDelayUntil的周期抖动在±10us以内，vTaskDelay的抖动可能到±100us。对于1ms的控制周期，10us的抖动可以接受，100us就太大了。所以PI控制任务必须用vTaskDelayUntil。

如果系统负载突然升高，PI控制任务可能错过执行时刻。V1项目里加了错过补偿：如果发现当前时刻已经超过预定时刻，就跳过这次控制，等下一个周期。跳过会导致控制输出保持上一次的值，短时间内影响不大，总比乱序执行好。

6. 常见问题与排查技巧实录

6.1 FreeRTOS相关的问题

问题一：任务跑不起来，程序卡在启动调度器之前。最常见的原因是栈空间不够，任务创建失败。检查xTaskCreate的返回值，如果是errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY，说明堆空间不够。V1项目里configTOTAL_HEAP_SIZE设了10KB，五个任务加队列和信号量，用了大约6KB，还剩4KB余量。

问题二：任务运行一段时间后HardFault。多半是栈溢出。开configCHECK_FOR_STACK_OVERFLOW=2，在vApplicationStackOverflowHook里打印出错任务名。V1项目里遇到过一次，是CAN任务里调用了printf，栈需求比预期大，把栈从256字加到384字就好了。

问题三：中断里调用FreeRTOS API导致死机。检查中断优先级是否高于configMAX_SYSCALL_INTERRUPT_PRIORITY。如果是，要么降低中断优先级，要么把API调用移到任务里。V1项目里串口中断最初优先级设成4，高于阈值5，调用xQueueSendFromISR时死机，改成6就好了。

6.2 CAN通信相关的问题

问题一：CAN发送失败，TEC持续增长。检查终端电阻是否接好，波特率是否匹配，CAN_H和CAN_L是否接反。V1项目里遇到过一次，两个节点波特率一个500k一个250k，TEC涨到255进入总线关闭。

问题二：CAN接收不到数据，REC不增长。检查过滤器配置是否正确，FIFO是否使能，接收中断是否开启。V1项目里过滤器掩码模式配错了，把不需要的ID也过滤进来了，导致FIFO溢出。

问题三：CAN通信偶尔丢帧。检查队列长度是否够用，中断处理是否太长。V1项目里CAN接收队列最初设了8个元素，高速通信时偶尔丢帧，加到16个就好了。

6.3 Flash操作相关的问题

问题一：Flash写入后读出来是0xFF。忘记擦除了。Flash写入前必须先擦除，擦除后数据是0xFF，写入才能把1变成0。

问题二：Flash擦除时程序跑飞。擦除的扇区里有正在执行的代码。检查链接脚本，确保参数区不在代码区范围内。V1项目里参数区从0x0800C000开始，代码区到0x0800BFFF结束，刚好错开。

问题三：Flash数据偶尔损坏。写入过程中断电了。用A/B备份加CRC校验，上电后自动恢复完整的那份数据。

6.4 PI控制相关的问题

问题一：系统振荡，输出忽大忽小。Kp太大或者Ki太大。先减小Ki，如果振荡消失说明是积分项的问题；如果还在振荡，减小Kp。

问题二：稳态误差消不掉。Ki太小或者积分限幅太紧。适当增大Ki或者放宽积分限幅。

问题三：控制输出有毛刺。误差信号有噪声。在误差计算前加一阶低通滤波，截止频率设为控制频率的1/10。V1项目里加了滤波后，输出毛刺明显减少。

实操心得：调试FreeRTOS项目时，把configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS打开，用vTaskList打印任务状态，能快速定位哪个任务卡住了。这个功能占一点RAM和Flash，但调试阶段非常值。

7. V1封装的代码组织与复用建议

7.1 目录结构与模块划分

V1项目的代码目录分成五层：硬件层、驱动层、系统层、应用层、配置层。硬件层放STM32的启动文件、链接脚本、寄存器定义。驱动层放CAN、Flash、GPIO、定时器的初始化代码。系统层放FreeRTOS的配置和移植文件。应用层放任务函数和业务逻辑。配置层放全局宏定义和参数结构体。

这种分层的好处是复用方便。下一个项目如果还是STM32F103，硬件层和系统层直接拷贝；如果换了STM32F407，硬件层要改，驱动层和系统层基本不动；如果只是应用逻辑变了，只改应用层就行。V1项目里我把驱动层和系统层做成了静态库，应用层单独编译链接，这样代码管理更清晰。

7.2 接口设计与命名规范

模块间的接口用头文件暴露，内部实现放在C文件里。命名规范统一用模块名_函数名的格式，比如CAN_SendMessage、Flash_WriteParams、PI_Update。全局变量加g_前缀，静态变量加s_前缀，宏定义全大写。

队列和信号量的句柄统一放在一个全局结构体里，比如g_SystemResources，里面包含xQueueCANRx、xQueueCANTx、xSemaphoreCANRx等。这样初始化和使用的时候一目了然，不会出现句柄满天飞的情况。

7.3 移植到新项目的检查清单

把V1封装移植到新项目时，按这个清单过一遍：时钟配置改了吗？GPIO引脚改了吗？CAN波特率改了吗？Flash扇区地址改了吗？任务栈大小够吗？队列长度够吗？中断优先级对吗？这八个问题检查完，基本就能跑起来了。

V1项目里我遇到过移植后CAN不工作的情况，查了半天发现是新项目的APB1时钟是42MHz不是36MHz，波特率算错了。所以时钟配置一定要先确认，波特率、定时器周期、串口波特率都依赖时钟。

7.4 后续扩展的方向

V1封装目前只做了基础功能，后续可以扩展的方向不少。比如加OTA升级，通过CAN总线接收固件包，写入Flash的备份区，重启后跳转到新固件。加文件系统，用外部SPI Flash存日志数据。加Modbus协议栈，通过串口和上位机通信。加看门狗任务，独立监控各任务的心跳。

但扩展之前，先把V1的稳定性跑透。我见过太多项目，基础功能还没测稳就急着加新功能，最后问题叠问题，排查起来痛苦不堪。V1封装的价值在于它提供了一个经过验证的起点，在这个起点上做加法，比从零开始搭要靠谱得多。

最后分享一个小技巧：在系统监控任务里加一个“任务心跳”机制，每个任务定期更新一个计数器，监控任务检查计数器是否在预期时间内变化。如果某个任务的心跳停了，说明它卡住了，可以触发报警或者重启。这个机制在V1项目里帮我提前发现了好几次潜在的死锁问题。