VC串口编程执行效率.doc

VC串口编程的执行效率 VC串口编程是一个古老的话题，好多年前跑得很好的程序，现在依然运行得很好！CPU的速度越来越快，使得程序的执行感觉效率越来越不是问题，硬件的进步掩盖了软件编程的效率差别。本文以两种不同VC串口编程思路为例，从小处、简单处了解一下内在的VC串口软件执行效率差别。 对一些简单的8位机，凭一个人的能力，尚能对这个小麻雀从软、硬件上系统地把握执行效率的问题。但对于PC上的VC程序来说，是博大精深！抛开硬件不说，软件分层架构，大体分driver、kernel、framework、app层。本来分层架构再加上VC的抽象思想，就是要封装细节、提供接口，使层与层、类与类之间清晰、明了。系统提供的API、class拿来用就行了，就像IC一样，把精力集中在解决现实问题的层面，反正CPU够快，效率问题不是太紧迫，但如果细追效率问题也不太现实，只能靠内嵌测试工具和统计方法，本来系统复杂到一定程度，就呈现出统计特征。 对于VC的串口应用编程来说，属app层编程。如果是两个win PC UART通信，标准硬件、API拿来用就行了，把精力集中在事物方面，底层的软、硬件进步了，看到的API接口还是一样的。但对于PC 与单片机的串口通信，软硬件是不对等的。VC UART功能完备，单片机UART是精简版。多年前的VC UART程序，现在依然运行良好，内在的效率是不同的。抛开细节，从app层面要说一下两种VC UART编程思路的效率，默认异步操作。思路一、 以UART口收、发的字节为单位，event驱动。接收thread: WaitForMultipleObjects() 阻塞 , UART 收到一个或n个字节（DMA FIFO决定n）, Event触发，thread 结束wait， ReadFile() 可一次读一个，也可一次几个字节。此处一次读一个字节，循环n次！每读一个字节，sendmessage(), 向窗口发收到char message。接收thread sendmessage() 阻塞，直到窗口winproc处理char message.(窗口若不是接收thread 创建的，还要thread Switch）.返回到 接收thread: WaitForMultipleObjects() 阻塞。思路二、 与思路一最大的不同是，采用readfile()的多字节读取方式。 接收Thread，首先purge UART 上来就Readfile（ , RXBUFF起始地址, 要读取字节数，指向异步structure-event 的指针）。 Asynchronous Readfile 有两个结果， pending 和readfile return immediately 。（if pending）bwait=TRUE; else bwait=FALSE; WaitForMultipleObjects(3, port-m_hEventArray, FALSE, INFINITE); If（bwait）GetOverlappedResult();（n个字节） else do nothing! (只是简单地忽略) 接下来，同样是 Sendmessage(, ,RXBUFF 首地址，); 返回开始的readfile();两种思路最大的不同是对readfile()的应用。异步Readfile（端口HANDLE, RXBUFF起始地址, 要读取字节数，指向异步structure-event 的指针）。只用指定要读取的最大个数，接收缓冲区地址，剩下的由系统自动异步完成，用event的signaled state 来指示操作的完成。当然可以readfile()一次异步读一个字节，就象思路一，这对于必较松散的UART通信，来一个处理一个，一口气来n个字节，循环n次即可，思路很简洁、直观！不用开缓冲，一个byte变量足矣。一个一次读取一字节的Asynchronous ReadFile(), 粗略地从微观上看： 应用层readfile(), kernel I/O manager 上层file driver,中间要径过很多各种drivers UART driver 读取一字节，放到指定位置，触发event signaled state, 最后由I/O manager 返回应用层。这还是直接串口操作。 如果用现在流行的USB转UART，那至少还要增加USB driver 层。 一个字节的异步readfile() , 要经过这么多关口，串越n多层，这是由系统封装的，对于app层的readfile() API 调用来说，一次读一个，读n个感觉差别不大，参数不同而已，现在CPU的速度足够快，虽然一次一个效率不高，感觉响应速度上并无明显差别。当然如果driver写得足够好，可自动将n个连续的一次一字节的readfile, 拼成一个一次n字节的readfile , 那另当别论。异步一次一个字节的ReadFile(), 有其存在的理由。早先的单片机速度与PC无可比性，UART也没DMA支持，一次一字节的异步ReadFile 很好地，在保证VC代码效率前提下，使PC 与慢速的单片机可靠通信。而且这种方式，VC代码的兼容性较好，多年前写的VC UART代码，仍能可靠地与现在的速度较快的、具备DMA+UART的单片机可靠通信。只是在串口数据帧的划分上复杂一些。显然，一次读取n个字节的异步readFile(), 系统效率要高，还能发挥DMA的缓冲操作能力。应用层的VC代码效率也很高。虽然不象思路一的event 驱动，异步ReadFile() 本身调用后，立马返回，接收Thread wait 异步readfile() 设定的event signaled. 异步readfile() 设定的event signaled, 大体分几种情况，一：要读取的字节数，完成放到RXBUFF 中，正常。 二：未达到设定的读取字节，读取超时，触发event。 三：接收出错，奇偶、FRAME error、under run、over run etc.第一种情况是比较理想的，串口通信，除了设设下位机参数，字节数固定的，稍微高级一点， 采用数据帧格式，帧长度是可变的，因此实用中，应主要是第二中情况具多，开辟RXBUFF 大于最长的数据帧字节数，通过规读超时，触发event！ 至于第三种情况，为了简化VC的串口编程，程序上按第二种情况处理，统一由数据帧的校验（XOR SUM OR CRC）处理。VC串口编程，采用第二种思路，在APP层面，通过异步ReadFile()一次读n个字节，极大地提升了VC 串口程序 应用层、系统层的执行效率，一次读n个字节，sendmessage（），窗口WinProc 一次处理n个字节 ，效率提高n倍。简单测试：打开很多窗口，系统很忙，同时运行VC UART 程序