使用MSCOMM32控件编写串口程序
加入技术交流群
在此基础上，我们看一个例子：
下面两张图 是一个 利用MsCom进行串口通讯（中断方式）的程序框图和回调VI的程序框图
使用RTThrsehold属性设置触发接收中断事件的触发条件，本程序设置为1，当缓冲器接收到一个字符时，就会发生中断事件——oncomm事件中断，很多条件都可以产生oncomm事件，区分产生中断的原因有Comevent的属性值来确定，当conevent为2时，表示是由于接收到字符产生的中断，由此进入接受中断处理程序。
而中断处理程序，接收到的数据是变体数据，转换为数组型数据，发送数组中，最后送到返回变量中，供显示和绘制实时图使用。
commevent的参数 对比表！
根据应用程序的用途和功能，在连接到其它设备过程中，以及接收或发送数据过程中，可能需要监视并响应一些事件和错误。 |
||
常数 |
值 |
描述 |
ComEvSend |
1 |
发送缓冲区中的字符数少于SThreshold。 |
ComEvReceive |
2 |
接收到Rthreshold个字符。在使用Input属性移去接收缓冲区中的数据之前，该事件将持续产生。 |
ComEvCTS |
3 |
CTS信号发生变化。 |
ComEvDSR |
4 |
DSR信号发生变化。该事件仅在DSR由1变为0时触发。 |
ComEvCD |
5 |
CD信号发生变化。 |
ComEvRing |
6 |
检测到电话振铃。某些UART（通用异步收发器）可能不支持本事件。 |
ComEvEOF |
7 |
收到文件结束符（ASCII字符26）。 |
下列错误同样会触发OnComm事件，并且在CommEvent属性中写入相应的值。 |
||
设置值 |
值 |
描述 |
ComEventBreak |
1001 |
收到Break信号。 |
ComEventFrame |
1004 |
帧错误。硬件检测到帧错误。 |
ComEventOverrun |
1006 |
端口超限。在下一个字符到达端口之前，前一字符还没有从硬件中读走，因而丢失。 |
ComEventRxOver |
1008 |
接收缓冲区溢出。接收缓冲区已没有空间。 |
ComEventRxParity |
1009 |
奇偶校验错误。硬件检测到奇偶校验错误。 |
comEventTxFull |
1010 |
发送缓冲区满。在试图将字符传入发送缓冲区时，该缓冲区已满。 |
ComEventDCB |
1011 |
在为端口获取设备控制块(DCB)时，发生不可预料的错误。 |
另外： 需要注意的是
如下图所示：
U8类型数值的数组。
————————————————————————————————————————————————
关于RTThrsehold
例如 接收到的数据远远小于发送的数据了，接收到的数据出现乱码了，等等。
经过反复的实验
我发现 如果将inputlen设置的过小(如1)，同时呢，发送的波特率过高，就会出现接受到的数据小于实际发送出的数据。
因为将RTHrsehold设置为1的时候，每收到一个字符就会产生一次中断，这次中断会提取 inputlen个数的字符。
如果波特率过高，就会导致，中断不能够及时发生（每次中断只读取一个字符，而产生的中断数目小于实际发送的字符数），很多数据到最后积累在缓冲区内。
（这是我通过程序最后读取缓冲区的数据大小进行的判断）
因此必要时，可以将RTHrsehold和inputlen的值都设大一些，才能够正常。（使得中断处理函数的时间远远小于产生中断的时间即可）
评论