1. 坑一查詢方式接收主循環(huán)一忙就丟字節(jié)1.1 現(xiàn)象描述與根因很多初學者第一次寫STC51串口接收用的都是類似這樣的查詢代碼while (1) { if (RI) { RI 0; buf[count] SBUF; } // 其他任務(wù)數(shù)碼管掃描、按鍵檢測、延時... }單獨跑這段代碼感覺一切正常。但一旦把其他功能加進來比如數(shù)碼管動態(tài)掃描、按鍵消抖、OLED刷新問題就來了——收到的數(shù)據(jù)不是丟一個兩個而是大量丟失甚至整個數(shù)據(jù)幀都收不全。你覺得串口調(diào)試助手上明明每次只發(fā)10個字節(jié)程序里卻只收到了5個、6個還經(jīng)常是斷斷續(xù)續(xù)的。查了波特率、查了接線、查了芯片都沒找到問題最后把主循環(huán)里的延時去掉數(shù)據(jù)才慢慢恢復。問題根源在于查詢方式意味著CPU必須持續(xù)盯著RI標志位。主循環(huán)一旦去執(zhí)行其他任務(wù)——特別是那些延時比較長的任務(wù)比如LED閃爍用的delay(1000)——串口數(shù)據(jù)到達時CPU根本不在接收現(xiàn)場硬件接收緩沖區(qū)就會被下一個字節(jié)覆蓋。STC51的UART硬件接收通道只有一個字節(jié)深度。也就是說只要上一幀數(shù)據(jù)進入SBUF后沒被及時搬走下一幀數(shù)據(jù)到達時就會把它頂?shù)暨B個通知都沒有。這不是芯片的設(shè)計缺陷而是幾乎所有8位單片機串口的通病。1.2 解決方案中斷驅(qū)動 環(huán)形緩沖區(qū)正確做法是把接收動作搬到中斷里讓UART數(shù)據(jù)一到就立刻被“搶救”進內(nèi)存緩沖區(qū)。主循環(huán)再去緩沖區(qū)里讀取、解析數(shù)據(jù)這樣即使主循環(huán)處理別的任務(wù)只要緩沖區(qū)沒滿數(shù)據(jù)就不會丟。#define RING_SIZE 64 volatile unsigned char ring_buf[RING_SIZE]; volatile unsigned char head 0; // 寫入位置 volatile unsigned char tail 0; // 讀取位置 void UART_ISR() interrupt 4 { unsigned char ch; if (RI) { RI 0; // 必須先清標志再讀數(shù)據(jù) ch SBUF; ring_buf[head] ch; head (head 1) % RING_SIZE; } if (TI) { TI 0; // 發(fā)送完成標志暫時用不到 } }主循環(huán)讀取unsigned char UART_ReadByte(unsigned char *byte) { if (head tail) { return 0; // 緩沖區(qū)為空 } *byte ring_buf[tail]; tail (tail 1) % RING_SIZE; return 1; }這套方案的核心叫“生產(chǎn)者—消費者模型”。中斷負責把數(shù)據(jù)快速存入緩沖區(qū)主循環(huán)決定什么時候取出來處理。雙方互不阻塞緩沖區(qū)就是中間的“倉庫”。需要注意幾個關(guān)鍵點環(huán)形緩沖區(qū)的大小要根據(jù)你的業(yè)務(wù)數(shù)據(jù)量來定。如果每次上位機發(fā)送64字節(jié)緩沖區(qū)至少設(shè)成128盡量避免出現(xiàn)“倉庫滿了生產(chǎn)者無法入庫”的情況。緩沖區(qū)溢出時代碼里的處理方式是靜默丟棄新數(shù)據(jù)。實際項目中建議加一個溢出標志方便排查問題——畢竟緩沖區(qū)溢出就意味著數(shù)據(jù)沒收到原因可能是緩沖區(qū)太小也可能是主循環(huán)處理太慢。環(huán)形緩沖區(qū)只適合單生產(chǎn)者、單消費者的場景。中斷往緩沖區(qū)寫、主循環(huán)從緩沖區(qū)讀是典型的單生產(chǎn)者單消費者不需要加鎖。1.3 為什么中斷里必須先清RI再讀SBUF這是從STC官方手冊和大量調(diào)試經(jīng)驗里驗證過的坑。如果先讀SBUF再清RI看起來也只差一行代碼但存在極其微小的隱患數(shù)據(jù)在SBUF里等著你搬你讀走之后硬件會認為緩沖區(qū)已空。然后你才清RI標志此時如果恰好又有新數(shù)據(jù)進來RI會再次被置位但你清的“RI”可能清掉了新數(shù)據(jù)對應(yīng)的標志位造成數(shù)據(jù)丟失或一次中斷處理兩個字節(jié)的混亂情況。最穩(wěn)妥的做法就是第一時間清RI再去讀SBUF。實測中先清后讀和先讀后清在低速波特率下通常沒什么區(qū)別但9600以上、系統(tǒng)開了其他高優(yōu)先級中斷時差異就可能體現(xiàn)出來。養(yǎng)成規(guī)范習慣能幫你省掉很多莫名其妙的排查時間。2. 坑二多字節(jié)數(shù)據(jù)幀“粘包”與“錯幀”2.1 數(shù)據(jù)幀的邊界在哪里解決了丟字節(jié)問題你會發(fā)現(xiàn)3個坑里的第二個更隱蔽數(shù)據(jù)一個不丟但它會“串位”。你發(fā)一段固定協(xié)議比如幀頭0xAA、命令0x01、一個字節(jié)數(shù)據(jù)、幀尾0x55按道理收到的數(shù)據(jù)會是一條一條的?？蓪嶋H解析出來的數(shù)據(jù)經(jīng)常是錯位的幀頭跑到中間、命令和數(shù)據(jù)對不上號有時一幀變兩幀。導致這個問題的原因是串口是純字節(jié)流傳輸。它不知道你發(fā)的“這10個字節(jié)是一個完整數(shù)據(jù)包”它只負責把字節(jié)一個接一個地送到接收端。也就是說單片機收到的是AA 01 0A 55 AA 02 0B 55而不是AA 01 0A 55 AA 02 0B 55如果上位機發(fā)送速度太快、程序啟動時上位機已經(jīng)發(fā)了一部分數(shù)據(jù)、或者中途有一個字節(jié)出了錯單片機就無法判斷哪里有邊界整個數(shù)據(jù)流就會崩塌。2.2 解決方案幀協(xié)議 狀態(tài)機拆幀解決辦法不是試圖讓串口“智能識別包”而是自己定義一套明確的幀格式然后用狀態(tài)機在數(shù)據(jù)流里不停地找邊界。比較常用的一種簡化幀格式字段長度說明幀頭2字節(jié)固定值 0xAA 0x55用來同步長度1字節(jié)數(shù)據(jù)部分長度命令1字節(jié)功能碼數(shù)據(jù)變長業(yè)務(wù)數(shù)據(jù)校驗1字節(jié)前面所有字節(jié)累加和低8位狀態(tài)機拆幀代碼typedef enum { FRAME_WAIT_HEAD1, FRAME_WAIT_HEAD2, FRAME_WAIT_LEN, FRAME_WAIT_CMD, FRAME_WAIT_DATA, FRAME_WAIT_CHECK } FRAME_STATE; #define FRAME_MAX_DATA_LEN 16 typedef struct { unsigned char len; // 數(shù)據(jù)段長度 unsigned char cmd; // 命令字 unsigned char data[FRAME_MAX_DATA_LEN]; } FRAME_T; FRAME_STATE state FRAME_WAIT_HEAD1; unsigned char rx_len 0; unsigned char rx_index 0; unsigned char rx_check_sum 0; FRAME_T rx_frame; void Frame_Parse(unsigned char byte) { switch (state) { case FRAME_WAIT_HEAD1: if (byte 0xAA) { state FRAME_WAIT_HEAD2; } else { state FRAME_WAIT_HEAD1; // 繼續(xù)找 } break; case FRAME_WAIT_HEAD2: if (byte 0x55) { state FRAME_WAIT_LEN; rx_check_sum 0xAA 0x55; // 從幀頭開始累加 } else if (byte 0xAA) { // 這里是重點不是0x55但也可能是新的幀頭 // 所以不能回到WAIT_HEAD1要保持WAIT_HEAD2 } else { state FRAME_WAIT_HEAD1; } break; case FRAME_WAIT_LEN: if (byte FRAME_MAX_DATA_LEN) { // 長度非法說明前面是噪聲重新搜幀頭 state FRAME_WAIT_HEAD1; break; } rx_len byte; rx_index 0; rx_check_sum byte; state FRAME_WAIT_CMD; break; case FRAME_WAIT_CMD: rx_frame.cmd byte; rx_check_sum byte; if (rx_len 0) { state FRAME_WAIT_CHECK; } else { state FRAME_WAIT_DATA; } break; case FRAME_WAIT_DATA: rx_frame.data[rx_index] byte; rx_check_sum byte; if (rx_index rx_len) { state FRAME_WAIT_CHECK; } break; case FRAME_WAIT_CHECK: if (rx_check_sum byte) { // 校驗通過一幀完整收到交給業(yè)務(wù)處理 Process_Frame(rx_frame); } state FRAME_WAIT_HEAD1; break; default: state FRAME_WAIT_HEAD1; break; } }然后在串口中斷里調(diào)用void UART_ISR() interrupt 4 { unsigned char ch; if (RI) { RI 0; ch SBUF; ring_buf[head] ch; head (head 1) % RING_SIZE; } if (TI) { TI 0; } }主循環(huán)里逐個取字節(jié)解析while (UART_ReadByte(ch)) { Frame_Parse(ch); }2.3 設(shè)計狀態(tài)機時最容易被忽略的細節(jié)細節(jié)一幀頭不匹配時不能盲目恢復到“等待幀頭1”。上面代碼里處理FRAME_WAIT_HEAD2時如果收到的字節(jié)不是0x55而是0xAA說明當前字節(jié)可能是新一幀的幀頭1那就直接保持在當前狀態(tài)繼續(xù)等0x55。如果你退回WAIT_HEAD1就會漏掉這個可能的幀頭導致整幀數(shù)據(jù)全部前移一位后面解析全部錯亂。細節(jié)二長度字段必須做合法性校驗。如果協(xié)議里定了數(shù)據(jù)段最大16字節(jié)而收到的長度字段是200那后面的狀態(tài)機會一直等待200個數(shù)據(jù)期間所有正常幀都會被當成數(shù)據(jù)吞掉。加一行判斷非法長度就回退到WAIT_HEAD1能省掉無數(shù)奇怪的問題。細節(jié)三校驗不通過時不一定要丟棄整幀。你可以把收到的字節(jié)存到錯誤日志里或者至少保留一個錯誤計數(shù)器。我在實際項目中靠這個計數(shù)定位過一臺上位機串口芯片損壞的問題——它發(fā)出來的高頻噪聲偶爾會破壞數(shù)據(jù)流但不會一直破壞錯誤計數(shù)一下子飆升才讓我注意到系統(tǒng)里有這個隱性干擾源。3. 坑三晶振誤差導致串口亂碼3.1 用12MHz晶振跑9600波特率為什么不行這個坑看著基礎(chǔ)實際上坑害的人非常多。尤其是從STC89C52入門的人手上常備12MHz晶振網(wǎng)上的例程寫9600波特率。結(jié)果下載到開發(fā)板串口助手收到的全是亂碼。你用STC系列大都知道傳統(tǒng)STC51的定時器1工作方式28位自動重裝載是串口波特率最常用的來源。它的波特率計算公式是波特率 SYSclk / 12 / 32 / (256 - TH1)公式里的SYSclk就是系統(tǒng)時鐘也就是晶振頻率。以11.0592MHz為例計算9600波特率TH1 256 - 11059200 / 12 / 32 / 9600 256 - 30 226 (0xE2)算出來是個整數(shù)完美。但換成12MHz晶振TH1 256 - 12000000 / 12 / 32 / 9600 256 - 32.55 ≈ 256 - 32 ≈ 224如果把TH1設(shè)成224實際波特率是實際波特率 12000000 / 12 / 32 / (256 - 224) 9765.6和9600之間的誤差約1.7%。看起來不大但串口通信要求波特率誤差在正負2%以內(nèi)才能保證不大量出錯1.7%這個數(shù)字雖然勉強在邊緣但受溫度、供電電壓影響后很容易就越界了。尤其是一行發(fā)多字節(jié)數(shù)據(jù)誤差會不斷累積最終導致某些字節(jié)的采樣點落在錯誤的時間窗口里收到的數(shù)據(jù)就變成亂碼。所以做串口通信的STC51工程老老實實用11.0592MHz晶振。有人說用STC內(nèi)部RC振蕩器也能湊合但那玩意兒誤差更大做演示可以做正式項目不要賭。3.2 波特率誤差的計算方法很多人拿到一段代碼直接抄了TH1和TL1的賦值并不理解這個值到底怎么算的。我建議你把下面這個計算模板存下來遇到不同晶振、不同波特率時自己算一遍第一步算分頻系數(shù) 分頻系數(shù) FOSC / 12 / 32 / BAUD 第二步計算重裝載值 RELOAD 256 - 分頻系數(shù) 第三步向下取整作為TH1 RELOAD_INT (unsigned char)RELOAD 第四步計算實際波特率 實際波特率 FOSC / 12 / 32 / (256 - RELOAD_INT) 第五步計算誤差率 誤差率 (實際波特率 - 目標波特率) / 目標波特率 * 100%以12MHz、9600波特率為例分頻系數(shù) 12000000 / 12 / 32 / 9600 32.55 RELOAD 256 - 32.55 223.45 TRUNC(RELOAD) 223 實際波特率 12000000 / 12 / 32 / (256 - 223) 9470 誤差率 (9470 - 9600) / 9600 -1.35%-1.35%看起來還可以接受但注意這只是理論計算實際中還需要考慮內(nèi)部RC振蕩器本身的離散性和溫漂誤差會比理論值更大。這也是我不建議用內(nèi)部RC做串口的核心原因。3.3 如何確認你的波特率到底準不準有一種非常簡單、不需要示波器的驗證方法用串口調(diào)試助手的“自動發(fā)送”功能以某個固定的時間間隔循環(huán)發(fā)送相同的數(shù)據(jù)然后在接收區(qū)觀察回顯數(shù)據(jù)是否穩(wěn)定不變。如果波特率偏差大接收區(qū)的內(nèi)容會發(fā)生周期性錯亂比如每次發(fā)到第7個字節(jié)開始出錯第13個字節(jié)恢復正常再往后又出錯——這個周期長度和波特率偏差直接相關(guān)。另一種更靠譜的方式是用邏輯分析儀或者示波器單步捕獲單片機TXD引腳的波形測量一個字節(jié)起始位8位數(shù)據(jù)的實際時間。如果發(fā)0x00電平變化最明顯看下降沿到下一個上升沿的時間反推波特率是否準確。但前提是你手里有邏輯分析儀并且愿意折騰。如果只是做課程設(shè)計或者比賽最簡單的方案還是換11.0592MHz晶振讓波特率計算變成精確整數(shù)從源頭消除不確定性。4. 完整示例代碼三合一健壯版串口工程4.1 硬件環(huán)境與引腳說明本文代碼面向最經(jīng)典的STC89C52RC或者兼容芯片開發(fā)環(huán)境是Keil C51晶振11.0592MHz波特率96008位數(shù)據(jù)、1位停止位、無校驗。接線方面只需要把USB轉(zhuǎn)串口模塊CH340或者CP2102的TXD接到單片機RXD引腳P3.0模塊的RXD接到單片機TXD引腳P3.1然后共地——這是很多新手容易忽略的一步。開發(fā)板自帶的串口電路一般已經(jīng)接好你只需要注意兩個點USB轉(zhuǎn)串口模塊的TXD/RXD和單片機P3.0/P3.1要交叉對應(yīng)如果是自制板下載程序時要把模塊的TXD和單片機P3.0之間的跳線拔掉再燒寫否則STC-ISP軟件會因為IO電平?jīng)_突報錯。4.2 完整代碼清單與注釋#include reg52.h #define FOSC 11059200UL #define BAUD 9600UL #define RING_SIZE 128 typedef enum { FRAME_WAIT_HEAD1, FRAME_WAIT_HEAD2, FRAME_WAIT_LEN, FRAME_WAIT_CMD, FRAME_WAIT_DATA, FRAME_WAIT_CHECK } FRAME_STATE; #define FRAME_MAX_DATA_LEN 16 typedef struct { unsigned char len; unsigned char cmd; unsigned char data[FRAME_MAX_DATA_LEN]; } FRAME_T; volatile unsigned char ring_buf[RING_SIZE]; volatile unsigned char head 0; volatile unsigned char tail 0; FRAME_STATE state FRAME_WAIT_HEAD1; unsigned char rx_len 0; unsigned char rx_index 0; unsigned char rx_check_sum 0; FRAME_T rx_frame; void UART_Init(void) { SCON 0x50; // 模式18位UART允許接收 TMOD 0x0F; // 清除TIMER1相關(guān)位 TMOD | 0x20; // 定時器1模式28位自動重裝載 PCON 0x00; // SMOD0 TH1 256 - FOSC / 12 / 32 / BAUD; // 重裝載值 TL1 TH1; // 初始值也要寫 TR1 1; // 啟動定時器1 ES 1; // 開啟串口中斷 EA 1; // 開啟總中斷 } void UART_ISR() interrupt 4 { unsigned char ch; if (RI) { RI 0; ch SBUF; ring_buf[head] ch; head (head 1) % RING_SIZE; } if (TI) { TI 0; } } unsigned char UART_ReadByte(unsigned char *byte) { if (head tail) { return 0; } *byte ring_buf[tail]; tail (tail 1) % RING_SIZE; return 1; } void UART_SendByte(unsigned char byte) { TI 0; SBUF byte; while (!TI); } void UART_SendString(unsigned char *str) { while (*str) { UART_SendByte(*str); } } void Process_Frame(FRAME_T *frame) { // 這里放你的業(yè)務(wù)處理邏輯 // 示例把收到的命令原樣發(fā)回上位機 UART_SendByte(0xAA); UART_SendByte(0x55); UART_SendByte(frame-len); UART_SendByte(frame-cmd); for (unsigned char i 0; i frame-len; i) { UART_SendByte(frame-data[i]); } // 重新計算校驗和 unsigned char sum 0xAA 0x55 frame-len frame-cmd; for (unsigned char i 0; i frame-len; i) { sum frame-data[i]; } UART_SendByte(sum); } void Frame_Parse(unsigned char byte) { switch (state) { case FRAME_WAIT_HEAD1: if (byte 0xAA) { state FRAME_WAIT_HEAD2; } break; case FRAME_WAIT_HEAD2: if (byte 0x55) { state FRAME_WAIT_LEN; rx_check_sum 0xAA 0x55; } else if (byte ! 0xAA) { state FRAME_WAIT_HEAD1; } break; case FRAME_WAIT_LEN: if (byte FRAME_MAX_DATA_LEN) { state FRAME_WAIT_HEAD1; break; } rx_len byte; rx_index 0; rx_check_sum byte; state FRAME_WAIT_CMD; break; case FRAME_WAIT_CMD: rx_frame.cmd byte; rx_check_sum byte; if (rx_len 0) { state FRAME_WAIT_CHECK; } else { state FRAME_WAIT_DATA; } break; case FRAME_WAIT_DATA: rx_frame.data[rx_index] byte; rx_check_sum byte; if (rx_index rx_len) { state FRAME_WAIT_CHECK; } break; case FRAME_WAIT_CHECK: if (rx_check_sum byte) { Process_Frame(rx_frame); } state FRAME_WAIT_HEAD1; break; default: state FRAME_WAIT_HEAD1; break; } } void main(void) { unsigned char ch; UART_Init(); UART_SendString(STC51 UART Ready\r\n); while (1) { if (UART_ReadByte(ch)) { Frame_Parse(ch); } } }4.3 上位機測試方法編譯下載后打開任意串口調(diào)試助手我用得比較多的是XCOM和友善串口助手兩者功能差不多。設(shè)置波特率9600、8位數(shù)據(jù)、無校驗、1位停止位打開對應(yīng)串口如果設(shè)備管理器里能看到CH340的COM口編號。測試時先發(fā)送下面的十六進制數(shù)據(jù)幀AA 55 01 01 2A 31我來拆一下這幀數(shù)據(jù)AA 55是幀頭01是長度表示后面只有1字節(jié)數(shù)據(jù)01是命令字2A是數(shù)據(jù)最后一個字節(jié)31是校驗和。校驗和計算方法是前面所有字節(jié)求和0xAA 0x55 0x01 0x01 0x2A 0x131取低8位是0x31正好匹配。如果一切正常單片機回顯內(nèi)容應(yīng)該就是這一整幀。如果你在串口助手里同時打開了“定時發(fā)送”設(shè)置100ms發(fā)一次連續(xù)發(fā)幾秒鐘回顯內(nèi)容也應(yīng)該一直保持正確——這能驗證中斷收數(shù)據(jù)和狀態(tài)機拆幀的穩(wěn)定性。5. 調(diào)試過程中最常遇見的幾個經(jīng)典問題5.1 收到亂碼先排查什么串口收到亂碼很多人第一反應(yīng)是代碼有問題。我的排查順序一直很固定第一步檢查波特率設(shè)置。先在串口助手那邊把波特率分別設(shè)成4800、9600、19200試一試如果能對應(yīng)上某種規(guī)律的亂碼大概率是波特率不匹配。如果怎么調(diào)都亂再看下一步。第二步檢查晶振。用示波器或者換上11.0592MHz晶振重新測試。這個判斷成本最低但能解決50%以上的亂碼問題。第三步檢查接線。TXD接RXD、RXD接TXD、共地這三條只要有一條不對亂碼是必然的。很多人把TXD接TXD以為同向連接也通結(jié)果是完全收不到數(shù)據(jù)或者收到一堆無意義噪聲。第四步檢查CH340驅(qū)動。Windows下如果設(shè)備管理器里根本沒有COM口那就是驅(qū)動沒裝好。CH340驅(qū)動安裝后需要檢查波特率設(shè)置是否和軟件里一致。這個步驟雖然基礎(chǔ)但我在幫助別人排查時發(fā)現(xiàn)頻率意外地高。5.2 串口燒寫失敗與程序跑飛STC單片機下載程序有一個和串口通信完全不同的地方它需要“上電復位進入ISP模式”。如果你用STC-ISP軟件點擊下載后沒有立刻給單片機斷電再上電大概率會卡在“正在檢測目標單片機”這一步。這個和串口通信本身無關(guān)但每個寫過STC的人幾乎都踩過這個坑。另外如果程序里初始化了串口并且一直在發(fā)數(shù)據(jù)有時會干擾ISP下載。穩(wěn)妥的做法是下載前把單片機電源斷開點擊下載按鍵之后給單片機重新上電讓它在“冷啟動”狀態(tài)下進入ISP區(qū)。程序跑飛的問題也值得留個心眼錯誤的中斷服務(wù)函數(shù)定義會直接導致程序異常復位。C51中斷服務(wù)函數(shù)要用interrupt 4這個數(shù)字對應(yīng)單片機中斷向量表中的串口中斷。如果你寫成了interrupt 3或者interrupt 5程序下載后可能一開串口就崩潰看起來像是串口代碼有問題實際是中斷向量對整個程序的沖擊。5.3 緩沖區(qū)不夠用怎么辦當你的數(shù)據(jù)量超過緩沖區(qū)容量或者主循環(huán)處理速度跟不上串口速率時環(huán)形緩沖區(qū)的劣勢就暴露出來了——頭部追尾數(shù)據(jù)被覆蓋。解決辦法有幾個思路。一是把緩沖區(qū)加大這是最簡單直接的方法。51單片機的RAM本身不大標準52是256字節(jié)但你可以用xdata聲明外部RAM比如STM32替換這種思路在STC15、STC8上更合適STC15和STC8很多型號自帶更大RAM和硬件FIFO甚至硬件緩沖區(qū)可以達到幾KB。二是提高主循環(huán)的“消費”速度把幀解析放到接收中斷中直接執(zhí)行。但這樣做的代價是中斷服務(wù)函數(shù)變長其他中斷的響應(yīng)延遲會變大。如果項目里還有定時器中斷、外部中斷可能引起的隱患是隱性的、難定位的。三是用STC15/STC8系列替代傳統(tǒng)STC51。這不是勸退而是從工程角度講STC8的串口模塊比傳統(tǒng)51進步太多自帶硬件FIFO接收多字節(jié)數(shù)據(jù)時基本不存在“只有一個字節(jié)緩沖”的窘境。如果你的項目還在選型階段且串口通信是核心功能直接選STC8或者STC15會少很多麻煩。寫在外面的心得體會我剛開始學STC51時串口通信這一塊卡了很久折騰了一圈最后發(fā)現(xiàn)核心問題就那么三個查詢接收丟數(shù)據(jù)、幀邊界對不齊、時鐘源精度不夠。這篇文章把我踩過的坑、最終采用的解法、測試時的經(jīng)驗按順序整理出來。在STC51上做串口通信本質(zhì)就是和硬件中斷、時序、緩沖管理打交道。建議真正想學透的人不要只抄上面的代碼而是拿著邏輯分析儀或者串口調(diào)試助手自己抓一次數(shù)據(jù)、自己寫一次狀態(tài)機、自己算一次波特率這個過程比看十篇文章都有用。代碼可以復制經(jīng)驗只能自己磨。