基于μC/OS-Ⅱ的线控转向中的FlexRay总线通信设计
段建民 汪然 于涌川
摘要： 本文基于μC／OS-II操作系统，设计了线控转向中FlexRay总线的通信部分。在满足实时性要求的基础上，利用其多任务的特点，节约了系统资源，避免了死锁问题的出现，并增加了通信故障检测报警功能，为今后开发线控转向系统奠定了基础。
Abstract：
Key words :
近年来，随着汽车工业和电子工业的不断发展，汽车线控转向技术成为了研究的热点，并提出了包括路感模拟、转向稳定性以及总线技术等诸多关键性问题并加以研究。其中的总线技术，已经得到了众多知名汽车公司的积极研究与应用。一些汽车制造商目前计划采用FlexRay总线，这是一种特别适合下一代汽车应用的网络通信总线，具有容错功能和确定的消息传输时间，能够满足汽车控制系统的高速率通信要求。
FlexRaY是时间触发的通信总线，对实时性要求较高，因此仅仅依靠由简单循环和中断服务程序组成的嵌入式程序将无法满足要求。同时，FlexRay通信在启动和运行过程中，需要利用循环对总线状态进行查询，既浪费大量的系统资源，又容易造成程序死锁，成为应用中的难点问题。
基于上述问题，本文基于μC/OS-II实时操作系统，设计了线控转向中FlexRay总线的通信部分。在满足实时性要求的基础上，利用其多任务的特点，节约了系统资源，避免了死锁问题的出现，并增加了通信故障检测报警功能，为今后开发线控转向系统奠定了基础。
1 FlexRay总线技术
为了满足汽车线控技术的需求，FlexRay联盟于2005年发布了FlexRay总线协议。其主要特点有：双通道传输，每个通道的传输速率高达lO Mb／s；具有灵活的使用方式，支持多种网络拓扑结构；负载率高；提供冗余机制。
从开放式系统互连参考模型角度来看，FlexRay通信协议定义了四层结构：物理层、传输层、表示层和应用层，各层功能描述见表1。表示层中，通信状态切换控制整个FlexRay通信的运行过程，具有十分重要的作用。
FlexRay协议操作控制(Proposal Operation Control，POC)将通信状态分为几种状态，分别为：配置状态(默认配置、配置)；就绪状态；唤醒状态；启动状态；正常状态(正常主动、正常被动)；暂停状态。其状态转换图如图1所示。当控制器主机接口(Controller Host InteRFace，CHI)给通讯控制器(CC)发送命令后，CC从暂停状态进入默认配置状态，满足配置条件后进入配置状态，完成网络初始化和节点通信任务初始化；之后可以进入就绪状态，完成节点内部通信设置，如果没有满足通信就绪条件，就返回配置状态继续配置；在就绪状态，CC可以发送唤醒帧，唤醒网络中没有在通信的节点，也可以获得CPU的启动通信命令，完成与FlexRay网络时钟同步；启动成功后进入正常状态，完成数据的收发；当出现错误时，可由正常状态进入暂停状态，重新等待CHI命令。
由此可见，控制器需要按照POC状态进行相应操作，因此会出现对POC状态的循环检测，容易造成程序死锁以及占用大量系统资源。按照操作系统的介绍，其任务是以循环的形式存在的，因此可以将检测POC状态放入任务中单独执行，通过操作系统进行任务调度，可以避免影响到其他任务中程序的运行，并且提高程序的执行效率。
2 基于MC9S12XF512的μC／OS-Ⅱ移植
μC／OS-Ⅱ是源码公开的操作系统，具有执行效率高、占用空间小和实时性能优良等特点。利用该操作系统的任务机制，设计实现Flex-Ray协议，可以大大提高系统的实时性和稳定性，并且可以避免检测POC状态时的死锁现象。
目前市场上支持FlexRay通信的单片机较少，只有Freescale公司的技术比较成熟。考虑到成本问题，选择16位单片机MC9S12XF512作为系统控制器芯片。操作系统的使用首先要解决的就是移植问题。根据μC／OS-Ⅱ的文件结构，移植时需要对OS_CPU．H，(OS_CPU_A．ASM和OS_CPUC．C三个文件进行修改，以适合MC9S12xF512芯片的需要。
2．1 修改OS_CPU．H文件
OS_CPU．H文件定义与CPU相关的硬件信息，包括各种数据类型对应的存储长度等。针对MC9S12xF512中的堆栈是由高地址向低地址增长的，所以常量OS_STK_GROWTH必须设置为1。同时，定义任务调度函数OS_TASK_SW()设置为软中断源。
2．2 修改OS_CPU_A．ASM文件
OS_CPU_A．ASM文件是使用汇编语言编写与任务调度部分有关的代码。包括任务级任务切换函数OSCtxSw()、中断级任务切换函数OSIntCtxSw()、以及让优先级最高的就绪态任务开始运行的函数OS-StartHighRdy()。
MC9S12XF512芯片不仅设有FLASH页面管理寄存器PPage，也有RAM页面管理寄存器RPage、E2PROM页面管理寄存器EPage以及全程寄存器GPage。当时钟节拍中断发生时，芯片会自动把CPU寄存器推入堆栈，但是并不包括上述各寄存器，因此在OS_CPU_A．ASM文件三个函数中，均需要加入将寄存器入栈和出栈的语句。由于篇幅有限，仅以PPage代码为例：
寄存器的入栈必须按照GPage，EPage，RPage，PPage的顺序，出栈则相反。
2．3 修改OS_CPUC．C文件
OS_CPUC．C文件是使用C语言编写与任务调度部分有关的代码，包括任务堆栈初始化函数OSTaskStklnit()和时钟节拍中断服务子程序OSTicklSR()。
2．3．1 修改任务堆栈初始化函数0STaskStkInit()
由于μC／OS-Ⅱ是利用中断方式来实现任务调度的，因此需要使用函数OSTaskStklnit()来模拟发生一次中断后的堆栈结构，按照中断后的进栈次序预留各个寄存器存储空间，而中断返回地址指向任务代码的起始地址。编写时需要根据芯片的中断后，X，Y，A，B，SP等寄存器入栈顺序来进行代码编写。首先在例程OSTaskStkInit()函数处设置断点，然后单步执行程序，观察X，Y，A，B，SP等寄存器状态是否与程序编写的存储值对应。发现对应于堆栈指针SP值的存储区地址是模拟中断时进栈的存储地址，而其中保存任务程序指针地址的内容是错误的，即不是任务的指针地址，因此每次在需要调用任务执行时都进入了错误的地址进行执行，并没有找到任务的代码。通过单步执行OSTaskStkI-nit()函数，可以发现原程序在存储任务代码指针PC值时，只存储了PC指针的高8位，但后8位未存，导致指针指向错误。因此修改程序为：
*--wstk=(INTl6U)((INT32U)task)；
2．3．2 修改时钟节拍中断服务子程序OSTickISR()
时钟节拍中断服务子程序OSTickISR()负责处理所有与定时相关的工作，如任务的延时、等待操作等。在时钟中断中将查询处于等待状态的任务，判断是否延时结束，否则将重新进行任务调度。可以通过调用OSIntEnter()。OS_SAVE_SP()，OSTimeTick()和OSIntExit()四个函数进行实现。OSintEnter()函数通知μC／OS-Ⅱ进入中断服务子程序，OS_SAVE_SP()函数用来保存堆栈指针，OSTimeTick()函数给要求延时若干时钟节拍的任务延迟计数器减1，当反复运行该程序后，计数器为0时，则表明该任务进入了就绪状态，OSintExit()函数标志时钟节拍中断服务子程序结束。
之后最重要的一点，就是要将中断服务子程序OSTickISR()与任务级任务切换函数OSCtxSw()添加到系统中断向量表的相应位置中。这里使用的是实时时钟中断模块(RTI)来实现时钟中断的产生，因此要将OSTickISR()连接到向量表RTI位置。OSCtxSw()函数是利用软中断来实现任务的切换功能的，因此软中断服务子程序的向量地址必须指向OSCtxSw()。
在进行上述程序编写后，下载代码到硬件中，μC／OS-Ⅱ就可以在本系统上实现运行了。
3 通信程序设计
利用任务形式来解决POC状态的检测问题，不仅可以提高程序效率以及避免死循环现象，同时，还可以建立通信故障检测报警任务，在不同的通信状态下，对驾驶员提供故障信息，方便处理。
线控转向程序结构包括系统初始化、通信控制、数据采集和控制算法四大部分。这里只对其中的系统初始化及通信控制部分进行了设计。
3．1 系统初始化
在主程序main()中，首先对MC9S12XF512芯片进行初始化，包括：时钟初始化、I／O口初始化、A／D模块初始化、PWM模块初始化以及FlexRay协议配置初始化。之后，调用OSInit()函数对μC／OS-Ⅱ操作系统进行初始化。接着创建三个任务，按照优先级顺序9、1l、13，分别为FlexRay通信启动任务、数据接收发送任务和故障检测报警任务，由这三个任务实现线控转向系统的通信部分功能，其他部分功能可通过创建其他任务进行扩展。最后调用OSStart()启动内核运行，让任务在操作系统的管理与调度下运行。
3．2通信任务设计
以Freescale公司开发的针对该芯片的FlexRay通讯传输层和表示层的驱动程序为基础，进行应用层的程序设计，即编写通信任务程序，完成协议的运行过程。
3．2．1 FlexRay通信启动任务
按照上文介绍的FlexRay协议中定义的协议运行过程，当对FlexRay通信进行初始配置后，协议将进入就绪状态，之后发送启动节点命令等待协议状态由启动状态变为正常主动状态；在正常主动状态中，首先发送关键帧启动网络中的其他节点，发送完成后进入到节点唤醒状态，然后开启FlexRay通信的各种中断，包括：传输中断、接收中断、存储区中断以及定时器中断等，最后挂起任务等待检测到通信故障时进行唤醒；协议正常被动状态是在通信出现故障时，重新配置协议，进行协议的重启。需要注意的是用户必须在多任务系统启动以后再开启时钟节拍器，也就是在调用Osatart()之后，由任务优先级最高的那个任务开启RTI中断，否则系统容易死锁。程序流程图如图2所示。
3．2．2 数据接收发送任务
FlexRay数据的接收发送是通过中断服务程序进行的，因此在该任务中，只需判断POC状态是否进入正常主动状态，如果是则使用全局变量对接收函数Fr_receive_da()和发送函数Fr_transmit_data()的消息缓冲区进行数据的读取和更新。
3．2．3 故障检测任务
在通信过程中，当其他节点因故障重启或是通信线路中断时，可以利用故障检测任务检查POC状态，当协议运行在正常被动状态时，则判断为通信线路出现故障，将故障LED指示灯设定为闪烁状态；当协议运行在暂停状态时，则判断为节点控制器故障，故障LED指示灯设定为常亮状态，并对FlexRay通信启动任务进行解挂，重新对协议进行配置，待故障解决，系统可以自动启动节点运行。程序流程图如图3所示。
4 实验验证
使用Vector公司的CANoe软件，可以方便地观察FlexRay总线上的数据流情况。实验中，将CANoe软件提供的FlexRay接口板VN3600接入总线网络中，之后参考MC9S12XF512芯片手册中FlexRay通信的MicroTick定义为25 ns，因此在FlexRay初始化定义中，设置参数P_MICRO_PER_M-ACRO_NOM为40，则一个MareroTick等于40个MicroTick，也就是说，FlexRay通信配置的基准时间片为lμs。据此，配置通信周期为5 000 μs；1个静态时槽长度为24μs，共有91个；1个动态时槽为5μs，共有289个；特征窗与网络空闲时间为1 371μs。
程序中对节点Node_A和Node_B的时槽定义如表2所示。
实验结果如图4所示，运行时间2 289 s，时槽变化与周期数均与设计一致，数据收发正常。由图5可知，帧速率为3 200帧／s，总计传输7 369 600帧，没有出现无效帧与错误帧，达到了实时性和稳定性的要求。
在通信过程中，分别进行故障模拟实验。
(1)突然断开总线来模拟应用现场出现线路故障的情况，可以发现数据停止更新，故障检测LED指示灯闪烁，说明程序检测到了线路故障问题并进行报警。当再次连接总线后，故障检测LED熄灭，数据继续更新，说明通信自动重新启动。
(2)将任意一个控制器进行掉电，模拟单一控制器故障情况，可以发现数据停止更新，故障检测LED指示灯开始常亮，说明程序检测到了任意节点故障导致通信中断的问题并进行报警。当再次开启掉电控制器后，故障检测LED熄灭，数据继续更新，说明通信自动重新启动。通过以上两个实验，验证了故障检测报警功能良好。
5 结语
针对线控转向系统FlexRay通信过程中存在的问题，将实时操作系统μC／OS-Ⅱ应用于系统中，进行了代码移植和通信任务设计。之后通过硬件实验，对数据结果和故障检测进行了测试，从实验结果可以看出，该系统解决了FlexRay总线应用的复杂问题，并利用μC／OS-Ⅱ操作系统保证了系统实时性、稳定性和安全性的要求，为今后实现线控转向系统在汽车辅助驾驶和智能驾驶方面的应用奠定了基础。
来源：现代电子技术
此内容为AET网站原创，未经授权禁止转载。