对于嵌入式应用程序,我应该使用CRC-16还是IP校验和(RFC1071)?

RFC1071是一个简单的16位字节对和。因此,有可能两个错误会“取消”,但仍会给出“通过”校验和。例如,位错误将位从1翻转到0。然后16位之后的另一个位错误将位从0翻转到1。RFC1071不会检测到这一点。但如果用CRC检查,同样的双位翻转错误也会被检测出来。

这种双位翻转错误在串行传输中是可能的。(在平行电缆上更可能出现这种情况,尤其是当一根电线“有噪音”,但现在谁使用平行电缆?)在闪存芯片中也是可能的,特别是当印刷电路板在微芯片和闪存芯片之间有一个不良的焊点时。总的来说,CRC在统计上在检测错误方面更强大,因为输入中的单个位变化会影响CRC移位寄存器中的多个位。

在实践中,另一件你想要检测到的事情可能是一个不完整的闪存上传,所以一大块代码只是丢失了。因此,在统计上,校验和可能是可以的,但我在我工作过的项目中总是喜欢使用CRC。通过一个基于表的CRC算法,我们可以得到所需的计算速度。

CRC32相对便宜,实施速度快。在 PNG sample code on W3C's website (表&的成本=1字节RAM,无需EEPROM资源即可轻松生成)。如果您在那里寻找其他CRC实现,就可以权衡表内存大小的计算时间。

在这种情况下,取你能负担得起的最好的校验和。闪存可能不会经常进行,因此闪存校验和可能比串行通信更复杂。

我考虑的其他校验和:

• CRC32
• MD5
• 沙哈

但这完全取决于您所做的应用程序以及如果不检测到错误可能造成的危害。

请在此处查看更多信息: http://en.wikipedia.org/wiki/List_of_checksum_algorithms

闪存数据可能是您不希望损坏的数据,所以CRC是好的。另一部分是串行协议。鉴于串行链路的速度较慢,您应该使用CRC。 ARM7芯片可以以比串行链路快得多的速度处理以太网校验和,所以代码速度不应该是一个问题,您将获得极大的健壮性提高。

对于闪存或(特别是)OTP之类的东西,通常最好同时具有CRC之类的东西,它可以很好地捕获随机错误组合,以及一个足够长而不会溢出的补码校验和。后者的优点是,只包括错误设置的位或只包括错误清除的位的任何错误组合都将被检测出来。