常用的通讯方式肯定是我们MCU人的MCU<->PC.
而数据丢失看着好象总是PC的问题,实际不能单凭感觉判断.
应该首先检查各自多能出现的错误,最简单而有效的方法是各自自环测试.
即将PC的2,3脚短路(当然MCU要脱机了,废话一下~~~),再用常用的串口
调试工具在一定的波特率下自发自收.
俺喜欢汽车电子的串口通V3.20,下载地址: http://blog.**/hotpower/66284/message.aspx
如果自环测试通过,在不考虑长线通讯带来的时延,则认为MCU可能有错.
再将MCU上的DB9的2,3脚短路,再MCU上编一个很小的自发自收程序.
在接收程序里进行比较,结果可以用LED/LCD等输出.
若不通过,肯定是MCU的问题.
若通过则问题就复杂了~~~
一般可能也肯定是MCU的错误,不妨再与PC联机,并将停止位改为2位
或MCU发送程序在发送一块数据包后加点停顿, 这样处理后应该不会出大问题.
若再出现问题,且PC侧的串口软件采用常用控件如MSComm,SPComm等,
这就带来了控件的正确应用的问题了~~~
再谈控件的正确应用的问题:
俺看过很多MCU编写的上位机应用程序,包括汽车电子的串口通~~~
哈哈~~~小小的批评一下汽车电子~~~
MCU人编写的串口控件有时很倒塌~~~思路全是MCU的裸奔或OS奔,和PC的Windows事件驱动机制有很大的冲突~~~
所以大家可以看出串口通的CPU占有率大的毛病所在~~~
所以它只能作为调试而不能应用到用户真正的程序中...
大家有没注意到---俺的帖图几乎全是串口通????哈哈~~~因为它很美~~~
可惜它不如HotComm很黄很暴力~~~
因为它是用CVI自带的串口函数编的,而HotComm是用API函数重新用多线程封装的~~~
所以即使一样的PC端程序,结果相差可谓**~~~
PC端正确的编程:
接收端:
1.一定要在控件的事件或回调函数中编写.
2.每次在事件或回调函数中编写的代码停留时间不要过长.
最好在下次引发事件或回调前退出.
3.应该正确选择或适当调整每次引发事件或回调的接收字节数目.
4.应该正确选择或适当调整接收缓冲区的大小.
总之,MCU人只要把PC的事件触发看成中断来编程即可~~~
结论: 一个巴掌拍不响~~~ |
楼主
