深入Windows通信编程

深入Windows通信编程

二、Windows通信疑难探讨现将笔者在实际编程中遇到的疑难和解决办法描述如下，希望对遇到类似问题的朋友有所启发。1.怎样用Windows未提供的波特率通信?Windows提供了由110bps至256000bps共十三种波特率，一般情况下已足够使用。但在某种特定情况下，例如通信对方使用150bps、又无法要求对方改变波特率时，Windows通信就比较困难了。首先想到的解决方法是直接调用BIOS中断14H来设置波特率(DOS提供了150bps的波特率)。结果是Windows屏蔽了该中断，尝试失败。最后的是采用"蒙混过关"的办法解决问题的:首先，以任一Windows支持的波特率(例如300bps)构造通信参数字符串，调用BuildCommDCB产生DCB数据结构;然后调用SetCommState设置通信参数;最后再调用自编函数直接修改串口通信寄存器的值。经实验，设置成功，且对Windows程序运行无任何不良影响。2.接收数据为何"丢失"?通过设置EnableCommNotification函数中的cbWriteNotify参数(在发送WM_COMMNOTIFY消息之前，通信设备驱动程序必须向应用程序出入队列中写入的字节数)，可以使系统每收到固定个字符发出一WM_COMMNOTIFY消息，这对于固定长度消息型的通信是很方便的。但实际应用时有时会发生接收数据"丢失"现象，即收到WM_COMMNOTIFY消息后从接收队列读出cbNotify个数据时，发现只有前面部分数据正确。经检查，"丢失"现象是由于接收数据超时引起的，当通信对方时钟频率较低时，规定时间内收不到cbWriteNotify指定的数据量，即所谓"超时"，Windows照样向应用程序发送带CN_RECEIVE标志的WM_COMMNOTIFY消息。然后，在应用程序输入队列数据读出之前，Windows不再发送该类消息。解决的方法是减小cbWriteNotify的设定值直到不再发生"超时"现象。发送数据时同样应正确设定cbOutQue值，以免产生"超时"现象。如果将cbWriteNotify或cbOutQue设为-1，则Windows不传送带CN_RECEIVE或CN_TRANSMIT标志的WM_COMMNOTIFY消息。3.怎样合理使用FlushComm与GetCommError函数?FlushComm函数的功能是清除指定设备接收或发送队列。GetCommError函数的功能是返回指定设备最近错误码和当前状态，更重要的是"解锁"功能:当出现通信错误时，Windows会锁死通信端口直到调用GetCommError。调用FlushComm的时机很重要，如果通信端口发生错误，不调用该函数就有可能会使接收队列包含不期望的数据;若随便调用该函数，也有可能造成尚未读入或发出的数据丢失。总之，调用该函数要做到"心中有数"。为了合理调用FlushComm和GetCommError函数，建议在事件掩码中包含EV_ERR与EV_BREAK。4.Windows多串口通信Windows最多可支持四个串口的通信，但对于ISA总线的PC，由于其COM1与COM3、COM2与COM4分别共用IRQ3和IRQ4，所以只能同时使用两个串口。MCA、EISA总线系统没有此限制。如果需要使用的端口不止四个，可以在PC护展槽中加插多用户卡，如美国的Comtrol、台湾的Moxa(摩莎)等，就可以支持几个到几十个串口，加上随卡提供的Windows驱动程序，就可以进行多串口通信。具体用法请参阅扩展卡说明书。三、Windows通信实例实例的通信环境为:本方COMPAQ4/50微机，安装中文Windows3.2;对方为8031单片机。通信参数设置:波特率150b