串口通訊，你真的會了嗎？

平時使用串口打印出現(xiàn)亂碼的，絕大部分原因是串口波特率沒對。那么，我們怎么測量實際的波特率呢？在這之前，順便一起回顧一下波特率的概念。

什么是波特率、比特率？

• 比特率(Bitrate)表示每秒鐘傳輸?shù)?code style="margin: 0px 2px;padding: 2px 4px;max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;font-size: 14px;border-radius: 4px;background-color: rgba(27, 31, 35, 0.0470588);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239, 112, 96);">二進制位數(shù)，單位為比特每秒(bit/s)。

• 波特率(Baudrate)表示每秒鐘傳送的碼元符號的個數(shù)，是衡量數(shù)據(jù)傳送速率的指標。

• 碼元是通訊信號調制的概念，通訊中常用時間間隔相同的符號來表示一個二進制數(shù)字，這樣的信號稱為碼元。

常見的通訊傳輸中，用 0V 表示數(shù)字 0， 5V 表示數(shù)字 1，那么一個碼元可以表示兩種狀態(tài) 0 和 1，所以一個碼元等于一個二進制比特位，此時波特率的大小與比特率一致。

如果在通訊傳輸中，有 0V、2V、 4V 以及 6V 分別表示二進制數(shù) 00、 01、 10、 11，那么每個碼元可以表示四種狀態(tài)，即兩個二進制比特位，所以碼元數(shù)是二進制比特位數(shù)的一半，這個時候的波特率為比特率的一半。因為很多常見的通訊（比如串口通訊）中一個碼元都是表示兩種狀態(tài)，所以大家常常直接以波特率來表示比特率 。

串口通訊協(xié)議

在串口通訊的協(xié)議層中，規(guī)定了數(shù)據(jù)包的內容，它由啟始位、主體數(shù)據(jù)、校驗位以及停止位組成，通訊雙方的數(shù)據(jù)包格式要約定一致才能正常收發(fā)數(shù)據(jù)，其數(shù)據(jù)幀組成如下：

下面，我們來實際驗證一下其數(shù)據(jù)幀是不是真的是這樣的。編寫如下代碼：

代碼很簡單，就是使用串口不斷地往外發(fā)數(shù)據(jù)0xAA（當然，發(fā)送其它數(shù)據(jù)也是可以的）。我們的串口配置如下：

我們可以使用示波器或者邏輯分析儀抓取實際信號看看數(shù)據(jù)是不是符合上面的幀格式。這里，我們使用邏輯分析儀抓取USART1的發(fā)送信號線（TX）：

從實際結果中，我們可以看到的確是按幀格式來發(fā)的。這里可能會有人有疑問，上面那個數(shù)據(jù)幀的圖片中有個空閑狀態(tài)，這個又是什么呢？空閑、空閑，當然是沒有在發(fā)數(shù)據(jù)時候的狀態(tài)呀，我們把我們的代碼改為：

在初始化完成之后只發(fā)送一次0xAA，邏輯分析儀抓到的數(shù)據(jù)為：

可見，空閑狀態(tài)是個高電平。在上一個的范例中，我們一直在while循環(huán)中發(fā)送數(shù)據(jù)0xAA，所以就沒有空閑狀態(tài)。

在這個實驗中，我們需要知道的是兩個點是：

• 串口發(fā)送數(shù)據(jù)是低位先發(fā)的。我們單片機發(fā)0xAA（10101010B），所以邏輯分析儀抓到的有效數(shù)據(jù)是01010101B。

• 單片機的串口使用的是TTL電平，為正邏輯電平信號。邏輯分析儀抓到的數(shù)據(jù)0對應著實際電壓0~0.5V，數(shù)據(jù)1對應著實際電壓2.4V-5V，

經(jīng)常與TTL電平標準做對比的是RS-232電平標準，如：

常見的電子電路中常使用 TTL 的電平標準，理想狀態(tài)下，使用 5V 表示二進制邏輯 1，使用 0V 表示邏輯 0；而為了增加串口通訊的遠距離傳輸及抗干擾能力，RS-232電平標準使用-15V 表示邏輯 1， 15V 表示邏輯 0。

在舊式的臺式計算機中一般會有 RS-232 標準的?COM 口(也稱?DB9 接口) ?：

在這個示例程序中，我們設置的串口波特率為115200bps。在串口通訊中，碼元只用1個二進制數(shù)來表示（即只有0 和 1兩種狀態(tài)），所以波特率與比特率在數(shù)值上是相等的。

而比特率表示的是每秒鐘傳輸?shù)?code style="margin: 0px 2px;padding: 2px 4px;max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;font-size: 14px;border-radius: 4px;background-color: rgba(27, 31, 35, 0.0470588);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239, 112, 96);">二進制位數(shù)，那我們知道傳一位數(shù)據(jù)的時間豈不是就可以反推出波特率是多少了嗎？從邏輯分析儀中，我們可以知道發(fā)送一位數(shù)據(jù)的時間如下：

發(fā)送一位數(shù)據(jù)的時間大約為8.667us，所以1秒鐘發(fā)送多少位數(shù)據(jù)是可以算出來的：

算出來的波特率為115380bps，與115200bps很相近。最終肯定是有一定的誤差，這個誤差產(chǎn)生的原因包括邏輯分析儀的質量及我們的測量環(huán)境等等因素。但是，這個誤差也是在允許的范圍內的，可以看看串口助手接收到的數(shù)據(jù)是不是正確的：

可見，數(shù)據(jù)接收正確，也就是波特率對的上了。

串口波特率對不上怎么解決？

在實際中。我們可能會遇到這樣的情況，代碼里配置的波特率與串口助手上設置的波特率一樣了，但還是出現(xiàn)異常情況。

異常情況如我們往串口助手發(fā)送字符串，串口助手上本該顯示的字符串出現(xiàn)了亂碼?；蛘呶覀兺谥职l(fā)送一個數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)移位了。

出這種情況大多是波特率對應不上，我們就得自己檢查我們的底層文件了，代碼中的某個與波特率計算相關的值（時鐘）與實際不匹配了，就會出現(xiàn)這樣的現(xiàn)象，比如之前我的一位同事就遇到這樣的情況就是這個原因導致的。

我們用STM32的時候，一般都是使用外部晶振，比如STM32F103系列，可輸入的外部晶振的范圍是4~16MHz：

經(jīng)驗值往往是8MHz，而且一般的demo工程底層代碼里默認的也是設置為8MHz，比如：

但是，如果實際晶振貼的不是8M的話，就出問題了（比如串口波特率就不正確了）。追根溯源，串口波特率是配進USART_Init函數(shù)中的，打開這個函數(shù)：

計算串口波特率需要一個apbclock變量，而這個值得來源從RCC_GetClocksFreq函數(shù)來，再打開這個函數(shù)：

所以要注意的是，HSE_VALUE這個值要與實際做對應。

遇到這種問題找誰說理去？經(jīng)驗就是不斷踩坑、不斷積累的一個過程，早點遇到坑可能也是一件好事。像類似底層的問題很少遇到，但是一旦遇到那就得比較棘手的問題了，需要很有耐心地去查找。

能用穩(wěn)定的芯片是一件很幸福的事情，用不穩(wěn)定、不成熟的芯片的時候，那個才是真的難啊，遇到問題真是讓人懷疑人生啊，軟件、硬件、芯片都可能有問題……

以上就是本次的筆記分享，希望各位喜歡！如有錯誤歡迎指出，謝謝！

END
作者：ZhengN來源：嵌入式大雜燴版權歸原作者所有，如有侵權，請聯(lián)系刪除。
▍