2013-10-23 70 views
0

我試圖爲2線RS485總線設計一個簡單可靠的主/從協議。RS485:簡單可靠的協議

總線上的所有節點都有唯一的地址。一個節點是能夠啓動通信的唯一節點的主節點。除非主站向它們發送請求,否則所有其他節點都不能發送任何內容。

我正在考慮簡單的「請求/響應」協議:主站向從站發送請求並等待其答案。之後,M將請求發送給另一個從站。 可能發生三種情況。

  1. 目標正確接收到兩個幀(請求和響應),事務結束時沒有問題。
  2. 來自主站的請求未被從站接收(校驗和錯誤)。超時後,主設備再次發送請求。沒問題。
  3. 主站未接收到從站的響應(校驗和錯誤)。超時後,主人可以再次發送請求。

恕我直言,最後一種情況是有問題的。從站無法理解第二個請求是否與第一個請求完全相同,因此它會處理該請求兩次。如果請求是「移動電機兩步」,「如果開關自上次請求後正在加載,請給我」,「切換繼電器」等等會發生什麼?

我認爲最簡單的「請求/響應」協議不能很好地工作,除非應用程序級知道協議的限制並且避免了傳輸兩次的危險請求。

你有一些很好的簡單可靠的協議建議嗎?我不想重新發明輪子。

+4

給請求添加某種序列號,重發的主機會發送第一次發送的序列號。在看到序列號後,從設備可以將其與最後接收到的命令進行比較,並在仍然響應命令時選擇忽略該操作。 – mocj

+0

在情況3中,您指示校驗和錯誤。如果發生錯誤,奴隸不會不處理請求嗎?並且不應該發送一個[NACK](https://en.wikipedia.org/wiki/Negative-acknowledge_character)表明它不理解請求? –

+0

我正在考慮主站收到的響應中的校驗和錯誤(或者,如果你想,如果主站根本沒有收到響應)。 – pozzugno

回答

0

我最近遇到HDLC在這裏,因爲我正在尋找類似的東西。它有一個適合您需求的操作模式。正常響應模式(NRM)就是您所描述的:僅從主站請求/響應。您可以使用open source HDLC framer作爲協議的基礎。我正在考慮自己使用這個功能,但似乎仍有相當數量的項目開發人員需要執行。

This是我碰到的答案,指出我在HDLC的方向。

+0

謝謝HDLC的建議非常好。現在唯一的問題是在低級8位微控制器上實現這個協議或子集,比如ATtiny Atmel系列。開源HDLC實現僅適用於PC。 – pozzugno

+0

庫部分可以在ATtiny上工作,但演示和測試代碼都是針對PC主機的。不過,我不確定這個庫的內存效率如何。 – rjp

+0

我更加關注圖書館。它僅解決同步成幀問題(避免幀中超過5個連續比特),但不實現異步成幀(如RS232/RS422/RS485連接),也不實現重傳時管理tx/rx序列號如有錯誤。 – pozzugno