485多机通信出现的怪问题

2020-02-04 09:06发布

做了个485通信板,七个U,专用于做实验用。485采用的自动收发电路,也就是只发0,1装上下拉电阻完成的那种。硬件很简单。但在实验中出现怪现象,即系统开机后,主机与分机能通信,但不通信的分机即只能接收到一个正确的数据,就是第一个地址码。而后面的数据码全出错。按理应该不会产生的串口中断,也产生了。通信协议最后有一条复位命令,是发给所有从机的。但除通信的从机能正确收到,其它从机收到的全是错误的数据。百思不得其解。不知各位是否也遇上过类似问题。
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
该问题目前已经被作者或者管理员关闭, 无法添加新回复
18条回答
BDXing6
1楼-- · 2020-02-05 16:55
本帖最后由 BDXing6 于 2012-4-23 16:57 编辑

多机通信总结
一、问题的提出:在一个51单片机组成的竞争型多主多从半双工485网络中,各节点任意双机通信正常,但其它节点机接收错误,因此无法接收到最后的总线释放广播命令,导致网络通信最终失常。
二、问题现象:
    1、本人将PC接入总线,按理来说,也相当于是一个从机。在COM助手中确能正常收到主从双机的通信数据。但节点从机接收的即是错误数据。
    2、调整网络通信波特率,一般而言,波特率越低,误码率将越低,但对本系统而言,相反。当波特率为9600或更低时,非通信从机完全接收不到正确的数据。但波特率调到最高1.36M时,系统非通信从机误码率大大降低,系统出现正常工作的现象。但通信机无论在那种波特率下都能正常工作,误码率始终保持在较低水平。
三:问题的分析与解决
    在各位网友的提议中,有一位提到了加延时,可为什么要加延时,延时多少,因此在网上查找答案,可无功而返,原因是大家都在延时,一般为1ms,可对我的系统而言,要求的高实时性,1ms太奢侈,无法接受,更何况没理由的延时,不是我编程的风格。于是只能自己开始找理由。
首先应做的是,了解非通信从机接收的错误数据到底是什么?于是在非通信机程序中插入断点,并将接收到的错误数据送到p1口。结果发现以下现象:
    1、通信主机呼叫从机数据11H,各从机均能接收正确。
    2、被呼叫从机应答数据11H,非通信机接收到的为84H,而主机可以正确接收。
    3、改变主机呼叫从机编号为呼叫13H号从机时,各从机均接收正确,但13号从机应答回复13H时,非通信机收到的却为C2H,同样主机接收正确。
    4、其实在多机通信中,大家知道,除主机发送地址码时,从机才可能产生中断,而对于被呼叫从机的应答(TB为0),非通信从机应该不会产生中断,可见,非通信从机接收到的错误数据其RB值应该是1了。
由于没有存贮示波器,不能看到通信时的真正波型,但我们可以将总线上出现的通信波型根据通信数据画出来,由此得到以下图型。

DSCN5278.JPG (533.37 KB, 下载次数: 1)

下载附件

2012-4-23 16:53 上传


    串口工作时,是以一个低电平为起始信号,在原理上就是1到零跳变检测器。这使我们想起了51的外部中断系统,边沿触发。其原理完全一样。不同的是,外部中断检测采用的是机器周期脉冲,而串口检测如图上所示是采用的定时器溢出脉冲,也就是波特率位脉冲,因此,要使串口检测到开始信号,必须让检测器能正确检测到高到低的跳变,并且低电平有足够的宽度。非通信机未能接收到正确的跳变,只能说明一点,总线上的波型在实际通信中产生了问题。由于呼叫与应答是由两个不同节点发出,波型时序上产生变异,只可能与中断响应时间有关了。通过对51结构的RI以及TI的产生时序进行查阅,这才发现真正的原因,那就是RI与TI并非一个字节完全发送完成或接收完成才产生的。资料显示:在串口模式三时,TI的置位同步于发送停止位。也就是说,开始发送停止位就将TI置位了。但由于发送数据都是系统自主行为,因此不会产生问题。而对RI就不一样了,RI的置位发生于接收到停止位一半的时候就发生了。正是由于这一半的时间,导致了非通信从机丢失了起始信号。
    我们可以这样来看,当主机呼叫从机时,从机产生中断,记住,这时总线上还有一半的终止位在发送,对于9600波特率而言,就是高电平还得保持50us。从机响应中断,对于被呼叫从机回发应答,由于这个处理过程很短,我的系统采用22M晶振,机器周期约45ns,平均指令时间约150ns,总体处理时间不超过约5us,于是就发送了回应。也就是说,主机发送完成还有45us的时间,总线电平就被从机的应答拉低。而对于非通信从机就不幸了,由于之前它也接收了前一字节的呼叫信号,也就是接收控制器已经开启,它要检测总线上的1-0跳变,必须完成这个字节的接收才会开始。而这个跳变在它进行检测前45us就由被呼叫从机发出。因此无论如何他也检测不到这个跳变了,这就是非通信从机丢失起始位的原因。之所以主机能正确接收到应答,那是因为主机在之前并没有开启接收控制器,1-0检测始终都在检测总线的负跳变。那为什么PC又能正确接收呢,原因只有一个,那就是PC的1-0跳变检测机制与51大不相同,1-0检测脉冲频率也高很多。比如说,当PC产生接收中断时,1-0检测器就立即开启。同时,这种现象的产生,也与采用的485自转换电路有关,在这个电路中,实际上只有零是发往总线的,而1是由总线上下拉电阻来产生,并且,对于发送数据的51来说,在发送停止位时,它实际上是处于接收状态,因此早到的应答信号也能有效触发接收控制器,这就导致了通信机能工作,非通信机出错。问题至此完全解决,修改相关参数,系统通信正常。
jqfsjt
2楼-- · 2020-02-05 18:27
这个要学习下,但是我刷新了多编,就是看不到图片。
BDXing6
3楼-- · 2020-02-05 20:08
系统再次发生接收错误,不过这次出现在总线竞争,第一个争得总线的发送正确后,第二个总线控制发出的地址码,被呼叫从机不能识别,不过有了前面的分析,问题解决得也快了。原因在于:前面提到的RI中断时序有错误,其实原资料文字描述是停止位发送一半时产生,但实际并非如此,仔细看图二最后一行RI时序就不难发现,RI的中断是在发送TB8的一半时就发生了,整整比文字描述提前了一个波特率位,9600时超过了100us,看来,资料的作者估计也是看错了。据此再次修改参数,多机竞争也未再发生错误。特此更正!
comeday
4楼-- · 2020-02-05 20:41
很强大很强大
r166
5楼-- · 2020-02-06 01:32
 精彩回答 2  元偷偷看……
BDXing6
6楼-- · 2020-02-06 04:59
从分析的结果来看,加不加延时应该根据情况来处理。其中包括:
数据处理时间,一般应用应该是没有什么问题,传输一个字节就得1ms多的时间,对于22M系统来说,就可执行几千条指令.处理时间应该是够了
第二是系统,如果是双机通信,没必要加。要是多机通信,又要求各从机都能获取应获的数据,则在接收到数据后的应答要加1.5个波特率位的时间,连续发送的话不用加。
我就是在回复数据时延时160us再发送的回复,并且不是采用的延时,而是定时中断发送。这样不会浪费系统资源。

一周热门 更多>