超级军网超大有用单片机作通讯的高手吗？
来源：百度文库 编辑：超级军网 时间：2024/04/27 20:52:18
用c8051作了一个项目，需要将rs232收到的数据转发出去，但发现将sbuf0寄存器赋值后到数据的第一位从串口发出的延迟时间为3us-30us不等，请问这个如何能缩短这个时间，要知道在57600波特率下，一个字节的宽度才17us。这么高的延迟会造成数据阻塞了。 用c8051作了一个项目，需要将rs232收到的数据转发出去，但发现将sbuf0寄存器赋值后到数据的第一位从串口发出的延迟时间为3us-30us不等，请问这个如何能缩短这个时间，要知道在57600波特率下，一个字节的宽度才17us。这么高的延迟会造成数据阻塞了。
sbuf赋值之后应该就自动开始发送数据了。是不是程序有问题？看一下其它寄存器设置？
中断方式发送？
你是在RI中断里面直接操作写入SBUF和TI来发送？
RI和TI都是中断，而且8051中两者级别一样，TI是中断不了RI的，如果你在发送后在中断服务程序里面还有其他操作，那是要等RI中断服务执行完成才能执行TI中断的
你这个延迟时间不定，看起来象是程序执行造成的，因为写入SBUF和TI之后，根据数据不同，执行的操作不同，造成延迟时间不一定。看起来挺象这个原因
如果你确定每位都需要转发无需鉴别的话，不如在硬件电路上直接用缓冲器连接TXD和RXD
你是在RI中断里面直接操作写入SBUF和TI来发送？
RI和TI都是中断，而且8051中两者级别一样，TI是中断不了RI的，如果你在发送后在中断服务程序里面还有其他操作，那是要等RI中断服务执行完成才能执行TI中断的
你这个延迟时间不定，看起来象是程序执行造成的，因为写入SBUF和TI之后，根据数据不同，执行的操作不同，造成延迟时间不一定。看起来挺象这个原因
如果你确定每位都需要转发无需鉴别的话，不如在硬件电路上直接用缓冲器连接TXD和RXD
奇怪了 发表于 2013-8-2 14:21
中断方式发送？
你是在RI中断里面直接操作写入SBUF和TI来发送？
RI和TI都是中断，而且8051中两者级别一样 ...
是在RI中断里面直接操作写入SBUF来发送的。TI好像不用写。
中断的级别很高，不可能被其他程序中断了。中断响应也非常及时，就是写完SBUF后，要等很长时间数据才开始引出起始位（不是发送完成引发下次用中断）。曾经怀疑是产生波特率的定时器1刚好被错过了，但有时延迟比定时器复位的时间还长，而且人为的修改定时器让他提前跳变也没效果。
中断方式发送？
你是在RI中断里面直接操作写入SBUF和TI来发送？
RI和TI都是中断，而且8051中两者级别一样 ...
是在RI中断里面直接操作写入SBUF来发送的。TI好像不用写。
中断的级别很高，不可能被其他程序中断了。中断响应也非常及时，就是写完SBUF后，要等很长时间数据才开始引出起始位（不是发送完成引发下次用中断）。曾经怀疑是产生波特率的定时器1刚好被错过了，但有时延迟比定时器复位的时间还长，而且人为的修改定时器让他提前跳变也没效果。
嗯，好久不做开发了，忘记得差不多了。
TI只是读或者清理掉而已，呵呵呵
其实你这个问题可以这样验证一下，什么事情都不干，程序开始就直接设定串口，禁止无关中断，同时不要往这个串口发数据，设定完毕直接发送数据，看看第一位什么时候出来。
TI只是读或者清理掉而已，呵呵呵
其实你这个问题可以这样验证一下，什么事情都不干，程序开始就直接设定串口，禁止无关中断，同时不要往这个串口发数据，设定完毕直接发送数据，看看第一位什么时候出来。
再看看每次发送都这样还是要重新上电或者复位才是这样
奇怪了 发表于 2013-8-2 15:20
再看看每次发送都这样还是要重新上电或者复位才是这样
问题的出现是随机的，我决定不在RI里立刻转发，来躲开这个问题，时间耗不起啊。
再看看每次发送都这样还是要重新上电或者复位才是这样
问题的出现是随机的，我决定不在RI里立刻转发，来躲开这个问题，时间耗不起啊。
不是单纯的数据收发项目，51不像arm的，指令周期比较固定，用最高抢断优先级的中断应该不至于波动这么大
苏联小苹果 发表于 2013-8-2 21:47
不是单纯的数据收发项目，51不像arm的，指令周期比较固定，用最高抢断优先级的中断应该不至于波动这么大
跟中断关系不大，停止位出现3us后中断就进入了。且非常稳定。
我现在加了一句TL1=-TH1/2；好像表面上把问题解决了。只是不知道原理不太敢用。
不是单纯的数据收发项目，51不像arm的，指令周期比较固定，用最高抢断优先级的中断应该不至于波动这么大
跟中断关系不大，停止位出现3us后中断就进入了。且非常稳定。
我现在加了一句TL1=-TH1/2；好像表面上把问题解决了。只是不知道原理不太敢用。
莫非是你定时中断中没有重装？
奇怪了 发表于 2013-8-2 22:44
莫非是你定时中断中没有重装？
定时1是自动重装的，但接收端在收到通讯信号后会自动脱离原来的计数器1进行所谓的同步，而发送依旧使用计数器1进行波特率的产生。在某种最差的情况下，这两个计数器会有1个波特率的时差。我猜大概是这个情况，但没有资料证实，试着强制把TL1设置为半满状态可以把两个计数器的时差缩微最多半个波特率。测试的结果好像真的就好了。不过想想还是太玄乎，不太敢用。
奇怪了 发表于 2013-8-2 22:44
莫非是你定时中断中没有重装？
定时1是自动重装的，但接收端在收到通讯信号后会自动脱离原来的计数器1进行所谓的同步，而发送依旧使用计数器1进行波特率的产生。在某种最差的情况下，这两个计数器会有1个波特率的时差。我猜大概是这个情况，但没有资料证实，试着强制把TL1设置为半满状态可以把两个计数器的时差缩微最多半个波特率。测试的结果好像真的就好了。不过想想还是太玄乎，不太敢用。
newdc 发表于 2013-8-2 23:06
定时1是自动重装的，但接收端在收到通讯信号后会自动脱离原来的计数器1进行所谓的同步，而发送依旧使用 ...
我依稀记得我以前习惯在定时中断里手动重装，不过我那时主要针对的波特率是1200和9600，而且不需立即原样转发，所以你的这个问题我没碰到过。
不过搞了两年延续了一代产品就没搞这个转行了，彻底忘光。
定时1是自动重装的，但接收端在收到通讯信号后会自动脱离原来的计数器1进行所谓的同步，而发送依旧使用 ...
我依稀记得我以前习惯在定时中断里手动重装，不过我那时主要针对的波特率是1200和9600，而且不需立即原样转发，所以你的这个问题我没碰到过。
不过搞了两年延续了一代产品就没搞这个转行了，彻底忘光。
用51是很多年前的事情了，现在做产品都用arm了，低端一点的可以用pic嘛，比51稳定多了
windrarara 发表于 2013-8-4 14:06
用51是很多年前的事情了，现在做产品都用arm了，低端一点的可以用pic嘛，比51稳定多了
arm做过一段，不过又转回来了，感觉还是c51顺手，现在51能跑50M，价格便宜，稳定也还不错。
用51是很多年前的事情了，现在做产品都用arm了，低端一点的可以用pic嘛，比51稳定多了
arm做过一段，不过又转回来了，感觉还是c51顺手，现在51能跑50M，价格便宜，稳定也还不错。
newdc 发表于 2013-8-4 22:52
arm做过一段，不过又转回来了，感觉还是c51顺手，现在51能跑50M，价格便宜，稳定也还不错。
我那些东西都是蛮复杂的，51肯定搞不定，有的要用上arm9跟linux，但是现在主流已经是cortexM3的cpu了，51能做的我现在都用pic做，pic的8位机做小一点的工业级应用比较稳定……
arm做过一段，不过又转回来了，感觉还是c51顺手，现在51能跑50M，价格便宜，稳定也还不错。
我那些东西都是蛮复杂的，51肯定搞不定，有的要用上arm9跟linux，但是现在主流已经是cortexM3的cpu了，51能做的我现在都用pic做，pic的8位机做小一点的工业级应用比较稳定……提供你的代码看看
春哥纯爷们，铁血真汉子
用Queue Buffer，给我钱，我可以给你搞定
契卡人民委员会 发表于 2013-8-9 14:27
用Queue Buffer，给我钱，我可以给你搞定
用缓冲区能够搞定，只是希望找到更简洁的方法了。
用Queue Buffer，给我钱，我可以给你搞定
用缓冲区能够搞定，只是希望找到更简洁的方法了。
newdc 发表于 2013-8-10 08:47
用缓冲区能够搞定，只是希望找到更简洁的方法了。
你就是一个UART转接吧？
如果是你说的情况，就老老实实的用缓冲区吧，TX和RX都要用缓冲区。
用缓冲区能够搞定，只是希望找到更简洁的方法了。
你就是一个UART转接吧？
如果是你说的情况，就老老实实的用缓冲区吧，TX和RX都要用缓冲区。
契卡人民委员会 发表于 2013-8-10 09:14
你就是一个UART转接吧？
如果是你说的情况，就老老实实的用缓冲区吧，TX和RX都要用缓冲区。
把负责产生发送波特率的计数器手工设置为半满，似乎达到了想要的效果，不会出错了，但理论上没想通，也就罢了。
你就是一个UART转接吧？
如果是你说的情况，就老老实实的用缓冲区吧，TX和RX都要用缓冲区。
把负责产生发送波特率的计数器手工设置为半满，似乎达到了想要的效果，不会出错了，但理论上没想通，也就罢了。