1、.VC 串口編程的執行效率VC 串口編程是一個古老的話題， 好多年前跑得很好的程序， 現在依然運行得很好！ CPU 的速度越來越快，使得程序的執行感覺效率越來越不是問題， 硬件的進步掩蓋了軟件編程的效率差別。本文以兩種不同VC 串口編程思路為例，從小處、簡單處了解一下內在的VC 串口軟件執行效率差別。對一些簡單的8 位機，憑一個人的能力，尚能對這個小麻雀從軟、硬件上系統地把握執行效率的問題。但對于PC 上的 VC 程序來說，是博大精深！拋開硬件不說，軟件分層架構，大體分 driver、kernel、framework、app 層。本來分層架構再加上VC 的抽象思想，就是要封裝細節、提供接口，使

2、層與層、類與類之間清晰、明了。系統提供的API 、class 拿來用就行了，就像IC 一樣，把精力集中在解決現實問題的層面，反正CPU 夠快，效率問題不是太緊迫，但如果細追效率問題也不太現實， 只能靠內嵌測試工具和統計方法，本來系統復雜到一定程度，就呈現出統計特征。對于 VC 的串口應用編程來說， 屬 app 層編程。如果是兩個 win PC UART 通信，標準硬件、 API 拿來用就行了，把精力集中在事物方面，底層的軟、硬件進步了，看到的API 接口還是一樣的。但對于 PC 與單片機的串口通信， 軟硬件是不對等的。 VC UART 功能完備，單片機 UART 是精簡版。多年前的 VC UA

3、RT 程序，現在依然運行良好，內在的效率是不同的。拋開細節，從 app 層面要說一下兩種 VC UART 編程思路的效率，默認異步操作。1 / 5.思路一、以 UART 口收、發的字節為單位， event 驅動。接收 thread: WaitForMultipleObjects() 阻塞 , UART 收到一個或 n個字節（ DMA FIFO 決定 n）, Event觸發， thread 結束 wait，ReadFile() 可一次讀一個，也可一次幾個字節。此處一次讀一個字節，循環n次！每讀一個字節， sendmessage(), 向窗口發收到 charmessage。接收 thread se

4、ndmessage()阻塞，直到窗口 winproc處理 char message.窗(口若不是接收 thread 創建的，還要 threadSwitch）.返回到接收 thread:WaitForMultipleObjects()阻塞。思路二、與思路一最大的不同是，采用readfile()的多字節讀取方式。接收 Thread，首先 purge UART上來就 Readfile（ , RXBUFF 起始地址 , 要讀取字節數，指向異步 structure->event 的指針）。Asynchronous Readfile 有兩個結果，pending 和 readfilereturn im

5、mediately 。（ if pending）bwait=TRUE; else bwait=FALSE;WaitForMultipleObjects(3, port->m_hEventArray, FALSE, INFINITE);2 / 5.If （bwait）GetOverlappedResult();（n個字節）elsedo nothing! (只是簡單地忽略 )接下來，同樣是Sendmessage(, ,RXBUFF 首地址， );返回開始的 readfile();兩種思路最大的不同是對readfile()的應用。異步 Readfile（端口 HANDLE, RXBUFF 起始

6、地址 , 要讀取字節數，指向異步 structure->event 的指針）。只用指定要讀取的最大個數，接收緩沖區地址，剩下的由系統自動異步完成，用 event的signaled state 來指示操作的完成。當然可以 readfile()一次異步讀一個字節，就象思路一，這對于必較松散的 UART 通信，來一個處理一個，一口氣來 n個字節，循環 n次即可，思路很簡潔、直觀！不用開緩沖，一個 byte變量足矣。一個一次讀取一字節的Asynchronous ReadFile(), 粗略地從微觀上看： 應用層 readfile(), >>kernel>> I/O man

7、ager>> 上層 file driver, 中間要徑過很多各種 drivers >> UART driver 讀取一字節，放到指定位置，觸發 event signaled state, 最后由 I/O manager 返回應用層。這還是直接串口操作。 如果用現在流行的 USB轉UART ，那至少還要增加 USB driver 層。 一個字節的異步 readfile() , 要經過這么多關口，串越 n多層，這是由系統封裝的，對于 app層的 readfile() API 調用來說，一次讀一個，讀 n個感覺差別不大，參數不同而已，現在3 / 5.CPU的速度足夠快，雖然一

8、次一個效率不高，感覺響應速度上并無明顯差別。當然如果 driver寫得足夠好，可自動將 n個連續的一次一字節的 readfile, 拼成一個一次 n字節的 readfile , 那另當別論。異步一次一個字節的 ReadFile(), 有其存在的理由。早先的單片機速度與 PC無可比性， UART 也沒 DMA 支持，一次一字節的異步ReadFile 很好地，在保證 VC 代碼效率前提下，使 PC 與慢速的單片機可靠通信。而且這種方式，VC代碼的兼容性較好，多年前寫的VC UART 代碼，仍能可靠地與現在的速度較快的、 具備 DMA+UART的單片機可靠通信。只是在串口數據幀的劃分上復雜一些。顯然

9、，一次讀取 n個字節的異步 readFile(), 系統效率要高，還能發揮 DMA 的緩沖操作能力。應用層的VC代碼效率也很高。雖然不象思路一的 event 驅動，異步 ReadFile() 本身調用后， 立馬返回，接收Thread wait 異步 readfile() 設定的 event signaled.異步 readfile() 設定的 event signaled, 大體分幾種情況，一：要讀取的字節數，完成放到RXBUFF 中，正常。二：未達到設定的讀取字節，讀取超時，觸發event。三：接收出錯，奇偶、 FRAME error 、under run、over run etc.第一種情

10、況是比較理想的，串口通信，除了設設下位機參數，字節數固定的，稍微高級一點，采用數據幀格式，幀長度是可變的，因此實用中，應主要是第二中情況具多，開辟RXBUFF 大于最長的數據幀字節數，通過規讀超時，觸發event！ 至于第三種情況，為了簡化 VC的串口編程，程序上按第二種情況處理，統一由數據幀的校4 / 5.驗（ XOR SUM OR CRC ）處理。VC 串口編程，采用第二種思路，在APP層面，通過異步 ReadFile() 一次讀 n個字節，極大地提升了 VC 串口程序 應用層、系統層的執行效率，一次讀 n個字節， sendmessage（），窗口 WinProc 一次處理 n 個字節 ，效率提高 n倍。簡單測試：打開很多窗口，系統很忙，同時運行 VC UART程序