485通訊異常

前段時間接到一個項目，要求用主控用485和MCU通信。將代碼調試好之后，驗證沒問題就發(fā)給測試了。測試測的也沒問題。

但是，到設備量產時，發(fā)現有幾臺設備功能異常。將設備拿回來排查，發(fā)現是485通信有問題，偶現通信失敗。

排查思路

復現問題

發(fā)給測試之前，功能都驗證了很多次，但是并沒有發(fā)現通信失敗的問題。設備拿到手，第一時間就嘗試復現通信失敗的問題，也沒有成功。

于是，寫了一個腳本，不斷的和MCU通信，看什么情況下會失敗。

果然，在通信若干次后，發(fā)現日志異常，主控接收數據出現了錯亂。

接著，繼續(xù)跑腳本，想看下什么情況下會失敗。但是，每次通信異常的時機都是隨機的，沒有規(guī)律。

觀察了下錯亂的數據，和正確的數據做了對比，也沒有什么發(fā)現。

清空buf

接收的數據出現了異常，第一個想到的是，是不是接收buffer不干凈，有其他數據干擾呢？

嘗試在接收buffer和發(fā)送buffer之前，手動清空下buf。確保不會有其它數據干擾。

重新跑腳本和MCU 通信，但是仍會失敗。

收發(fā)時序

光看是什么辦法了。上示波器看下主控和MCU的時序的。

正常來講，主控和MCU的485控制管腳應該是正好反向的電平。即主控485控制管腳高電平發(fā)送的時候，MCU的485控制管腳應該是低電平。

問題復現時，對比了管腳的電平，確實是反向的，沒有問題。這也排除了收發(fā)時序對不上的問題。

(綠色的是MCU的485控制管腳，黃色的是主控的485控制管腳)

收發(fā)數據正確

小示波器沒有解碼的功能，只能找硬件來量下主控的RX和MCU的TX。確認下，到底是主控接收的不對，還是MCU發(fā)的不對。

顯然，是主控接收的數據有問題了。

仔細觀察會發(fā)現，綠色波形這里有個半高電平，覆蓋了黃色的低電平。導致第一幀出錯了，后面的數據也都錯亂了。

又重新復現了幾次，發(fā)現每次失敗時都是這種現象。那為什么這里會有個半高電平呢？

確認問題

和硬件對著原理圖經過一番討論，硬件給到的結論是，485芯片的RX管腳接了3.3V的上拉，只有當485芯片的使能管腳拉高時，RX才會有3.3V的半高電平出現。硬件懷疑是485控制管腳和MCU的時序沒對上。

不過，我之前也量了主控和MCU的485控制管腳的電平，看了是對的？難道是我看錯了？

接著又重新量了主控和MCU的485控制管腳，發(fā)現確實有問題，具體如下圖。兩者有1.5ms的高電平是重合的，這或許就是問題所在！

又重新復現了幾次問題，發(fā)現每次通信失敗時，都會有一段高電平是重合的。

到這里，基本也就明確了問題原因：主控和MCU的485控制管腳時序沒對上！

尋找問題根因

從波形找出了問題所在，回歸串口編程，繼續(xù)看下代碼吧。把重點放在了時序切換的代碼上。

代碼里面，在切換485管腳時有這樣兩段代碼。

以下只是偽代碼

代碼一：

setdir(SEND)??//切換為發(fā)送狀態(tài)
write()????//發(fā)送數據
tcdrain(fd)???//判斷是否寫完
setdir(READ)??//切換為讀狀態(tài)

代碼二：

do
{
?ioctl(fd,TIOCSERGETLSR,&lsr)?//判斷發(fā)送buffer是否寫完
}while(!(lsr&TIOCSER_TEMT))?//如果TX為空，返回TIOCSER_TEMT

這兩段代碼，都是和485管腳切換相關的，根據不同情況走不同邏輯，出問題的代碼走的是代碼一片段。

tcdrain 和 TIOCSERGETLSR

那這兩段代碼有什么區(qū)別呢？

tcdrain是應用層控制tty的一個函數，調用 tcdrain()函數后會使得應用程序阻塞， 直到串口輸出緩沖區(qū)中的數據全部發(fā)送完畢為止。

ioctl(fd,TIOCSERGETLSR,&lsr)是獲取tty 設備的線路狀態(tài)寄存器( LSR )的值。

這兩段代碼最大區(qū)別就是延時不同！

tcdrain()是等待fd所引用的串口設備數據傳輸完畢。雖然在物理上數據已傳輸完畢時，但Linux對硬件實時性高，對于用戶請求的實時性較低。所以操作系統會有延時，導致tcdrain()多停留幾ms，從而導致數據發(fā)送完后，485管腳的控制方向不能及時切換。

如果對接的485設備，接收和應答的延遲小于tcdrain()的延時，那方向切換不及時將導致數據接收丟失。這就是問題根因所在。

那為什么操作系統會有延時呢？

這個得說說Linux工作隊列相關機制，對于硬件操作Linux處理的很及時，但是對于數據Linux可能將其交給系統的下半部的內核線程去處理，這就可能導致用戶的系統調用存在一定的延時，而485通信對時間要求又很嚴格，1ms的延時就會導致數據錯亂。

總結

嚴謹細致。在問題發(fā)生時，我也去量過主控和和MCU 485控制管腳的電平，只看到了兩者是反向的，但是并沒有放大去看最后一段電平的細節(jié)。導致遺漏了解決問題的線索。一切問題發(fā)生都是有原因的。偶現問題并不好排查，但是我們可以嘗試制作偶現問題發(fā)生的條件，看有沒有可能成為必現問題。如果不能必現，可嘗試通過腳本去不斷運行在問題發(fā)生的場景，使其出現的概率提升。心態(tài)。放平心態(tài)，多看代碼。認真分析。