VC串口編程執(zhí)行效率

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

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

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

4、ndmessage()阻塞，直到窗口 winproc處理 char message.窗(口若不是接收 thread 創(chuàng)建的，還要 threadSwitch）.返回到接收 thread:WaitForMultipleObjects()阻塞。思路二、與思路一最大的不同是，采用readfile()的多字節(jié)讀取方式。接收 Thread，首先 purge UART上來就 Readfile（ , RXBUFF 起始地址 , 要讀取字節(jié)數(shù)，指向異步 structure->event 的指針）。Asynchronous Readfile 有兩個結(jié)果，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個字節(jié)）elsedo nothing! (只是簡單地忽略 )接下來，同樣是Sendmessage(, ,RXBUFF 首地址， );返回開始的 readfile();兩種思路最大的不同是對readfile()的應(yīng)用。異步 Readfile（端口 HANDLE, RXBUFF 起始

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

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

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

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

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