4352|16

66

帖子

0

TA的资源

一粒金砂(初级)

楼主
 

波特率大讨论 [复制链接]

   最近做一个串口的发送与接受,整了好长一段时间了,总是有数据遗落或者乱码的问题。
   以前加入协议:‘@’+char+char+‘#’,导致接受时落掉数据,现在我干脆每次发生一个char,协议这东西在波特率误差的情况下只会增加误码率而导致遗落数据,我还发现这种波特率误差有累积效应。
   奇偶校验在发送端和接受段是如何设置的?我感觉单个字节的话用这个校验可能还好些。这样会增加-个校验位bit9,在接受端的话就是判断RB9了?

   
   望各位朋友指点,多多分享你的经验。
   

最新回复

   谢谢各位朋友,问题已经解决,一个地方没有喂狗,导致时序比较杂乱,经过喂狗后,问题彻底解决,呵呵,真高兴。  详情 回复 发表于 2010-2-2 14:54
点赞 关注

回复
举报

67

帖子

0

TA的资源

一粒金砂(初级)

沙发
 
  最近做一个串口的发送与接受,整了好长一段时间了,总是有数据遗落或者乱码的问题。
  以前加入协议:‘@’+char+char+‘#’,导致接受时落掉数据,现在我干脆每次发生一个char,协议这东西在波特率误差的情况下只会增加误码率而导致遗落数据,我还发现这种波特率误差有累积效应。
  奇偶校验在发送端和接受段是如何设置的?我感觉单个字节的话用这个校验可能还好些。这样会增加-个校验位bit9,在接受端的话就是判断RB9了?
  
  望各位朋友指点,多多分享你的经验。


 
 

回复

69

帖子

0

TA的资源

一粒金砂(初级)

板凳
 
先顶下,吃完饭,再好好看下

MARK
 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

4
 
可以考虑以下的一些因素:
1、晶振是否是串口通讯的最佳频率,否则会有误码率。但不会太高,也就是千分之几。不知楼主所说的“丢码或是乱码”的比例有多高
2、关于通讯协议的问题。楼主的通讯协议本身没有校验机制,建议加上来。我在做串口通俗讯协议的时候,大概是这样的(假设收发是固定长度的):起始字节(1个字节)+时间戳(1~2个字节)+控制命令(1个字节)+控制命令中携带的数据(N个字节)+校验码(1个字节)+结束字节(1个字节)
3、接收方需要有容错机制,也就是如果判断出接收的数据有误,需要如何处理的问题。当然,往往是要求发送方重发。
4、如果串口收发是在中断中进行的,请注意不要在中断中做太多对数据处理的事情。最好仅仅做接收,当一帧的数据接收完毕后再在主循环中做处理。
5、测试环境是否是高磁场、高电场之类的。我曾经在一个有电弧焊的地方调试程序,只要电焊一启动,程序就莫名其妙出现问题。
 
 
 

回复

63

帖子

0

TA的资源

一粒金砂(初级)

5
 
   时间戳:我从来没有试过,单片机能有这个功能吗?
   之所以现在舍弃起始字节和结束字节,就是由于误码率的影响,就是说发送数据越长,误差的可能性越大,这样接受方按照此协议接受必定出现问题。就造成遗落。
   由于在发送方有定时中断控制扫描,如果在发送的时候关闭中断,发现会造成扫描被打断后的灯的闪烁。
   容错机制还没有想到,我倒想试试连续发送三个一样的字节(数据量为1字节),在接收方判断,多数一样者为正确解,这种方法是不是比应答式的容错还好些呢?
 
 
 

回复

71

帖子

0

TA的资源

一粒金砂(初级)

6
 
   通过示波器的监察,发现一个bit的时间跨度为105.6us,计算为:
>> 1000000/105.6

ans =

  9.4697e+003  
  接近9600了,难道是电磁干扰的原因?
 
 
 

回复

72

帖子

0

TA的资源

一粒金砂(初级)

7
 
波特率误差不得大于3%。
波特率误差没有累积效应,起始位是同步用的。
UART将在第7,8,9三个位上检测信号(取2/3).
 
 
 

回复

82

帖子

0

TA的资源

一粒金砂(初级)

8
 
引用 6 楼 schlafenhamster 的回复:
UART将在第7,8,9三个位上检测信号(取2/3).

这种检测是单方面的发送方检测吧?看不出有什么作用。一个字节的发送究竟占用了多少位?9位还是10位?
 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

9
 
首先需要确保晶振的 以及对应电容的温度的品性,
尽量减少对应电容的误差,可以考虑买好的,

另外所谓的频率误差也不会有楼主这么严重,
至于前导码与后导码, 这些也是可以不要的。

我们的UART 短距离通讯,115200 9600等都很稳定。

建议楼主用示波器抓下 出现数据遗落或者乱码时,TX与RX的波形,很可能是外部干扰、传输距离过远,否则不会这么不稳定。

另外在UART转RS232等电路上 最好加上TVS,不仅仅可以放静电,也可以放一点冲击的干扰。
 
 
 

回复

94

帖子

0

TA的资源

一粒金砂(初级)

10
 
误差率小于4.5%就可以相当稳定了,不会像楼主说的那样
 
 
 

回复

66

帖子

0

TA的资源

一粒金砂(初级)

11
 
引用 4 楼 hallowwar 的回复:
? 时间戳:我从来没有试过,单片机能有这个功能吗?
? 之所以现在舍弃起始字节和结束字节,就是由于误码率的影响,就是说发送数据越长,误差的可能性越大,这样接受方按照此协议接受必定出现问题。就造成遗落。
? 由于在发送方有定时中断控制扫描,如果在发送的时候关闭中断,发现会造成扫描被打断后的灯的闪烁。
? 容错机制还没有想到,我倒想试试连续发送三个一样的字节(数据量为1字节),在接收方判断,多数一样者为正确解,这种方法是不是比应答式的容错还好些呢?

“时间戳:我从来没有试过,单片机能有这个功能吗?”
这个“时间戳”算是个广义的概念吧。我一般用四个字节的自然数序列码来实现。以此来保证接收到的帧数据的顺序没有被打乱。
 
 
 

回复

89

帖子

0

TA的资源

一粒金砂(初级)

12
 
误差看来不是问题,示波器里面在乱码的时候有毛刺干扰,现在加个kyzf的TVS试试看。我还想搞一个表决算法,就是5个数据的表决,这样毛刺也不用担心了。

哪位有表决算法么?
  谢谢提供。
 
 
 

回复

69

帖子

0

TA的资源

一粒金砂(初级)

13
 
引用 10 楼 jiqiang01234 的回复:
引用 4 楼 hallowwar 的回复:

“时间戳:我从来没有试过,单片机能有这个功能吗?”
这个“时间戳”算是个广义的概念吧。我一般用四个字节的自然数序列码来实现。以此来保证接收到的帧数据的顺序没有被打乱。


  那你的数据有很多帧的吧?串口忙的过来么?11.0592Mhz适合做115200的通讯?
 
 
 

回复

65

帖子

0

TA的资源

一粒金砂(初级)

14
 
引用 12 楼 hallowwar 的回复:
引用 10 楼 jiqiang01234 的回复:
引用 4 楼 hallowwar 的回复:

“时间戳:我从来没有试过,单片机能有这个功能吗?”
这个“时间戳”算是个广义的概念吧。我一般用四个字节的自然数序列码来实现。以此来保证接收到的帧数据的顺序没有被打乱。


? 那你的数据有很多帧的吧?串口忙的过来么?11.0592Mhz适合做115200的通讯?

我所说的“帧”是指一次数据的收发。当然,这一“帧”的数据并非一定是一次完整的逻辑意义上的数据。比如,一次完整的数据也需要好几十k,需要拆开若干次来发送。
 
 
 

回复

42

帖子

0

TA的资源

一粒金砂(初级)

15
 
"这种检测是单方面的发送方检测吧?看不出有什么作用。"
这是接受方的UART做的,1位被分成16个等分(即UART的时钟是波特率的16倍),UART在7,8,9等分(即时钟)上检测。
 
 
 

回复

74

帖子

0

TA的资源

一粒金砂(初级)

16
 
引用 14 楼 schlafenhamster 的回复:
这是接受方的UART做的,1位被分成16个等分(即UART的时钟是波特率的16倍),UART在7,8,9等分(即时钟)上检测。


需要做什么设置的么?这样看来可以排除一些扰动的干扰,不错。我加了TVS不管用,波形反而变平缓了(我的接法是: 二极管正极接地,负极接单片机RX)。
 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

17
 
   谢谢各位朋友,问题已经解决,一个地方没有喂狗,导致时序比较杂乱,经过喂狗后,问题彻底解决,呵呵,真高兴。
 
 
 

回复
您需要登录后才可以回帖 登录 | 注册

随便看看
查找数据手册?

EEWorld Datasheet 技术支持

相关文章 更多>>
关闭
站长推荐上一条 1/9 下一条

 
EEWorld订阅号

 
EEWorld服务号

 
汽车开发圈

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 国产芯 安防电子 汽车电子 手机便携 工业控制 家用电子 医疗电子 测试测量 网络通信 物联网

北京市海淀区中关村大街18号B座15层1530室 电话:(010)82350740 邮编:100190

电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2025 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表