485多机通信出现的怪问题
做了个485通信板,七个U,专用于做实验用。485采用的自动收发电路,也就是只发0,1装上下拉电阻完成的那种。硬件很简单。但在实验中出现怪现象,即系统开机后,主机与分机能通信,但不通信的分机即只能接收到一个正确的数据,就是第一个地址码。而后面的数据码全出错。按理应该不会产生的串口中断,也产生了。通信协议最后有一条复位命令,是发给所有从机的。但除通信的从机能正确收到,其它从机收到的全是错误的数据。百思不得其解。不知各位是否也遇上过类似问题。 楼主最好贴上程序才好分析啊 通讯程序状态改变时是否加了小延时? 本帖最后由 BDXing6 于 2012-4-21 11:34 编辑先上485图
一共有6个。编号08~13.临时画的草图,下面ACC实际是地。
程序很简单。这个是发送程序
setb tr1 ;打开定时器一
clr ti ;清串口发送接收中断标志
clr ri
clr sm2 ;清地址桢接收响应位,自已作为主机,接收所有数据
setb tb8 ;第一个数据为地址桢
clr join ;连接标志复位
setb es ;开串口中断
mov sbuf,SSO_ToAdd ;发送握手信息
这个是接收
jb rb8,int_s2 ;是地址或命令广播(地址从1~32H,广播命令为80~0FFH),从机才能收到
;========从机接收数据桢=========
mov a,r5 ;R5用于保存接收数据的个数,开始时为零
jz int_s1 ;是接收的第一个数据
mov @r1,sbuf ;数据送缓冲区
inc r1
djnz r5,int_s_ret
mov a,#SSI_Add ;数据接收完成,进行校验和处理(第一个数据一直加到第n-1个数据应等于第n个数据)
call DataAdd
cjne a,sbuf,int_sp ;校验和不等转移
mov sbuf,#MyNum ;数据接收正确,回发本机编号,数据接收完成,等待广播命令
setb DataSSI ;数据到达标志置位
jmp int_s_ret
int_sp: mov sbuf,#Com_Err ;数据传输出错,回送错误信息,要求重发数据
jmp int_s_ret
int_s1: ;接收的第一个数据字节为数据个数
mov r5,sbuf ;第一个数据是以后的数据个数,送R5
mov r1,#SSI_Add ;接收缓冲区地址送R1,准备接收数据
mov @r1,sbuf ;数据个数也同时存入数据缓冲区,作为以后的校验用
inc r1 ;数据缓存区地址加一
dec r5 ;已接收一个数据
jmp int_s_ret
int_s2: ;=========从机地址或命令桢处理============
mov a,sbuf
jb acc.7,int_s5 ;是广播命令转移
cjne a,#MyNum,int_s_ret ;不是呼叫本机退出
clr tb8 ;清发送地址桢位
clr sm2 ;是呼叫本机,清SM2,准备接收数据
setb Join ;连接建立标志置位
mov r5,#0 ;R5用于存放应接收的数据个数,接收数据前清零
mov sbuf,a ;将本机编号发回发送方,确认连接。
jmp int_s_ret
int_s5:
;===========广播指令处理============
mov Com_Add,a ;收到广播指令不回复,命令保存在寄存器最后一个单元中(地址为0fh)
setb command ;广播命令到达标志置位
jmp int_s_ret
程序很简单,应该是没有问题。 看不懂你的图,你画个好点的吧。接上拉/下拉时,请仔细检查每个端口是否都接上拉/下拉了,用示波器打一下看看上升沿下降沿是否符合逻辑。我前几天把两组I2C总线合到一起之后就不正常了,几个设备经常没有响应。后来把第二条I2C总线的上拉焊回去(开始想着已经有上拉了,就用不到了),通信就再也没有问题了。 这个图的原理很简单:
在接收数据时,TX为1,三级管截止,485处于接收状态,总线数据送入RX。
发送时,当TX为0时,三级管导通,485在发送状态,同时,TX送入D输入端。TX为1时,三级管截止,485在接收状态,但AB的上下拉使得总线上为1。以此来自动切换485的收发
其实,硬件的问题应该不大,因为,网络上几个节点均可正常通信(说明软件也应该是没有问题的),问题在于,只有通信的节点机能正常接收数据,而没有通信的即接收的是错误的数据。想不明白。 485芯片收发有个切换时间不知道你注意了没有
汇编我看不懂也懒得看 A,B的上下拉错了,应该是A上拉,B下拉! A是接的上拉,B下拉。不然跟那台从机也通信不了。实际上是都能通信。
481、485切换时间在ns级,最高也只1us,487、488等在us级,最高2us。对本系统而言,可以不考虑。实际上通信也正常。 这个问题一定要搞清楚,从总线开始,一个字节一个字节的查。开工! 本帖最后由 BDXing6 于 2012-4-21 16:22 编辑
把我做实验的板子图片先发上来,挣点人气。 楼主说开机一会儿可以通信,硬件又简单,我觉得还是程序上面控制485模块收发上有问题! 本帖最后由 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了。
由于没有存贮示波器,不能看到通信时的真正波型,但我们可以将总线上出现的通信波型根据通信数据画出来,由此得到以下图型。
在图中我们惊人的发现,从机应答的串口起始信号丢了。非通信从机是从应答信号出现的第一个0位开始的,因此而产生了接收错误。问题是查了出来,可为什么会这样?更何况,同样的信号为什么在PC机上又没丢,而是被正解的识别出来了呢?这可能就得从51串口的内部结构来认识了:看下图:
串口工作时,是以一个低电平为起始信号,在原理上就是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来说,在发送停止位时,它实际上是处于接收状态,因此早到的应答信号也能有效触发接收控制器,这就导致了通信机能工作,非通信机出错。问题至此完全解决,修改相关参数,系统通信正常。
这个要学习下,但是我刷新了多编,就是看不到图片。 系统再次发生接收错误,不过这次出现在总线竞争,第一个争得总线的发送正确后,第二个总线控制发出的地址码,被呼叫从机不能识别,不过有了前面的分析,问题解决得也快了。原因在于:前面提到的RI中断时序有错误,其实原资料文字描述是停止位发送一半时产生,但实际并非如此,仔细看图二最后一行RI时序就不难发现,RI的中断是在发送TB8的一半时就发生了,整整比文字描述提前了一个波特率位,9600时超过了100us,看来,资料的作者估计也是看错了。据此再次修改参数,多机竞争也未再发生错误。特此更正! 很强大很强大 楼主到底加没加延时啊? 从分析的结果来看,加不加延时应该根据情况来处理。其中包括:
数据处理时间,一般应用应该是没有什么问题,传输一个字节就得1ms多的时间,对于22M系统来说,就可执行几千条指令.处理时间应该是够了
第二是系统,如果是双机通信,没必要加。要是多机通信,又要求各从机都能获取应获的数据,则在接收到数据后的应答要加1.5个波特率位的时间,连续发送的话不用加。
我就是在回复数据时延时160us再发送的回复,并且不是采用的延时,而是定时中断发送。这样不会浪费系统资源。
页:
[1]