1.背景介绍
主要应用场景在物联网中，底端设备注册报文的上报，需要对报文的有效载荷(data)进行crc16的复验，验证与设备端的crc校验是否相等，如果相等，报文有效，设备上报就会注册成功，不是第一次则会刷新心跳时间，避免通信中断告警。设备的报文结果以及设备的crc16位置如下：
平台端需要重新对注册包内容（不包含设备的crc计算字节）进行crc校验计算，与设备端的crc校验对比。如果相等，则平台端的crc校验成功。
备注：本文的crc校验全部指crc16的校验。
本文侧重测试crc的性能，不讲crc校验的原理，因为crc只是个校验数据准确性的工具，而且每个报文（不单单心跳报文），还有ai,di,do,ao，告警报文等都需要校验，因此，执行crc程序段的性能显得尤为重要。
如果读者对crc的校验原理感兴趣，请自行网上搜索相关资料进行深入研究，此处不再展开。
2.1. 直接计算crc校验
以下代码已经做过验证，与设备端的crc校验码相等（协议是基于变种的私有modbus协议），具体校验步骤可参考如下程序注释。最终将此类封装在了crc16的帮助类里面。
2.2. 查短表法计算crc16校验
查短表法计算crc16，性能佳，而且只需很小内存空间.
2.3.查大表法计算crc16校验
校验结果调了1天没调成功,后面会将测试结果贴出，性能与查短表几乎一样，而且浪费内存，所以没有采用此法。
3.三种校验方式的测试方法
3.1.直接计算crc校验的时间测试
3.2.查短表计算crc校验的时间测试
3.3.查长表计算crc校验的时间测试
根据网上的资源，测试计算结果有问题。校验结果昨天调了1天没调成功，而且性能跟查短表几乎一样，还需要占用更多内存，所以直接pass。
4.校验结果的测试
4.1. crc静态帮助类中的校验结果方法
这里最终是采用2.2. 查短表法计算crc16校验。通过默认设置模式mode="table"调用。校验成功返回true，校验失败返回false。
4.2. crc验证方法的顶层调用
测试crc验证方法
5. 不同校验方式的性能差异
这里主要是对比2.1与2.2。方法2.3弃用。
6. 结果输出
查长表计算crc与查短表crc校验计算，性能基本一样，甚至短表性能更佳；查短表性能是直接计算的3~5倍，所需计算时间是微秒级基本可以忽略不计；查长表计算校验结果有问题，4f0c为不正确结果，还需要占用更多内存，所以直接pass。
7.小结
第一次输出性能时间需要比较久，原因是net core刚启动完成，需要做的事比较多。
到此这篇关于c#基于modbus三种crc16校验方法的性能对比的文章就介绍到这了,更多相关c# crc16校验内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
版权声明：本文为博主原创文章，遵循 cc 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/jerrymouseli/p/12592565.html
