引言

应用实时多任务操作系统(RTOS)作为嵌入式设计的基础和开发平台将成为嵌入式应用设计的主流。μC/OS-II是一种源码公开、可移植性、可固化、可裁剪、占先式的实时多任务操作系统，目前已经得到广泛的应用。

在为电力系统接地选线装置开发的数据采集监测系统的设计中，笔者设计了集散式的数据采集结构，灵活的组态适应了目前国内多数中低压输配电网的数据采集需求。在此硬件平台上，笔者将实时操作系统μC/OS-II移植到TMS320LF2407A型号的DSP上，实现了多任务的并行执行，系统的可靠性和实时性得到大幅提升;设计了CAN总线驱动程序，使得下位采集处理模块与上位的主控制器具备了可靠快速的通信功能和协调功能。

1. 集散式的数据采集系统设计

系统的整体结构如图1所示：

图1 集散式选线系统整体结构

图中反映出目前变电站常见的网络结构。一般的基于集中式数据采集方式在应用上存在一定的缺点，比如针对不同变电站实际情况配置不够灵活等。而基于集散式的数据采集系统却具有系统适应能力强，组态方便，可靠性高等优点。因此，根据变电站网络的这种结构，本装置设计采用集散式数据采集的方式，即在每条支路上均挂接一个独立的智能数据采集及处理模块负责实时采集和数据预处理;主控制器与各智能采集处理模块通过CAN现场总线进行通讯，从而不仅实现主控的功能，还具备灵活的集散扩充性能。

2. CAN总线接口的设计

在各种现场总线网络中，最早为汽车电子设备互连而开发的CAN总线由于其简单灵活的配置以及强大的实时控制和检错纠错能力而在诸多自动化领域中得到了广泛的使用。

美国TI公司DSP产品线中的2000系列是专为工业控制应用设计的数字信号处理器，具有强大的数字信号处理能力，还集成了丰富的外设和I/O，成为现代电机控制、电力系统自动化等应用中很好选择。在这款DSP处理器上，自带了兼容CAN2.0B标准的CAN总线控制器，因此只需外接一片CAN总线收发芯片即可使模块具有完整的CAN总线通信能力，在此使用支持1M bps的PCA82C250收发器芯片，接口设计见图2。

图2 采集模块CAN总线接口

3. μC/OS-II在2407上的移植

绝大部分μC/OS-II的源码是用移植性很强的ANSI C写的，只有和微处理器硬件相关的那部分是用汇编语言写的。而TI公司提供的编译器Code Composer Studio (C2000) V2.20支持C语言和汇编语言开发，笔者在此编译器的基础上完成了μC/OS-II的移植。移植工作主要集中在三个文件的修改工作：修改头文件OS_CPU.H相关的内容，包括：数据类型定义、堆栈增长方向、中断相关的一些宏定义等;OS_CPU_C.C中编写任务堆栈初始化函数及系统HOOK函;OS_CPU_A.ASM中编写四个汇编语言函数：OSStartHighRdy(), OSCtxSw(), OSIntCtxSw()和OsTickISR()。

具体移植过程由于不是本文重点，恕笔者不再详述。

4. 基于缓冲队列支持下的CAN总线驱动程序设计

驱动程序是连接底层的硬件和上层的API函数的纽带，有了驱动程序模块，就可以把操作系统的API函数和底层的硬件分开来。任何一个硬件的改变、删除或者添加，只需要随之改变、删除或者添加提供给操作系统的相应的驱动程序就可以了，并不会影响到API函数的功能，更不会影响到用户的应用程序。同时，为了保证在实时多任务操作系统中，对硬件访问的唯一性，系统的驱动程序要受控于相应的操作系统的多任务之间的同步机制。

(1) μC/OS-II的通信机制

μC/OS-II在处理任务之间的通信和同步的时候，主要通过以下几种方式：信号量(Semaphore)，邮箱(Mailbox)，消息队列(Queue)和互斥信号量(Mutex)。具体的通过事件控制块(ECB)来实现。μC/OS-II中定义的数据结构OS_EVENT能够维护任务间通信和同步的所有信息，该数据结构不仅包含了事件本身的定义，如信号量的计数器、指向邮箱的指针、指向消息队列的指针数组、互斥量中能否获得资源的Flag和正在使用该互斥量的任务，还定义了等待该事件的所有任务列表。事件发生后，等待的优先级最高的任务进入就绪态。

(2) 缓冲队列的设计和通信任务的配合

在微机系统中,一般串行设备或者其他字符型设备都存在外设处理速度和CPU速度不匹配的问题，所以需要建立相应的缓冲区。向CAN口发送数据时，只要把数据写到缓冲区，然后由CAN控制器逐个取出往外发送。从CAN口接收数据时，往往等收到若干个字节后才需要CPU进行处理，所以这些预收的数据可以先存在缓冲区。缓冲区可以设置收到若干个字节后再中断CPU，这样就避免了因为CPU的频繁中断而降低系统的实时性。

在对缓冲区读写的过程中，经常会遇到想发送数据的时候，缓冲区已满;想去读的时候，接受缓冲却是空的。对于用户程序端，采用传统的查询工作方式，频繁的读取使得程序效率大为降低。如果引入读、写两个信号量分别对缓冲区两端的操作进行同步，问题自然解决：用户任务想写但缓冲区满时，在信号量上休眠，让CPU运行别的任务，待ISR从缓冲区读走数据后唤醒这个休眠的任务;类似的，用户任务想读但缓冲区空时，也可以在信号量上休眠，待外部设备有数据来了再唤醒。其中，μC/OS-II的信号量提供了超时等待机制，CAN端口本身也有超时读写能力。

接受和发送的数据缓冲区数据结构定义如下：

typedef struct {

INT16U BufRxCtr; //接受缓冲中的字符的数目

OS_EVENT BufRxSem; //接受信号量

INT8U BufRxInPtr; //接收缓冲中下一个字符的写入位置

INT8U BufRxOutPtr; //接收缓冲中下一个待读出字符的位置

INT8U BufRx[CAN_BUF_SIZE]; //接收环形缓冲区的大小

INT16U BufTxCtr; //发送缓冲中字符的数目

OS_EVENT BufTxSem; //发送信号量

INT8U BufTxInPtr; //发送缓冲中下一个字符的写入位置

INT8U BufTxOutPtr; //发送缓冲中下一个待读出字符的位置

INT8U BufTx[CAN_BUF_SIZE]; //发送环形缓冲区的大小

}CAN_BUF;

其他接口函数如下：

Void CanInitHW ( ); //设置CAN控制器端口中断向量

Void CANSendMsg ( ); //向CAN控制器端口发送数据

Void CANReceiveMsg ( ); //从CAN控制器端口接受数据

图3 基于缓冲队列的CAN通信过程

基于缓冲队列支持下的CAN通信任务通信过程如图3所示。

在该通信任务中，采用查询方式发送，中断方式接收，任何时候只要没有关中断，中断任务的优先级高于其他任何任务。可以说，该任务是“基于中断响应”的。这样处理的好处是能够最大的保证了通信的实时性，同时也使得系统资源的利用率大大提高(相比于收发都采用查询的方式)。任务间的通信和同步通过邮箱和信号量机制进行。

当用户应用程序(或任务)要求进行远程CAN通信的时候，应用程序(或任务)先要获得BufTxSem并向发送缓冲区BufTx装入报文，写入缓冲区结束后释放信号量BufTxSem，通过邮箱通知CAN通信任务处理报文并完成报文的发送。

当总线发来报文时，接受节点的CAN控制器会产生一个接收中断，当前运行任务被挂起，CAN通信任务被激活并抢占运行，获取信号量BufRxSem，然后从总线上读取报文并写入缓冲区 ，写入结束后释放信号量BufRxSem，并通过邮箱通知相应的用户应用程序(或任务);应用程序(或任务)通过获得信号量BufRxSem从缓冲区内读取相应的报文信息。

(3) μC/OS-II的中断任务的处理

在μC/OS-II中，中断服务程序一般用汇编语言来写。以下是中断服务程序的示意代码：

Void UserISR( void ) {

保存全部CPU寄存器;

调用OSIntEnter或OSIntNesting直接加1;

执行用户代码做中断服务;

调用OSIntExit;

恢复所有CPU寄存器;

执行中断返回指令;

}

μC/OS-II提供了两个ISR与内核的接口函数：OSIntEnter和OSIntExit。OSIntEnter通知内核中断服务程序开始运行了，并把一个全局变量OSIntNesting加1。此中断嵌套计数器可以确保所有中断处理完成后再作任务调度。另一个接口函数OSIntExit则通知内核，中断服务已结束。根据相应情况，返回被中断点(可能是一个任务或者被嵌套的中断服务程序)或由内核作任务调度。

用户编写的ISR必须被安装到某一位置，以便中断发生后，CPU根据相应的中断向量运行准确的服务程序。许多实时操作系统都提供了安装、卸载中断服务程序的API接口函数，有些成熟的RTOS甚至对中断控制器的管理都有相应的API函数。但 μC/OS-II内核没有提供类似的接口函数，需要用户在对应的CPU移植中自己实现。在DSP2407中，我们可以在设计中断向量表的时候把用户的中断入口写好，这样一旦CAN通信接受中断发生时，DSP2407就能自动从中断向量表里读取相应的程序入口，进而跳转执行用户的ISR程序。

结束语

基于RTOS平台上开发用户的应用程序，便于在实时操作系统内核下实现多任务处理，可以大大缩短产品开发周期，进一步提高应用程序的可移植性和可维护性。基于本文原理开发的应用于集散式数据采集系统的CAN总线远程通信构件具有良好的可扩充性和移植性，对各种实际现场情况能够进行灵活的配置和设定，真正实现了通信模块驱动程序的封装。