串行消息分離

我試圖在微控制器和c＃windows應用程序之間實現串行通信。串行消息分離

我已經在微機控制器方向的計算機上正常工作。但是我很難確定如何在另一個方向上實現通信。

我的郵件是由4個字節

B0 - 地址/發送
B1的值的名稱 - 高字節
B2 - 低字節
B3 - 校驗=加法的字節0-2

爲了確保收到完整的消息，我讓微控制器放棄當前的消息如果字節之間的時間長於20ms，則表示工作正常，並且可以容忍可能導致同步丟失的通信故障。

我不知道如何在c＃應用程序中執行此延遲，因爲我知道您對時序的精確控制較少。

我已經看到其他的ASCII協議發送一個開始和停止字符，但不知道如何在發送二進制數據時實現這一點，其中我的值可以在字節中取任何可能的值，並且可能碰巧是無論開始還是停止字符是。

由於資源有限，我需要保持微控制器的基礎，而控制器的主要任務需要非常精確（sub us範圍），將ascii轉換爲十進制。

有沒有人建議我應該如何從微處理器或計算機端實現這一點。

編輯
我看過一些其他的問題就在這裏，但他們都似乎是指更大的基於ASCII消息。

來源

2013-03-14 Hugoagogo

對於它的價值，我所使用的協議大多具有指定的開始/結束消息標記，字節值2和3，然後使用擒縱算法來表示實際數據值3（結束（有時也稱爲DLE編碼） – 2013-03-14 06:43:41

這是一個非常糟糕的主意。它假設電線另一端的機器能夠提供相同的保證。在微控制器上20毫秒毫無問題。無法啓動Linux或Windows的計算機。正在忙於寫入串行端口的線程很容易丟失數百毫秒的處理器。在C＃中的垃圾回收。

只是不優化的例外情況，沒有意義。超時應該在第二個範圍內，比您預期的最壞情況大10倍。通過框架使協議更加可靠。總是一個起始字節，讓接收器有機會重新同步。不妨包括一個長度字節，遲早你肯定會需要它。通過校驗和來支持CRC。查看RFC916以獲得可恢復的協議建議，儘管被廣泛忽視。當我使用它時工作得很好，雖然它需要額外的工作才能使連接嘗試可靠，但您必須刷新接收緩衝區。

來源

2013-03-14 13:45:11

這是一個很好的建議，但它是一個問題，它不是基於.net kernal的串行端口，因爲它只是將win32包裝到ReadTimeout和readByte功能中API？還有，在調度時窗口沒有16ms的分辨率（假設他有一個專門的讀線程，只有一個循環）？ – Serdalis 2013-03-14 14:04:32

是的，當字節在驅動程序的發送緩衝區中時，它是完全沒有問題的被中斷處理程序清空，問題是將用戶模式程序中的字節傳送到發送緩衝區，通過這樣的協議，程序一次寫入一個字節的可能性很大。這不是你可以測試的東西，它只是偶爾發生。如果你沒有辦法從協議故障中恢復，那就是它的結束。 – 2013-03-14 14:11:33

可以使用下面的命令設置read timeout爲20ms，

serialPort.ReadTimeout = 20;

這將使讀操作超時20毫秒之後，在這種情況下，你可以做你想做的。

不要使用ReadExisting與此超時，因爲它不依賴於讀超時，
改用Read()或readByte()並檢查是否有Timeout Exception

incedently同樣可以用WriteTimeout即使在成功寫入完成。所以要注意這一點。

來源

2013-03-14 12:28:47 Serdalis

串行消息分離

回答

相關問題