本帖最后由 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来说，在发送停止位时，它实际上是处于接收状态，因此早到的应答信号也能有效触发接收控制器，这就导致了通信机能工作，非通信机出错。问题至此完全解决，修改相关参数，系统通信正常。

这个要学习下，但是我刷新了多编，就是看不到图片。

系统再次发生接收错误，不过这次出现在总线竞争，第一个争得总线的发送正确后，第二个总线控制发出的地址码，被呼叫从机不能识别，不过有了前面的分析，问题解决得也快了。原因在于：前面提到的RI中断时序有错误，其实原资料文字描述是停止位发送一半时产生，但实际并非如此，仔细看图二最后一行RI时序就不难发现，RI的中断是在发送TB8的一半时就发生了，整整比文字描述提前了一个波特率位，9600时超过了100us，看来，资料的作者估计也是看错了。据此再次修改参数，多机竞争也未再发生错误。特此更正！

很强大很强大

从分析的结果来看，加不加延时应该根据情况来处理。其中包括:
数据处理时间，一般应用应该是没有什么问题，传输一个字节就得1ms多的时间，对于22M系统来说，就可执行几千条指令.处理时间应该是够了
第二是系统，如果是双机通信，没必要加。要是多机通信，又要求各从机都能获取应获的数据，则在接收到数据后的应答要加1.5个波特率位的时间，连续发送的话不用加。
我就是在回复数据时延时160us再发送的回复，并且不是采用的延时，而是定时中断发送。这样不会浪费系统资源。