tms570 can 接收大量数据_CAN通讯系列--CAN总线基础3

上篇文章讲述了CAN总线的特点，以及CAN协议帧的基础知识，包括数据帧和遥控帧。本文将在此基础上通过相关的协议标准，寄存器和整车控制器CAN通信报文来进一步深化CAN协议帧的理解，同时可了解到一个简单版的CAN通讯功能实现。

4 CAN协议标准及其他有关内容

当要深入CAN通讯功能时，就必须得介绍下CAN2.0协议标准和ISO 11898标准。为什么呢？因为只有通过这些协议标准才能掌握CAN通讯的基石，更好地了解CAN通讯功能的硬件与软件。当去了解这些协议标准时，发现CAN通讯框架是基于OSI参考模型来设计。那么什么是OSI参考模型？它有什么作用?接下来从OSI参考模型开始了解。

4.1 OSI 参考模型

引自[3]:
OSI参考模型是一个逻辑上的定义，一个规范，它把网络从逻辑上分为七层，每一层都对应着不同的作用，这七层分别为应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。对OSI七层网络模型的定义，对后续的各种网络技术的评判和分析提供了依据，也是学习网络技术的基础。
OSI参考模型的七层协议的分层目的是为了解决异种机互连的问题，包括互连时所遇到的兼容性问题。分层的最大优点是将服务、接口和协议这三者明确地区分开。
在这个参考模型的数据传输过程当中，不同主机对等层之间会按照协议进行通信，同一主机的不同层之间通过接口进行通信。在这个模型中，每一层将上一层传递过来的通信数据加上若干控制位后再传递给下一层，最终由物理层传递到对方物理层，再逐级上传，从而实现了对等层之间的逻辑通信。

图1 OSI 参考模型，来源不详

考虑到作为汽车底层网络，其信息传输量相对较少，信息传输的实时性要求较高，网络连接方式相对较简单，因此，CAN总线网络底层只采用了OSI 7层参考模型的最低两层，即物理层和数据链路层，而在高层只有应用层。物理层和数据链路层的功能可由CAN接口器件来实现，应用层的功能是由微处理器实现的。这里先了解下物理层和数据链路层：

1）物理层

物理层是OSI参考模型中最底层，主要定义了系统的电气、机械、过程和功能标准。如：电压、物理数据速率、最大传输距离、物理联接器和其他的类似特性。物理层的主要功能是利用传输介质为数据链路层提供物理连接，负责数据流的物理传输工作。物理层传输的基本单位是比特流，即0和1，也就是最基本的电信号或光信号，是最基本的物理传输特征。

图2 物理层与CAN通讯相关的内容，引自[1]

2）数据链路层

数据链路层是在通信实体间建立数据链路联接，传输的基本单位为“帧”，并为网络层提供差错控制和流量控制服务。数据链路层由MAC(介质访问控制子层)和LLC(逻辑链路控制子层)组成，其中MAC的主要任务是规定如何在物理线路上传输帧，LLC对在同一条网络链路上的设备之间的通信进行管理。数据链路控制子层主要负责逻辑上识别不同协议类型，并对其进行封装，也就是说数据链路控制子层会接受网络协议数据、分组的数据包并且添加更多的控制信息，从而把这个分组传送到它的目标设备。

图3 数据链路层与CAN通讯相关的内容，引自[1]

到此我们就对OSI参考模型的物理层和数据链路层有了基本的概念，那么CAN协议标准都对物理层和数据链路层做了什么定义呢？下面来具体了解：

4.2 ISO 11898 标准

1991年，Bosch发布CAN 2.0 标准协议，随后 ISO 标准化了该协议，发布了ISO 11898 和 ISO 11519 两种标准。这两种标准对数据链路层的定义相同，但物理层不同。这里我们主要关心CAN总线标准对数据链路层的定义，故下面只选取 ISO 11898 进行分析即可，如图4。因为 ISO 11898-2,3,4主要是针对于CAN总线的物理特性，电气特性等，不在本系列文章讨论范围内，故只考虑 ISO 11898-1，对应于OSI参考模型的数据链路层和物理层情况如图5所示。

图4 ISO 11898: 2003(E)

图5 ISO11898-1对应的OSI参考模型的物理层和数据链路层，引自[2]

由图5可知，CAN通讯的物理层定义信号怎样传输；数据链路层的LLC子层的功能主要是报文滤波、超载通知和恢复管理；MAC子层的功能主要是传送规则，即控制帧结构、执行仲裁、错误检测、出错标定和故障界定，是实现CAN协议的核心。

下面具体了解下ISO 11898-1标准，本文主要关注3块内容：

服务原语
LLC子层
MAC子层

1）服务原语 有3种通用类型：

请求（request），即服务用户向服务提供者发起请求服务；
通知（indication），即服务提供者向服务用户通知一个对其重要的服务提供者内部事件；
确认（confirm），即服务提供者向服务用户传达先前请求服务的结果，是成功还是失败，是完成还是未完成。

通俗地讲，发送时，用户先请求提供者，然后提供者发送，再向用户确认；接收时，提供者通知用户，如下图6。当信息经过LLC或MAC传输，即发送或者接收，同样地遵循上述的规则，所以在此先介绍这三条服务原语，为后续LLC和MAC的描述做铺垫。

图6 服务原语的使用示意

2）LLC子层

LLC子层提供两种无连接模式传输服务，分别为Unknowledged data transfer service和Unacknowledged remote data request service，这里我们就关注前者，对于这种服务会使用LLC data frame，用来发送和接收。

根据上述服务原语的描述，我们知道发送数据时，LLC用户传输数据给LLC子层，并请求LLC子层发送，当LLC子层发送数据后，向LLC用户确认发送状态。当接收数据时，LLC子层通知LLC用户有数据到达。这里每条服务原语对数据有怎样的规定呢？下图7做了清晰的定义。

图7 LLC子层服务原语，引自[2]

到此我们就知道了LLC子层的发送与接收过程。另外，LLC子层可以与对等的LLC实体交换数据单元的，也就是交换LLC数据帧。

图8 LLC子层的数据传输类型

一个LLC数据帧由3个位段（bit field）组成，即id，长度和数据3段，基本对应于上篇文章的CAN协议帧的三段，其中id段稍有不同，它包含3个部分：基本id，扩展flag和扩展id，但在MAC子层会将id段处理成CAN协议帧的id段格式。

图9 LLC数据帧，引自[2]

3）MAC子层

MAC子层是OSI DLL的最底层部分，介于LLC子层和PLS子层间，因此提供了访问这两层的接口，另外也提供了打包接收数据/解包发送数据，接收/发送介质访问管理等功能，如下图10。

图10 MAC子层的功能，引自[2]

与上述LLC子层同样的思路，LLC与MAC间的数据传输使用的服务原语如下所示：

图11 MAC子层的数据传输类型，引自[2]

图12 MAC子层服务原语6

回看图10可知道，MAC子层分为两条完全独立的操作部分，即发送和接收。MAC发送或接收的数据帧就是上篇文章所述的CAN协议帧，即如下图13所示。

图13 MAC数据帧结构，引自[2]

对于发送部分，MAC子层要实现：数据打包和发送介质访问管理。

数据打包，包括：LLC数据帧的接收；CRC序列计算；MAC数据帧的构建（即增加SOF，SRR位，IDE位，RTR位，保留位，CRC，ACK和EOF到LLC数据帧）。
发送介质访问管理，包括：识别到总线空闲时发起发送；位填充；仲裁，仲裁失败转为接收模式；ACK检查等；向物理层发送一串位流（a serial bit stream）。

图14 发送部分，从LLC用户到物理层接口过程

对于接收部分：MAC子层要实现：接收介质访问管理和数据解包。

接收介质访问管理，包括：从物理层接收一串位流；删除填充的位；发送ACK等。
数据解包，包括：移除数据帧的MAC特定信息；把LLC数据帧和接口控制信息给LLC子层。

图15 接收部分，从物理层接口到LLC用户过程

上面提到了位填充（bit stuffing）和去位填充（bit destuffing），这里引用[4]的解释：

图16 位填充，引自[4]

通过上面的内容，我们就了解了CAN协议帧的由来，按照OSI参考模型来分层CAN通讯架构，CAN协议帧具体在哪层使用，如何使用（当然以上内容也将为后续的CAN通讯软件实现做了铺垫）。而且我们也知道CAN协议帧最终CAN接口器件来实现，那么具体是怎么通过硬件来实现？

4.3 CAN协议帧的相关寄存器

从基于AUTOSAR架构的软件开发，一般会涉及到与CAN协议帧有关的几种寄存器，比如与id对应的寄存器，与数据对应的寄存器和与长度对应的寄存器。也就是说通过对寄存器的了解，就可以很清楚地明白CAN协议帧是怎么通过硬件（寄存器）实现的。下面分别通过Infineon和NXP 飞思卡尔的用户手册稍作了解。

下图17为Infineon的仲裁寄存器定义：

图17 仲裁寄存器，引自[5]

下图18为Infineon的数据寄存器（低位）的定义。

图18 数据寄存器（低位），引自[5]

下图19为Infineon的功能控制寄存器，24-27位定义了DLC。

图19 功能控制寄存器中的DLC，引自[5]

NXP的用户手册中定义的CAN协议帧的寄存器如下图20：

图20 CAN协议帧相关的寄存器，引自[6]

下图21为NXP的标识符寄存器定义：

图21 标识符寄存器，引自[6]

下图22为NXP的数据段寄存器定义：

图22 数据段寄存器，引自[6]

下图23为NXP的数据长度寄存器定义：

图23 数据长度寄存器，引自[6]

CAN协议帧就这样通过寄存器来实现：发送时，从软件写入到寄存器（硬件）；接收时，从寄存器读取到软件。

4.4 整车控制器CAN通信报文与CAN协议帧

整车控制器CAN通信报文定义了控制器（比如VCU）与其他控制器（比如ECU,TCU,MCU等）通过哪些id通信，每条报文有多长，数据表示什么信号，不同信号值代表什么意思等信息，如下图24所示。

图24 整车控制器报文示意

也就是说整车控制器CAN通信报文首先必须基于CAN协议帧来定义的，其次它赋予每一条CAN协议帧的实际意义，即不同id的帧数据段代表着不同的物理意义。当然这些并不在物理层和数据链路层实现，而是在应用层来实现，也就是通过软件实现物理层数据的解析。

到此我们就了解到了与CAN协议帧相关的协议标准，寄存器和整车控制器CAN通信报文。基于这些内容就基本可以实现一个简单版的CAN通讯功能，即接收功能：从读取相关寄存器的数据，最终传给应用层，将数据解析成具有意义的信号；发送功能：将应用层信号转换成规定的数据形式发送，写入寄存器，再向应用层确认。

写到此也产生了一个问题：数据最终发送方是以显隐性电平形式逐位地发送到总线上，那么接收方是怎么正确地接收这一位一位的总线电平呢？下篇文章将回答这个问题，即介绍ISO 11898-1中有关物理层PLS的内容。

Reference:

[1] 汽车CAN总线协议规范-深圳速锐得科技有限公司-国六OBD在线监测 |远程排放管理终端|CANBUS总线开发|汽车总线数据应用

[2] ISO 11989-1

[3] CAN总线通信模型与OSI的七层参考模型(转)_microcosmv的博客-CSDN博客

[4] CAN入门书

[5] TC27x D-Step 32-Bit Single-Chip Microcontroller

[6] MC9S08DZ60 HCS08微控制器