VB串口数据接收方式

1、1、在OnComm事件中接收数据：这种方式能充分MSCOMM控件的特性。OnComm事件还可以检查和处理通讯错误；可以通过检查CommEvent属性的值来查询事件和错误；对于不定长数据以及对数据进行处理比较复杂的情况，此法不是很方便。PrivateSubMSComm_OnComm()SelectCaseMSComm1.CommEvent错误CasecomEventBreak收到Break。CasecomEventCDTOCD(RLSD)超时。CasecomEventCTSTOCTSTimeout。CasecomEventDSRTODSRTimeout。CasecomEventFrameFram

2、ingErrorCasecomEventOverrun数据丢失。CasecomEventRxOver接收缓冲区溢出。CasecomEventRxParityParity错误。CasecomEventTxFull传输缓冲区已满。CasecomEventDCB获取DCB时意外错误事件CasecomEvCDCD线状态变化。CasecomEvCTSCTS线状态变化。CasecomEvDSRDSR线状态变化。CasecomEvRingRingIndicator变化。CasecomEvReceive收到RThreshold#ofchars.CasecomEvSend传输缓冲区有Sthreshold个字符C

3、asecomEvEof输入数据流中发现EOF字符EndSelectEndSub2.轮循法采集数据:A、定时器轮循法对于数据包方式收发数据以及不需即时响应情况，用轮循法更好些。实际上轮循法最大的好处在于集中处理数据而且不太占用CPU。轮循法要注意定时采集的时间片段大小；这里用二进制收发模式；使属性RThreshold、SThreshold为0,屏蔽ONCOMM事件。InputMode=comInputModeBinaryRThreshold=0SThreshold=0PrivateSubTmrComm_Timer()采用轮循法采集数据DimRx_buff()AsByteDimokstringAs

4、StringDimReceivedLenAsIntegerOnErrorGoToErrorHandlerTmrComm.Enabled=False关闭定时器Ifcommport.InBufferCount0ThenReceivedLen=commport.InBufferCountRx_buff=commport.Inputokstring=StrConv(tempbyte,vbUnicode)IfReceivedLen=6ThenIfChr(tempbyte(0)=:Andtempbyte(3)=&h0aThenEndIfIfInstr(okstring,:END*,vbBinaryComp

5、are)ThenEndIfEndIfTmrComm.Enabled=True打开定时器EndSubB、直接轮循法此法用于接收少量控制命令字；保存输入子串的缓冲区DimInstringAsString使用COM1。MSComm1.CommPort=19600波特，无奇偶校验，8位数据，一个停止位。MSComm1.Settings=9600,N,8,1当输入占用时，告诉控件读入整个缓冲区。MSComm1.InputLen=0打开端口。MSComm1.PortOpen=True将attention命令送到调制解调器。MSComm1.Output=ATV1Q0&Chr$(13)确保调制解调器以OK响应

6、。等待数据返回到串行端口。DoDoEventsBuffer$=Buffer$&MSComm1.InputLoopUntilInStr(Buffer$,OK&vbCRLF)从串行端口读OK响应。关闭串行端口。MSComm1.PortOpen=False如何处理不定长数据的接收在处理串口通讯时，经常会遇到不定长数据的接收。由于通讯任务不同及编程要求的差异所以采用的方法也有所不同。本文就此问题进行探讨。不定长数据从数据格式上分，可分为有格式和无格式。一、无格式不定长数据的接收这种格式在实际串口通讯中用得不多，一般只用传送字符串数据。问题在于怎么判断接收结束。一般用时间延迟的方法解决。A、对于非握手式

7、通讯，可用一个定时器定时轮循接收，并假定每个轮循接收完成。用ONCOMM事件接收也可，只是不如定时器定时轮循接收简便。B、对于握手方式通讯，可用直接轮循法提高接收的准确性。下面是实现此法的函数：FunctionsComm(sCommandAsString,comReceiveAsMSComm)AsStringDimnReceiveCountAsIntegerIfcomReceive.PortOpen=FalseThencomReceive.PortOpen=TrueEndIfcomReceive.Output=sCommandDonReceiveCount=comReceive.InBuffe

8、rCountsleep(2)API函数,挂起当前进程一段时间LoopUntilcomReceive.InBufferCount=nReceiveCountIfcomReceive.PortOpen=TrueThensComm=comReceive.InputEndIfEndFunction注：此函数参照了xth文。此法一般是能确保数据接收的正确，但由于WINDOWS是多任务操作系统，当有耗时的进程运行时会丢失数据。如果系统会出现这种情况，可增大函数sleep()的参数值。二、不定长格式数据的接收对于不定长数据接收最好的方法是制定通讯协议，比如定义开始字符和结束字符。由于单片机系统通讯一般不太复

9、杂，没必要去制定一套象通用计算机间通讯的协议，而根据单片机系统的大小和性能要求制定通讯协议。实际上为便于交流、维护以及一致性，可制定一套可伸缩的通讯协议。定义了开始字符和结束字符就容易实现不定长格式数据通讯，但在实际通讯编程还是容易出现一些比较隐蔽的通讯错误。下面就常用方法分别进行分析。A、定时器轮循法。假定每个轮循期数据接收完毕，并在每个轮循期处理数据，由于有开始字符和结束字符很容易确定接收数据的完整性。好象合理设定轮循时间值就万无一失了，但被动接收数据时无论如何也找不合适的轮循时间值，因为启动定时器和数据到来基本不同步，这就会出现一次发送的数据被分在两个轮循期接收，所以被动接收数据时不能假

10、定每个轮循期数据接收完毕。在接收到结束字符后才确定一次数据接收完毕就可解决此问题。B、OnComm事件法。方法和定时器轮循法基本相同，因为每次OnCommg事件也只能接收到一部分数据。在VB的在线帮助中这样注解“设置Rthreshold为1，接收缓冲区收到每一个字符都会使MSComm控件产生OnComm事件。”。但实际上OnComm事件并不是每收到一个字符便触发一次OnComm事件。OnComm事件是在缓冲区收到几个甚至几十个字节数据后才被触发的。版主认为这是WINDOWS多任务使操作系统不能实时响应造成的。如果要在每次OnComm事件接收一个字符似乎可设INPUTLEN属性为1,但实际行不通

11、。VB在线帮助中“有该属性在从输出格式为定长数据的机器读取数据时非常有用”的注解，好象在说对定长字符有效，但版主发现INPUTLEN设为16,接收16个字符定长数据时却被当作两次接收了，一次12个，一次4个。建议在OnComm事件中接收数据要定义通讯协议并检测数据的完整性。对于不定长格式数据的接收程序员更喜欢定时器轮循法，也许OnComm事件不好控制吧。对于不定长数据的接收，最佳方法可能是在OnComm事件中启动定时器轮循接收，并同时停止OnComm事件的触发，接收完毕后或超时开启OnComm事件。用字符方式收发码值大于127的字符数据VB的通讯控件友好、功能强大，编程速度快是众人皆知的。加上

12、VB的易学、易用，快速开发等特点，数据通讯量不是很大时，在单片机通讯领域广泛地使用VB开发PC上层通讯软件。实际开发时会有不少问题，这里就用字符方式收发码值大127的字符数据进行讨论。在实际开发中经常遇到通讯只是用来发送一些控制字符命令和少量数据。在VB的中文在线帮助中有“若数据只用ANSI字符集，则用comlnputModeText”的表述。ANSI字符集是0-127这容易使人误解为&h88也可用“INPUTMIDE=comInputModeText”方式收发。我刚开始用VB编通讯模块时就为此迷惑过，网上不少网友也时常问及这种问题。实际上在VB中0-127是可以正常收发的，大于127即&H7

13、F的只有&H80和&HFF能够收发，其余ANSI字符都被过滤为0。由于串口通讯是以字节收发的，数据如以comInputModeText模式收发则非字符串数据会被过滤。在VB中用“INPUTMIDE=comlnputModeBinary”就可以解决这个问题，只是收发都必须用动态数组来完成。用comInputModeBinary模式编程稍有点复杂，调试也不直观，对于初学者不易掌握。另外软件完成后，在实际应用时会增加工程维护难度，因为对于二进制代码不是易于理解的。比如下端机发送现场统计数据233，comInputModeBinary模式下串口监测到“：A&H233;,它代表A探针的温度。一般串口监测软件要么用ASCII方式显示，要么用二进制方式显示。用ASCII方式则不能看到&H233,而二进制方式则示不好理解，如果显示586523359，我想没有人喜欢这种方式（如果有更好的方式的话）。但如果显示“：A233；”不就解决问题了！用comInputModeText方式就可完成任务了，只是多了一段数据分离程序。对于一般通讯要求这种方法不为是一种好方法。由于通讯任务是多种多样的，有时候这种方法就有点力不从心了，如传送较多的的数据时，这会显著地增加通讯量，通讯变得复杂了，