第一篇关于软件工程论文：
《高速串口的软件设计模式研究》
关键词：高速串口；设计模式。
Abstract:The high-speed serial communication works with a mass of data streams.The buffer overflows in result of reading delayed insituation of time-limited tasks.The paper proposed a software design model to solve the problem.The design model used Windows API andoverlapped functions to implement reading and writing operation.Multithread technique was used and synchron设ation was discussed.For theapplication of transfer image streams compressed by JPEG with serial communication,the design model was optim设ed.The test of transfer-ring image data with s设e 640*480,frame frequency 12Hz,compression ratio 12.5proves that the proposed design model meets the needs ofengineering application.
Keywords:high-speed serial communication;design model.
0引言。
在工业测控应用领域，PC机与下位机主要采用以RS232、RS422为电气标准的串行接口方式。由于串行接口方式的需求依然存在，目前出现了两种普遍应用的串行接口卡。一类是多串口接口卡，这类接口卡一般采用跳线方式来兼容RS232和RS422两种标准；另一类则是USB转串口接口卡，这类接口卡与PC机采用USB接口方式因而具有热拔插特性，但在PC机中被映射为串口设备，这一特点使得上位机程序可完全按照串口设备进行设计。
随着测控领域对数据传输带宽的要求不断增加，串行接口卡呈现出高码率的特点，其波特率甚至高达8M.本文针对高码率串口的特点，提出一种上位机软件设计模式，解决复杂任务环境下由于码率高而引起的接收缓冲区溢出问题。针对使用串口传输图像数据这一具有特殊要求的应用场合，对该设计模式进行了改进，测试结果表明该设计模式具有普遍 的 应 用价值。
1 MSComm控件的应用局限性。
MSComm控件是微软采用ActiveX技术设计的一种应用非常普遍的串口控件，该控件采用事件方式通知应用程序串口设备已接收到一定数量的数据。对于PC机配备的标准串口收发器而言，其波特率一般不超过256000,亦即每秒数据吞吐量小于32kB.MSComm控件的接口函数允许设置的最大接收缓冲区为32kB（MSComm提供的设置接收缓冲区的参数为signed short型），表明在传输带宽完全被占用且波特率为256000的条件下，应用程序读取串口的最大可允许延时不超过1s,否则会造成接收缓冲区溢出而丢失数据[1].
对于小规模的应用程序而言，1s的延时要求很容易满足，一般不会出现接收缓冲区溢出的情况。对于高速串口，其波特率一般为2 M至4 M,亦即每秒数据吞吐量为0.25 MB至0.5MB,对于32kB的接收缓冲区而言，可允许的最大读取延时为64ms至128ms,对于波特率为8 M的串口卡而言，最大读取延时仅为32ms.
在采用MSComm控件进行高速串口的上位机软件设计时，一般在主窗口中响应串口事件，不具备太大的灵活性[2].主程序中一些具有可观耗时的任务或主窗口的屏幕刷新均有可能导致读取延时超过128ms.此外，在该台计算机中若同时运行着另一CPU使用率较高的应用软件，也可能导致响应串口事件不及时。因此，MSComm控件在高速串口的上位机软件设计中具有很大局限性。
2基于Windows API的串口软件设计。
微软Windows平台将PC机的所有外围设备均映射为文件，因而对其读写等操作均与读写硬盘上的实际文件相同。对文件的读写操作，Windows API提供了非重叠I/O和重叠I/O两种方式。调用一个读或写文件的API函数时，在重叠I/O方式下，无论读或写操作是否完成，该API函数立即返回；在非重叠I/O方式下，直到读或写操作完成时，该API函数才返回。在多线程应用程序中，重叠I/O方式具有更高的效率，在读写操作不能立即返回时，读写操作会自动转入后台运行[3].
在采用Windows API进行串口上位机软件设计时，主要涉及的API函数为ReadFile、WaitForSingleObject、GetOver-lappedResult和ClearCommError.其中，ReadFile函数用于读取串口，WaitForSingleObject用于等待重叠I/O事件被激活，GetOverlappedResult用于获取重叠I/O执行结果，ClearCom-mError则用于清除各种串口错误同时返回串口状态。基本逻辑流程如图1所示。
采用重叠I/O方式读取串口缓冲区时，在读取到的数据还未达到由用户设定的数量要求时，Wait ForSingleObject将会一直等待，若在子线程中则该线程会处于挂起状态。为防止陷入长期等待，WaitForSingleObject允许设置超时返回。写串口操作与该逻辑流程基本一致，这里不详述[4].
3多线程的设计模式。
3.1多线程设计模型。
一般而言，在读取串口数据后，需要对这些数据进行分包、解算、存储等操作。在高速串口上位机软件设计中，若将读取串口数据和数据处理任务安排在一个子线程中执行，当数据处理任务复杂繁琐、耗时可观时，则极易出现读取串口不及时而导致数据丢失的现象。因此，在高速串口应用软件设计中，必须将读取串 口数据和数据处理分别采用两个 子 线 程实现。
如图2所示为一种可行的多线程设计模型。在该模型中，在内存开辟了A片与B片两块缓存区，读取串口数据子线程通过写指针ptrWrite将从串口读取的数据存入缓存区，数据处理子线程则通过读指针ptrRead从缓存区读取串口数据进行处理。为保证数据的一致性，读指针ptrRead与写指针ptr-Write不能同时指向同一片缓存区。同时，在读指针ptrRead所指向的缓存区串口数据被处理完成后应交换读指针ptrRead与写指针ptrWrite所指向的缓存区。
在一些特殊应用场合如采用高速串口传输图像数据，如若设计为当写指针ptrWrite指向的缓存区被写满后才交换读写指针，则会出现图像数据流传输不均匀的缺陷，在视觉上则表现为图像场景快慢不均。因此，采用当数据处理子线程完成数据处理任务后立即交换读写指针的设计方案更具普适性。
若当A片与B片缓存区均设置为5MB,在传输带宽被完全占用的条件下，对于波特率为4 M的高速串口，每秒产生0.5MB的数据，此时数据处理子线程读取缓存区的最大延时可达10s.
3.2 同步控制逻辑。
在图2中，交换读指针ptrRead与写指针ptrWrite指向的缓存区涉及到两个子线程的相关变量，因此必须考虑这些变量的一致性问题，亦即线程的同步问题。Windows为线程同步提供了关键区、互斥锁、信号量和事件对象等方式。
