最近困扰笔者的是一个通信设备的CRC16（循环冗余校验）的计算问题。设备协议是通过抓包得到的，但是CRC16校验一直不准确，最开始笔者因为CRC校验只有应用于modbus这一种，后来在领导的提点下才知道原来CRC16计算有很多公式。笔者在ip33网页上的CRC计算工具上面一个个试，发现居然没有一个是准确的，那就意味着不能准确定位到计算模型。
那可能只有一种：设备的CRC循环冗余校验是自定义的参数模型。
无从下手。从设备手册入手，以前看过手册给的C语言的计算方法，笔者以前根据这个计算方法挪到LabVIEW的公式节点(formula node)上计算结果与抓包结果也不一致，当时是放弃了。昨晚又看了一遍具体的说明，重新用公式节点编写手册中的计算方法，还是不准确！根据手册内的蛛丝马迹，最开始笔者以为是那里面的byte0没有写清除，于是加上DLE数据通信换码符（\），不对；加上确认06字符，不对；改变字节数组的顺序，还是不对。
今天带娃期间，笔者也一直在想这个问题。今晚哄娃睡觉后，笔者再次打开昨晚写的公式节点，和以前的MODBUS CRC对比了一下，突然发现一个问题：公式节点不支持指针，公式节点照搬C语言时，自增i的问题，笔者将其写成了db = bufp[i++]， i重复自增了。C语言指针自增定位到字节数组的每一个字节，但是 bufp[i]已经在for循环中自增了。
不动脑子的后果！同时在这一次计算中，笔者在数据操作中发现了两个函数：交换字节和交换字。还记得以前高低字节交换花了很大力气，移位啥的再组合，现在一个函数搞定，交换字可以交换高低16位的数字。
有时候是需要一点灵感的，还记得大学毕业论文是角度和弧度没有转换导致计算错误，一直纠结了好久，突然有一天脑海突然浮现出角度要转换成弧度，那一刻感觉开光了。有时还得多想一想！最近发现系列文章-为什么这么设计（Why’s THE Design），计算机领域中一个具体的问题并从不同的角度讨论这种设计的优缺点，觉得很有意思。思维方式是要训练的，多学习多涉猎是一种保持头脑清醒，避免“犯困” 的方式。
网友评论