RS232：要校驗還是不要校驗？

我開始爲一個設備編寫代碼，該設備將以全雙工模式進行數據輸入輸出，所以我會在出現問題時使用硬件握手並設置中斷條件。但是，當涉及到錯誤檢測時，不太清楚最好的方法是什麼。RS232：要校驗還是不要校驗？

RS232有內置的奇偶校驗，我可以使用。據我瞭解，如果我使用8個數據位，一個奇偶校驗位和一個停止位，那麼線上的數據包將是10位。這意味着對於每發送1024個字節，我都會發送128字節的驗證信息。由於奇偶校驗對於每個字節是50/50的事情，因此持續少於一個字節的短暫突發噪聲將導致仍然與奇偶校驗位一致的損壞不是不太可能的。所以這似乎不是一個可靠的測試。

如果我在每個1024字節的末尾使用校驗和，在115200波特仍然只有80ms，我的驗證開銷從12％下降到小於1％，即使我使用64位校驗和。錯過腐敗很難。

僅僅是一種在sub 100波特連接的時代很有用的技術，它早已過時，我應該使用塊校驗和，或者我錯過了什麼？

來源

2014-02-11 Craig Graham

還有一些值得考慮的事情：可能會出現在使用此環境的環境中的短暫爆發噪聲？如果是這樣，RS-232肯定是不適合的，它將被視爲室內，辦公環境總線。更好的選擇是RS-485（代碼兼容）或更好，CAN（不兼容）。 – Lundin

@Lundin [RS-485]（http://en.wikipedia.org/wiki/Rs4850）將不滿足OP需要的「全雙工模式下的數據輸入和輸出」，它不是全雙工通信協議。 [RS-422]（http://en.wikipedia.org/wiki/Rs422）將提供更好的電噪聲免疫力，但仍保留全雙工能力。 – chux

@Lundin - *「RS-232 ...被認爲是......巴士」 - 不是「巴士」，而是通信鏈路。巴士意味着控制，尋址，甚至是電力以及數據。 – sawdust

建議計算並附加CRC而不是校驗和。 16位可能會滿足您的需求 - 我會使用32位。隨機噪聲的16位在64k中將失敗1。 4G中的32位1。
校驗和雖然容易計算，但會受到噪聲突發的影響，被解釋爲0 - 就串行錯誤而言並不罕見。
開銷計算有點偏離。 1開始+8數據+1停止位= 10對10 +奇偶校驗= 11.
奇偶不值得它IMO。除了幀錯誤（錯誤停止位）提供的內容之外，沒有發現太多的東西。不提供消息完整性。

來源

2014-02-11 15:10:16 chux

CRC和校驗和是兩個不同的東西（它們都是不經意地使用的）。 CRC是用於計算_checksum_的_algorithm_（循環冗餘校驗）。更正式地說，從CRC算法獲得並添加到包中的校驗和被稱爲[FCS]（http://en.wikipedia.org/wiki/Frame_check_sequence）（幀校驗序列）。 – Lundin

@Lundin根據我的經驗，校驗和（值）是以前數據的總和（算法） - 因此名稱爲「校驗和」。校驗碼（值）是描述附加到循環冗餘校驗（CRC）的消息的代碼的通用名稱，但是是用於計算這些消息的許多算法之一。短語「CRC」當然適用於算法。但它也適用於檢查代碼本身。許多通信標準將校驗碼稱爲「CRC」（例如ISO 15693.），但是可能ISO不是正式的，應該稱之爲FCS？ – chux

奇偶校驗是一種非常粗糙，老式的錯誤檢測方式。它爲您的傳輸增加了很多開銷：實際上它比校驗和增加了更多的延遲。對於以115200波特發送的1024字節，奇偶校驗會導致8.88ms的額外延遲。所以最好忘記你曾經聽說過平價，並認爲它是一個過時的功能。對於使用哪種校驗和算法，CRC被廣泛認爲是最好的選擇。但是，具有64位多項式的CRC需要相當長的一段時間來計算。

考慮將大塊數據分成更小的包，每個包都有較小的校驗和，比如CRC-8或CRC-16。

來源

2014-02-11 15:21:25 Lundin

在出現這個時候已經接受了其他答案，兩者都很相當，但是非常感謝。 –

@CraigGraham該網站可以讓你改變主意:)儘管你可以對所有答案都贊成有幫助。 – Lundin

RS232：要校驗還是不要校驗？

回答

相關問題