|
环境:FreeRTOS 8.1.2, MCU STM32F103ZET6 @72MHz, Keil MDK 4.72, STM Lib 3.5. Code running in Flash.
方法:仅仅定义了5个任务,两个任务是每隔一秒去toggle不同的LED,一个任务是用FreeRTOS的utility来每隔5秒统计各个任务状态以及CPU占用率,还有一个TaskButton是等待外部中断发来Semaphore并进行处理的任务,最后一个是负责printf到串口的守护任务。然后启动一个STM32内部定时器,计数频率为1MHz,就是计数器每1uS加一。安装并启动一个外部中断,连接到一个按钮,设为上升沿触发。在中断ISR里面,一进去就清零定时器,然后发semaphore给任务TaskButton,之后强制任务切换并立即退出。任务TaskButton收到semaphore后立刻读出计数器的值,这时这个值就可以认为是事件处理任务对对中断响应处理的反应时间,以uS为单位,通过printf打印出来。所以,每次按按钮就会触发中断并打印响应时间。
结果:绝大部分时候打印出来的结果在10-12uS。由于按钮未作任何软硬件消抖,可能会有重入,这时按一次会看到连续多次打印,第一次正常在10-12uS,后面几次的结果会偏大很多,甚至达到80uS。
分析:觉得这个10-12uS的时间基本上就是FreeRTOS发送Semaphore、中断退出、做任务切换调度、TaskButton任务中接收semaphore的过程的时间。也可以看作是FreeRTOS的任务对中断事件的响应速度。
注意:由于打开了FreeRTOS的统计功能,在任务切换时会消耗一些额外的时间。
就是说,如果要求对中断事件响应速度要小于10uS,相应的处理就必须在中断ISR里面做掉。
常用的做法是在ISR里面做需要快速反应的事情,同时做最基本的数据收集处理,然后尽快退出,发送信令给某个处理任务让其处理需要较多时间和资源的工作。
大家有何看法? |
|