发 帖  
原厂入驻New
申请华秋企业认证 多层板首单免费打样!
30s提交资料,10分钟通过审核(免费赔付+顺丰包邮)>>立即报名
[问答] 为什么串行通信不一致?
111 Linux UART
分享
我已经遇到了一个奇怪的问题,使用EUSAT上的PIC18F45 K22设计。UART正在与另一个运行Linux的CPU通信,在9600/8/1/否时,当我第一次用ICD3加载代码时,只要不循环电源,通信就可以正常工作。在一个电源周期之后,我得到的唯一通信故障是当Linux cpu请求来自PIC的长度超过20个字符的响应时。当请求更长的字符串时,第十九个字符总是被Linux CPU错误地接收到。两个CPU之间最长的通信字符串是23个字符,除了19个字符外,所有字符都被正确接收。所有更短的通信“握手”都被正确地接收到了。这是波特率比赛吗?当代码加载并启动ICD3与重新启动电源时,是否初始化了不同的东西?我试着将SPBRG1(通常为25)设置为23、24、26和27,但是这并没有解决问题。顺便说一句,如果可以的话,我正在使用内部振荡器。谢谢你的想法。
0
2019-8-20 11:29:02   评论 分享淘帖 邀请回答

相关问题

11个回答
更新:我发现了我不一致的通信问题的原因。它似乎与内部时钟(16MHz)频率有关。这导致波特率失误匹配。当我用逻辑分析仪对数据流进行分析时,我可以看到偶尔的帧错误。我能够通过调整振荡器频率下降——OSCTUNE=0x30来校正与我正在工作的单元的通信。虽然这个装置在这个时间点工作正常,我仍然需要提出一个解决方案,将工作生产,并将继续工作数年,一旦产品被运到我们的客户。我不知道随着时间的推移会发生什么样的漂移。有没有人对这一长期解决方案有什么见解?
2019-8-20 11:40:16 评论

举报

我想,你不想用水晶吧?
2019-8-20 12:12:10 评论

举报

至少有一个需要水晶,除非他想要自动波特。
2019-8-20 12:27:12 评论

举报

PC有一个水晶。看看PIC 2%在室温3%热的数据表。5%是工作的极限。如果两块板都没有晶体,如果没有工作的话。是的,水晶会解决这个问题。
2019-8-20 13:13:08 评论

举报

USAT操作总是在每个起始位下降沿重新同步,而不考虑数字停止位。增加停止位的数量不会帮助解决由时钟频率不当产生的问题。正如NKurzman所言,两个系统时钟之间的相对差值不能超过5%。换句话说,如果一个系统是+3%,而另一个系统是-2%,则相对差值是5%。考虑每个字符传输中有一个起始位、8个数据位和一个停止位(总共10位)。接收机在开始比特下降沿上启动内部定时器,并相对于开始比特边缘采样每个比特的中间。如果最后一个样本超过一个比特的+/- 1/2,那么该样本将处于相邻的比特时间。做数学:+/-0.5/10++/- 5%。一些协议。如LIN,通过在每个事务上执行自动波特来补偿频率漂移。它运行良好,比添加晶体便宜。
2019-8-20 13:40:18 评论

举报

啊!但这是个问题。你认为UART会在完成前一个停止位之前开始下一个起始位吗?大多数UART在比特周期上进行多个级别的采样。最早一点何时在停止位周期内接受新的起始位?我从来没有见过它。50%不可能,75%可能,100%可能!这取决于UART的设计,并不是所有的都是平等的。在这种情况下,另一端甚至不是PIC UART。我的观点是,如果字符是背对背的,时钟之间的误差需要比5%小很多。在OPs案中,这个问题只显示了20个字符。在这种情况下,使用两个停止位可能有助于解决问题,但如果不能保证内部时钟,这当然不是最好的解决方案。
2019-8-20 13:57:16 评论

举报

这仍然是错误的。UART同步对于每个字符都会发生。在ICD3复位(但不是开机)之后,我看到了18F USART的问题,除非在USART配置之前插入了相当长的延迟,否则传输垃圾。我尝试了各种组合的电能定时器等,无济于事。整个字符串是垃圾,然而,不只是第n个字符。
2019-8-20 14:14:26 评论

举报

好点。这让我很好奇,所以我测量了它。对于PIC,我测量当至少51.9%的起始位时间已经过去时,开始位将被可靠地检测到。甚至我发现这很难相信,因为位采样应该发生在停止位的40.44%、50.0%和56.3%点。给出假定的设计采样,怀疑的好处将把开始位边缘检测早在停止位的56.3%点。这将减少两个系统时钟在(1-0.563)/ 10=4.37%之间的相对误差。然而,在PIC EUSAT外设中没有插入2个停止位的规定。一个可能的解决方法是为9位传输配置EUSART,并将TX9D位设置为1。起始位检测不是累加。相对时钟频率的问题很可能发生在任何字符上。短字符串总是有效的,而长字符串并不意味着其他系统不能像它来得那么快地处理数据,或者接收缓冲区溢出。如果两个停止位方法不起作用,那么我将尝试发送字符串作为一系列短脉冲,允许接收机时间赶上。
2019-8-20 14:31:44 评论

举报

2019-8-20 14:48:42 评论

举报

是的,令人惊讶的是这么早。对于使用x16时钟工作的UART来说,在位的7,8,9 16位进行采样似乎是一种常见的做法(我已经多次看到这种情况)。我想在10/16接受下一个开始位将会是一个很有可能的设计。如果UART只有X4时钟,那么它就不那么容易了,很可能是75%。这也是一个很好的观点。然而,在PIC EUSAT外设中没有插入2个停止位的规定。一个可能的解决方法是为9位传输配置EUSART,并将TX9D位设置为1。我只是检查了一下我是如何做到这一点的,是的,TX9/TX9D正是我所做的。它的优点是可以在1个停止位(8位,RX9=0)模式下保持RX。我记得在PIC时代以前的一段时间里,我看过UARTS,它强制接收第2个停止位。这个观察很奇怪。起始位检测不是累加。相对时钟频率的问题很可能发生在任何字符上。短字符串总是有效的,而长字符串并不意味着其他系统不能像它来得那么快地处理数据,或者接收缓冲区溢出。如果两个停止位方法不起作用,那么我会试着将字符串发送为一系列短脉冲,让接收器有时间跟上。假设TX时钟比RX时钟快7/16位宽度超过10位。如果一个特定的接收器在10/16接受下一个起始位,那么第二个字符实际上被检测到1/16位延迟。这在第三个字符2/16后面直到16个字符之后我们已经滑了一点。因此,如果下一个开始位在可以接受的最早点之前到达,并且没有指定,那么它是累加的:-(当然,例如,它已经接近于不为第一个字符工作的极限。这是一种“带和括号”的东西。得到你的时钟,然后帮助另一端;-)
2019-8-20 14:57:30 评论

举报

我很高兴你提出这一点,因为这正是我要做的。在下降沿上检测起始位。如果在停止位采样完成之前发生该下降沿,那么起始位看起来像一个失败的停止位,并且接收器不会再次开始采样直到下一个下降沿发生。直到下一个字符中的一个数据位或下一个字符之后的开始位(如果该字符碰巧是0或MS位中具有1s的字符),才会出现这种情况。换言之,歪斜起始位(1/16、2/16等)是不可能的。这就是我的意思,不是累积的。
2019-8-20 15:04:04 评论

举报

只有小组成员才能发言,加入小组>>

56个成员聚集在这个小组

加入小组

创建小组步骤

关闭

站长推荐 上一条 /10 下一条

快速回复 返回顶部 返回列表