毕业设计（论文）-CANFlexRay网关的设计与实现.doc

摘要摘要为了解决CAN(Controller Area Network)网络和FlexRay网络之间的数据共享问题,提出了一种CAN/FlexRay网关设计方案。通过对两种网络的分析和研究,设计实现了基于处理器的网关的硬件和软件。 该网关完成了CAN网络和FlexRay网络的互联,实现了不同网络设备的数据共享问题。 关键字：CAN，FlexRay，网关51AbstractABSTRACTIn order to handle the data sharing between CAN(Controller Area Network) and FlexRay networks, a design scheme of CAN/FlexRay gateway is proposed. By analyzing and researching these two networks, a gateway processor-based hardware and software is designed and implemented. The interconnection between CAN and FlexRay networks has been achieved by CAN /FlexRay gateway which can share data between two different networks equipment. Keywords：CAN,FlexRay,gateway目录目 录第1章绪论11.1课题研究背景11.2 国内研究现状21.2.1CAN总线技术21.2.2FlexRay总线技术31.2.3车载网关技术41.2.4嵌入式实时操作系统C/OS-III5第2章网关技术分析与研究72.1网关技术分析72.2网关技术研究92.2.1消息转换92.2.2消息调度102.2.3消息存储12第3章硬件设计143.1总体设计143.2FlexRay模块的设计153.3CAN模块的设计16第4章C/OS-III194.1概述194.2C/CPU描述模块214.2.1 cpu.h文件234.2.2 cpu_a.asm文件244.3C/OS-III CPU描述模块254.3.1os_cpu_a.asm文件254.3.2os_cpu.h文件304.3.3os_cpu_c.c文件304.4BSP模块314.5测试移植代码32第5章软件设计335.1总体设计335.2系统初始化流程335.3FlexRay模块345.4CAN模块初始化395.5FlexRay到CAN数据转发流程405.6CAN到FlexRay数据转发流程43第6章总结与展望456.1全文总结456.2未来工作展望45参考文献46致谢47外文资料原文48外文资料译文50第1章 绪论第1章绪论1.1课题研究背景随着汽车智能化的发展，相对于传统的机械控制系统，智能化汽车在驾驶体验随着汽车电子岛发展有了长足的进步。电子产品纳最早引入汽车岛时候主要用于管理系统，紧随其后的是汽车音响。如今，包括传动系统、车身、底盘、辅助驾驶系统以及主动和被动安全系统在内的所有主要系统都实现了电子控制。和传统岛机械控制系统相比，电子控制系统在节能减排、绿色出行等方面有着相当优势，这也是今后电子控制的发展方向，尤其是降低二氧化碳的排放量、提高燃油的利用效率等。同样电子控制在汽车安全保障方面也有着不俗的表现，随着电子设备在汽车控制系统的应用，汽车中增强安全和舒适体验岛功能越来越多，实现这些功能的电子控制单元（一下称ECU）也就越来越多。如今高端汽车有100多个ECU。早期时候，ECU之间大多数比较独立。对着电子控制系统所能提供的支持越来越多，所要用到的ECU数量也随之上升，功能分散到多个ECU上实现的分布式系统开始逐步取代组网到一起的ECU。早在上世纪90年代，研究汽车总线的前辈们就发现将这些相对独立的系统组网到一起实现相互交互是一件大有裨益的事情。CAN总线网络也正是在那时候推出的。但随着系统复杂度越来越大，人们又认识到车内网络不仅要提供更快速的数据传送，而且还必须提供确定性的和具备容错功能的通信链路。所以，先进的分布式控制系统是一个发展的必然趋势。在可预见的十几年内的CAN总线仍能胜任其车载总线的工作。事实上，采用FlexRay可能未必会对CAN应用（如雨刷和电控车窗）产生太大的影响。因为这些都仅限于局部控制，无需与汽车其余部件进行大量通信，而且只需要很低的数据带宽。但是随着电子技术的发展，电子器件成本下降以及减少网络设备复杂度将会是CAN最大的敌人。因为FlexRay能够全面降低复杂性，并可提供更经济最有效的一流解决方案。同步数据传输是确定的特性，使得FlexRay总线可以同时保证提供最小的消息传输延时和消息抖动。CAN中所采用的判优方法可使高优先级消息先行发送，而让低优先级消息延迟发送，所以只有最高优先级消息的时延才是确定的，其他消息的时延则无法给出预测。FlexRay为同步传输部分中的每个消息预先设定独立的传输时间。FlexRay在全局标准时间基础上采用冗余和容错分布式始终实现时钟同步，从而保证所有网络节点都能在一个紧凑的预先设定的精确时间窗中有秩序得工作。在同步通信阶段，每个ECU都被分配若干个固定时隙（具体根据ECU数据吞吐量网络复杂度等因素决定）。这种分配保证了在同步传输阶段的全部消息无需竞争带宽，当然也无需经过判优。虽然车载总线的发展速度非常快，不过令人遗憾的是，至今仍没有一个通信网络可以满足车载总线对成本、开销、吞吐量、实时性能和复杂性能等方面的要求。所以，汽车原始设备制造商仍将继续采用多种联网协议（包括CAN、LIN和MOST）。未来的一段时间内汽车将是多种网络并存的情况。2006年宝马公司率先将FlexRay总线技术应用在新型X5的电子控制减震器系统中。之后X5中的自动驾驶系统中也采用了FlexRay解决方案，通过高速的FlexRay总线对随时变化的道路状况进行快速的反应并作出补偿。许多其他的七成制造商也纷纷步其后尘加快FlexRay总线的研发速度。就像X5的减震器系统与自动驾驶系统一样，FlexRay总线的在汽车上的应用将会从某几个控制系统开始来取代CAN总线。其他的FlexRay部署将能够实现一些CAN无法支持的新应用。但在FlexRay技术成熟和实现成本降低之前，FlexRay和CAN将一起并存。1.2 国内研究现状1.2.1CAN总线技术早在1994年戴姆勒公司就开始了车载CAN总线的开发与应用，随着电子技术的发展与汽车工业的发展，越来越多的公司开始根据自己的需求来自定义CAN总线的协议。当前常用的三个版本分别是容错CAN（FT-CAN）、高速CAN（HS-CAN）和单线CAN（SW-CAN）。CAN总线在汽车上的应用主要分为控制功能与信息采集，其中控制功能包括车门、车窗、雨刷等车身自动控制设备，信息采集功能包括采集水温、车速、发动机转速、油量等信息的实时数据。高速CAN多数用于传动系应用，包括引擎、传动和变速箱以及防抱死刹车系统（ABS）。还有一种CAN是基于时间触发式的（TT-CAN）。虽然TT-CAN线在带宽1Mbps时最大长度只有40米，不过应用在汽车上还是足够的。在实际应用中我们发现CAN协议具有可变并且较大的抖动。为了增加TT-CAN的可预测性和可靠性，凯特林大学的研究人员Juan R. Pimentel和MG公司的Jason Paskvan通过大量试验数据来分析证实了CAN的通信架构中的抖动特性。他们提出了一种更具确定性的FlexCAN，FlexCAN这种拓扑结构在不失灵活性的前提下，用于线控是极好的。德尔福公司的B. Peery Commpton提出了另一种串行的通信协议，图1.1 ，这种协议能够在FlexRay和CAN之间发现成本、开销、吞吐量、实时性能和复杂性能的最佳平衡点。也就是Goldilocks协议，这不单单只是个协议，它还包括了基于单个消息调度原理的协议集。Goldilocks协议后向兼容CAN车载网络协议，在性能和功能方面与FlexRay网络协议相比是不相上下的，在速度方面就。Goldilocks与CAN的优先级仲裁是移植的，但它基于FMA原理执行调度和离线仿真。1.2.2FlexRay总线技术自从1999年戴姆勒与宝马开始进行FlexRay研究至今FlexRay总线已经走所了十几年的历程了，在这起监FlexRay总线技术有了长足的进步，逐渐的走向了成熟，被越来越多的汽车生产厂商所看中。从BMW采用FlexRay针对玄关系统所作的减震控制我们可以看到FlexRay总线用在车身控制是很有发展前景的。虽然该功能可由CAN总线实现，不过在实际的车身控制中运用新技术替换CAN，更能凸显FlexRay出众的性能。但是CAN在将来的汽车控制架构中仍旧保持着成本优势。虽然CAN无法满足现代汽车对总带宽的要求，但灵活的工程设计至少会暂时弥补这个短板。在未来的几年里，传统的汽车机械系统（如刹车和转向系统）将被通过高速容错通信总线与高性能MCU组成的电子控制系统所取代。在一辆装备了综合驾驶辅助系统的汽车上，X-By-Wire将为驾驶员带来更舒适驾驶体验。显然FlexRay的特性使它在下一代汽车应用的网络通信系统中成为一枝独秀。木且已经成立了FlexRay协会，促使各大汽车零配件OME厂商在X-By-Wire系统上采用同一个标准。宝马、戴姆勒克莱斯勒、摩托罗拉和飞利浦半导体联合开发和建立了一套关于FlexRay总线的标准，该标准进一步提高了FlexRay的一致性、可靠性、竞争力和效率，而且海简化了开发和使用流程、降低了实现成本。FlexRay将会使汽车发展成一个完全的可靠性强的电控系统，彻底摆脱对后备机械系统的需要。X-By-Wire的应用除了对总线系统的速度有较高的要求，还需要总线具有确定性和容错行同时又支持分布式控制系统，这样就保证了汽车应用对可靠性、可用性、灵活性和高数据速率的要求，这一点是其他总线无法比拟的。FlexRay通信系统远比其他通信协议更复杂，除了协议本身，它还包括一个专用的高速数据收发器，此外海定义了FlexRay节点内各组建间的软硬件接口。FlexRay协议定义了网络化汽车系统内通信处理的格式和功能。不同于现有的汽车协议比如MOST、CAN等，FlexRay在可靠性上有着极大的优势，并在汽车各电子系统之间的通信中扮演重要角色。应用FlexRay等新的数据传输协议将会明显的提高总线实时性以及可靠性。FlexRay协议也是实现X-By-Wire的良好平台。如图1.2所示X-By-Wire正在逐步的使用电子控制元件来取代传统的液压和机械控制系统。1.2.3车载网关技术目前国内的网管技术研究还局限于学术层面，没有走向市场化，比如有文献探讨研究CAN/LIN总线嵌入式网管的实现技术，还有的对CAN/MOST总线网关的应用实现技术进行研究。但是多数对车载网关的研究偏重于硬件实现，在对网关内部数据调度、数据转换、容错能力以及故障回复处理系统的为数不多。通常收到特定的硬件限制，网关内所采用的数据转发方法和数据调度以及错误处理等操作都会直接影响到网关的性能。在提高网关转发效率上，主动队列治理算法中的随机早期丢弃算法是一个不错的选择，也就是说以某一概率丢弃或标记数据包来获取系统网络拥塞的情况。当然这种方法在因特网这种对实时性要求不苛刻的网络环境下是比较靠谱的，不过却很难满足车载网络对实时可靠性的要求。至于FlexRay/CAN网关，有文献探讨了利用OSEK操作系统（OSEK/OS）OSEK/VDX2005和OSEK车载网络管理（OSEK/NM）OSEK/VDX2004来实现整个网关架构。OSEK/OS是一个标准化的实时操作系统的分布式自动化控制系统单元。所提出的架构符合要求的可重用性，灵活性 ，通过使用标准化和调制的可移植性。此外，按照这个架构构建的系统，可以有限的减少不必要的网络开销和失败。尽管确定路由路径是根据目的地节点状态动态变化的，这也不妨碍OSEK系统能够提供可靠性的支持。保证网关的可靠性关键要解决好时间触发网络和事件触发网络是同时链接到网关产生的定时冲突。此外，网关应当存储由联机记录仪的跟踪信息，这样回溯数据日志的时候就很容易发现故障实例了。1.2.4嵌入式实时操作系统C/OS-III说到C/OS我们就不得不谈到广泛应用的C/OS-II了，同Linux一样，它也是一款开源的系统，由于绝大部分代码都是采用标准C编写的，所依据优极强的可移植性，当然作为一款嵌入式实时系统C/OS-II代码在执行效率、实时性能和可扩展性都有着极为出色的表现，固化所需的空间也非常小，最精间的内科可剪裁到2KB。联邦航空局（FAA）商用航行器认证也是对C/OS-II在嵌入式实时操作系统中优异表现的肯定。C/OS-III作为C/OS-II的第三代内核，提供了当下实时系统内核所具有的全部功能，包括资源管理、同步、任务间通信等等。此外C/OS-III还具有其他实时系统不具备的性能，比如在运行是完成性能测试（内核为每个时间都附加上时间戳，这样用户可以追踪到事件开关中断的时间，由此得到事件的响应时间），互斥型信号量之间可以互相嵌套、可以相任意任务发送信号量或者消息（该任务可能没有请求发送信号或者请求发送消息队列），任务可以被内核的多个院所挂起，这样在实现为其他任务的服务或“出错代码”服务的任务时就更加方便了。随着嵌入式系统规模越来越大以及对负载均衡的要求越来越苛刻，无法支持轮询调度C/OS-II在处理起来这些问题上就显得有些捉襟见肘了，针对这一新的需求C/OS-III不仅增加了优先级数量而且还允许多个任务使用时间片调度法共享同一个优先级，用户在程序运行中动态配置或者变更实时操作系统内核资源，不如任务栈、事件标志组、消息队列、存储块划分等。在资源复用方面，也做了很大优化，在RAM允许的情况下用户可以定义任意多个内核资源以及任意分配的存储块容量，由于C/OS-III在设计之初就考虑到了在32为处理器上的应用，所以能够广泛的适应各种CPU架构，可以方便地按照不同的CPU架构优化，让其数据位数宽度可灵活的调整为CPU的最佳位宽；一些特殊的汇编指令可以让其优先级解决算法（priority resolution algorithm）变得更加灵活，C/OS-III针对以ARM Cortex为代表的新一代CPU，面向带有可用于优先级差表的硬件指令（如CLZ、FFI）的CPU的嵌入式应用，也就是说C/OS-III允许利用某些CPU的特殊硬件指令来实现高校的任务调度算法，而无需使用C/OS-II中所采用的软件任务调度算法，通过给调度器上所的方法实现临界段的进出可以有效的减少开关中断引起的额外开销，这样时间可以能够得到更及时的响应。通过C/Probe 工具能够让用户像调试普通软件程序一样在程序运行在硬件平台上时观察和修改各种变量。此外Micrium 还提供了很多与C/OS-III内核配套的软件的开发包。与其他的大型商用RTOS类似，C/OS-III同样能以传统的BSP方式，实现诸如USB主机、文件系统、TCP/IP协议栈等，还提供系统本身的调试工具以及多种MCU的开发包等。第2章 网关技术分析与研究第2章网关技术分析与研究2.1网关技术分析我们平常所能接触到的网关多数是应用在以太网上的，这些网关通常侧重于提高网络传输效率，而不是实时性能，因为以太网上的延迟和误操作所造成的错误结果远远小于在汽车上或者其他工业控制上。作为车上网络的网关，必须把实时性能作为一项重要的性能指标，因为汽车在形式过程中一个错误的操作都可能会造成灾难性的后果。所以车上网关必须满足一下要求：可靠性，容错性，可重用性，灵活性，可移植性，安全性。在提高网关的可靠性方面，我们认为至少可以从一下三个方面考虑。首先，高优先级的消息必须尽快转发。在这里我们选择全局优先级机制来解决这个问题。根据信号的重要性不同，我们给CAN、FlexRay总线上的保温制定不同的优先级。信号的重要程度取决于次信号对车辆安全形式的影响程度，高优先级的消息将会有限被转发，而低优先级的消息将会暂时存储在发送缓存里。其次，网关要保证不转发失败（错误）节点的报文，也就是不想无法收到报文的节点转发消息。在车载网络系统中，丢失像刹车操作等的消息可能酿成严重的交通事故。此外CAN总线和FlexRay总线都提供了失败重传的机制，这样就增加了不必要的网络负载。在分布式系统中使用OSEK/NM，我们可以直销网络配置，即使替代路径被发现，纪实这样的替代路径有助于失败节点恢复，在这段时间此节点仍旧是失效节点。最后，网关向目的地节点发送消息，通过使用替代路径。如果没有替代的路径，然后网关将暂停发送到目的节点直到其重新被网关认可。再次，网关必须要满足异构协议，假设一条CAN报文在一个给定时间到达。网关根据转换和路由的机制对接收到的报文进行翻译和路由。如果所转换到消息必须被传输到FlexRay总线时隙10，然后翻译和消息格式化过程完成瞬间内，如图所示。但是，如果网关完成的转换过程在图中所示的（c）中所接收到的消息将被发送在下一周期中的时隙10.在这种情况下，由于是简单不连续性和可能的数据丢失，网关将保证不了本次消息传输的可操作性。为了解决这一问题，在接收到消息（信号）的时候，可以考虑引入一个标志。当有消息到达时，置位该标志，当该消息被完全传送到目标网络之后翻转此标志位。在FlexRay动态段时当有消息的标志为是置位，图中（d）此时该消息将会在完成转换时第一时间发送出去。有了这样一个机制，所有CAN消息将会在一个FlexRay消息周期内完成转换。在FlexRay-CAN方向需要解决的一个难题就是波特率的差异，FlexRay总线要比CAN总线的最大通信速度高10倍，因此网关必须提供一个机制来克服因为波特率差异而引起的消息丢失。这里我们采用一个网关意外的机制，对于FlexRay-CAN的关于信号报文，通过双预测模型来减少报文的传送量，纪实传输也只传输变化的参数而不是全部的数据，这样就可以大量减少不必要的负载。此外对于非实时的大量数据，网关将进行暂存，知道CAN总线负载低的时候在予以处理。还有一种情况需要提到，假设一条FlexRay报文Fa在图2.1中所示的（a）时刻到达，其拆解后的报文为FaCAN1,FaCAN2,FaCANn（n1），发往CAN节点x，假设在图2.1所致的（b）时刻开始进行转换后的第一次CAN报文传输，在c时刻另一发往CAN节点x的FlexRay报文Fc到达，拆解后的报文为FcCAN1，FcCAN2FcCANn（n1）。此时就可能造成CAN总线上报文的发送序列为FaCAN1，FaCAN2FcCANiFaCANn的情况，从而打乱Fa的顺序传输。综上所述采用合适的数据帧转换方法和调度算法对网关缓冲区的数据进行管理，可以有效的提高系统的有效负载和降低数据在网关的延迟时间，同时可以保证实时数据传送实时性。这个问题的解决直接影响到网关性能和整个车身网络性能的好坏。因此本文使用基于多消息队列混合调度算法的数据转换方法以及用散列表暂存数据的办法以保证网关的性能，下面将详细的对该方法进行介绍。2.2网关技术研究2.2.1消息转换FlexRay的帧格式如图2.2所示，这里我们选取FrameID的后4位作为消息的目的地址来使用，前7位用来标记优先级。CAN总线格式如图所示，这里我们使用扩展帧格式利用帧id的后5为作为目的地址，其他为暂时用作优先级位。FlexRay/CAN网关需要处理的数据转换有2种，分别为FlexRay/CAN转换和CAN/FlexRay转换。数据转发首先需要解决帧格式的转换问题。真个是的转换如图2.4所示，本文采用多小系帧打包的方法。根据上述对CAN与FlexRay帧结构的分析，为了提高发送效率，选取CAN发送队列中发往统一FlexRay节点的前n个报文存储在FlexRay帧有效数据部分，打包成FlexRay帧的发送。按照之前我们对总线报文的设计，每帧CAN包括携带8为有效数据，FlexRay的有效数据最多为254字节，所以0nW2）。轮转次数为i，非实时数据所栈非实时队列缓冲区比例为Q，阀值X为一小于1的固定百分数，则算法表达如图所示。初始化时，为保证实时消息的发送，W1应尽可能的较W2要大。轮巡的周期一句硬实时队列的权值而定，故每次轮巡硬实时消息都能发送，保证了硬实时消息的实时性。但由于非实时消息的权值W2较小，某一时刻如果非实时消息到来较多，就会造成非实时消息的阻塞延迟较大。在这里依照当前非实时对列中的消息比例，对非实时队列采用动态权值，超出一定比例就动态加1,可以改善非实时消息阻塞的情况，兼顾公平性。如果每一个队列都有需要服务的数据帧，则选取队列的前n个发往统一个目的节点的组包称转发数据帧的格式并发送。如果处理非实时队列是不足n个组包，则从实时队列中找到发往统一节点的报文补足，相反如果处理实时队列是则不必补足；如果队列为空，则不处理此队列，转而处理下个队列。轮转次数为i，非实时数据所占非实时队列缓冲区比例为Q，阀值X为小于1的固定百分数，R1：初始化赋予R1=a，R2=b；ab，a、b均为整数；轮转次数为i=1；R2：对进入网关的CAN帧按实时性分类，进入不同的队列，在队列内部按照EDF算法进行排序。R3：在轮巡过程中，遵循如下规则：如果i=W2，对非实时队列的数据组包发送，在此情况下，如果Q=X，则W2=W2+1；以上情况返回R2；如果iW1，一个轮巡周期结束，返回R1；2.2.3消息存储在报文在网关内部的暂存过程中，由于每个节点所发送的报文数量的差异，不可能为每个节点单独安排一段空间来存储报文。所以一个高校的存储机制也是一个能够提升网关性能的重要因子。为了进行更高小的存储管理，在网关的数据转换时鉴于CAN包文的相对独立性，所以内部FlexRay报文也在进行拆解后以CAN报文的形式存储，利用目的地址为关键字存放在散列表中，为了减小碰撞，提高查找效率，在这里我们使用双重散列法，这里直接选h1为key%slot_size（slot_size为散列表最大长度），h2为key%(slot_size-1)，m=slotsize16第3章 硬件设计第3章硬件设计3.1总体设计根据前面所讨论的网关设计需求，网关主要由以下几个部分组成：MCU及外围电路、CAN模块、FlexRay模块，在这里MCU我们选取Freescale公司的MC9S12XF512作为主控芯片，该款芯片是Freescale公司基于S12X架构，为车身、底盘和安全应用中使用的FlexRay网络节点提供高性能、经济的分布式控制解决方案。MC9S12XF512具有存储器保护单元（MPU）和带有纠错码（ECC）的闪存，以及增强型EEPROM功能（EEE）和调频锁相环（IPLL）。MC9S12XF512的闪存容量有512KB具有更大的可编程空间。3.2FlexRay模块的设计MC9S12XF512V1RM拥有满足FlexRay 3.0 标准的控制器模块，支持10Mbps的双通道高速串行通信。MC9S12XF512内部复杂的FlexRay即存储区根据数据格式分配响应存储空间，并用来存放缓冲消息的帧头、帧状态和帧的有效载荷数据。FlexRay功能模块主要由主机控制接口CHI、协议引擎PE、时钟交互接口CDC三个组件组成，如图3.2所示。协议引擎（PE）具有两发送单元TxA和TxB跟两个接受单元RxA和RxB，用来实现在两个通道上面的收发功能；时钟控制单元（TCU）用来保持整个FlexRay网络的全局时钟的同步；PE的全部活动则由定序引擎（SEQ）来控制。主机控制接口（CHI）提供主机访问模式的配置、控制、状态寄存器以及消息缓冲区的配置、控制、状态寄存器。消息缓冲区优自己的一段存储空间也就是FrM。在FlexRay块存储在帧的报头和有效载荷数据接受的帧或帧中发送的FrM。该应用程序访问的FrM检索和提供的帧是由FlexRay块处理。除了帧报头和有效载荷数据，FlexRay的块存储同步帧相关表格在FrM的应用程序处理的FlexRay位于内存的MCU在系统内存中。在FlexRay块有权访问FrM通过总线主站接口（BMIF）。主机提供的FrM窗口内的其实地址系统内存编程的系统内存的基址高寄存器（SYMBADHR）。系统内存基地址低字节寄存器（SYMBADLR）。所有FrM相关的便宜量存储在便宜寄存器。到FrM窗口的MCU系统的存储器的物理地址指针计算使用的FlexRay内存的基地之的便宜值。跨时钟域单元实现从CHI时钟域的信号交叉的PE时钟域，反之亦然，以允许异步的PE和CHI时钟域。本次实现中，我们选用恩智浦公司早期生产的TJA1080作为FlexRay总线的电气物理层的芯片。输入/输出管理模块用于提供主机对TJA1080的管理功能，包括操作配置、在节点配置的操作模式、星型配置的操作模式等。在工作模式下，MC9S12XF512可直接访问TJA1080的正常收发模块和发送器，完成物理信号到数字信号的相互转换。总线失效检测器用于检测总线上的数据活动状态，如果总线负载较重，TJA1080会自动的关闭发送器，已达到迅速减轻总线上的负载的目的。温度检测模块用于检测TJA1080的温度，当温度超过配置模式中设定的值时自动关闭总线收发器。唤醒模块根据总线失效检测器中反馈的信息来唤醒TJA1080以及给出总线活动状态信号，当总线空闲超过一定时间是将TJA1080转为睡眠模式，降低系统功耗。3.3CAN模块的设计CAN模块主要由收发引擎、验收码过滤和缓冲区、配置寄存器、时钟源、低电平电流检测模块组成。详细如图所示。低通电流检测模块用于监测总线电平变化，用来唤醒收发引擎（总线空闲时RXCAN为高电平，总线空闲一段时间后MSCAN模块会计入休眠模式）。收发引擎模块根据CAN协议对发送报文编解码（此处为数字信号，优收发器转换为差分信号）。验收滤波器对接收到的报文进行过滤操作，通过校验的报文才会存储在接收缓冲区内。配置寄存器模块则负责对哥哥模块功能的设置，以及中断信号的产生。MC33742是Freescale公司专门面向汽车电子控制设备开发的符合CAN2.0协议的具有总线收发器功能的单片机。两个电压调节器VDD和V2可以有效的应对汽车负载突降瞬态状况、一个支持最大1MBps的高速CAN收发器、可选择的看门够电路和低功耗管理模块。作为受保护的电压调节器VDD可提供高达200mA的电流。使用不同的外部PNP晶体管，监视器双电压稳压器可以方便的调节电流输出。因为只有TJA1080一款芯片对电源优+12V的需要，所以这里我们使用MC33742的VSUP端口作为电源省去了额外的电压调节期间。通过L0-L3引脚可以用来链接外部时间，在收到CAN消息是或者优外部时间，唤醒SBC离开停止和休眠模式。通过SPI接口还可以将看门狗电路配置为窗口或超时操作、或者在调试模式中禁用看门狗电路。低功耗模式可以配置为正常模式、待机模式、停止模式或者休眠模式，尽量减少响应时间和低功耗之间的冲突。第4章 C/OS-III第4章C/OS-III4.1概述C/OS-III操作系统的移植就是让一个实时内核针对特定的处理器作出响应的改造，来让这个才做系统可以在这款处理器上运行。MC9S12XF512所用的ANSI C编译器能产生可重入代码，并且支持八个级别的嵌套中断，能够灵活的分配给每个中断优先级的中断源和一个非屏蔽高优先级中断（XIRQ），八个增强型捕捉定时器，可重入中断响亮表以及512KB的Flash、1KB的EEPROM和4KB的RAM。综上所述，MC9S12XF512具备移植C/OS-III的条件。图中显示了MC9S12XF512处理器的编程模式下寄存器结构，除了累加器和段寄存器以外，其他寄存器都是16位，在任务切换过程中必须保存所有寄存器的内容。为了能用16位寄存器寻址8M的全局地址空间，MC8S12XF512同样也是用了存储器分段的方法。内存的物理地址用段地址寄存器和偏移量寄存器共同表示。计算方法如下：GPAGE为全局指令专用的段存储器，用来指向整个存储空间。PPAGE寄存器用来映射16KB的FlashRPAGE寄存器用来映射4KB的RAMEPAGE寄存器用来映射1KB的EEPROM本文采用CodeWarrior for S12（X） V5.1（以下简称CW）作为开发工具，CW除了具备将用户程序翻译成MCU机器码的基本功能外，还是一个支持Freescale各型号MCU的源代码级调试器和完整的芯片仿真器等。下图示意C/OS-III的结构以及硬件关系，其中需要在移植过程中尽心改动的主要有C/CPU、C/OS-III和BSP部分，也就是（2）、（3）、（5）、（6）模块。4.2C/CPU描述模块图中（6）C/CPU Specific包含cpu_def.h、 cpu_cfg.h、 cpu_core.c、 cpu_core.h、 cpu.h、 cpu.c、 cpu_a.asm，在这一部分中，主要需要改写的是与处理器有关的数据类型和宏定义。4.2.1 cpu.h文件通常不同的处理器之间字长是不同的，为了确保可靠性，Cpu.h中定义了MC9S12XF512相关的数据类型，不采用C语言中常用的int、short等常用的数据类型，为了能够清楚的表达字长和数据类型，我们在这里对需要用到的数据类型重新定义。下面给出本实现过程中需要注意的关键数据定义：typedef void CPU_VOID;typedef unsigned char CPU_CHAR;typedef unsigned char CPU_BOOLEAN;typedef unsigned char CPU_INT08U;typedef signed char CPU_INT08S;typedef unsigned short CPU_INT16U;typedef signed short CPU_INT16S;typedef unsigned int CPU_INT32U;typedef signed int CPU_INT32S;typedef unsigned long long CPU_INT64U;typedef signed long long CPU_INT64S;typedef float CPU_FP32;typedef double CPU_FP64;typedef volatile CPU_INT08U CPU_REG08;typedef volatile CPU_INT16U CPU_REG16;typedef volatile CPU_INT32U CPU_REG32;typedef volatile CPU_INT64U CPU_REG64;typedef void (*CPU_FNCT_VOID)(void);typedef void (*CPU_FNCT_PTR)(void *);typedef CPU_INT16U CPU_ADDR;typedef CPU_INT16U CPU_DATA;typedef CPU_DATA CPU_ALIGN;typedef CPU_ADDR CPU_SIZE_T;typedef CPU_INT08U CPU_STK;typedef CPU_ADDR CPU_STK_SIZE;typedef CPU_INT16U CPU_ERR;typedef CPU_INT32U CPU_SR;typedef CPU_INT32U CPU_TS;#define CPU_CFG_STK_GROWTH CPU_STK_GROWTH_HI_TO_LO#define CPU_ST_ALLOC() CPU_SR CPU_sr = (CPU_ST)0;#define CPU_CRITICAL_ENTER() CPU_sr = CPU_SR_Save(); #define CPU_CRITICAL_EXIT() CPU_SR_Restore(CPU_sr); #define CPU_CFG_ADDR_SIZE CPU_WORD_SIZE_16#define CPU_CFG_DATA_SIZE CPU_WORD_SIZE_16#define CPU_CFG_ENDIAN_TYPE CPU_ENDIAN_TYPE_BIG1)定义 C/OS-III使用的栈的数据类型，即出入栈数据的宽度为8位；2)定义状态寄存器类型，用来储存CPU状态；3)定义一个时间戳类型，通常用于为某些特定操作定时或者测量任务运行时间等；4)定义堆栈的增长方向从高地址像低地址方向；5)Codewarrior允许用户得到当前处理器的状态字并保存到C函数的局部变量中，这个变量可以用来恢复PSW；6)定义进入临界区的实现方法，调用CPU_SR_Save()函数得到中断发生是CPU状态寄存器的值，并被、关闭所有中断；7)定义离开临界区的实现方法，调用CPU_SR_Restore()函数恢复中断发生前CPU状态寄存器的值，并打开中断；8)定义处理器地址字长为16位；9)定义处理器数据字长为16位，需要注意的是编译器和处理器字长的匹配；10)定义存储器的存储格式，MC9S12XF512内部采取的是大端存储模式。4.2.2 cpu_a.asm文件在这个文件中需要用汇编语言实现CPU_SR_Save()、CPU_SR_Restore()两个函数实现CPU_CRITICAL_ENTER()时，需要通过此函数将CPU的状态寄存器保存到局部变量中。CPU_CRITICAL_EXIT()调用CPU_SR_Restore()函数从这个局部变量中恢复状态寄存器。4.3C/OS-III CPU描述模块图中C/OS-III CPU Specific 中包含3个文件os_cpu.h、os_cpu_a.asm、os_cpu_c.c。其中os_cpu.h文件中优与处理器相关的常量、宏和结构体的定义。需要改写的是一下两条：#define OS_TASK_SW() _asm(”swi”);为了实现认为切换OS_TASK_SW需要模仿一次中断过程，MC9S12可以通过软中断指令swi来实现。#define OS_TS_GET() (CPU_TS)CPU_TS_TmrRd();时间戳可以通过调用CPU_TS_TmrRd()来获取，CPU_TS_TmrRd()可以读取16位的时间计数器ECT_TCNT。4.3.1os_cpu_a.asm文件在这个文件中需要改写以下4个函数：OSStartHighRdy()OSStartHighRdy()该函数优OSStart()调用，功能是让就绪态的优先级最高的任务运行。OSStartHighRdy()默认指针OSTCBHighRdyPtr指向优先级最高的就绪态任务控制块。1)调用用户自定义的钩子函数，通常用户可以在这里自定义一些上下文切换相关的操作；2)将OSRunning设置为TRUE(1)，也就是从此起系统开始运行多任务，这里要注意一点，再次之前至少要建立一个用户任务，否则OSRCBHighRdyPtr是空指针；3)OSStartHighRdy()从任务控制块OS_TCB中获得并恢复堆栈指针；4)OSStartHighRdy()把CPU关于任务切换的寄存器保存到任务堆栈中；5)执行RIT指令从中断中返回，开始运行高优先级的任务。OSStartHighRdy;call OSTaskSwHookldab #$01stab OSRunningldx OSTCBHighRdyPtrlds 0,xpulastaa PPAGEpulastaa RPAGEpulastaa EPAGEpulastaa GPAGErtiOSCtxSW()OSCtxSW()是一个任务级的任务切换函数，在任务中调用，区别于在中断程序中调用的OSIntCtxSW()。在MC9S12XF512系统上，通过执行一次软中断指令实现任务切换，软中断向量指向OSCtxSW()。OSCtxSw;ldaa GPAGEpshaldaa EPAGEpshaldaa RPAGEpshaldaa PPAGEpshaldy OSTCBCurPtrsts 0,ycall OSTaskSwHookldx OSTCBHighRdyPtrstx OSTCBCurPtrldab OSPrioHighRdystab OSPrioCurlds 0,xpulastaa PPAGEpulastaa RPAGEpulastaa EPAGEpulastaa GPAGErti1)将挂起任务的地址段寄存器保存到当前任务的堆栈中，即保存任务被切换前的运行情况；2)调用可有用户定义的应用程序接口函数OSTaskSwHook();3)从OSTaskSwHook()返回后，OSTCBHighRdyPtr被复制给OSTCBCurPtr。也就是说新任务就是当前的任务；4)从OSTCBCurPtr中取出新任务的栈指针；5)复制新任务的优先级；6)从新任务的堆栈中弹出相应值到CPU的地址寄存器中；7)中断返回，恢复程序计数器（PC）和状态寄存器（SR），新任务从被抢栈的点继续运行。OSIntCtxSw()通常中断处理函数会中断更高优先级的任务，并使之进入就绪状态，为了能让被打断的任务能在中断结束后立即恢复运行，需要做任务切换。在中断子服务程序调用OSIntExit()时，慧用到OSIntCtxSw()函数做任务切换，与普通的任务切换函数OSCtxSw()不同的地方是OSIntCtxSw()函数默认CPU寄存器保存在被中断了的任务中，因为之前已经发生了中断也就是没有OSCrxSw()中的(1)操作。同样，堆栈指针也被保存在任务控制块中。OSTickIST()这部分代码是否卸载OS_CPU_A.asm中取决于tick中断是否由CPU自己产生，是否需要用户用汇编语言来实现，也就是说CPU或者MCU中可以预留一个专用的计数器时，才需要下面这段代码：1)同所有C/OS-III的中断服务程序一样，任务的运行状况需要保存到当前任务堆栈中；2)当进入中断服务程序是，需要告诉C/OS-III 进入了中断服务子程序，在此选择将OSIntNestingCtr加1,而不是调用OSIntEnter();3)如果中断服务子程序是第一层，也就是说没有中断嵌套的情况出现，则需要把堆栈执政保存到当前任务的控制块中；4)调用用户自定义的中断处理函数OSTickISR_Handler()；5)中断服务子程序ISR完成后，调用OSIntExit()。如果中断服务子程序ISR使优先级高的任务进入了就绪态，则OSIntExit()不返回，而是做任务切换，让与优先级更高的任务运行；6)逐个恢复寄存器；7)返回中断源;OSTickISR:ldaa GPAGEpshaldaa EPAGEpshaldaa RPAGEpshaldaa PPAGEpshainc OSIntNestingCtrldab OSIntNestingCtrcmpb #$01bne OSTickISR1ldy OSTCBCurPtrsts 0,yOSTickISR1:call OSTickISR_Handlercall OSIntExitpulastaa PPAGEpulastaa RPAGEpulastaa EPAGEpulastaa GPAGErti4.3.2os_cpu.h文件这个文件里只有两个需要改写的宏定义OS_TASK_SW()与OS_TS_GET()，其中OS_TASK_SW()任务级的上下文切换代码石油OSCtxSw()执行的，在OS_CPU_A.ASM中实现的。而OS_TS_GET()通过调用CPU_TS_TmrRd()读取定时器的值来得到系统的时间戳。4.3.3os_cpu_c.c文件这个文件中需要改写的只有OSTaskStkInit()对操作系统的移植起到关键作用。OSTaskCreat()通过调用OSTaskStkInit()，初始化任务的栈结构，将堆栈初始化成中断之后的样子。代码如下：1)通过一个局部指针变量，指向栈起始地址；2)通常p_arg