FreeRTOS移植

FreeRTOS移植
THEDI手动移植
非常麻烦,上网查
快速移植
使用STM32CubeMX快速移植,下面主要讲需要注意的地方:
内核版本选择
STM32CubeMX使用的接口并不是原生的FreeRTOS的接口,而是在此基础上进行封装的过后的通用的RTOS的API。具体区别如下:
特点 | FreeRTOS原生接口 | CMSIS-RTOS接口(V1/V2) |
---|---|---|
设计者 | FreeRTOS作者 | ARM公司 |
可移植性 | 只能用在FreeRTOS | 只要有适配层,可换RTOS |
API名称 | xTaskCreate , vTaskDelay |
osThreadNew , osDelay |
文档参考 | FreeRTOS官方文档 | ARM CMSIS-RTOS文档 |
CubeMX生成 | 原生接口不生成适配层 | CubeMX自动生成适配层代码 |
生态适配 | 多数FreeRTOS例程 | 适合中间件/跨平台通用库 |
在中间件中可以找到FREERTOS,但是此时有内核版本CMSIS_V1
和CMSIS_V2
CMSIS_V1
:大多数情况下V1就够用了
CMSIS_V2
:V2比V1其实就是内核版本更高,功能更多了而已
TimeBase-时基选择
使用FreeRTOS的时候,需要把HAL库的时基(TimeBase Source)
,切换为除了SysTick以外的任意TIM
为什么需要更换HAL的时基?
裸机开发
:HAL库时基默认使用的SysTick(1ms中断计数1次),我们的HAL_Delay就是基于SysTick来延时的
操作系统(FreeRTOS等)
:OS由于需要处理任务调度
、时间片轮转
、延时
,也需要占用SysTick作为调度器的时基,并且会使SysTick的中断优先级很低,保证任务调度机制正常工作,不会抢占其他中断服务程序
。所以使用操作系统的时候就可能会出现OS和HAL共同使用SysTick的情况,这种情况下由于SysTick优先级很低,在高优先级中断中调用HAL_Delay就会卡死。
推荐做法
:使用TIM外设产生HAL心跳,systick产生freertos的心跳,HAL是不依赖于OS API的一套硬件操作接口。我们修改HAL库的时基为其他TIM,让FreeRTOS默认使用SysTick是最好的选择,HAL库的延时等可以通过TIM实现
配置完成后我们可以看到:
HAL_Init中的HAL_InitTick对时基的配置变成了TIM1
,而不是SysTick:
而FreeRTOS中默认使用SysTick
作为时基: