最近測試涉及到底層串口代碼的修改。經(jīng)過這次修改，突然發(fā)現(xiàn)其實(shí)自己對于串口的一些特性以前并不是十分清楚。

首先遇到的一些問題：

1)在使用IO的數(shù)據(jù)位的時候，沒有考慮校驗(yàn)位所占的位數(shù)。

2)在設(shè)置串口輸入的時候，使用懸空輸入。

關(guān)于1)，在一次使用STM32串口參數(shù)9600,N,8,1與另一個 8051MCU通信的時候發(fā)現(xiàn)偶校驗(yàn)沒有問題，但是無校驗(yàn)通信就出現(xiàn)異常。但是，當(dāng)將STM32與電腦通信的時候，偶校驗(yàn)與無校驗(yàn)通信又完全都是正確的。8051MCU單獨(dú)與電腦通信也都是完全正確的。查看代碼，還真不知道有什么不對勁的。因?yàn)檫@段代碼，用了很長時間了。后來一個同事看代碼后，提醒說對于數(shù)據(jù)位的設(shè)置，偶校驗(yàn)和無校驗(yàn)是一致的，既然沒有數(shù)據(jù)位，有可能會少一位。從這點(diǎn)看，這段代碼可以修改看看。于是在這個地方，將偶校驗(yàn)的時候數(shù)據(jù)位長度設(shè)置為9bit，無校驗(yàn)的時候設(shè)置為8bit。重新測試，發(fā)現(xiàn)通信正常了。

原來這段代碼，由于一直用偶校驗(yàn)進(jìn)行通信，所以對于奇校驗(yàn)和無校驗(yàn)的參數(shù)設(shè)置，沒有測試過。雖然，已經(jīng)存在很長時間，但是由于一直沒有用到奇校驗(yàn)和無校驗(yàn)，于是這個BUG。一直潛伏到現(xiàn)在。直到這次使用到才發(fā)現(xiàn)。

關(guān)于2)，是在一次使用中發(fā)現(xiàn)，串口線的連接如果與從機(jī)分離，則串口上會莫名接收到一些00數(shù)據(jù)。一開始沒有在意，以為是離開確定電平后，導(dǎo)致的什么干擾造成的。但是，沒有去考慮是什么造成接收這么容易受干擾。直到有一次，和同事確認(rèn)串口的初始化電平設(shè)置時，他告訴說是懸空設(shè)置。這下子感覺不對了，懸空很容易造成受干擾。于是馬上查看串口的初始化代碼，發(fā)現(xiàn)確實(shí)是懸空設(shè)置。馬上修改了。在測試，將連接的串口懸空，也沒有再收到。

后來查看了關(guān)于串口的內(nèi)容發(fā)現(xiàn)以前有些東西沒有注意到：

串口分為同步串口，異步串口。

這里說的串口指通常說的UART，異步串行通信接口。

還有就是同步串口，即SPI，I2C之類。

首先，UART不需要接收和發(fā)送兩端嚴(yán)格的時鐘同步，在不通信的時候IO電平呈現(xiàn)高電平，即空閑。所以對于UART來說，如果沒有數(shù)據(jù)交互，數(shù)據(jù)線是呈現(xiàn)高電平的。

對于UART的數(shù)據(jù)位問題，是包含數(shù)據(jù)+校驗(yàn)的bit數(shù)總和。

為了提高UART的抗干擾性，無論在哪一種工作模式下，都能夠保證數(shù)據(jù)線上有穩(wěn)定的電平。所以串口設(shè)置時，對于串口輸入引腳設(shè)置為上拉輸入。對于串口的設(shè)置，輸出一般設(shè)置為push-pull，輸入一般設(shè)置為pull up。

(這里有一個疑問，為什么串口還會留下懸空輸入?既然一般情況下，上拉輸入對于接收方而言會處于一個比較穩(wěn)定的狀態(tài)。如果將輸入設(shè)置為懸空輸入反而會引入接收不穩(wěn)定的因素，為什么會有懸空輸入。在什么地方，又會使用懸空輸入呢?在不同電壓的時候可能是一種情況，及3.3VTTL電平的CPU，與5.0VTTL的CPU直接使用串口通信的時候，為了避免電平問題采用懸空有可能是一個種情況。)

這里也提出一個問題，對于系統(tǒng)的底層代碼要格外嚴(yán)謹(jǐn)。保證開發(fā)出來的代碼，有高的穩(wěn)定性，可靠性。才能保證其他程序順利開發(fā)。

同時對于代碼的測試要盡可能覆蓋所有代碼。對于開發(fā)過程中，引入的功能及代碼要進(jìn)行實(shí)際測試，明確其執(zhí)行到的時候?qū)τ诔绦虻挠绊憽]有運(yùn)行過的代碼，在程序中就是一座可能噴發(fā)的活火山。所以對于添加的功能及代碼，要確保執(zhí)行過。

在開發(fā)過程中，要時刻保持警惕，警惕可能出現(xiàn)異常的地方，學(xué)著用推理去找到BUG的巢穴。