嵌入式OS入门笔记-以RTX为案例:十.Keil的RTX调试支持
调试(debug)是软件开发的一个重要环节,对于嵌入式开发而言这个环节其实比较依赖一些硬件资源(硬件debugger)的支持。传统的嵌入式系统的调试比较依赖断点(breakpoint)和单步调试(single step through)。而 ARM cortex-M 系列的芯片其实有很强的CoreSight片上调试支持,实际上就是一个小的调试硬件,作为ARM的标准,内嵌在ARM的芯片里。在ARM自家的调试器ULINK-pro等的帮助下,可以实现代码覆盖率,代码剖析,代码性能分析等非常强大的调试功能。不同架构的Cortex-M系列的芯片支持不同的CoreSight部件,详见官方网站的说明。
作为ARM自家的软件开发工具,Keil自然也在调试方面有很多相应的支持。我们这里简单介绍一下Keil对RTX的支持,操作系统感知调试(OS-aware debugging)。主要有两个功能,一个是系统和进程观察窗口(System and Thread Viewer),另外一个是事件窗口(Event Viewer)。
这里以STM32F4Discovery板作为例子。
1.系统和进程观察窗口(System and Thread Viewer)
首先这个功能和其他Cortex-M芯片,查看内存值(Memory Window 或者 Watch window)的运作原理类似,RTOS会把相关的进程信息储存在内存里面,然后这个系统和进程观察窗口就会从这个内存区域里面提取信息,其他的RTOS开发者也可以利用这个功能。
用法具体说来,非常简单,首先进入调试模式。
然后在View菜单中,确定Periodic Window Update被点选了:
最后,在Debug菜单中的OS Support栏中,点选System and Thread Viewer:
然后就可以看到这个窗口:
这就是系统和进程窗口,里面提供了RTX系统的基本设置,例如堆栈大小,时间片设置等和进程的基本信息,例如进程ID,进程优先度,当前进程状态,进程的delay时间,进程等待的事件值和当前的事件值和堆栈的适用程度。这个窗口还会实时更新各个进程的状态,非常好用。
举一个简单的例子,如果所有的进程都处于WAIT_SEM(等待信号量)的状态,而只有os_idle_demon处于Running状态,那么很可能就是进入了死锁的状态。调试时可以根据这里了解更多关于进程的实时情况。
2.事件窗口(Event Viewer)
可能在第一步配置系统和进程窗口时很多人都留意到了OS support中的,Event Viewer选项,没错,勾选它,就能启动这个调试功能。但这个调试功能需要SWV(Serial Wire Viewer)的支持。
首先要退出调试模式,然后点选Target Option,选择其中的Debug 栏目,点选在Debugger选择栏右侧的Settings按钮:
然后点选里面的Trace(跟踪)栏目,开启Trace,失能Periodic和EXCTRC选项,其余配置参考下图:
然后再进入调试模式,运行,就能看到这个事件窗口了:
清晰记录了具体某一时刻,哪个进程在运行,和进程运行之间的切换。
如果你勾选开启右上角的3个小功能:Task Info, Cursor和 Show Cycles,然后再把鼠标移至任一进程,就会出现进程信息框:
这些信息包括当前时间片里,进程开始的事件结束的事件,和该进程最大和最小的一段时间片。最为重要的是这个Called,这个数据是当前进程运行的次数,也就相当于这个是个profiler的数据,我们可以找出运行次数最高的进程,针对性地去优化程序。
3.其他RTX调试技巧
RTX本身提供了一个功能,能够返回当前时间(以RTX设置的时间单位为单位,初始时间是RTX开始Initialize的时间,也就是os_sys_init()的那一刻):
current_time=os_time_get();
通过读取当前的操作系统时间,也能够实现一些性能方面的调试功能,但这需要代码里面额外写入这部分相关的调试代码。