用MSCOMM控件如何判断接收的是地址还是数据？

fyz2841585 2012-07-20 09:53:45

用MSCOMM控件如何判断接收的是地址还是数据；硬件的波特率为19200，上位机在接收到单片机命令时能否这么快的做出回应？听说windows的精度只有50毫秒，该如何解决，分不够，可以加分

...全文

157 24 打赏收藏转发到动态举报

写回复

用AI写文章

24 条回复

切换为时间正序

请发表友善的回复…

发表回复

贪玩的老鼠 2012-07-21

打赏
举报

串口通信是接收和发送数据，
不管是消息、命令，数据你都得打包成数据包发送！
上位机与下位机必须遵循数据包协议

fyz2841585 2012-07-20

打赏
举报

肯请lfchen帮我们想个办法，硬件部门之间的通信，用这个协议通信正常，但是与上位机通信，就老是出错

fyz2841585 2012-07-20

打赏
举报

回复lfchen：莫非是我们硬件部门协议定义的有问题？如果不改协议，只能通过帧长度来判断是否是数据还是地址？

一条晚起的虫 2012-07-20

打赏
举报

// 你这个协议以地址码开始(0x03)，那么数值中就应该尽量的避免地址这样的数值出现。

fyz2841585 2012-07-20

打赏
举报

我windows上位机收到的一帧大小只有6个字节，因为数据内容比较小，一帧的时间大概是3-5毫秒。
如果不改协议的话，应该如何处理？

一条晚起的虫 2012-07-20

打赏
举报

// 一般来说，一个良好的协议，起始码和结束码都是数值信息（除校验码）中不会出现的值。

schlafenhamster 2012-07-20

打赏
举报

19200 约0.5ms一个字符。
1字节 1字节 1字节 0-252字节 2字节 1字节。
你计算一下一帧要多少时间？

你的协议本身不好处理：
目的地址帧长度功能码数据内容 CRC校验结束码
应该:
开始码目的地址帧长度功能码数据内容 CRC校验【结束码】
否则处理时麻烦。

你必须先找到开始码【结束码】，不是的全不要。
找到后记录，直到帧结束。
分析CRC校验
。。。

一条晚起的虫 2012-07-20

打赏
举报

// 下位机要求10ms有一个应答？这个windows支持不了
// 解析协议的时候，收到0x03，然后按照协议再收取帧长度，根据帧长度可以算出本帧数据余下的长度，收完
// 算出CRC，如果CRC正确，则本帧正确。

fyz2841585 2012-07-20

打赏
举报

[Quote=引用 4 楼的回复:]
地址还是数据
要协议规定，
如
地址前加‘ADR’
数据前加 'DATA'
[/Quote]
协议是这样规定的：基本信息帧格式：
目的地址帧长度功能码数据内容 CRC校验结束码
1字节 1字节 1字节 0-252字节 2字节 1字节

到目前为止，我的上位机的目的地址为0x03，硬件给我发消息帧的时候，我的上位机分不清楚0x03究竟是地址还是数据。硬件规定波特率为19200，周期大概是10毫秒，我的上位机能否及时给与回应？会不会耽误硬件的工作？

一条晚起的虫 2012-07-20

打赏
举报

// 串口通讯中只有数据
// 至于数据表示的是地址还是数值，要根据通讯协议确定。
// 19200的波特率，PC表示完全没有压力

schlafenhamster 2012-07-20

打赏
举报

地址还是数据
要协议规定，
如
地址前加‘ADR’
数据前加 'DATA'

fronz 2012-07-20

打赏
举报

补充，处理程序中一定要简化，首先要发送响应下位机的握手信号。然后在处理帧长度，功能吗、等

Jarrylogin 2012-07-20

打赏
举报

把地址打包成数据内容一起传上来,再根据格式解析出地址内容

fronz 2012-07-20

打赏
举报

[Quote=引用 21 楼的回复:]

回复fronz：
硬件设计本来没想跟pc机通信，跟上位机通信是后来加上去的想法，但是协议已经不能改。
下位机对外通讯的链接是总线型的。
下位机所有链接的主机都是通过地址来区分，而且这种询问方式，硬件也想跟windows上位机通信。
不能这样能否做到，如不能，该如何改进？
[/Quote]
可以，
但不安全。
而且编写通讯时代码可能比较笨拙。
可以这么做:
每次取一帧6个字节，判断第一个是否0x03，是转入处理程序，清空接收缓冲区。
不是，直接清空接收缓冲区。
其实就是完全模拟原有硬件的工作方式。调试程序时，一定确保能完整地接收一帧。
----------------
你添加的上位机通讯在整个网络中实际是有风险的。一定不能同时有多个机子在总线上发送数据。
我不知道你这个通讯协议的方式是否已经安全地投入使用了（未加上位机的情况下）
很容易出现地址数据与其他数据混淆的现象。应该加编码的，唉，不过既然不能改。我也不说了。

fyz2841585 2012-07-20

打赏
举报

[Quote=引用 1 楼的回复:]
1 MSCOMM控件只能接收数据不能接收地址。
2 不必担心，上位机能做出反应。
[/Quote]
请问，那我该如何判断是否是地址呢，如果不用mscomm控件，要用什么呢？

observer001 2012-07-20

打赏
举报

1 MSCOMM控件只能接收数据不能接收地址。
2 不必担心，上位机能做出反应。

fyz2841585 2012-07-20

打赏
举报

回复fronz：
硬件设计本来没想跟pc机通信，跟上位机通信是后来加上去的想法，但是协议已经不能改。
下位机对外通讯的链接是总线型的。
下位机所有链接的主机都是通过地址来区分，而且这种询问方式，硬件也想跟windows上位机通信。
不能这样能否做到，如不能，该如何改进？

fronz 2012-07-20

打赏
举报

从协议看来，你下位机设计的初衷其通讯对象并不像是pc机。你下位机对外通讯的链接是星形？

如果确定，每帧数据量（固定6字节），波特率19200，看传输速率对PC机来说没问题
（传输过程6个字节也只是3毫秒多一点）。
pc机如果需要对收到后的数据处理后回应，那么所耗时间主要就在这些处理过程上了。
如不需要复杂的处理，直接返回下位机信号，应该没问题。

你下位机所有链接的主机都是通过地址来区分？通讯协议似乎不是很恰当，没法直接区分数据中的信息。

fyz2841585 2012-07-20