引言
随着数字信号处理技术的发展，越来越多的应用于各行各业。但是，以往多数的DSP系统是基于流程图的设计方法，该方法设计的程序稳定性不高，流程中任意一个环节出错都将导致系统崩溃甚至死机。使用RTOS将对系统的稳定性有很大的改善。使应用模块化，可极大提高程序的可读性、可扩展性和可移植性。
TI公司的定点DSP处理芯片TMS320C54X是目前应用比较广泛的一种DSP芯片，具有功耗低、运行速度快等优点，适合低速率语音编码的应用。
uC/OS-II是一种免费应且源代码公开的实时内核，经过多年的实际应用，显示出强大的功能和巨大的商业价值。本文实现了uC/OS-II在TMS320C54X上的移植，并提出了在uC/OS-II的平台上的低速率语音编码器的系统设计方案。
uC/OS-II在TMS320C54X上的移植
要实现uC/OS-II的移植，主要改写以下三个文件
OS_CPU.H文件
包括定义数据类型、代码值界区的中断控制、堆栈增长方向变量、任务切换函数定义和变量声明。TMS320C54X中的堆栈数据类型为16位，定义为：
typedef unsigned int OS_STK
在TMS320C54X中所有的堆栈都必须用OS_STK声明。
RTOS在进入系统临界区之前必须关闭中断，退出临界区后再打开中断。uC/OS-II定义了两个宏来关闭/打开中断：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。
用OS_STK_GROWTH来设置，OS_STK_GROWTH为0表示堆栈从低地址向高地址递增;OS_STK_GROWTH为1表示堆栈从高向低地址递减，TMS320C54X中，堆栈地址是由高向低递减的。
在uC/OS-II中，OS_TASK_SW()用来实现任务切换。OS_TASK_SW()函数模拟一次中断过程，在中断返回时进行任务切换。
另外，还声明了一个8位变量，用来调用DOS的时钟节拍函数，在TMS320C54X中应该屏蔽掉。
OS_CPU_A.ASM文件
在此文件中，需改写函数：OSStartHighRdy()、OSCtxSw()、OSIntCtxSw()。
OSStartHighRdy(0)函数由Sstart()函数调用，功能是运行优先级最高的就绪任务。其过程为：获得优先级最高任务的TCB地址→设置堆栈指针→恢复任务环境→中断返回→运行新任务。在TMS320C54X中实现如程序列表1，其中，CONTEXT_RESTORE是将C54X中的寄存器出栈的宏定义，在此不再详述。
OSCtxSw()函数是一个任务级的任务切换函数。软中断向量指向此函数。在uC/OS-II中，如果任务调用了某个函数，而该函数的执行结果可能造成系统任务的重新调度，则在函数的末尾会调用OSSched()。OSSched()查找当前就绪最高优先级任务，如果不是当前任务，则找到该任务TCB的地址，并拷贝到变量OSTCBHighRdy中，然后通过宏OS_TASK_SW()执行软中断调用OSCtxSw()进行任务切换。变量OSTCBCur始终包含指向当前运行任务TCB的指针。在TMS320C54X中实现如程序列表2。
OSIntCtxSw()函数与OSCtxSw()函数类似，不同的是，OSIntCtxSw()函数进行中断级任务切换。中断可能引起任务切换，在中断服务程序的最后会调用OSIntExit()函数检查任务就绪状态，如果需要进行任务切换，则调用OSIntCtxSw()。值得注意的是，产生中断后，CPU寄存器会自动被保存，所以，在此函数中不再进行环境保存。在TMS320C54X中实现如程序列表3。
OS_CPU_C.C文件
在此文件中，只需修改OSTaskStkInit()函数。OSTaskStkInit()由任务创建函数OSTaskCreate()或OSTaskCreateExt()调用，用来初始化任务的堆栈。OSTaskStkInit()与调用它的函数有三个参数进行传递：任务代码起始地址(task)，参数指针(pdata)，任务堆栈顶地址(ptos)。为提高代码效率，此函数用汇编语言改写，在TMS320C54X中实现如程序列表4。(程序列表1~4，均见本刊网站 http://www.eaw.com.cn)
基于uC/OS-II的低速率语音编码器系统设计
本系统中，低速率语音编码器的功能有语音编码、语音解码、回波抵消、模拟接口、数字接口等。另外，为提高系统的稳定性，增加了空闲任务和监视任务。系统结构如图1所示。
系统由里向外分为三层：操作系统层、任务层、硬件层。
硬件层设计
硬件层设计主要包括串口和HPI口，用于接收(发送)语音信号和信道上的数据。
任务层设计
本系统中共有七个任务，其优先级从高到低依次为：监控任务、模拟接口任务、数字接口任务、回波抵消任务、编码任务、解码任务、Idle任务。各任务的状态有4种，即等待态和挂起态、就绪态、运行态以及中断态，状态的转换关系如图2所示。
监视任务设计思路为：被监视任务正常运行时其执行时间是可预估的，被监视任务在其即将运行完毕时向监视任务发送消息说明自身运行正常。被监视任务运行时，监视任务处于等待态，等待被监视任务给它发送消息，等待时间被设定为预计的任务正常运行所需的最大时间。若等待时间内监视任务收到消息，则认为发送消息的任务运行正常，依照各任务执行顺序的先后下一任务开始运行，监视任务等待下一任务发送的消息。若等待时间已过，监视任务仍未收到消息，则系统的时间管理函数将强行把监视任务视为就绪态。因监视任务的优先权是最高的，它将抢占对CPU的控制权并采取相应的纠错方案。
操作系统层设计
在应用中，各个任务之间都有数据要交换，本设计中采用消息机制实现任务间通信。编码任务需要模拟接口任务发送的消息，以接收用于编码的语音数据;数字接口任务需要编码任务发送的消息，以接收用于发往信道的编码数据;解码任务需要数字接口任务发来的消息，以接收来自信道的用于解码的解码字;模拟接口任务需要解码任务发来的消息，以接收用于D/A转换的数字语音信号。回波抵消任务需要等待的消息来自模拟接口任务和解码任务。监控任务接收所有其任务发来的消息，确认系统是否正常运行。
在运行过程中，操作系统对各任务进行调度。其动作为：
系统启动时，建立所有的任务，除回波抵消任务外，都处于就绪态;
此时，监控任务优先级最高，查询消息队列，没有消息的到来，转为等待态;
模拟接口任务运行，接收/发送数据，发数据给回波抵消任务，并使回波抵消任务处于就绪态;如条件达到(如帧数已够)，向编码任务发消息，传送数据，运行完毕，自行进入挂起态，等待下一次串口中断将其转为就绪态;
数字接口任务运行，接收/发送数据，如条件达到(如编码字数够)，向解码任务发消息，传送数据，运行完毕，自行进入挂起态，等待下一次串口中断(或HPI中断)将其转为就绪态;
如消息足够，回波抵消任务运行，运行完毕，自行处于挂起态;
编码任务运行，如有模拟接口任务发来的消息，则运行，编码完毕，向数字接口发消息;否则，处于等待态;
解码任务运行，如有数字接口任务发来的消息，则运行，解码完毕，向模拟接口任务和回波抵消任务发消息;否则，处于等待态;
在所有任务都执行完毕后，Idle任务运行。
由于所有的任务都有严格的执行时间限制，因此，上述的任务流程在正常情况下可以顺利进行。否则，监控任务会重启系统。
结语
本文在TMS320C54X的硬件平台上实现uC/OS-II，并针对传统的系统设计方法设计的低速率语音编码器稳定性不佳的问题，提出了基于uC/OS-II的低速率语音编码器系统设计的方案。由于低速率语音编码器通常是单片的，内部任务相对较少。使用实时内核来管理这些任务，会增加系统的内存和CPU时间的消耗，而任务调度的优势不能很好地显示出来，该设计有一定局限性。但是，在系统的内存足够大、CPU运行速度足够快的情况下，使用实时内核设计低速率语音编码器，有利于系统的后继开发。