1、信号角度
从信号角度,主要想再说明下:信号在CAN总线上是电压形式,在软件中是二进制数,这是怎么转换的?信号在软件中是如何变化的?
1.1 数模转换
通过本系列前面文章,我们知道ECU之间通过CAN总线通讯。从信号转换角度:模拟信号到数字信号,比如接收,如图1所示。
其具体过程为:在CAN总线上,信号表现为电压形式,其具体值根据ISO11898和ISO11519标准的定义而来。然后电压信号经过CAN收发器转换成数字信号,即逻辑电平0和1。
接着这些逻辑电平序列将被ECU硬件单元处理,丢弃或存入寄存器。反之,发送过程其实就是一个数字信号到模拟信号的转换过程。
图1 CAN总线到ECU的信号转换
这里若需掌握各个环节的细节:
关于CAN总线特性,可通过ISO11898,ISO11519系列标准研究总线的电器和物理特性。
关于信号转换实现,可研究CAN收发器的原理与特性等。
关于寄存器存储,可细读相应的芯片手册,并动手去配置芯片和调试代码。
1.2 信号变化
上述的逻辑电平序列有什么规律?有什么作用?通过前面文章我们知道CAN协议标准定义了这些逻辑电平序列,使这些数据有了实际意义,其实就是一些数据帧,遥控帧等的信息。
通过配置CAN硬件单元,比如利用IDE的数据就可以决定ECU是否接收某个CanId的数据,进而再准确将接收的相应数据存入相应的寄存器,比如IDE存入IDE相关的寄存器,DLC存入长度相关的寄存器。
当软件通过硬件接口访问相应的寄存器,就可以读取到对应的数据,比如长度,数据等信息。这样软件按照OSI参考模型的架构将这些读取的数据以协议数据单元(PDU)格式逐层向上传输,直到将PDU解包成报文通讯协议规定的信号形式,整个过程如下图2所示。
图2 CAN通讯的信号变化过程 这里若研究各个环节的实现:关于CAN帧定义,可细读CAN协议和ISO11898-1标准。
关于寄存器的存储与提取,可研究相应的芯片手册。
关于CAN通讯架构,可参考OSI参考模型,ISO17356和AUTOSAR文档等。
2、软硬件角度
从软硬件角度,要实现怎么样CAN通讯功能,就决定了要用怎样的硬件和软件。那么从软件工程师角度,是怎么看硬件?又是怎么看软件的?
2.1 硬件
从软件工程师角度,主要是根据芯片手册,ECU原理图和其他驱动的用户手册来助于对软件的理解,比如了解CAN的硬件连接,即从总线连接到哪个PIN,PIN连接到什么收发器,收发器连接到芯片的哪些引脚。或者了解提取寄存器数据,要对芯片进行的哪些配置,怎么配置等。或者更深入地就是硬件特性变化会对软件产生怎样的影响等等。
2.2 软件
从前面文章我们知道,先明确了一个清晰的软件架构,如下图3的中间部分,再从控制流和数据流考虑。若采用一个极其简单的架构,如图3最左侧部分,从寄存器提取完数据,直接给应用层去解析。
但这样的架构显然满足不了软件的安全性,可移植性,可重用性和可扩展性等要求,所以为了满足这些要求,会采用基于OSI参考模型的AUTOSAR架构,如图3最右侧部分,只允许CAN Driver 访问硬件,向上只对接CAN Interface,与上层的模块通讯均由CAN Interface统一管理,通过PduR路由到更多的上层模块,减少接口等等。
当然前面文章出于内容更易懂且精炼的考虑,采用了图3中间部分的基于OSI参考模型的AUTOSAR架构的简约版。
图3 CAN通讯的软件架构,引自[1]
这个软件架构的CAN通讯控制流如下图4所示。前面文章已经大体上介绍了CAN发送与接收的控制过程,比如不同模块如何进行数据传输,同一模块中数据传输所需具备的条件。另外也介绍了这些过程所涉及的接收通知,发送,发送确认的相关函数与动作。抽象地讲就是实现一个功能需先要以一定的时序组织不同的模块,然后各个模块要满足各自一定的条件才去采取执行某些活动,最后考虑这些活动如何具体地一步一步实施。
图4
当然通过控制流不难发现,数据流也极其重要。基于OSI参考模型,协议数据单元(PDU)在不同的层会有不同的名字,比如数据链路层的PDU叫L-PDU,网络层的PDU叫N-PDU,交互层的PDU叫I-PDU。我们根据这些PDU和其他信息的映射关系,链接关系,就可构建起整个CAN通讯功能的数据流,类似于图5。
这样使得我们能更好理解AUTOSAR配置工具,比如VECTOR或EB工具配置内容的设置和链接关系;也能更深入AUTOSAR的CAN通讯实现原理与方法,比如硬件的访问机制,从L-PDU到N-PDU到I-PDU的映射逻辑等。
图5 PDU的传输,引自[1]
这里若想研究软件的各个模块,可根据ISO11898-1, ISO17356-4和相关AUTOSAR文档。
3、功能视角
功能需求决定了硬件和软件,所以先看软件实现了怎么样的功能,然后再看软件具体是怎样实现的。正如目前文章介绍的只是最常见的CAN通讯发送与接收功能,没有考虑通讯错误的情况,也没有考虑总线关闭的情况。为了完善CAN通讯基本功能,也为了强化CAN通讯功能,下面将大概列举出来,也算是预告下后面文章的内容。
对于CAN通讯错误的情况,CAN协议标准定义了一套完成的错误处理机制。比如: 针对总线信号有定义错误帧,下图6所示。
图6 错误帧定义,引自[2]
针对总线通讯单元有定义主动错误,被动错误和总线关闭状态,如图7所示。
图7 单元的错误状态,引自[2]
针对CAN通讯网络有定义无通讯模式,静默模式,完全通讯模式,如图8所示。
图8 CanSM状态机,引自[3]
对于CAN数据帧数据长度不够的情况,有提出一种更灵活的CAN数据帧,即CANFD。
图9 CANFD概念,引自[4]
对于CAN通讯网络能被唤醒的情况,如下图10所示。
图10 具备唤醒的CAN网络示意,引自[5]
就先列出这些典型的CAN通讯功能,通过这些新功能不难发现:为了应对日益增加的功能需求,不管是针对个人还是企业,硬件还是软件,其实都需要不断地进行更新和强化。
到此我们就从3个视角既回顾了CAN通讯的基本发送与接收功能,也提出了CAN通讯的新功能,为了让大家更加全面且系统地了解CAN通讯功能,后面文章将在CAN发送与接收的主树干上继续生枝发叶。审核编辑:刘清
免责声明:文章内容来自互联网,本站不对其真实性负责,也不承担任何法律责任,如有侵权等情况,请与本站联系删除。
转载请注明出处:基于AUTOSAR的CAN通讯介绍-autosarbuilder https://www.yhzz.com.cn/a/7494.html