案例： 一文本框中有4個字節(jié)數據，點command后mscomm控件將這4個字節(jié)發(fā)送給了AT89S52，MCU接到數據，我的下位機程序利用中斷處理了這4個字節(jié)數據（我一直在說字節(jié)哦）。 疑問： 單片機每次只能接收一個字節(jié)數據（SBUF只能裝一個，否則會被后來的數覆蓋），雖然MSCOMM是一次發(fā)了4個，但單片機收到一個字節(jié)后就應該中斷（是收一個而不是4個都收到后才中斷置位RI吧？），等我的程序把數據從SBUF后取走并清0RI后，它再接收下一個字節(jié)(是因為收到SBUF中數被移走的信號還是收到RI為0的信號？)直到4個都收到。但在MCU端中斷時MSCOMM仍在發(fā)數據，這部分數豈不是會漏掉？另外我說的通信流程對嗎？

這種情況通常不會出現，因為：

    1、單片機每“次”的確只能接收1個字節(jié)，但由于串口的速度實在太低，通常都在115200bps以下（即使用了同步方式也“只能”達到1Mbps）。注意，是bps，位/秒，而不是“字節(jié)/秒”，這就是“串”行通信，要至少8個“bps時間”才能接收一個完整的字符，事實上，加上起始位等，8個位往往傳送不了一個字節(jié)（不知道我的理解是不是有偏差），這就是說，速度至少還要再慢上8倍。

    2、帶有USART的單片機里USART一般都是做為“外部設備”，獨立于MCU進行收發(fā)工作，即其收發(fā)過程中的串-并和并-串轉換以及數據IO過程都是“自主”和“自動”的，不需要CPU逐位進行收發(fā)處理，因此，在CPU將數據送到SBUF后，便可以放手不管了，USART收發(fā)器會自動將SBUF的內容轉換成串行數據發(fā)送出去。接收時也是由USART將串行數據轉成并行數據并存放到SBUF后才會通知MCU（產生接收中斷）。MCU所需要做的只是往SBUF送數或從SBUF中取數（都只要1個指令周期）。

    3、設置串口參數的時候應該能看出，為了適應串口的慢，不得不動用定時器進行延時，以“產生”所需要的波特率，而這個“延時”通常都要給8位甚至16位定時器設置初值，定時器每一次計數都需要一個指令周期，即CPU可以執(zhí)行一條指令的時間，而定時器兩次串口溢出才僅僅接收或發(fā)送一個“位”，接收一個字節(jié)需要數倍于此的時間，那么這么長的時間對CPU來說，足以從容地從SBUF里取出數據并對其進行處理了。

    4、即使CPU的任務相當繁重，或對接收到的每個字節(jié)都需要進行相當復雜的處理，我們也完全可以通過建立接收緩沖區(qū)的方式將暫時來不及處理的數據暫存起來，等CPU空閑時再做處理。而從SBUF取出數據并保存到緩沖區(qū)只需要很少的幾條指令就能完成，不會影響到串口繼續(xù)接收。

    5、標準的RS-232協(xié)議并非只有TX、RX和GND三個引腳，即便是最簡單的9針插口，也專門設計了檢測傳輸狀態(tài)和收發(fā)請求的針腳。如果單片機真的實在無法及時完成收發(fā)動作，也完全可以利用一個口線作為狀態(tài)標識，使PC能夠知道單片機什么時候可以接收數據，而不會任由數據丟失。

    6、為了增加數據傳輸的可靠性，大量數據傳輸時通常都會采用CRC校驗方式，并以“包”或“幀”的方式發(fā)送有格式約定的字節(jié)流，而非單個字符，這樣一來，完全可以通過約定一些“通信協(xié)議”的方式，使收發(fā)雙方都能夠及時知道接收的數據是否完整，并及時重發(fā)新發(fā)送出錯的數據。

   現在所能想到的暫時就這么多，思路較亂，文字表述也挺羅索，謹供參考，歡迎交流。