9106
前段時(shí)間接到一個(gè)項(xiàng)目，要求用主控用485和MCU通信。將代碼調(diào)試好之后，驗(yàn)證沒問題就發(fā)給測試了。測試測的也沒問題。
但是，到設(shè)備量產(chǎn)時(shí)，發(fā)現(xiàn)有幾臺設(shè)備功能異常。將設(shè)備拿回來排查，發(fā)現(xiàn)是485通信有問題，偶現(xiàn)通信失敗。
排查思路
復(fù)現(xiàn)問題
發(fā)給測試之前，功能都驗(yàn)證了很多次，但是并沒有發(fā)現(xiàn)通信失敗的問題。設(shè)備拿到手，第一時(shí)間就嘗試復(fù)現(xiàn)通信失敗的問題，也沒有成功。
于是，寫了一個(gè)腳本，不斷的和MCU通信，看什么情況下會失敗。
果然，在通信若干次后，發(fā)現(xiàn)日志異常，主控接收數(shù)據(jù)出現(xiàn)了錯亂。
接著，繼續(xù)跑腳本，想看下什么情況下會失敗。但是，每次通信異常的時(shí)機(jī)都是隨機(jī)的，沒有規(guī)律。
觀察了下錯亂的數(shù)據(jù)，和正確的數(shù)據(jù)做了對比，也沒有什么發(fā)現(xiàn)。
清空buf
接收的數(shù)據(jù)出現(xiàn)了異常，第一個(gè)想到的是，是不是接收buffer不干凈，有其他數(shù)據(jù)干擾呢？
嘗試在接收buffer和發(fā)送buffer之前，手動清空下buf。確保不會有其它數(shù)據(jù)干擾。
重新跑腳本和MCU 通信，但是仍會失敗。
收發(fā)時(shí)序
光看是什么辦法了。上示波器看下主控和MCU的時(shí)序的。
正常來講，主控和MCU的485控制管腳應(yīng)該是正好反向的電平。即主控485控制管腳高電平發(fā)送的時(shí)候，MCU的485控制管腳應(yīng)該是低電平。
問題復(fù)現(xiàn)時(shí)，對比了管腳的電平，確實(shí)是反向的，沒有問題。這也排除了收發(fā)時(shí)序?qū)Σ簧系膯栴}。
(綠色的是MCU的485控制管腳，黃色的是主控的485控制管腳)
收發(fā)數(shù)據(jù)正確
小示波器沒有解碼的功能，只能找硬件來量下主控的RX和MCU的TX。確認(rèn)下，到底是主控接收的不對，還是MCU發(fā)的不對。
顯然，是主控接收的數(shù)據(jù)有問題了。
仔細(xì)觀察會發(fā)現(xiàn)，綠色波形這里有個(gè)半高電平，覆蓋了黃色的低電平。導(dǎo)致第一幀出錯了，后面的數(shù)據(jù)也都錯亂了。
又重新復(fù)現(xiàn)了幾次，發(fā)現(xiàn)每次失敗時(shí)都是這種現(xiàn)象。那為什么這里會有個(gè)半高電平呢？
確認(rèn)問題
和硬件對著原理圖經(jīng)過一番討論，硬件給到的結(jié)論是，485芯片的RX管腳接了3.3V的上拉，只有當(dāng)485芯片的使能管腳拉高時(shí)，RX才會有3.3V的半高電平出現(xiàn)。硬件懷疑是485控制管腳和MCU的時(shí)序沒對上。
不過，我之前也量了主控和MCU的485控制管腳的電平，看了是對的？難道是我看錯了？
接著又重新量了主控和MCU的485控制管腳，發(fā)現(xiàn)確實(shí)有問題，具體如下圖。兩者有1.5ms的高電平是重合的，這或許就是問題所在！
又重新復(fù)現(xiàn)了幾次問題，發(fā)現(xiàn)每次通信失敗時(shí)，都會有一段高電平是重合的。
到這里，基本也就明確了問題原因：主控和MCU的485控制管腳時(shí)序沒對上！
尋找問題根因
從波形找出了問題所在，回歸串口編程，繼續(xù)看下代碼吧。把重點(diǎn)放在了時(shí)序切換的代碼上。
代碼里面，在切換485管腳時(shí)有這樣兩段代碼。
以下只是偽代碼
代碼一：
setdir(SEND)??//切換為發(fā)送狀態(tài)
write()????//發(fā)送數(shù)據(jù)
tcdrain(fd)???//判斷是否寫完
setdir(READ)??//切換為讀狀態(tài)
代碼二：
do
{
?ioctl(fd,TIOCSERGETLSR,&lsr)?//判斷發(fā)送buffer是否寫完
}while(!(lsr&TIOCSER_TEMT))?//如果TX為空，返回TIOCSER_TEMT
這兩段代碼，都是和485管腳切換相關(guān)的，根據(jù)不同情況走不同邏輯，出問題的代碼走的是代碼一片段。
tcdrain 和 TIOCSERGETLSR
那這兩段代碼有什么區(qū)別呢？
tcdrain是應(yīng)用層控制tty的一個(gè)函數(shù)，調(diào)用 tcdrain()函數(shù)后會使得應(yīng)用程序阻塞， 直到串口輸出緩沖區(qū)中的數(shù)據(jù)全部發(fā)送完畢為止。
ioctl(fd,TIOCSERGETLSR,&lsr)是獲取tty 設(shè)備的線路狀態(tài)寄存器( LSR )的值。
這兩段代碼最大區(qū)別就是延時(shí)不同！
tcdrain()是等待fd所引用的串口設(shè)備數(shù)據(jù)傳輸完畢。雖然在物理上數(shù)據(jù)已傳輸完畢時(shí)，但Linux對硬件實(shí)時(shí)性高，對于用戶請求的實(shí)時(shí)性較低。所以操作系統(tǒng)會有延時(shí)，導(dǎo)致tcdrain()多停留幾ms，從而導(dǎo)致數(shù)據(jù)發(fā)送完后，485管腳的控制方向不能及時(shí)切換。
如果對接的485設(shè)備，接收和應(yīng)答的延遲小于tcdrain()的延時(shí)，那方向切換不及時(shí)將導(dǎo)致數(shù)據(jù)接收丟失。這就是問題根因所在。
那為什么操作系統(tǒng)會有延時(shí)呢？
這個(gè)得說說Linux工作隊(duì)列相關(guān)機(jī)制，對于硬件操作Linux處理的很及時(shí)，但是對于數(shù)據(jù)Linux可能將其交給系統(tǒng)的下半部的內(nèi)核線程去處理，這就可能導(dǎo)致用戶的系統(tǒng)調(diào)用存在一定的延時(shí)，而485通信對時(shí)間要求又很嚴(yán)格，1ms的延時(shí)就會導(dǎo)致數(shù)據(jù)錯亂。
總結(jié)
- 嚴(yán)謹(jǐn)細(xì)致。在問題發(fā)生時(shí)，我也去量過主控和和MCU 485控制管腳的電平，只看到了兩者是反向的，但是并沒有放大去看最后一段電平的細(xì)節(jié)。導(dǎo)致遺漏了解決問題的線索。一切問題發(fā)生都是有原因的。偶現(xiàn)問題并不好排查，但是我們可以嘗試制作偶現(xiàn)問題發(fā)生的條件，看有沒有可能成為必現(xiàn)問題。如果不能必現(xiàn)，可嘗試通過腳本去不斷運(yùn)行在問題發(fā)生的場景，使其出現(xiàn)的概率提升。心態(tài)。放平心態(tài)，多看代碼。認(rèn)真分析。
