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

首先遇到的一些問題：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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