背景

前段時(shí)間接到一個(gè)項(xiàng)目，要求用主控用485和MCU通信。將代碼調(diào)試好之后，驗(yàn)證沒問題就發(fā)給測(cè)試了。測(cè)試測(cè)的也沒問題。

但是，到設(shè)備量產(chǎn)時(shí)，發(fā)現(xiàn)有幾臺(tái)設(shè)備功能異常。將設(shè)備拿回來排查，發(fā)現(xiàn)是485通信有問題，偶現(xiàn)通信失敗。

排查思路

復(fù)現(xiàn)問題

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

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

果然，在通信若干次后，發(fā)現(xiàn)日志異常，主控接收數(shù)據(jù)出現(xiàn)了錯(cuò)亂。

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

觀察了下錯(cuò)亂的數(shù)據(jù)，和正確的數(shù)據(jù)做了對(duì)比，也沒有什么發(fā)現(xiàn)。

清空buf

接收的數(shù)據(jù)出現(xiàn)了異常，第一個(gè)想到的是，是不是接收buffer不干凈，有其他數(shù)據(jù)干擾呢？

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

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

收發(fā)時(shí)序

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

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

問題復(fù)現(xiàn)時(shí)，對(duì)比了管腳的電平，確實(shí)是反向的，沒有問題。這也排除了收發(fā)時(shí)序?qū)Σ簧系膯栴}。

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

收發(fā)數(shù)據(jù)正確

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

顯然，是主控接收的數(shù)據(jù)有問題了。

仔細(xì)觀察會(huì)發(fā)現(xiàn)，綠色波形這里有個(gè)半高電平，覆蓋了黃色的低電平。導(dǎo)致第一幀出錯(cuò)了，后面的數(shù)據(jù)也都錯(cuò)亂了。

又重新復(fù)現(xiàn)了幾次，發(fā)現(xiàn)每次失敗時(shí)都是這種現(xiàn)象。那為什么這里會(huì)有個(gè)半高電平呢？

確認(rèn)問題

和硬件對(duì)著原理圖經(jīng)過一番討論，硬件給到的結(jié)論是，485芯片的RX管腳接了3.3V的上拉，只有當(dāng)485芯片的使能管腳拉高時(shí)，RX才會(huì)有3.3V的半高電平出現(xiàn)。硬件懷疑是485控制管腳和MCU的時(shí)序沒對(duì)上。

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

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

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

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

尋找問題根因

從波形找出了問題所在，回歸串口編程，繼續(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ù)后會(huì)使得應(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對(duì)硬件實(shí)時(shí)性高，對(duì)于用戶請(qǐng)求的實(shí)時(shí)性較低。所以操作系統(tǒng)會(huì)有延時(shí)，導(dǎo)致tcdrain()多停留幾ms，從而導(dǎo)致數(shù)據(jù)發(fā)送完后，485管腳的控制方向不能及時(shí)切換。

如果對(duì)接的485設(shè)備，接收和應(yīng)答的延遲小于tcdrain()的延時(shí)，那方向切換不及時(shí)將導(dǎo)致數(shù)據(jù)接收丟失。這就是問題根因所在。

那為什么操作系統(tǒng)會(huì)有延時(shí)呢？

這個(gè)得說說Linux工作隊(duì)列相關(guān)機(jī)制，對(duì)于硬件操作Linux處理的很及時(shí)，但是對(duì)于數(shù)據(jù)Linux可能將其交給系統(tǒng)的下半部的內(nèi)核線程去處理，這就可能導(dǎo)致用戶的系統(tǒng)調(diào)用存在一定的延時(shí)，而485通信對(duì)時(shí)間要求又很嚴(yán)格，1ms的延時(shí)就會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂。

總結(jié)

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

總結(jié)

以上是生活随笔為你收集整理的Linux 485驱动通信异常的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。