1. 从物理量到CAN报文先在脑子里把这条链路走通上周调试控制器时同事拿着抓包软件走过来指着一帧十六进制报文问我这帧数据是C2 5D 78 9E 7F 00 00 00对应的物理量到底是多少转速多少、温度多少、电压多少这句话几乎是每个做CAN总线开发的人都会遇到的灵魂拷问。物理量如何变成CAN报文里的十六进制数它并不是某一个魔法步骤而是从传感器、ADC采样、Scale/Offset标定、位和字节排列再到十六进制编码的一整套链路。这篇我打算把这条链路从头到尾拆开配合可以直接复现的C语言和Python代码让新手能照着算让老手在处理十六进制数怎么计算成float这类问题时也有章可循。搞懂这件事之前先别纠结某一位是不是填反了脑子里得有整条数据流的框架。一个物理量要进CAN总线一般要经历五步传感器把物理量变成模拟电压ADC把模拟电压量化成一个有限精度的整数协议设计者用Scale、Offset和位宽把物理量映射成协议允许的原始整数原始整数转成十六进制并按字节顺序塞进CAN报文数据场接收端按同样规则反算把十六进制还原成物理量。第三步和第四步是绝大多数人卡住的地方——第三步是约定第四步是编码方式。很多人拿着报文不知道怎么解析就是因为不知道这个约定如果是自己发一帧数据又容易在进位、舍入、字节序上栽跟头。1.1 链路全览五个环节谁也躲不掉CAN报文的经典数据场是8个字节也就是64个bit。一帧里可以放一个信号也可以按位切开放好几个信号具体怎么切由DBC文件或者协议表说了算。拿我上面那个例子来说一帧报文里其实放了三个信号16位转速、8位温度、16位电压剩下的字节是预留或填充零。接收到以后再把每个信号按位抠出来套公式还原成有单位的数值。所以物理量变十六进制这个动作本质上是两件事一是按公式把真实物理数值算成整数二是把这个整数按照协议规定的位置和字节序摆进数据场。如果只做第一件事值算对了也可能因为字节序搞反导致整车报错如果只做第二件事协议定错了或者舍入规则不一致收发双方看到的物理量就会出现0.0几的漂移。这五步每一步都影响最终结果缺一个都不行。1.2 为什么CAN总线上跑的是整数而不是float很多刚入门的同学会问既然温度是25.5℃直接把float塞进报文不就行了当然可以塞IEEE754标准下的float最终也是4个字节CAN完全传得动。但绝大多数车载、工业控制协议都选择整数加Scale/Offset的方案原因很实在。第一是省位。一个float固定占32bit而一个温度信号如果只要1℃精度、范围从-40到215℃8bit无符号整数配合Offset-40就够用了。同样一帧8字节数据整数方案可以塞下好几个信号float方案可能只能塞下两个带宽利用率完全不同。第二是嵌入式端计算负担小。很多MCU没有硬件浮点单元整数乘除法用几条指令就完事float运算慢一个数量级。第三是协议可读性更好。DBC里写的是0.125 rpm/bit0.01 V/bit现场工程师拿计算器就能验算没必要对着4字节浮点猜字节序。我见过一些私有协议图省事直接把float怼进CAN报文结果解析端稍微写错一点字节序数值就变成天文数字。其实float不是不能用但要做好端序约定、对齐规则、特殊值处理成本比整数方案高不少。这也是J1939、CANopen等主流应用层协议优先选择整数标定方案的原因。1.3 十六进制只是给电脑看的人肉友好格式聊到CAN报文绕不开十六进制。为什么不用纯二进制写报文因为二进制一长串0和1人眼极难分辨。为什么不用十进制因为计算机存储的最小单位是字节而一个字节8bit刚好可以用两位十六进制数表示从00到FF。比如0x5D就是二进制0101 1101也是十进制93。CAN报文解析工具里默认用十六进制显示本质上是把一个字节拆成两个半字节看方便人对齐和检查位。这里有一个基本功看到十六进制要能快速估算它对应的量级。1字节最大0xFF是2552字节最大0xFFFF是655353字节最大0xFFFFFF是167772154字节最大0xFFFFFFFF是4294967295。做CAN协议时脑子里要有这张表否则很容易出现8bit信号塞了300这个数的溢出事故。后面第3章我会用具体报文演示整个换算过程先把链路走通再谈细节。2. 决定换算关系的三个铁律Scale、Offset、位宽CAN报文解析时最核心的信息全在DBC文件里。一个信号通常写作这样MotorSpeed : 0|161 (0.125,0) [0|8000] rpm。这一行里包含了起始位0、长度16、字节序1Intel、符号无符号、Scale0.125、Offset0、物理范围0~8000 rpm。很多人只看数值忽略了这个表达式的每一部分都是在给你规定换算规则。换算公式并不难但要分清楚方向。接收端解码时用的是物理值 原始整数 × Scale Offset。发送端编码时用的是反过来原始整数 (物理值 - Offset) / Scale。写代码时我习惯把原始单位叫Raw把物理单位叫Physical这样代码里一眼就能看出谁是协议值、谁是真实值避免混用。2.1 编码公式与解码公式方向千万别搞反常见的坑是拿着发送公式去解析报文。假设协议定义EngineSpeed raw × 0.125收到0x0E 0x50这种数据时正确做法是先拼成0x0E50 3664再乘0.125得到458 rpm。但如果你用反了拿物理量458去乘0.125得到57.25那就完全错了。所以我在写标定公式时一定会写两行注释放在代码里一行是Encode物理量转Raw一行是DecodeRaw转物理量并且用实际数值验证一遍。这个习惯帮我排掉过很多低级错误。公式看起来简单但在16进制、10进制之间来回切的时候人的注意力稍一分散就会把分子分母搞反。2.2 为什么温度要带Offset电压就不带Offset的存在是为了解决协议里没有负数的问题。CAN报文数据场通常按无符号整数解释而温度、海拔这类物理量天生是负数。如果不想引入有符号补码最简单的办法就是给信号加一个固定的偏移量把所有负数都整体抬高到非负区间。比如温度范围-40~215℃我们用8bit无符号数表示如果Offset0-40℃根本没法表示。于是协议把温度做成存储值 温度 40收到0x78120时反算120 - 40 80℃。在DBC里这个Offset会被写成-40公式是物理值 raw × 1 (-40)看起来好像很奇怪其实它表达的就是存储值先经过一个-40的修正才是真实值。电压、转速这类物理量通常不出现负数所以Offset经常是0新手容易忽略Offset只在有符号负数场景下才想起它。峰值提醒一句不要为了省一个符号位就硬把负数塞进无符号字段如果协议没定义Offset也没定义补码那这帧报文就只能表示正数电路稍一异常采集到的负值就直接溢出变成巨大正数排查起来非常头疼。2.3 位宽决定表达范围别把0xFFFFFFFF当自由世界信号位宽直接决定原始整数能放到多大。8bit最大25512bit最大409516bit最大6553524bit最大1677721532bit最大4294967295。这是无符号情况下的上限如果协议定义成有符号上限还要减半。选位宽时要同时考虑范围和分辨率。举个例子电压范围0~655.35V如果分辨率要做到0.01V那么一共需要65535个码值16bit刚好够用如果只给8bit最多255个码值分辨率最多只有655.35/255≈2.57V这精度显然没法用。反过来如果某信号只需要0~200你却给它16bit那高8位常年是0浪费了宝贵的报文空间还会让DBC文件里出现一堆没有任何意义的空余位。我建议在协议设计阶段就把这张表贴在电脑旁边位宽无符号范围常见场景8bit0~255温度、占空比、状态码12bit0~4095ADC原始值、扭矩百分比16bit0~65535转速、电压、高精度温度24bit0~16777215累计里程、累计油耗32bit0~4294967295时间戳、特殊扩展值算位宽时永远按最大物理值/Scale 1来反推最小位数。比如最大转速8000rpmScale0.125那最大Raw就是6400016bit刚好兜得住如果Scale改成0.5最大Raw就是16000也可以如果改成0.01最大Raw变成80000016bit就爆了得用32bit或者调整协议。2.4 字节顺序Intel还是Motorola错了就全乱同样的0x5DC2在Intel小端和Motorola大端格式下的线上字节顺序完全不同。Intel格式下低字节在前C2 5DMotorola格式下高字节在前5D C2。如果接收端用错字节序0x5DC2会被解析成0xC25D物理量直接变成原来的几倍甚至几十倍这一看就是典型的字节序错误。DBC里1表示Intel0表示Motorola。很多初学者以为Motorola只是简单地把两个字节交换其实对于跨字节、跨位的信号Motorola的位编号规则会和直觉完全相反。Motorola格式里的起始位通常指信号的最高有效位而Intel格式里的起始位通常指最低有效位两者在CANdb这类工具里画出来的位序图也不一样。遇到不按字节对齐的Motorola信号我强烈建议别手工拼位直接用工具生成代码或者用解析库处理否则非常容易在看起来对、实际差一个位的泥潭里折腾半天。3. 一个真实报文实例从转速到0x5DC2的完整实操理论说再多不如拿一个实际报文算一遍。假设某个电机控制器的DBC定义了三路信号BO_ 180 MotorData: 8 ECU SG_ MotorSpeed : 0|161 (0.125,0) [0|8000] rpm ECU SG_ MotorTemp : 16|81 (1,-40) [-40|215] degC ECU SG_ BatteryVolt : 24|161 (0.01,0) [0|655.35] V ECU这个DBC表达的意思非常简单MotorSpeed从第0位开始用16bitIntel字节序无符号每1个Raw对应0.125rpm偏移0MotorTemp从第16位开始用8bit每1个Raw对应1℃偏移-40BatteryVolt从第24位开始用16bit每1个Raw对应0.01V偏移0。现在假设当前真实物理量是转速3000.25rpm温度80℃电压326.70V。我们要把这组物理量变成一帧CAN报文。3.1 先按公式算原始整数先算MotorSpeed。因为Offset0Raw 3000.25 / 0.125 24002。这里要注意虽然结果是整数但很多浮点上算出来的东西并不总是那么干净尤其在不同语言、不同编译器下3000.25 / 0.125可能算出24001.999999直接强转成整数就变成24001了白白丢掉一个LSB。所以编码时我会统一加四舍五入再取整(3000.25 / 0.125 0.5f)最后强转。24002转成十六进制是0x5DC2二进制是0101 1101 1100 0010。Intel格式下低字节在前所以第0字节放0xC2第1字节放0x5D。再算MotorTemp。因为Offset-40Raw (80 - (-40)) / 1 120。120转十六进制是0x78只占8bit放在第2字节。最后算BatteryVolt。Raw 326.70 / 0.01 32670转十六进制是0x7F9E。Intel格式下低字节在前放在第3字节的是0x9E第4字节是0x7F。这样一帧8字节报文就拼出来了C2 5D 78 9E 7F 00 00 00。这就是我文章开头让同事犯晕的那帧数据现在它已经有了明确物理意义。3.2 逐字节打包用C语言实现可靠发送在实际嵌入式代码里我通常用结构体指针直接操作uint8_t data[8]数组把每个信号按位填进去。下面的代码专门针对上面这个DBC定义#include stdint.h typedef struct { uint8_t data[8]; } CanFrame; void motor_data_encode(CanFrame *f, float speed_rpm, float temp_c, float volt_v) { uint16_t speed_raw (uint16_t)((speed_rpm - 0.0f) / 0.125f 0.5f); uint8_t temp_raw (uint8_t) (((temp_c - (-40.0f)) / 1.0f) 0.5f); uint16_t volt_raw (uint16_t)((volt_v - 0.0f) / 0.01f 0.5f); f-data[0] speed_raw 0xFF; f-data[1] (speed_raw 8) 0xFF; f-data[2] temp_raw; f-data[3] volt_raw 0xFF; f-data[4] (volt_raw 8) 0xFF; f-data[5] 0; f-data[6] 0; f-data[7] 0; }这段代码的关键在于理解 0xFF和 8的作用。speed_raw 0xFF是取低字节(speed_raw 8) 0xFF是取高字节。因为CAN报文数据场是字节数组我们必须把16bit整数拆成两个8bit往里填。看到data[0]放低字节、data[1]放高字节就实现了一个标准的Intel小端存放。温度那行因为只有8bit直接赋值即可。0.5f的作用是四舍五入而不是截断。这是我在实际项目中反复强调的点嵌入式平台上的浮点转整型默认是向零截断的9.9999f转成int就是9不是10。加0.5能保证大多数情况下的舍入正确但如果你需要严格四舍五入建议用C99的roundf()再转换。3.3 收到报文怎么反向解析用Python快速还原拿到一帧报文第一件事是什么先看DBC确认每路信号的起始位、长度、字节序和Scale/Offset。没有DBC就开始解析等于盲人摸象。以刚才的C2 5D 78 9E 7F 00 00 00为例解析代码极简单frame bytes.fromhex(C2 5D 78 9E 7F 00 00 00) speed_raw frame[0] | (frame[1] 8) speed speed_raw * 0.125 print(MotorSpeed:, speed_raw, speed, rpm) temp_raw frame[2] temp temp_raw * 1 (-40) print(MotorTemp:, temp_raw, temp, degC) volt_raw frame[3] | (frame[4] 8) volt volt_raw * 0.01 print(BatteryVolt:, volt_raw, volt, V)运行结果应该是MotorSpeed 24002 × 0.125 3000.25rpmMotorTemp 80℃BatteryVolt 326.70V。整个解析过程就是编码的逆过程从字节数组拼整数再乘Scale加Offset。这里要注意Python里的frame[1] 8会让整数变成十进制再和frame[0]按位或即可。如果报文里是Motorola格式拼接顺序要反过来写成frame[0] 8 | frame[1]。我看到过太多人把Python当成万能工具却没有先问自己一句DBC里写的到底是1还是0这个顺序错了后面全白算。3.4 十六进制怎么计算成float遇到IEEE754也别慌有些协议的某些信号确实会直接传IEEE754的float比如一些基于CANopen的设备对象字典。遇到这种需求首先要确认协议文档里规定的字节序然后按这个顺序把4字节拼成一个uint32_t再把它按位解释成float。这里的按位解释不是强转而是用memcpy或者联合体避免违反严格别名规则。先说一个经典例子物理量5.0IEEE754单精度浮点表示是0x40A00000。如果协议规定大端传输线上看到的是40 A0 00 00如果协议规定小端传输线上看到的是00 00 A0 40。看到40 A0 00 00想还原成float最稳的是直接用struct模块import struct data bytes.fromhex(40 A0 00 00) value struct.unpack(f, data)[0] print(value) # 5.0C语言里我常用这种方式uint32_t raw ((uint32_t)data[0] 24) | ((uint32_t)data[1] 16) | ((uint32_t)data[2] 8) | ((uint32_t)data[3]); float value; memcpy(value, raw, sizeof(value));注意大端拼接时第一个字节放最高位小端拼接时第一个字节放最低位。如果只调换一两个字节的位置结果可能是一个完全错误但看起来很有规律的数比如20.0变成2.8e-44这种极小的数。我调试过一个传感器上位机一直显示0.00001这样的值后来发现是协议文档写着大端但某个固件版本按小端发送两边各信各的导致尾数完全不对。排查这类问题最直接的办法是拿一个已知物理量比如5.0V标准电压源灌进去抓一帧原始报文反推字节序和字节内位序。4. 常见问题与排查技巧实录4.1 小数点左移时最右侧的1怎么处理这个问题在搜索引擎里经常出现翻译成工程语言就是物理量乘Scale变成整数时被丢掉的小数部分怎么办比如一个物理量12.1Scale0.125那么Raw 12.1 / 0.125 96.8。96.8转成整数是96还是97这个最右侧的1其实就是二进制小数点移动后遗留下来的量化尾数。工程上必须有一个明确的舍入规则否则发送端和接收端对不上。我的默认做法是四舍五入先加0.5再截断。还是96.8这个例子96.8 0.5 97.3截断后是97。如果Scale是0.125这种2的负幂本质上可以写成左移3位Raw (uint32_t)(物理量 × 8 0.5)。这样更直观小数点左移三位后原本二进制小数部分最右侧的1会被移进整数部分如果还有残余位就被舍入规则吃掉。但要注意四舍五入只适用于正数。如果物理量是负的加0.5再截断会出错。我建议负值场景直接用roundf()或者先用Offset把所有物理量抬到非负区间再做四舍五入这样逻辑简单且不容易踩坑。最彻底的办法是协议设计阶段就把单位定成最小精度比如0.01℃就存百分之一摄氏度这个整数全程不碰float也就根本没有小数点左移时最右侧的1这种烦恼。4.2 负数到底怎么传有符号补码还是加OffsetCAN报文里的字节本身没有正负概念负数信号要么用有符号补码要么用Offset抬升。两条路线各有优劣。Offset路线的好处是简单直观比如温度-40℃存成00℃存成40解析时统一减40所有字节都按无符号处理。有符号补码路线的特点是协议少存一个Offset字段原始值直接就是int8_t、int16_t解析时按类型读取。J1939里不少温度、压力信号走的是Offset路线而很多私有协议喜欢直接用有符号数。这里的坑在于混用。如果一个协议文档既写了Offset-40又写了信号为有符号那解码结果会和预期差出一大截。比如原始字节0xD8按无符号加Offset算216-40176℃按有符号补码算-40-40-80℃。两者完全是灾难性的差异。所以我拿到一个DBC或者协议表第一件事就是把所有信号的符号、Offset、Scale列成一张清单确认没有二义性后再写代码。4.3 解析结果跳变、大得离谱先查这四件事解析出来的物理量各种异常原因通常集中在四个方向。一是字节序错误Motorola被当成Intel解析数值会在低位和高位之间发生错位。二是位宽错误16bit信号被按8bit截断高位信息直接丢失数值周期性跳变。三是符号错误无符号字段里存了负数补码或者有符号字段被当成无符号解析结果出现负值突然跳到巨大正数。四是公式方向错误该乘的除、该加的减甚至Scale和Offset跟相邻信号搞混了。排查时不要上来就在报文里翻来翻去。先构造一个已知物理量比如用标准源灌入5.0V或者让执行机构停在3000rpm再抓一帧报文看原始字节是否符合协议定义。抓住那帧已知报文后用十六进制计算器和DBC里的公式一笔一笔验算最多十分钟就能定位问题在哪一个环节。最怕的是用一堆未知报文去试解析算法那等于在黑暗里找一个颜色出错的小数点。4.4 手算与工具速查5种方式快速换算日常调试中我不可能永远开着计算器下面这几个方法能快速完成物理量和十六进制之间的换算。一是Windows自带的计算器切到程序员模式16进制、10进制互转非常方便。二是Linux终端直接跑printf %X\n 24002立刻得到5DC2。三是Python里用hex(24002)/int(5DC2, 16)适合批量验算。四是很多CAN上位机自带信号解析窗口输入原始字节和Scale/Offset直接显示物理值这个最为直观。五是Excel或者WPS里用HEX2DEC、DEC2HEX函数适合离线整理一大批协议表。最后分享两个我个人坚持的习惯。第一任何Scale/Offset不为1或0的信号我都会在代码里写一个自测用例编码函数算出原始值解码函数再还原物理量两次误差应在精度范围内。第二抓包工具里看到的十六进制报文最好直接以字节为单位显示不要用bit流模式否则人眼很容易被位编号绕晕。踩过几次坑之后你会发现CAN报文解析其实没有太多高深理论剩下的就是严谨、可复现的操作流程。
