早期的MCU因為片上外設資源（比如UART、I2C、SPI等）很少，就有“模擬”這種操作。 ? 今天為大家帶來幾種IO口模擬串口"硬核"操作，相信大家對類似于串口這樣的電平類通信會有新的認識。

IO模擬串口需求

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

IO模擬串口需求

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

上圖來源于:ST芯片datasheet

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

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

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

IO模擬串口原理

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

通信物理格式

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

分析一下：

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

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

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

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

4、IO模擬串口必備妙招

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

1

純延時模擬

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

參考偽代碼：

 1/************************************************
 2?* Fuction ：IO_UartSend
 3?*?Descir??:??IO口模擬串口發送
 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);??//發送?Start?bit
11????pUart->BaudDelay(pUart);?????????//?根據baudRate延時?
12????while(bitCnt--)???????????????????????//循環發送data?bit?
13????{
14????????pUart->SetTxPin(pUart,(pUart?&?0x01));?//發送?Start?bit????
15????????byte?>>=?1;????????????????????????????//移位所發數據?
16????????pUart->BaudDelay(pUart);???????????????//根據baudRate延時??
17????}
18????pUart->SetTxPin(pUart,PIN_HIGH);?//發送stop?bit?
19????pUart->BaudDelay(pUart);?????????//根據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);?????????//根據baudRate延時?
35????????while(bitCnt--)
36????????{
37????????????Recv?>>=?1;
38????????????if(pUart->GetRxPin(pUart))Recv?|=?0x80;?//如果接受到電平為1,則置位?
39????????????pUart->BaudDelay(pUart);?????????//根據baudRate延時?
40????????}
41????}
42????return?Recv;?//最終返回接受到的數據?
43}

分析一下：

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

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

2

外部中斷法

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

以上均存在的不穩定因素 :

其不穩定因素主要來源于傳輸的電平翻轉不是絕對的穩定，同時波特率傳輸的時間也不一定完全相同，如下圖所示:

分析一下：

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

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

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

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

3

外部中斷+定時器法

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

分析一下：

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

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

4

單定時器法

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

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

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

分析一下：

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

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

下面是作者采用1/3bit周期法的結果，該辦法也是大家經常選用的。

4

其他方法

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

分析一下：

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

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

審核編輯：黃飛

?