电子说
一、理解CMSIS-RTOS
现在网上很多资料和文章实际上都没有讲清楚CMSIS-RTOS这个东西,但理解它的原理构成太重要了,所以我按自己的理解把RTOS这部分的架构整理了一下,如有问题欢迎指正。
1.什么是FreeRTOS?
**目前CubeMX支持的CMSIS-RTOS使用的第三方内核就是FreeRTOS **
FreeRTOS是一个开源的轻量级实时操作系统,目前在我国嵌入式市场占有很大份额。与μC/OS-2/3、embOS等商业系统相比,在进行产品级应用时更加便捷自由。如果你先前接触过乐鑫的esp模块的话现在对FreeRTOS一定有比较深入的了解。
2.什么是CMSIS?
CMSIS(Common Microcontroller Software Interface Standard)是ARM提出的一种 Cortex-M /A处理器系列的与供应商无关的硬件抽象层和软件接口层。
CMSIS的主要组件包含两个:
对STM32的CMSIS-RTOS来说,架构图中的Real Time Kernel 就是FreeRTOS(抽象层); CMSIS-CORE提供了硬件层的映射关系,与芯片型号有对应关系。
而CMSIS-RTOS API则实现了第三方实时内核API的再封装,与第三方实时内核有对应关系
综上,STM32CubeMX的 Middleware虽然使用了FreeRTOS,但部分函数其实已经经过封装了),※使用的是CMSIS API 及 FreeRTOS的原生API。
CMSIS-RTOS在用户的应用代码和第三方的RTOS Kernel直接架起一道桥梁,一个设计在不同的RTOS之间移植,或者在不同Cortex MCU直接移植的时候,如果两个RTOS都实现了CMSIS-RTOS,那么用户的应用程序代码完全可以不做修改。
二、项目文件解析
其中 Drivers/CMSIS文件夹主要存放Cortex内核及设备文件、微控制器专用启动代码/系统文件,即CMSIS-RTOS Core部分的内容。
※而Middleware文件夹中则是FreeRTOS API和封装的CMSIS API的声明和定义。
三、启用FreeRTOS
① 使用CubeMX的情况下配置FreeRTOS非常简单,生成的代码相对也比较规整:
界面选择CMSIS_V2,移植性更好
系统时钟源会与RTOS冲突,需更改。
②随后进入config param选项卡或者文件配置参数【保存在FreeRTOSConfig.h中】:
configUSE_PREEMPTION: 调度模式配置。配置为1时为抢占式调度,配置为0时为合作式调度。实时操纵系统为实现其功能,应当设置为1。
configUSE_MUTEXES:(※) 使用互斥锁功能(1开) 。 互斥锁的作用是实现多任务间共享资源的独占式处理,防止多线程同时访问操作同一资源发生错误。
configUSE_RECURSIVE_MUTEXES:(※) 使用递归互斥锁
对STM32硬件来说,中断优先级越高值越小。而对FreeRTOS,任务优先级越高值越大。
※中断屏蔽/分类管理
RTOS在cortex-M上的实现是通过软件方式实现的。拿CubeMX生成的代码来说,
main.c中执行完初始化代码后执行osKernelStart(),进入消息回环(Scheduler)。
因此,硬件中断仍然有效;虽然已经使用了RTOS,但对于一些特殊功能,例如运动急停、避障等还是必须依靠中断实现。这引来了两个问题;
首先是中断会影响任务执行。对此FreeRTOS提供了中断屏蔽的方法,采用类似蒙版的方式,利用BASEPRI寄存器对不同优先级的中断进行分类管理:
configPRIO_BITS: MCU使用的优先级位数 ,STM32有4位所以设置为4,对应0~15优先级;数值越小,优先级越高。不要修改
另外,系统默认使用组4的配置,即16个优先级均为抢占优先级。
configLIBRARY_LOWEST_INTERRUPT_PRIORITY: MCU的最低优先级, STM32为15。不要修改
configKERNEL_INTERRUPT_PRIORITY:*设置内核使用的中断优先级。默认设置为最低优先级(8位高位填补)。*无必要修改
configMAX_SYSCALL_INTERRUPT_PRIORITY* 优先级阈值转换,不要修改。*
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY:*配置FreeRTOS系统可管理的最大优先级。*对于cortex-M3取值为 0-15。
本项的意义在于,当中断的优先性等于或低于此值时,这类中断将由RTOS系统托管。 具体包括可被RTOS屏蔽,可以通过经RTOS托管的入口(函数名称相同)访问等;此类被接管的中断可以使用RTOS的部分API(FromISR的安全函数)。
而高于设定值优先级的中断则会照常执行,即*裸金属层的硬件级中断。*此类中断不能使用RTOS的API( 与RTOS系统运行平级,执行时中断了RTOS的运行) 。
一般使用RTOS时大部分中断都应由系统托管,使用RTOS不可控的硬件级中断容易导致执行错误和其他问题。CubeMX配置时也设置了限制。
CMSIS-RTOS控制中断开启关闭的函数为portDISABLE_INTERRUPTS()和portENABLE_INTERRUPTS(),两者定义在 portmacro.h中:
实际上是通过了宏定义的方式调用了RTOS的vPortRaiseBASEPRI()和vPortSetBASEPRI(0).
※延时函数的使用
在裸金属编程的时候,我们习惯使用LL_mDelay()和自定义的相似原理函数;而这在引入RTOS后会产生问题:
可以看到LL_mDelay()使用了SysTick计数器,调用时还会清零。而FreeRTOS用的时钟源就是SysTick。因此只要使用了CMSIS-RTOS,都不应使用利用Systick实现的延时函数。
当然 CMSIS和FreeRTOS也提供了相应的延时函数:
CMSIS API:
osStatus_t osDelay (uint32_t ticks); //延时ticks个心跳;基于vTaskDelay();
osStatus_t osDelayUntil (uint32_t ticks);//延时至心跳计数为ticks; 基于vTaskDelayUntil();
FreeRTOS API:
void vTaskDelay( const TickType_t xTicksToDelay );//定时(相对心跳数),并阻塞task
TickType_t xTaskGetTickCount();//返回系统此时心跳数
void vTaskDelayUntil( TickType_t * const pxPreviousWakeTime, const TickType_t xTimeIncrement );
//定时(相对心跳数),并阻塞task.
vTaskDelay()和vTaskDelayUntil()效果不同,vTaskDelay()延时是相对延时,如果执行中发生中断将会导致执行周期的延长等问题。而vTaskDelayUntil是绝对延时,相对执行更严格。
当处于延时中时,任务会进入阻塞状态,延时执行完毕后转入准备状态,等待系统****跳转运行(高优先先行),所以任务优先级不高的话执行时序也不能被严格保证。
※有关线程状态:
由此可见在使用RTOS的情况下,利用中断执行时序将变得非常复杂麻烦;中断延时一般只能通过__NOP__实现,严重影响系统效率,因此一般中断只用于改变标志位、状态位、硬件操作上,及时性的时序操作请利用中断联系信号机制实现。
全部0条评论
快来发表一下你的评论吧 !