对于嵌入式应用程序，我应该使用 CRC-16 还是 IP 校验和 (RFC1071)？
我正在 ARM7 处理器上编写嵌入式应用程序，我需要某种形式的校验和来验证通过串行链路发送的数据以及存储在闪存中的数据。 我想知道这两个 CRC 中哪一个更适合这个目的。 主要的权衡是代码速度与鲁棒性。 我应该考虑另一个 CRC 吗？ 您有 ARM 高效实现的链接吗？
I'm writing an embedded application on an ARM7 processor and I need some form of checksum for data that I'm sending over a serial link as well for data that I'm storing in the flash. I was wondering which of the two CRCs would be better suited for the purpose. The main trade-off are code speed versus robustness. Should I consider another CRC? Do you have a link to an efficient implementation for ARM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
RFC1071 是字节对的简单 16 位和。 因此，两个错误有可能“抵消”，但仍然给出“通过”校验和。 例如，一个位错误将一位从 1 翻转为 0。然后 16 位之后的另一个位错误将一位从 0 翻转为 1。RFC1071 不会检测到这一点。 但如果使用 CRC 进行检查，就会检测到相同的双位翻转错误。
这种双位翻转错误在串行传输中是可能发生的。 （在并行电缆上更有可能出现这种情况，特别是如果一根电线“有噪音”，但现在谁使用并行电缆？）在闪存芯片中也有可能出现这种情况，尤其是当 PCB 微型芯片和闪存芯片之间的焊点不良时。 总体而言，CRC 在检测错误方面在统计上更加稳健，因为输入中的单个位变化会影响 CRC 移位寄存器中的多个位。
在实践中，您想要检测的另一件事可能是不完整的 Flash 上传，因此大部分代码都丢失了。 为此，从统计上看，校验和可能没问题，但在我从事的项目中我一直偏爱 CRC。 通过基于表的 CRC 算法，我们已经能够获得所需的计算速度。
RFC1071 is a simple 16-bit sum of pairs of bytes. As such, it's possible that two errors could "cancel out", and still give a "pass" checksum. E.g. a bit error flips a bit from 1 to 0. Then another bit error 16 bits later flips a bit from 0 to 1. RFC1071 will not detect this. But the same double-bit-flip error, if being checked with a CRC, would be detected.
This sort of double-bit-flip error is possible in a serial transmission. (It is much more likely on a parallel cable especially if one wire is "noisy" but who uses parallel these days?) It's also possible in a Flash chip, especially if the PCB has a bad solder joint between micro and Flash chip. Overall, a CRC is statistically more robust at detecting errors because a single bit change in the input affects multiple bits in the CRC shift register.
In practice the other thing that's likely, that you want to detect, is an incomplete Flash upload, so a large chunk of the code is simply missing. For that, statistically a checksum is probably fine but I've always favoured a CRC in projects I've worked on. With a table-based CRC algorithm, we've been able to get the calculation speeds required.
CRC32 相对便宜且实施速度快。 W3C 网站上的 PNG 示例代码中有一个信誉良好且高效的实现（成本=1Kbyte RAM 用于表并且可以轻松生成，无需 EEPROM 资源）。 如果您寻找其他 CRC 实现，则可以权衡表内存大小和计算时间。
CRC32 is relatively cheap and quick to implement. There's a reputable and efficient implementation in the PNG sample code on W3C's website (cost=1Kbyte RAM for table & it can be generated easily w/o needing EEPROM resources). You can tradeoff table memory size for calculation time if you look out there for other CRC implementations.
在这种情况下采取您能承受的最佳校验和。 闪存可能不会经常进行，因此闪存校验和可能比串行通信的校验和更复杂。
我想到的其他校验和：
但这完全取决于您正在执行的应用程序以及如果您没有检测到错误可能造成的危害。
请在此处查看更多信息：http://en.wikipedia.org/wiki/List_of_checksum_algorithms
Take the best checksum you can afford in the situation. Flashing might not be done often, so the flash-checksum can be more sophisticated than the one for the serial communication.
Additional checksums I have in mind:
but this depends entirely on the application you are doing and the harm that can be done if you don't detect an error.
Take a look here for more input: http://en.wikipedia.org/wiki/List_of_checksum_algorithms
闪存数据可能是您不希望被损坏的数据，因此 crc 很好。 另一部分是串行协议。 鉴于串行链路的速度较慢，您应该使用 crc。
ARM7 芯片可以以远高于串行链路速度的速度处理以太网校验和，因此代码速度应该不是问题，并且鲁棒性将得到巨大提高。
Flash data is likely something you don't want to be corrupted, so crc is good. The other part is a serial protocol. Given the slow speed of serial link, you should go with a crc.
ARM7 chip can handle ethernet checksuming at speed much higher than the speed of a serial link, so code speed should not be a problem, and you will get a huge increase in robustness.
对于闪存或（尤其是）OTP 之类的东西，通常最好同时拥有 CRC 之类的东西，它可以很好地捕获错误的随机组合，以及足够长而不会溢出的补码校验和。 后者将具有以下优点：将检测到仅包括错误设置的位或仅包括错误清除的位的任何错误组合。
For things like flash memory or (especially) OTP, it's often good to have both something like a CRC which will do a good job of catching random combinations of errors, and a one's-complement checksum which is long enough not to overflow. The latter will have the advantage that any combination of errors which includes only erroneously-set bits or includes only erroneously-cleared bits will be detected.