收發數據正確
小示波器沒有解碼的功能，只能找硬件來量下主控的RX和MCU的TX。確認下，到底是主控接收的不對，還是MCU發的不對。
顯然，是主控接收的數據有問題了。
仔細觀察會發現，綠色波形這里有個半高電平，覆蓋了黃色的低電平。導致第一幀出錯了，后面的數據也都錯亂了。
又重新復現了幾次，發現每次失敗時都是這種現象。那為什么這里會有個半高電平呢？
確認問題
和硬件對著原理圖經過一番討論，硬件給到的結論是，485芯片的RX管腳接了3.3V的上拉，只有當485芯片的使能管腳拉高時，RX才會有3.3V的半高電平出現。硬件懷疑是485控制管腳和MCU的時序沒對上。
不過，我之前也量了主控和MCU的485控制管腳的電平，看了是對的？難道是我看錯了？
接著又重新量了主控和MCU的485控制管腳，發現確實有問題，具體如下圖。兩者有1.5ms的高電平是重合的，這或許就是問題所在！
又重新復現了幾次問題，發現每次通信失敗時，都會有一段高電平是重合的。
到這里，基本也就明確了問題原因：主控和MCU的485控制管腳時序沒對上！
尋找問題根因
從波形找出了問題所在，回歸串口編程，繼續看下代碼吧。把重點放在了時序切換的代碼上。
代碼里面，在切換485管腳時有這樣兩段代碼。
以下只是偽代碼
代碼一：
setdir(SEND) //切換為發送狀態
write() //發送數據
tcdrain(fd) //判斷是否寫完
setdir(READ) //切換為讀狀態
代碼二：
do
{
ioctl(fd,TIOCSERGETLSR,&lsr) //判斷發送buffer是否寫完
}while(!(lsr&TIOCSER_TEMT)) //如果TX為空，返回TIOCSER_TEMT
這兩段代碼，都是和485管腳切換相關的，根據不同情況走不同邏輯，出問題的代碼走的是代碼一片段。換成代碼二后，數據收發就正常了。
tcdrain 和 TIOCSERGETLSR
那這兩段代碼有什么區別呢？
tcdrain是應用層控制tty的一個函數，調用 tcdrain()函數后會使得應用程序阻塞， 直到串口輸出緩沖區中的數據全部發送完畢為止。
ioctl(fd,TIOCSERGETLSR,&lsr)是獲取tty 設備的線路狀態寄存器( LSR )的值。
這兩段代碼最大區別就是延時不同！
tcdrain()是等待fd所引用的串口設備數據傳輸完畢。雖然在物理上數據已傳輸完畢時，但Linux對硬件實時性高，對于用戶請求的實時性較低。所以操作系統會有延時，導致tcdrain()多停留幾ms，從而導致數據發送完后，485管腳的控制方向不能及時切換。
如果對接的485設備，接收和應答的延遲小于tcdrain()的延時，那方向切換不及時將導致數據接收丟失。這就是問題根因所在。
那為什么操作系統會有延時呢？
這個得說說Linux工作隊列相關機制，對于硬件操作Linux處理的很及時，但是對于數據Linux可能將其交給系統的下半部的內核線程去處理，這就可能導致用戶的系統調用存在一定的延時，而485通信對時間要求又很嚴格，1ms的延時就會導致數據錯亂。
總結
- 嚴謹細致。在問題發生時，我也去量過主控和和MCU 485控制管腳的電平，只看到了兩者是反向的，但是并沒有放大去看最后一段電平的細節。導致遺漏了解決問題的線索。
- 一切問題發生都是有原因的。偶現問題并不好排查，但是我們可以嘗試制作偶現問題發生的條件，看有沒有可能成為必現問題。如果不能必現，可嘗試通過腳本去不斷運行在問題發生的場景，使其出現的概率提升。
- 心態。放平心態，多看代碼。認真分析。
作者：嵌入式與Linux那些事
