μC/OS-Il在TMS320VC33上的可靠应用
扫描二维码
随时随地手机看文章
1 宏OS_ENTER_CRITlCAL和OS_EXIT_ CRITICAL
在μC／OS_ II中，0S_ENTER_CRITICAL和OS_ EXIT_CRITIcAL这两个宏分别实现关中断和开中断的功能。TMS320VC33的全局中断控制在ST寄存器的 GIE位(第13位)，GIE=1时全局允许中断，GIE=O时全局禁止中断。这两个宏最简单直接的实现是使用与或指令修改GIE位，即“andn 2000H，st”和“0r 2000H，st”，网 上的移植代码就是采用了这种方式。但这不是一个非常可靠的方法，原因是TMS320VC33的流水线执行结构。为了提高代码的执行效率，TMS320VC33采取了四级流水线执行结构，指令的执行分为取指令、指令解码、读操作数和指令执行四个阶段，每个阶段都是并行执行的。在理想情况下(即不存在流水线冲突和等待周期)，每个机器周期内都有四条不同的指令分别位于取指、解码、读和执行阶段。这时每条指令都以单机器周期执行，DSP达到其最大标称的指令吞吐量。当产生中断请求并且允许中断时，DSP不会立即执行中断服务程序，而是要先禁止中断、获取中断向量、保存返回地址，然后再跳转至中断服务程序。而以上各步都是与流水线操作同步的，在流水线结构中，DSP对中断响应步骤如表1所列。
表1中，proga+l是单周期取指指令。如果prog a+l 是多周期取指指令(例如取指时含有等待状态)，中断响应会延迟到prog a+l执行以后。由表1可知，DSP对中断 的响应是在取指边界而不是指令的执行边界。假设prog a一2是关中断指令“andn 2000H，st”，那么prog a一1、 prog a甚至prog a+l仍然是可中断的，必须等到prog a +l执行完毕后才能完全禁止中断。同样在开中断时，紧邻开中断指令的后三条指令是不响应中断的。现在考虑下面的情况：系统通过OS_ENTER_CRITICAL宏禁止中断时，同时发生了中断请求，并且紧邻的三条指令是访问全局变量的指令。此时，由于流水线结构的执行特点， DSP还是会响应中断，如果相应的中断服务程序也访问了同样的全局变量，这样就可能破坏数据的一致性，造成系统的崩溃。为了防止这种情况，必须在改变系统中断状态时能够消除流水线操作带来的影响。为可靠实现OS_ ENTER_CRlTICAL和OS_EXIT_CRITICAL宏，在修改 ST寄存器之前加一条指令“RPTS O”。因为在RPTS指 令执行过程中会自动禁止中断，并且停止流水线操作，只有RPTS指令的下一条指令执行完毕后，DSP才会重新打开流水线。这样就保证了改变DSP中断状态时不会响应中断，也不会执行其他指令。上述宏的可靠实现为：
需要说明的是，利用trap指令的实现方式也是可靠的，但trap和rets／reti会两次清除流水线，因而会对性能稍微有点影响。OS_ENTER_CRITICAL宏的另外两种实现方法首先要保存DSP的中断状态，然后再改变中断状态。相应的，OS_EXIT_CRlTICAL宏可直接从前面保存的状态进行恢复。由于流水线操作的影响，要正确保存ST寄存器的状态，直接的存储或压栈指令是不行的，需要一些附加的保护性代码，本文就不再深入讨论了。
2 OSRdyGrp和OSRdyTbl
在笔者的应用系统中，除了定时器1中断外，还使用 了外部中断2、DMA中断和串口接收中断，把这些中断全 部打开后，会出现一个非常奇怪的现象。系统刚开始运行 时一切正常，一段时间后，与idle task不在同一个优先级 组的所有任务再也不执行了。但从程序上看，这些任务应 该处于就绪状态，除非就绪任务的优先级与idle task处于 同一个组，否则系统永远都在执行idle task。通过检查 OSRdyTbl发现，这些不被调度的任务的确处于就绪状 态，但在OSRdyGrp中却没有设置相应的标志．如果在 OSRdyTbl表中任务是就绪的，与该任务优先级组相对应 的OSRdyGrp中的标志却是0，那么任务调度时这些就绪 的任务是不会被调度的。在μC／OS-II中，OSRdyGrp与 OSRdyTbl的值都是同时修改的，并且还采用了临界区保 护，为什么还会出现OSRdyGrp与OSRdyTbl状态不一致 的现象呢?通过对汇编代码的仔细分析，发现问题出现在 函数OSTimeTick中，编译器产生了高效但不可靠的代 码。笔者使用的开发平台是Code Composer V4.1，代码 生成工具版本为5.11。此版本的代码生成工具产生的 OSTimeTick函数的汇编代码如下：
OSTimeTick函数的while循环结构从第5行开始至第23行结束。修改OSRdyGrp的语句是第8行，可以看出对OSRdyGrp的修改没有保存至相应的内存单元，而是保存在寄存器r0中，对OSRdyTbl的修改却直接保存到了内存单元(第14行)。位于循环体外的第4行语句将OSRdyGrp赋值给10，第24行将r0的内容保存至OSRdyGrp。编译器利用寄存器优化了对OSRdyGrp的访问，循环结构中OSRdyGrp值的每次改变都保存在寄存器中，只是在循环开始和结束时访问了两次内存，编译器这样的处理显然是高效的．如果不优化，语句“OSRdyGrp|=ptcb->OSTCBBitY”必须以读-改-写的方式实现，OSRdyGrp值的每次改变需要访问两次内存，而一般情况下对内存的访问是耗时的．应尽量避免。由上述代码容易看出，这样的优化使得对OSRdyGrp的访问位于临界区以外，因而引入了不安全因素。因为在时钟节拍中断服务程序OSTicklSR中允许嵌套中断，所以第19行以后的语句是可中断的。如果在20~23行之间发生了中断，并且相应的中断服务程序改变了OSRdyGrp，那么第24行的赋值可能使OSRdyrp获得一个错误的结果，造成 OSRdy(jrp与C)SRdyrTbl的不一致。第4行的赋值语句同样是危险的，如果有中断发生，rO中暂存的值不一定是当前正确的OSRdyGrp。奇怪的是，无论采用何种编译优化选项，编译器对OSRdyGrp的处理都是一样的，即使禁止优化也没有用。在函数0S_TaskStat中对于OSStatRdy 的处理，无论采用何种编译优化选项都不会对OSStatRdy 进行寄存器优化。知道原因后，对这一问题的处理是非常简单的，只要在OSRdyGrp声明时加上volatile修饰符(位于文件uCOS_II．H中)就可以禁止编译器对OSRdyGrp 进行寄存器优化。给OSRdyGrp加上volatile修饰符后的编译结果为：
与上面的第7、8行对比可以看出，对OSRdyGrp的每次修改都访问了内存单元，并且是在临界区内进行的。
3 中断处理程序
因为任务的切换是以中断方式进行的，如果某个中断向量的处理程序可能引起任务切换或者允许嵌套中断，该中断处理程序必须严格按照μC／OS_II要求的步骤进行。其中涉及到全部寄存器的保存与恢复、特定的μC／OS_II 函数调用、任务切换的处理等。虽然Code Composer支持 C语言的中断处理函数，但是C函数的中断处理程序不能产生正确的堆栈结构，所以最好不要直接用C语言处理中断而是使用汇编语言。惟一的例外是中断处理不涉及 μC／0S_II函数调用，并且禁止中断嵌套，这时使用C语言会比较方便。时钟节拍中断服务程序OSTicklSR为中断服务程序的编写提供了一个很好的范例。OSTicklSR 采用汇编语言实现了寄存器的保存与恢复，以及μC／OS_H 函数调用，真正的中断处理在C函数CSTimeTick中。用户的中断处理程序完全可以采用和OSTicklSR相同的汇编语言框架，然后用C函数完成实际的处理。需要说明的是，如果允许中断嵌套，开中断指令必须要放在OSin_ tEnter函数调用之后。如果在OSintEnter之前开中断，嵌套的中断服务程序不会知道自己是否是嵌套执行的，因而可能会执行任务切换。这样外层中断的堆栈将处于一个不确定的状态，引起系统的崩溃。关于这一点，网上移植代码的处理是不正确的。
结语
μC／0S-II是一个非常适合TMS320VC33的实时系统。因为μC／OS_II自身的内存占用非常小，对于一般的系统而言，DSP的片上RAM就可以容纳全部的操作系统和应用程序代码。试验表明，经过正确移植后，系统具备非常高的可靠性。
下载文档
