让【思想】头疼的Motorola编码
【思想】所在的公司有一套完善CAN通讯的入网标准，比如使用Intel编码就是其中一条。大部分的供应商都会遵守客户入网标准，但是也有出现一些例外。最近【思想】就遇到这么一个，由于种种原因坚持使用Motorola编码拒绝修改成Intel，打不过他，只好迁就他（真·思想·没地位）。
【思想】之前从没接触过Motorola编码，花了大把时间在吃这口屎上！祸福相依，没想到，这个机会在Debug下，古德曼汽车工业旗下的各种基础开发工具，让它们全面支持Motorola格式编码！
区别
首先，我们来对比Motorola与【思想】比较熟悉Intel编码在协议上有什么不同。双方的区别主要体现为报文信号中的起始位置定义不同！先从Vector自带CANdb++Editor工具说起。
在Message Signal窗口中ByteOrder选项中配置报文的字节序。配置的方式是很简单，但究其根本确实有天壤之别。
信号长度大于8个位
为了演示方便，【思想】在一个报文中分别添加了Intel与Motorola格式长度为12bits的信号。注意：实际工程中千万别这么做！！！！报文中的lsb标记为读取的起始位，msb为读取的终止位。
Intel格式比较好理解，起始位从第4位读取到第15位结束；
Motorola格式就比较诡异了，起始位是第28位，读取从第28位起到该字节结束，既从第28位读取到第31位。然后从第16位读取到第23位。很拗口！容我喝口水！就好比我的位置火车的中间车上，到车尾餐车吃饭，然后又返回车前的卫生间上厕所（ 这个比喻好像有点不太雅），及其蛋疼！
所以在刚开始接触Motorola协议的时候就会有这样的奇葩现象，起始位是60长度12，那岂不是结束位会在72？？？？
信号长度小于8个位
【思想】继续往报文中分别添加了Intel与Motorola格式长度为6bits的信号，可以看到LBS与MBS标志是相同的，也就是说Intel与Motorola格式影响
还没完，如果是上面这种极端情况（没有工程师会整出这样的CAN矩阵），即使长度小于8bits但是分属于两个字节的情况，读取时也会受到字节序的影响。
小结一下
Intel与Motorola什么情况下会影响我们的读取操作：
1、信号长度大于8bits；
2、信号长度小于8bits，但分属于2个Bytes的情况；
小心有坑！
接下来【思想】要嫌弃下CANdb++Editor的表里不如一了！
如上图，定义的Motorola格式信号的起始位是34，信号长度是6
DBC文件使用的是ASCII编码，可以通过记事本打开查看内容（DBC文件格式又是一个知识点，以后再找时间详细介绍一下）。起始位居然是39？？？
如果你跟【思想】一样，觉得CANdb++Editor非常不好用，可以试试古德曼汽车工业出品的DBC编辑工具
或许对于大部分人来说这并不影响使用，但是如果大伙需要开发基于DBC的上位机或者生成工具的时候，这就非常蛋疼。这种表里不如一会造成开发者的困惑！！
嵌入式中怎么处理
那在嵌入式开发中如何处理摩托罗拉格式的CAN报文呢？
大家不要心急，古德曼汽车工业正在酝酿一款CAN通讯C语言协议栈工具完美支持Intel与Motorola！敬请期待！