本文主要是介绍cubemx在使用freertos的时候为何推荐使用除systick以外的timebase，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
摘要
第一次使用stm32cubemx,在配置freertos后生成代码时会提示:
When FreeRTOS is used.It is strongly recommended to use a HAL timebase source other than the Systic
Why???
网上搜了下,结合相关源码看了下,理清了思路.用一句话总结就是:防止在高优先级(优先级高于systick)中断服务中调用HAL_Delay(),导致中断服务忙等待,这样任何优先级低于该中断的中断都得不到服务,当然也包括os的全部调度.
当然可能还有一些其他我想不到的原因,也欢迎小伙伴们提供宝贵信息.
分析:
stm32+freertos之所以要用到两套timebase(一是freertos的心跳tick (os_tick),二是更底层的与freertos的api无关的HAL心跳tick (hal_tick),譬如systick (这个是强制的os_tick)和timer (譬如timer1,hal_tick)):
是因为freertos强制使用systick作为自己的心跳,且systick的优先级被强制设置为最低；如果HAL的心跳也使用systick,也即sys_tick == hal_tick.那么在某些情况下将产生我们不想看到的结果,譬如:
案例:
systick的中断优先级为最低的5,我们有个中断int_a的优先级为4,显然int_a的优先级要高于systick,systick的中断是不能够抢占int_a的.
考虑以下情形,int_a的中断服务里调用了HAL_Dealy(10),等待10个tick (HAL_Delay()内部是一个while循环,不断的读取当前的hal_tick来判断是否到时间)；hal_tick随着时间的流失是不断增长的,由于只有一个timebase源(systick),hal_tick增长的任务也就交给systick的中断服务了,由于systick不能够抢占int_a,就导致了systick无法处理自己的中断服务,hal_tick也就不会增长,int_a的HAL_Delay(10)也就永远等不来自己返回的日子了.其结果就是int_a中断无法返回,任何优先级低于此中断的中断都无法得到服务,当然也包括os的全部调度,因为os的调度依赖与systick中断.
正确的做法:
timer(譬如timer1)产生HAL心跳,systick产生freertos心跳.HAL是不依赖os API的一套硬件操作接口.
一般的HAL心跳每1ms发生一次
os_tick是如何工作的:
当配置了两套时基时,systick作为os的心跳,它的优先级应该配置成最低(cubemx为我们实现了这一工作).这事因为:
systick的中断服务,主要处理一些os层面的东西,譬如查看是否有blocked的任务已经就绪了,然后执行任务切换等工作.作为一个实时系统为了保持实时性不打搅其他的中断服务,stm32cubemx里会强制systick的优先级为最低,譬如我用的stmf107的systick的抢占优先级为15(最低).mcu运行过程中按照设定周期性地产生中断,譬如设置为100HZ那就是每10ms产生一次systick更新中断.每一次中断中都会增加sys_tick计数,执行一些os的操作,然后调度任务(调度的方法是trigger一个pensv中断,这是一个优先级最低的中断,他会等到其他中断服务都执行完后,再处理自己的服务,获取下一个执行的任务,服务返回时跳转到该任务堆栈执行,这一块还是看一下<cortex-M3权威指南>吧,不赘述了).
osDelay()这一freertos API就是参考sys_tick这一时基,任务的调度切换(或者说os系统层面)是基于这一时基的,我们可以通过cubemx来配置这一时基的周期,譬如100HZ
hal_tick是如何工作的:
为了保证HAL时基的可靠,防止出现上面我们讲的一直忙等待问题,强制设定它的优先级为最高0,譬如我们用timer1作为HAL时基(cubemx里SYS部分配置).一般HAL时基一般是1ms,每1ms hal_tick计数加1(它的中断服务也就只干了这么一件事).
HAL_Delay()这一HAL API就是参考hal_tick这一时基的.
这篇关于cubemx在使用freertos的时候为何推荐使用除systick以外的timebase的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
