1、聊一聊

好了，今天為大家?guī)韼追NIO口模擬串口"硬核"操作，相信大家對類似于串口這樣的電平類通信會有新的認識。

2、IO模擬串口需求

"IO模擬UART"是作者大一加入學(xué)校創(chuàng)新團隊老師出的第一道題目。畢竟當時專業(yè)知識不夠，心里想：“實驗室老師怎么這么變tai，有現(xiàn)成的串口不用，非得整個模擬串口”，接到這個題目一頭霧水，于是上網(wǎng)各種找資料，最后基本實現(xiàn)了該功能，實現(xiàn)辦法算是最初級的實現(xiàn)方式，不過確實給我開啟了嵌入式的大門，所以今天也把這方面的東西分享給大家，希望對大家有幫助。

IO模擬串口需求

● 很多小伙伴應(yīng)該都了解到現(xiàn)在很多的高性能的MCU都有大量的串口外設(shè)，比如下圖的stm32F103系列USART高達5個，然而在我們一般的項目中可能僅僅就使用了2個左右的樣子，并且串口外設(shè)引腳還可以remap重新映射，這對于那些對串口資源需求量比較大的項目，或許帶來了一些緩解的福音。

上圖來源于:ST芯片datasheet

● 但是對于一些系統(tǒng)集成類項目，串口作為一種常用的簡易通信方式基本上是大部分設(shè)備都會預(yù)留的外置接口，然而不同的廠家通信接口協(xié)議都不太一樣，串口的配置信息比如波特率、格式等等都不盡相同，所以這樣大量的串口資源的需求就成為了MCU選型的一種評估條件。

往往這樣的系統(tǒng)集成軟件代碼設(shè)計相對比較簡單，基本上是進行數(shù)據(jù)收發(fā)或者轉(zhuǎn)發(fā)等等功能，所以也沒有必要選擇非常高性能的控制器，這樣串口的軟件實現(xiàn)成為了一種需求。

對于一些USART硬件上連接錯誤，比如原理圖引腳弄錯，如果飛線非常影響外觀，重新制版開發(fā)周期拉長，那么模擬串口也是值得考慮的。

3、IO模擬串口原理

大部分的通信方式都是通過電平傳遞信號，高電平表示1，低電平表示0，制定通信電平01的時間和空間規(guī)則，通信雙方就可以根據(jù)對應(yīng)的規(guī)則進行解析數(shù)據(jù)，從而進行信息的傳遞，下面作者簡單把串口通信的物理通信格式跟大家板書一下，以便后面模擬串口進行參考。

通信物理格式

下面作者以8個數(shù)據(jù)位，1個停止位，無奇偶校驗位為例:

分析一下：

上圖就是一幀簡單的串口數(shù)據(jù)幀，總線處于空閑的時候處于高電平，通過一個起始位，作為一幀數(shù)據(jù)的開始，然后以LSB->MSB的方式依次傳輸一個8位的數(shù)據(jù)，最后以1bit的停止位結(jié)束，這樣就結(jié)束了一個byte數(shù)據(jù)的傳輸。

那么但我們發(fā)送N個數(shù)據(jù)，總線上就會有N個這樣的數(shù)據(jù)幀傳輸，這樣就形成了大家平常所謂的"字節(jié)流"，在一個總線上所有的bit所維持的電平時間是固定的，這個時間的由波特率來決定，比如9600bit/s，也就是說其一個電平維持的為(1/9600)s。那個這個參數(shù)就也成了模擬串口信號的基礎(chǔ)時間約束。

值得大家注意的是串口通信的數(shù)據(jù)幀格式并不是全是(8個數(shù)據(jù)位，1個停止位，無奇偶校驗位）同樣的格式，其中數(shù)據(jù)位個數(shù)也有7,8,9個，停止位也有2個的，這個具體根據(jù)雙方協(xié)議格式來進行選擇，同時通信還有同步、異步，全雙工和半雙工等等，大家不太理解可以找時間補補。

上面我們了解了串口的電平格式，下面開始進入真正模擬串口的階段。

4、IO模擬串口必備妙招

作者這里會為大家介紹幾種辦法來模擬串口，每種方案都有自己的特點，大家可以根據(jù)實際項目和資源進行選擇和開發(fā)。

1、純延時模擬

這種方式就是當年老師出模擬串口題我所采用的辦法，可以說該辦法僅僅只是為了模擬一個串口出來(俗稱 : 為了交作業(yè)），從一個電平到下一個電平的過程均采用硬延時，然而這里的延時就是對應(yīng)著波特率所規(guī)定的電平持續(xù)時間，傳輸1位所需要的時間 T = 1/9600 約為104.167us，那么我們只需要按照對應(yīng)的格式翻轉(zhuǎn)IO口，然后delay延時對應(yīng)的時間即可完成模擬。

參考偽代碼：

1/************************************************ 2 * Fuction ：IO_UartSend 3 * Descir : IO口模擬串口發(fā)送 4 * Author : (公眾號:最后一個bug) 5 ***********************************************/ 6void IO_UartSend( sUart *pUart,unsigned char byte) 7{ 8 9 unsigned char bitCnt = 8; 10 pUart->SetTxPin(pUart,PIN_LOW); //發(fā)送 Start bit 11 pUart->BaudDelay(pUart); // 根據(jù)baudRate延時 12 while(bitCnt--) //循環(huán)發(fā)送data bit 13 { 14 pUart->SetTxPin(pUart,(pUart & 0x01)); //發(fā)送 Start bit 15 byte >>= 1; //移位所發(fā)數(shù)據(jù) 16 pUart->BaudDelay(pUart); //根據(jù)baudRate延時 17 } 18 pUart->SetTxPin(pUart,PIN_HIGH); //發(fā)送stop bit 19 pUart->BaudDelay(pUart); //根據(jù)baudRate延時 20} 21 22/************************************************ 23 * Fuction ：IO_UartRecv 24 * Descir : IO口模擬串口接受 25 * Author : (公眾號:最后一個bug) 26 ***********************************************/ 27unsigned char IO_UartRecv(sUart *pUart) 28{ 29 unsigned char Recv; 30 unsigned char bitCnt = 8; 31 32 while(!pUart->GetRxPin(pUart)) //如果接受到低電平起始位 33 { 34 pUart->BaudDelay(pUart); //根據(jù)baudRate延時 35 while(bitCnt--) 36 { 37 Recv >>= 1; 38 if(pUart->GetRxPin(pUart))Recv |= 0x80; //如果接受到電平為1,則置位 39 pUart->BaudDelay(pUart); //根據(jù)baudRate延時 40 } 41 } 42 return Recv; //最終返回接受到的數(shù)據(jù) 43}

分析一下：

上面主要是IO口模擬串口的發(fā)送和接受，發(fā)送相對比較簡單，接受部分通過不斷的查詢對應(yīng)的接收引腳是否已經(jīng)拉低成為低電平，如果拉低成為了低電平就認為接受到了start_bit，后面便通過延時進行后面數(shù)據(jù)的接收。然而其中根據(jù)波特率進行的延時一般就直接用指令周期來進行測量延時了。

此方法對于簡單的模擬串口收發(fā)功能基本實現(xiàn)了，不過其只能實現(xiàn)通信的半雙工，同時通過不斷的查詢RX的電平狀態(tài)比較浪費CPU資源，那么需要進一步改善。

2、外部中斷法

查詢比較耗費時間和資源，那么自然而然就想到采用中斷的方法來進行處理，采用IO口的外部中斷功能當RX引腳接受到一個start_bit的時候觸發(fā)一個下降沿外部中斷(記得關(guān)外部中斷)，然后在外部中斷中進行延時獲得對應(yīng)的bit數(shù)據(jù)，其處理過程與上面的延時法并沒有很大的區(qū)別，所以這就不過多解釋。

以上均存在的不穩(wěn)定因素 :

其不穩(wěn)定因素主要來源于傳輸?shù)碾娖椒D(zhuǎn)不是絕對的穩(wěn)定，同時波特率傳輸?shù)臅r間也不一定完全相同，如下圖所示:

分析一下：

如上圖所示首次獲取電平的位置，都是在下降沿的位置開始進行數(shù)據(jù)的獲取，然后通過波特率所對應(yīng)的延時來進行下一bit位的獲取，從而獲得最終的傳輸數(shù)據(jù)。

大家應(yīng)該都知道通信線路上是存在物理阻抗的，其對應(yīng)的通信線路上的電平變化是不可能像上圖中的方波那么標準的，其過程均存在一個上升時間和下降時間，同時再加上傳輸?shù)腷it時間間隔并不是嚴格的一致，所以在電平變化附近進行電平的判斷是會存在誤判的風(fēng)險。

然而如果我們在首次獲取以后延時半個周期,如上圖藍色虛線箭頭所示位置進行判斷便能夠比較可靠的獲得通信bit數(shù)據(jù)了。

雖然能夠獲得穩(wěn)定的數(shù)據(jù)，不過采用硬延時在軟件設(shè)計中終究是一個不太好的實現(xiàn)方案，同時以上通信還無法實現(xiàn)全雙工，所以還是有必要再進行優(yōu)化改善。

3、外部中斷+定時器法

其實要解決硬延時最直接的處理辦法就是使用定時器來進行處理，大家把發(fā)送和接受都放到對應(yīng)的時間間隔里處理，這里大家比較常用的一種方案就是使用外部中斷獲得start_bit的位置，然后在外部中斷中開啟1/2bit定時，比如9600波特率，其一個bit傳輸需要104.167us，那么一般我們會采用104.167us/2的來設(shè)置定時時間進行后續(xù)電平的獲取，如下圖所示:

分析一下：

然而這樣的方案，在僅僅模擬一個串口還是比較方便，不過如果模擬多個串口就需要多個定時器，這樣實在是太浪費資源了。

那么是否用一個定時器就能搞定呢?很多小伙伴可能會說：我直接開一個bit周期的定時器不斷的定時周期到來進行判斷不就可以了嗎?下面我們簡單的看下該辦法的效果。

4、單定時器法

首先這里實驗一下bit周期定時法,作者編寫好相應(yīng)的代碼以后，以20ms的速度發(fā)送兩個字符55，然后讓其回顯的實驗結(jié)果如下:

我們發(fā)現(xiàn)其存在較高的誤碼問題，其主要的原因還是跟我們之前所說的影響因素有關(guān)，如果定時器中斷到來的時間剛好位于串口電平跳變附近，那么極有可能會存在讀取IO口電平錯誤問題。

那么所有的問題就歸結(jié)到如何在電平穩(wěn)定的時候讀取IO口的狀態(tài)，那么最直接的辦法就是提高定時器的中斷頻率，比如1/3bit周期法等等更高的定時器中斷頻率，如下圖所示1/3bit周期法:

分析一下：

采用1/3bit周期法，其起始位的下降沿一定在1-2之間，如果我們判斷起始位在1位置處，后續(xù)數(shù)據(jù)bit仍然是1位置，還是會出現(xiàn)之前的不穩(wěn)定因素，所以這里需要調(diào)整讀取IO的位置。

那么采用1/3bit周期法會在判斷起始bit下降沿的下一個定時器周期開始讀取對應(yīng)的電平，如果在1位置讀取到了第一個低電平，那么后續(xù)都會在2位置進行數(shù)據(jù)讀取；如果在2位置才讀取到了第一個低電平，后續(xù)都會在3位置進行數(shù)據(jù)讀取，這樣在2,3位置讀取的數(shù)據(jù)均是處于比較穩(wěn)定的數(shù)據(jù)。

下面是作者采用1/3bit周期法的結(jié)果，該辦法也是大家經(jīng)常選用的。

4、其他方法

對于一些高端的MCU一般會有捕獲口，其實捕獲口有點類似于中斷外部+定時器的方法，不過其原理是通過計算每個相鄰邊沿跳變中間所包含的bit個數(shù)，從而獲得最終的數(shù)據(jù)，如下圖所示:

分析一下：

采用捕獲的辦法不再是采集電平，通過定時器獲得每個跳變之間的時間間隔，然后通過時間間隔/波特率對應(yīng)的電平持續(xù)時間 = 電平個數(shù)，從而最終算出最后的數(shù)據(jù)。

該方案是比較穩(wěn)定的，如果手頭的芯片沒有對應(yīng)的Capture功能，大家也可以使用外部中斷(注意上升沿和下降沿的處理)+定時器的方法代替捕獲功能。

審核編輯：何安