|
目前，uCOS-II已经被成功移植到多种微处理器 上，其中也包括TMS320VC33。在uCOS-II的网站上可以免费下载相关处理器的移植代码，这些代码可以作为 uCOS-II应用中一个非常好的起点。笔者在应用这些 移植代码时遇到了一些问题，因此如何使移植更加可靠、 高效，仍然是一个值得深入探讨的话题。网上 TMS320VC33的移植代码已经完成了基本的移植工作， 本文不对移植的详细过程进行赘述，而只就移植及应用过程中的一些关键步骤和涉及到代码可靠性的问题进行讨论。 1 宏OS_ENTER_CRITlCAL和OS_EXIT_ CRITICAL
在uCOS_ 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，那么任务调度时这些就绪 的任务是不会被调度的。在uCOS-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 中断处理程序
因为任务的切换是以中断方式进行的，如果某个中断向量的处理程序可能引起任务切换或者允许嵌套中断，该中断处理程序必须严格按照uCOS_II要求的步骤进行。其中涉及到全部寄存器的保存与恢复、特定的uCOS_II 函数调用、任务切换的处理等。虽然Code Composer支持 C语言的中断处理函数，但是C函数的中断处理程序不能产生正确的堆栈结构，所以最好不要直接用C语言处理中断而是使用汇编语言。惟一的例外是中断处理不涉及 uCOS_II函数调用，并且禁止中断嵌套，这时使用C语言会比较方便。时钟节拍中断服务程序OSTicklSR为中断服务程序的编写提供了一个很好的范例。OSTicklSR 采用汇编语言实现了寄存器的保存与恢复，以及uCOS_H 函数调用，真正的中断处理在C函数CSTimeTick中。用户的中断处理程序完全可以采用和OSTicklSR相同的汇编语言框架，然后用C函数完成实际的处理。需要说明的是，如果允许中断嵌套，开中断指令必须要放在OSin_ tEnter函数调用之后。如果在OSintEnter之前开中断，嵌套的中断服务程序不会知道自己是否是嵌套执行的，因而可能会执行任务切换。这样外层中断的堆栈将处于一个不确定的状态，引起系统的崩溃。关于这一点，网上移植代码的处理是不正确的。 结语
uCOS-II是一个非常适合TMS320VC33的实时系统。因为uCOS_II自身的内存占用非常小，对于一般的系统而言，DSP的片上RAM就可以容纳全部的操作系统和应用程序代码。试验表明，经过正确移植后，系统具备非常高的可靠性。
|
