我开始编写一个设备代码,用于以全双工模式流入和流出数据,因此我将使用硬件握手并在出现问题时设置中断条件。但是当涉及到错误检测时,最不明确的方法就不太清楚了。
RS232内置奇偶校验,我可以使用。据我了解,如果我使用8个数据位,一个奇偶校验位和一个停止位,则线上的数据包将为10位。这意味着对于我发送的每1024个字节,我还发送与其交错的128字节的验证信息。
由于每个字节的奇偶校验是50/50,因此持续少于一个字节的短脉冲突发不会导致与奇偶校验位保持一致的损坏。所以它似乎不是一个可靠的测试。
如果我在每个1024字节结束时使用校验和,在115200波特率下仍然只有80ms,我的验证开销从12%下降到不到1%,即使我使用64位校验和。并且很难错过腐败。
奇偶校验只是一种在低于100波特连接时很有用的技术,并且已经过时了,我应该使用块校验和,或者我错过了什么?
答案 0 :(得分:4)
奇偶校验是一种非常粗糙,过时的错误检测方式。并且它为您的传输增加了大量开销:实际上它增加了比校验和更多的延迟。对于以115200波特发送的1024字节,奇偶校验将导致8.88ms的额外延迟。所以最好忘记你曾经听说过奇偶校验,并认为它是一个过时的功能。
对于使用哪种校验和算法,CRC被广泛认为是最佳选择。但是,具有64位多项式的CRC将需要相当长的时间来计算。
考虑将大块数据拆分成较小的包,每个包的校验和较小,例如CRC-8或CRC-16。
答案 1 :(得分:1)
建议计算并附加CRC而不是校验和。 16位可能满足您的需求 - 我使用32位。具有随机噪声的16位将在64k中失败1。 4G中的32位1。
Checksum虽然易于计算,却受到被解释为0的噪声突发的影响 - 就串行错误而言并非罕见。
开销计算有点偏。 1开始+ 8数据+ 1停止位= 10对10 +奇偶校验= 11.
奇偶校验不值得IMO。没有检测到超出帧错误(错误的停止位)提供的内容。不提供消息完整性。