在使用RTOS的嵌入式应用程序中，通常会要求某些任务在规定的时间内作出响应。但当RTOS开始运行后，不同任务之间的切换由RTOS任务调度器负责，对于程序开发者RTOS应用程序的实际运行过程并不是非常直观，如果还需要对应用程序进行启动时间，运行时间等维度的分析，传统的调试方式在解决这些问题时将变得困难，此时可以借助Tracealyzer这样的图形化RTOS跟踪分析工具。

Tracealyzer提供了30多种相互关联的运行时行为视图，包括任务调度、中断、任务之间的相互作用，以及从应用程序代码中记录的用户事件等。Tracealyzer作为传统调试的补充，提供了更高层次的调试视图，非常适合理解典型的实时问题。如图1所示从任务进入就绪状态到任务开始运行的这段时间称为任务的启动时间。

图1

本文将借助一个实例来演示如何使用Tracealyzer来优化RTOS任务启动时间。实验中包含2个任务（ButTest和TestTask）和一个按键中断，ButTest任务阻塞等待信号量，收到按键中断释放的信号量后开始运行。TestTask任务的优先级高于ButTest任务。

图2

打开Tracealyzer的Actor Instance Graphs视图，选择Startup启动时间视图，可以发现ButTest任务的启动时间大部分都在2.5ms以内，但是也有部分情况下的启动时间超过了30ms。如果要优化这些位置的任务启动时间，那么可以在Tracealyzer视图中双击这些位置跳转到跟踪记录以进行进一步的分析。

图3

在跟踪视图中，可以看到ButTest任务从任务就绪到实际开始运行之间存在一段黄色虚线部分，从跟踪视图中可以看到虚线部分系统中运行的是优先级更高的TestTask任务（红色部分）。根据分析可知是由于TestTask任务抢占了ButTest任务导致该任务的启动时间大幅提高到了超过30ms。

图4

根据上面的分析结果，将ButTest任务的优先级调整为高于TestTask任务以避免任务被抢占，生成新的跟踪记录如下：

图5

根据跟踪视图可以发现，ButTest任务不被抢占的情况下，任务的启动时间都进一步下降到了1ms以下，但是在不同情况下依然存在从100us到1ms范围内的启动时间差距，能否再进一步优化任务的启动时间呢？

图6

根据跟踪视图分析可以看到，此时影响启动时间的是空闲任务(灰色部分)，为什么低优先级的空闲任务会影响到更高优先级任务的启动时间呢？这其实是系统目前使用的任务切换机制决定的，当没有主动触发任务切换时，系统的任务切换由SysTick定时器中断触发，因此虽然此时ButTest任务已经就绪，但是没有触发SysTick定时器中断的情况下也不会发生任务切换。

图7

在按键中断中，加上portEND_SWITCHING_ISR( xHigherPriorityTaskWoken )语句，当有任务接受信号量进入就绪状态后，在中断退出的时候将会主动执行一次任务切换,避免了等待SysTick中断的时间。

可以看到经过优化后，ButTest任务的启动时间进一步下降到了7us左右，对比开始最高超过30ms的启动时间有了大幅的优化。

图8

基于Tracealyzer的视图捕获，分析异常的启动时间，优化了任务优先级配置，正确的实现受OS管理的中断ISR处理。更多Tracealyzer技术资讯，请订阅“麦克泰技术”微信公众号，欢迎咨询：info@bmrtech.com

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。