CAN通信协议

船用发动机监控系统为什么使用CAN总线通信协议呢?

  • 控制器局域网络(CAN)具有高保密性,有效的支持分布式控制或实时控制的串行通信网络;
  • 速率高,CAN的位速率可达1Mbps(40m);
  • 廉价,多使用与交通运载工具、发动机控制部件等;
  • 采用线性总线结构,每个子系统对总线具有相同的权利,多主工作方式。任意一个节点可以在任何时候向网络上的其他节点发送信息而不分主从;
  • 发送信息分为不同的优先级,采用非破坏性总线裁决技术,当两个节点同时向网络上传递信息时,优先级低的停止发送数据,而优先级高的节点不受影响的继续传递数据;
  • 与总线相连的单元没有类似于“地址”的信息,因此总线上增加单元时,连接在总线上的其他单元软硬件及应用层都不需要改变,节点按照滤波器过滤接收的信息;
  • 具有检错、错误通知、错误恢复的功能;
  • 具有点对点,一点对多点,全局广播接收传送数据的功能。

CAN总线基础知识:

  • 总线状态总线有“显性”和“隐性”两个状态,“显性”对应逻辑“0”,“隐性”对应逻辑“1”。“显性”状态和“隐性”状态相与的结果为“显性”状态,所以两个节点同时分别发送“0”和“1”时,总线上呈现“0”。也就是说在总线上显性电平具有优先权,只有所有的单元都输出隐性电平,总线上才为隐性电平。另外在CAN总线的起止端都有一个120欧的终端电阻来做阻抗匹配,以减少回波。
  • CAN协议通过以下5种类型的帧进行:
    数据帧
    远程帧
    错误帧
    过载帧
    间隔帧

CAN报文发送优先权抉择:

  • CAN 总线以报文为单位进行数据传送,报文的优先级结合在11 位标识符中,具有最低二进制数的标识符有最高的优先级。这种优先级一旦在系统设计时被确立后就不能再被更改。总线读取中的冲突可通过位仲裁解决。如图2 所示,当几个站同时发送报文时,站1 的报文标识符为011111;站2 的报文标识符为0100110;站3 的报文标识符为0100111。所有标识符都有相同的两位01,直到第3 位进行比较时,站1 的报文被丢掉,因为它的第3 位为高,而其它两个站的报文第3位为低。站2 和站3 报文的4、5、6 位相同,直到第7 位时,站3 的报文才被丢失。注意,总线中的信号持续跟踪最后获得总线读取权的站的报文。在此例中,站2 的报文被跟踪。这种非破坏性位仲裁方法的优点在于,在网络最终确定哪一个站的报文被传送以前,报文的起始部分已经在网络上传送了。所有未获得总线读取权的站都成为具有最高优先权报文的接收站,并且不会在总线再次空闲前发送报文。

CAN数据帧组成:

  • (1) 帧起始。 表示数据开的段帧起始。 
    (2) 仲裁段。 表示该帧优先级的仲裁段。
    (3) 控制段。 表示数据的字节及保留位控制段。 
    (4) 数据段。 数据的内容,一帧可发送0~8个字节的数据段。
    (5) CRC段。 检查帧的传输错误段。
    (6) ACK段。 表示确认正常接收的段。 
    (7) 帧结束。 表示数据的段帧结束。
  • 数据帧的构成如下图所示:图中D表示显性电平,R表示显性电平。

  • 应答场(ACK)包括应答位和应答分隔符。发送站发送的这两位均为隐性电平(逻辑1),这时正确接收报文的接收站发送主控电平(逻辑0)覆盖它。用这种方法,发送站可以保证网络中至少有一个站能正确接收到报文远程帧由6 个场组成:帧起始、仲裁场、控制场、CRC 场、应答场和帧结束。远程帧不存在数据场。远程帧的RTR 位必须是隐位。DLC 的数据值是独立的,它可以是0~8 中的任何数值,为对应数据帧的数据长度。
时间: 2024-07-29 14:56:36

CAN通信协议的相关文章

ZigBee通信协议标准化是大势所趋

当前,通信技术迅猛发展,ZigBee作为一种新兴的短距离无线通信技术,正有力地推动着低速率无线个人区域网络的发展.以往受制于ZigBee的使用没有标准,在实际应用中,ZigBee接入互联网时需要复杂的应用层网关,也不能实现端到端的数据传输和控制,相互之间不兼容,不利于产业化的发展. 直到ZigBee联盟的成立并于2004年12月通过了ZigBee 1.0标准,ZigBee开始获得快速的发展.在接下来的十多年里,ZigBee 2.0.ZigBee3.0相继推出.联盟成员规模在不断扩大,在无线通信领

Mysql通信协议

Mysql四种通信协议(linux下本地连接的都是socket 其他都是tcp) 当连接mysql时,使用-h127.0.0.1时,linux与unix下的连接协议为socket协议,windows下为memory协议. 如:   [[email protected] ~]# mysql -uandy -pandy -h127.0.0.1 当连接mysql时,使用非-h127.0.0.1时,使用tcp/ip协议. 如:   [[email protected] ~]# mysql -uandy

通信协议之序列化

原文转自:http://blog.chinaunix.net/uid-27105712-id-3266286.html 通信协议可以理解两个节点之间为了协同工作实现信息交换,协商一定的规则和约定,例如规定字节序,各个字段类型,使用什么压缩算法或加密算法等.常见的有tcp,udo,http,sip等常见协议.协议有流程规范和编码规范.流程如呼叫流程等信令流程,编码规范规定所有信令和数据如何打包/解包. 编码规范就是我们通常所说的编解码,序列化.不光是用在通信工作上,在存储工作上我们也经常用到.如我

通信协议------Http、TCP、UDP

CP   HTTP   UDP: 都是通信协议,也就是通信时所遵守的规则,只有双方按照这个规则“说话”,对方才能理解或为之服务. TCP   HTTP   UDP三者的关系: TCP/IP是个协议组,可分为四个层次:网络接口层.网络层.传输层和应用层.在网络层有IP协议.ICMP协议.ARP协议.RARP协议和BOOTP协议.在传输层中有TCP协议与UDP协议.在应用层有FTP.HTTP.TELNET.SMTP.DNS等协议.因此,HTTP本身就是一个协议,是从Web服务器传输超文本到本地浏览器

Hadoop 学习笔记五 ---Hadoop系统通信协议介绍

本文约定: DN: DataNode TT: TaskTracker NN: NameNode SNN: Secondry NameNode JT: JobTracker 本文介绍Hadoop各节点和Client之间通信协议. Hadoop的通信是建立在RPC的基础上,关于RPC的详解介绍大家可以参照 "hadoop rpc机制 && 将avro引入hadoop rpc机制初探" Hadoop中节点之间的通信是比较复杂的一个网络,若可以把它们之间的通信网络了解清楚,那么

了解saltstack的通信协议zeromq(一)

学了saltstack有一段时间了,说实话,对于一个python爱好者来说salt源代码真是一个宝藏啊.于是乎去看了源代码,发现所有问题都卡在了底层通信上,在看saltstack之前都不知道有一个这么好的zeromq通信协议.现在就来记录关于zeromq的学习笔记. zmq是什么:zmq是基于之前协议(tcp,ipc,inproc)开发的并发框架,采用异步IO非阻塞方式,多对多的通信模式,无需在意服务端和客户端的启动顺序.它包含四种通信模式:PAIR/PAIR,REP/REQ,PUB/SUB,P

Redis 通信协议

本文和大家分享的主要是redis 通信协议相关内容,一起来看看吧,希望对大家 学习redis有所帮助. 几乎所有的主流编程语言都有Redis 的客户端,不考虑 Redis 非常流行的原因,如果站在技术的角度看原因还有两个: 1.  客户端与服务端之间的通信协议是在  TCP 协议  之上构建的. 客户端和服务器通过 TCP  连接来进行数据交互, 服务器默认的端口号为  6379  . 客户端和服务器发送的命令或数据一律以  \r\n  (CRLF )结尾. 1. Redis 制定了  RESP

TCP应用程序通信协议的处理

TCP应用程序通信协议的处理 flyfish 2015-6-29 一 流式处理 TCP是一种流协议(stream protocol).TCP数据是以字节流的形式传递给接收者的,没有固有的"报文"或"报文边界"或者用户可见的"分组"的概念. 它只是传送了一个字节流,我们无法准确地预测在一个特定的读操作中会返回多少字节.尽管网络层数据在节点之间是以IP分组的形式传输的,但分组中的数据量与send调用中传送给TCP多少数据并没有直接关系.而且,接收程序

通信协议

设计基本思路: 当客户端连接的时候,服务器会向客户端发回一条消息告知他的IP 地址,然后关闭连接并继续接受端口的连接.建立各个命令功能相对应的函数,发送请求,等待服务端的服务.服务器端初始化Winsocket,创建socket,获取主机信息,并对客户端进行对话.发送回复讯息给客户端,响应完毕关闭连接,释放Winsocket 帧格式: 数据头+数据长度+数据内容+校验码+数据尾 是协议的一部分,还要考虑对不同帧的处理,比如 数据帧,控制帧,应答帧等. 帧格式的重点在控制码,而对不同帧的控制则对应流

通信协议之版本号管理

通信协议制定以后也可能会修正,继而推出后续版本,这样就可能导致多个版本的通信协议存在. 不同的客户端可能实现的是不同版本的通信协议. 但服务端程序却只有一个,它如何同时支持客户端多个版本的通信协议?都能正确解析不同协议里面的数据? 应该定义多个版本通信协议的数据封包格式,服务端按照不同的版本使用不同的数据封包来解析数据. 客户端传递上来的数据包里面应该有标明是属于哪个版本通信协议的字段. 通信协议之版本号管理,布布扣,bubuko.com