μC／OS-II的CAN驱动程序设计

摘要：实时性是衡量CAN现场总线系统性能的一个重要标准。本文提出一种采用μC／OS-II操作系统和I-CAN协议，在应用层面上提高CAN总线系统实时性的驱动程序设计方案，并以分层的方式逐层阐述CAN驱动程序的设计过程。
关键词：CAN总线；μC／OS-II；实时性；驱动程序

引言
    CAN总线是德国Bosch公司于1983年针对汽车应用而开发的，一种能有效支持分布式控制和实时控制的串行通信网络，属于现场总线的范畴。其通信距离与波特率有关，最大通信距离可达10 km，最大通信波特率可达1 Mbps。CAN总线仲裁采用1l位(CAN2．OA协议)和29位(CAN 2．OB协议)标志，以及非破坏性仲裁总线结构机制，可以确定数据块的优先级，保证在网络节点冲突时最高优先级节点不需要冲突等待。CAN总线上的任何节点均可在任意时刻，主动向网络上其他节点发送信息而不分主次，从而实现各节点之间的自由通信。目前，CAN总线协议已被国际标准化组织认证，技术比较成熟，已广泛应用于汽车、工业、高速网络和低价位多路连线等领域中。
    μC／OS-II是Jean J．Labrosse开发的一种小型嵌入式操作系统。它实质上是基于优先级的可剥夺型内核，系统中的所有任务都有一个唯一的优先级别，适合应用于实时性要求较强的场合。本文采用μC／OS-II来设计CAN的驱动程序，以满足系统的实时要求。

1 CAN节点的硬件设计
    CAN节点是分布在CAN网络中进行相互通信的基本单元，主要由主控制器、CAN控制器和CAN收发器组成。本设计中，节点的基本结构如图1所示。在CAN网络中，ECU(Electronic Control Unit)是指一个具有完整功能的CAN节点。

    采用NXP公司的LPC2368作为CAN节点的主控制器。LPC2368是一款基于ARM7TDMI-S内核的RISC处理器，包含2个兼容CAN2．0B规范的CAN控制器。每个CAN控制器拥有双重接收缓冲器和三态发送缓冲器，具有快速的硬件实现的搜索算法，可以支持大量的CAN标识符。
    LPC2368是一款3．3 V器件，虽然其对应的CAN收发器接口引脚能够承受5 V电压，但为了让CAN节点能够更稳定地运行，这里采用TI公司的3．3 V CAN收发器SN65HVD230D与之配合使用。凭借高输入阻抗特性，SN65HVD230D可以在一条总线上支持多达120个CAN节点，并且能够和5V的CAN收发器良好地兼容。本文重点介绍CAN驱动程序的设计方法。

2 CAN驱动程序设计总体思想
    为了使软件可移植性强、易于维护，采用分层的方法编写CAN驱动程序。驱动程序分层结构如图2所示。图中，双向箭头表示实时操作系统μC／OS-II与CAN驱动程序之间的数据交换，单向箭头表示上层软件对下层软件的调用。

3 CAN设备控制层和CAN接口控制层
    CAN设备控制层的主要任务是：初始化主控制器与CAN控制器之间的连接配置，复位CAN控制器，建立主控制器和CAN控制器之间的通信函数。由于LPC2368内部集成了CAN控制器，CPU可以通过内部APB总线接口对CAN控制器的所有寄存器进行访问，所以不再需要编写设备控制驱动层程序，已经完全由硬件实现了。
    CAN接口控制层主要任务是：实现CAN控制器的各种功能，如设置控制模式、发送数据、释放接收缓冲区、配置验收滤波器等。这些操作都是通过读写CAN控制器的内部相关寄存器来实现的。
    CAN控制器初始化程序(在应用层中实现，内部调用的函数也都是在该层中编写的)如下：

    为了使程序更加简洁、可读性更强，可以通过宏定义的形式进行编写。例如：
    #define CAN_MOD_RM()CANlMOD |=1
    CANlMOD是CAN控制器的模式寄存器，最低位置1可使CAN控制器进入复位模式。这种模式下，可以对控制器的所有寄存器进行写操作。其他对CAN控制器内部寄存器的操作可以参照LPC2368的技术手册。

4 CAN协议层
    从OSI网络模型的角度来看，现场总线网络一般实现了第1层(物理层)、第2层(数据链路层)、第7层(应用层)；而CAN现场总线仅仅定义了第1层、第2层，这两层分别由CAN收发器和CAN控制器实现。CAN总线没有规定应用层，本身并不完整，因此需要一个高层协议来定义CAN报文中11／29位标识符、8字节的使用。目前，已经有一些国际上标准的CAN总线高层协议，例如DeviceNet协议和CANopen协议；但是这个协议规范比较复杂，理解和开发难度都比较大，对于一些并不复杂的基于CAN总线的控制网络不太适合。本设计采用国内周立功CAN开发组织根据实际应用制定的简单的CAN应用层协议I-CAN协议，作为软件设计的CAN协议层。ICAN协议中的29位帧标识符定义如表1所列。

    CAN总线仲裁是从标识符的最高位(28位)开始逐位进行的。每一个发送器都对发送位的电平与被监控的总线电平进行比较：如果相同，则这个单元可以继续发送；如果发送的是“隐性”(逻辑1)电平，而监控到的却为“显性”(逻辑O)电平，那么该单元就失去了仲裁，必须退出发送状态。根据I-CAN源节点编号部分可以看出，节点的地址编号越小，优先级也就越高，在仲裁时能够优先获得总线使用权。在CAN网络系统中，节点越重要，分配的地址编号的优先级相应地也越高。譬如，车载网络中的发动机电控单元就应该比定向大灯电控单元的优先级高，这样才能保证重要的报文及时传送出去。在节点接收到报文之后，应用程序依据I-CAN协议解析报文标识符，并实现其指定的功能。

5 CAN应用层
    CAN应用层实现CAN控制器的所有功能。CAN设备控制驱动层、CAN接口驱动层和CAN协议层都在应用层的控制之中。应用层主要实现的任务包括：
    ①初始化CAN控制器，以及与应用层相关的全局变量。
    ②编写CAN控制器的中断服务程序。
    ③报文处理任务。该任务基于I-CAN协议来解析报文，并实现报文指示的功能。
    ④报文发送任务。该任务存储未能发送的报文，并在发送缓冲区可用的情况下自动发送报文。
    初始化CAN控制器的程序详见第3节。由于初始化CAN控制器直接和CAN物理层及链路层的性能挂钩，因此只有依据具体应用环境正确地配置CAN控制器，才能使系统稳定地运行。
5．1 中断服务程序
    中断服务程序用来判断CAN控制器的中断类型，并作出相应的响应。具体程序如下：

    这里只对接收中断、发送中断以及总线错误中断进行阐述，其他类型的CAN中断处理应根据具体系统进行具体设计。
5．1．1 接收中断
    接收中断处理函数CANl_RI_HANDLE()负责接收报文，并将报文发送到任务的消息队列中。其代码如下：

    其中，RI_DATA为定义的结构体CAN_MSG变量；CANlRFS、CANlRID、CANlRDA和CANlRDB分别为CAN控制器存储接收报文帧信息、标识符、数据字节的寄存器。CAN_MSG结构体如下所示：

5．1．2 发送中断
    当发送中断处理函数通过TX_CNT判断出报文发送函数的消息队列中有待发送报文时，通过函数OSSemPost(CAN_TX_OVER)向其发送信号量，通知其可以发送报文了。若TX_CNT为0，说明消息队列中没有待发送的报文，则不发送信号量。
5．1．3 总线错误中断
    CANl BEI HANDLE()通过查询中断和捕获寄存器来判断是何种错误类型，并将它记录下来以便于系统诊断。
    由于CANl_RI_HANDLE()和OSSemPost()都可能就绪等待中的任务，所以为了保证系统能够严格按照优先级来执行任务。程序采用OSIntEx-it()函数进行中断级任务切换，在执行完中断服务程序后运行一个具有最高级别的任务，而不是返回被中断的任务。
5．2 应用层面临的问题及解决方法
    下面将结合应用层面临的实际问题，对报文处理和报文发送函数进行详细阐述。
    ①CAN节点将CAN中断设为FIQ中断，而其他中断设为不同优先级的IRQ中断。由于FIQ中断能够打断IRQ中断，所以节点在任何情况下都能尽快地响应CAN中断，提高了系统的实时性。
    编写的CAN中断服务程序应该越短越好，在不影响系统性能的情况下尽量将中断服务任务放到中断服务程序外执行，以便尽早退出FIQ中断模式，从而使节点能够响应新的中断，减少系统中的中断延时。其中，接收中断处理是最占用节点资源的，它不仅需要根据I-CAN协议对报文进行解析，还需要执行报文指定的功能，所以必须放到中断服务程序外执行。解决的办法是，通过μC／OS-II中的OSTaskCreate()函数建立一个报文处理任务，这个任务由一个请求消息队列函数OSQPend()和一个报文解析处理函数组成。报文处理函数如下：

    如果需要发送CAN报文，首先要查询是否有可用的发送缓冲区：若有则可用就直接发送，无须通过消息队列作为中介，从而提高程序运行效率；若都被锁定，则调用OSQPost()将报文发送到报文发送函数的消息队列MESSAGE_TX中，并执行TX_CNT++操作。
    ②在繁忙的CAN网络中，节点可能会由于仲裁丢失而无法及时将数据传输，因此必须要对待发送的数据进行存储，等待节点获得总线使用权时再发送出去。LPC2368的CAN控制器有一个三态发送缓冲区，最多能够存储3个报文。若3个缓冲区都处于锁定状态(报文正在等待发送或正
处于发送过程)，而又有一个报文需要发送，则需要额外的缓冲区先将它存储起来，以待节点获得总线使用权时再发送。
    定义一个指针数组，把建立的消息数据缓冲区的首地址存入这个数组中，然后再调用OSQCreate()函数来创建一个用于存储发送报文的消息队列MESSAGE TX，最后通过OSTaskCreate()函数建立一个负责发送报文的任务。该任务由一个请求消息队列函数OSQPend()和一个请求信号量函数OSSemPend()组成。报文发送函数如下：

    其中，变量TX_CNT记录MESSAGE_TX中的报文数目。任务向MESSAGE_TX发送一个报文，TX_CNT就加1；报文发送函数成功发送一个报文，TX _CNT就减1。这样，中断服务程序就可以根据TX_CNT来判断是否有向CAN_TX_OVER发送信号量的必要，减少了不必要的冗余操作。
    除非在CAN节点任务中有比将处理好的CAN报文发送出去更重要的任务要做，一般来讲，报文发送任务在节点任务中应该具有最高的优先级，以保证CAN系统的实时性。
    ③LPC2368的最高运行速率可达72 MHz，而CAN最高传输速率为1 Mb／s。一般情况下，即使连续接收到2个报文，CPU也完全有能力在接收完第、2个报文前将第1个报文处理完毕，所以只需要建立一个报文处理任务。
    还有些要完成较复杂任务的节点，譬如车载网络中的中央控制部件(BSI)。在全CAN车载网络中，它同时连接内部网、车身网和舒适网3个网络。作为汽车车载网络系统中枢，BSI任务繁重，对CAN报文的处理经常会被各种中断和内部任务打断，所以不能保证及时处理上一次接收
的CAN报文。另外，由于消息队列是采取先进先出(FIF0)或者后进先出(LIFO)的方式来组织报文的，当消息队列中积攒多个还没处理的报文时，无法先取出优先级最高的报文进行处理。为了能够优先处理重要设备发送过来的报文，必须针对系统中每个与本节点有进行CAN通信关系的节点建立一个独立的报文处理任务。这个任务包含一个独立的消息队列，并且发送报文的节点优先级越高，该任务设置的优先级也应该越高。为此CANl_R1_HANDLE()函数也应该做出相应的修改。修改之后的程序代码如下所示：

    再结合CAN链路层的仲裁机制，就可以保证优先级别高的节点优先发送报文，并被接收节点优先处理。至此，CAN驱动程序的整个脉络已经非常清晰，其总体流程略——编者注。

结语
    本文基于μC／OS-II操作系统、针对实时性要求较高的CAN系统编写的CAN驱动程序简洁、高效，在不同的应用环境下只需添加相应的用户代码，就可以组成完整的CAN驱动程序。但在提高高优先级节点实时性的同时，在一定程度上也降低了低优先级节点的实时性，所以在工程应用中应根据实际需要兼顾高低优先级节点的实时性能。