VC串口编程执行效率_第1页
VC串口编程执行效率_第2页
VC串口编程执行效率_第3页
免费预览已结束,剩余2页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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程序

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论