完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
扫一扫,分享给好友
嗨,所有的人,都到了你盯着无数次,却看不到的地步。那就是我。我是一位经验丰富的设计师,多年来偶尔会有UART字节丢失的问题。这一次,我错过了,没有看到一个原因。我有一个PIC32 MX470接收数据包在UART,解析它们,然后回复UART。在很长一段时间,有时长达一个小时的周期性消息,一个字节在RX端丢失。下面是详细说明:FrReStuuUT中断是最高优先级字节被写入循环缓冲器,只有ISR写入此缓冲器(但丢失的字节不在缓冲器的边缘附近)。r)指向接收到的字节的位置的指针仅由ISR115200波特(每字节86个字节,如果我的数学正确)写的PIC时钟速率80 MHz(足够的时间来处理ISR并把接收到的字节填充到缓冲器中)“470 UART没有FIFO,但我不认为我是OV。错误的。(我应该检查一下,但我怀疑。)有没有想过我可能错过什么?谢谢你对我可能尝试的任何建议。戴夫
以上来自于百度翻译 以下为原文 Hi All, Ever get to the point where you've stared at something a zillion times but just don't see it? That's me. I am an experienced designer and have had problems with dropping UART bytes occasionally over the years. This time I'm missing it and don't see a reason. I have a PIC32MX470 which receives packets over UART, parses them, then replies over UART. Over a long period of time, sometimes up to an hour of periodic messages, a byte gets lost on the RX side. Here are details: FreeRTOS UART interrupt is highest priority Bytes get written into a circular buffer and only the ISR writes this buffer (but the lost byte is nowhere near the edges of the buffer) The pointer to the location where the received byte is saved is only written by the ISR 115200 BAUD (86 usec per byte, if my math is right) PIC clock rate 80 MHz (plenty of time to handle the ISR and stuff the received byte into the buffer) The '470 UART doesn't have a FIFO, but I don't think I'm overrunning. (I should check this, but I doubt it.) Any thoughts as to what I might be missing? Thanks for any suggestions on what I might try. Dave |
|
相关推荐
12个回答
|
|
戴夫:这个问题几乎必须在UART中运行。有没有办法在那个端口上启用FIFO?微芯片UART通常有它们。除非UART有一个拒绝一个字节的机制,而没有一个良好的起始和停止位,它可能是传输噪声,错误。你的发送/接收时钟有多近?你在推动时间限制吗?RTOS是否可以阻止86 USEC的中断服务?并导致一个字节被丢弃?---格雷厄姆=
以上来自于百度翻译 以下为原文 Dave: The problem almost has to be an over-run in the UART. Is there any way to enable a FIFO on that port? Microchip UARTs usually have them. Unless the UART has a mechanism for rejecting a byte without a well formed start and stop bit, in which it could be transmission noise, error. How close are your transmission/receive clocks? Are you pushing the timing limits, there? Is there any way the RTOS could block interrupt service for 86 usec? and cause a byte to be dropped? --- Graham == |
|
|
|
如果在接收到的字节上出现溢出或帧错误,是否设置标志?
以上来自于百度翻译 以下为原文 Do you set a flag if an overrun or framing error occurs on a received byte? |
|
|
|
要么:1)缓冲区溢出。2)环形缓冲区代码中的缺陷。使用指针或计数器变量来确定状态吗?(计数器变量可能不安全)3)现实。RS232会丢失字节。你在计算框架错误吗?缓冲区溢出?还有其他丢失的字符吗?你的协议应该被设计来处理它,如果它重要的话。
以上来自于百度翻译 以下为原文 Either: 1) Buffer overrun. 2) A defect in your ring Buffer code. Are you using the pointers or a counter variable to determine status? (A counter variable may not be safe) 3) Reality. RS232 can lose bytes. are you counting framing errors? Buffer overruns? Any other lost chars? Your protocol should be designed to deal with this, if it matters. |
|
|
|
是的,我说我没有检查超支。我会在早上做那件事。无论如何,即使我读了一个坏字节从U?RXRG,这个坏字节将被存储在我的缓冲区中。缓冲区具有前面和后面的字节,都是正确的。丢失的字节实际上是丢失的,不仅仅是错误的,我错了。这部分有FIFO。我正在使用它们。(哎呀,2年前我写了这个代码。-)我将在晨练、TX和RX时钟中进一步研究这一点?六羟甲基三聚氰胺六甲醚。。。没想到。“470”实际上是与“460”的UART通话,而“460”是通过USB与PC机通话。我相信他们都用同样的水晶。我知道,FrReTOS配置文件对于两个PIC都具有相同的时钟配置,并且两个PIC使用相同的源文件初始化UART和ISR。(只有更高级的代码是不同的)WRT FRIERTOS阻塞,我不这么认为。我初始化我的系统,然后手动检查所有的IP寄存器。FRIERTOS只为定时器使用一个中断,它的级别很低。谢谢戴夫。
以上来自于百度翻译 以下为原文 Yeah, I said I wasn't checking overrun. I will do that in the morning. Regardless, even if I read a bad byte from U?RXREG, that bad byte would be stored in my buffer. The buffer has the preceding and following bytes, both correct. The byte that is missing is truely missing, not just incorrect. I was wrong. This part does have FIFOs. I am using them. (Gee, I wrote this code 2 years ago. :-) ) I will look into this further in the morning. TX and RX clocks? Hmmm... Hadn't thought of that. The '470 is actually talking to a '460 over UART, and the '460 is talking to a PC over USB. I believe they both use the same crystal. I know that the FreeRTOS configuration file has exactly the same clock configuration for both PICs, and both PICs uses the same source file to initialize the UART and for the ISR. (Only the higher level code is different.) WRT FreeRTOS blocking, I don't think so. I initialized my system then manually checked all the IP registers. FreeRTOS only uses one interrupt for a timer and it is a very low level. Thanks Graham. Dave |
|
|
|
感谢QHB。我回答Graham时,我明天检查超支。86个具有12.5毫秒指令时钟的USEC是永恒的。我仍然希望在一个超载中读取一个坏字节,并且仍然会有一个中断,它会把一些东西放进我的循环缓冲区。
以上来自于百度翻译 以下为原文 Thanks qhb. As I replied to Graham, I will check overrun tomorrow. 86 usec with a 12.5 nsec instruction clock is forever though. And I would still expect to read a bad byte on an overrun and still get an interrupt which would put *something* into my circular buffer. It really is as if I'm missing an interrupt. Dave |
|
|
|
嗨,NKurzman,正如上面所说,不会超支还是给我坏数据读U?一个中断的RXRG?它是一个完全丢失的字节,不是坏数据。我的循环缓冲区中没有错误。我用这个代码已经20年了,从来没有像这样的问题。我有一个开始指针和结束指针。当RX中断发生时,U?读取RXRG,并将其存储在结束指针上,然后指针递增。除了在ISR中的这一行代码外,结束指针从未写入任何地方。缓冲区很大,从来没有溢出。这是一个丢失的炭。它完全消失了,我的协议也被使用了20年。具有CRC保护的AHDLC。当字节丢失时,消息被抛出。扔掉消息是可以恢复的,但是它会减慢系统。谢谢,戴夫
以上来自于百度翻译 以下为原文 Hi NKurzman, As said above, wouldn't an overrun still give me bad data reading U?RXREG on an interrupt? It's a completely missing byte, not bad data. No chance there is an error in my circular buffer. I've been using this code for 20 years and have never had a problem like this. I have a start and an end pointer. When the RX interrupt occurs, U?RXREG is read and it is stored ad the end pointer then the pointer incremented. The end pointer is never written anywhere but this one line of code in the ISR. The buffer is large and there is never an overrun. It is a lost char. It is completely missing. My protocol has also been used for 20 years. AHDLC with CRC protection. When the byte is lost, the message is tossed. Tossing the message is recoverable, but it slows down the system. Thanks, Dave |
|
|
|
检查溢出帧和您的环形缓冲区已满。如果你找不到任何东西,那么确保发送者不是丢失字节的那个人。
以上来自于百度翻译 以下为原文 Check for overrun framing and your ring buffer is full. If you find nothing then be sure the sender is not the one lossing the byte. |
|
|
|
好的,我想我发现了:“注意:接收FIFO中的数据应该在清除ORR位之前被读取。当OER位被清除时,FIFO被重置,这导致缓冲器中的所有数据丢失。“我在每次FIFO读取之后清除ORR,因为我的CRC会捕获数据中的任何错误。但我想如果你?RXDA(数据可用)位被设置,在下一个字节到达后,我将读取当前字节,然后清除导致FIFO重置的ORR,u?RXDA将被清除,下一个字节被抛出。我假设这是原因,但是它需要大量的测试。谢谢所有人给我指出了正确的方向。戴夫
以上来自于百度翻译 以下为原文 OK, I think I found it: "Note: The data in the receive FIFO should be read prior to clearing the OERR bit. The FIFO is reset when the OERR bit is cleared, which causes all data in the buffer to be lost." I was clearing OERR after every FIFO read because my CRC would catch any errors in the data. But I think if U?RXDA (data available) bit is set, I would read the current byte just after the next byte arrives, then clear OERR causing the FIFO to be reset, U?RXDA to be cleared, and the next byte being tossed. I'll assume this is the reason but it will take a lot of testing. Thanks to all for pointing me in the right direction. Dave |
|
|
|
溢出意味着你完全丢失了一个字节(或几个),没有跟踪。帧错误意味着一个接收错误。字节可能很好。
以上来自于百度翻译 以下为原文 Overrun means that you have lost a byte (or several) completely, without a trace. Framing error means just a reception error. The byte may be still good. |
|
|
|
你能展示你的ISR代码吗?您是否使用原子指令来清除/设置寄存器中的位(例如中断标志),或者是用位操作(RMW)来执行?您是否为每个中断清空FIFO或仅仅读取一个字节?Ruben
以上来自于百度翻译 以下为原文 Can you show your ISR code? Are you using atomic instructions for clearing/setting bits in register (interrupt flags for example) or are you doing it with bit operations (RMW)? Are you emptying the FIFO for each interrupt or just reading one byte? /Ruben |
|
|
|
|
|
|
|
嗨,注意,有一个硅问题与UART超载在PIC32 MX470需要注意…阅读勘误表第16页10.
以上来自于百度翻译 以下为原文 Hi, Pay attention, there is a silicon issue with UART overrun on the PIC32MX470 which needs to be taken care of... Read the errata #16 page 10 Regards |
|
|
|
只有小组成员才能发言,加入小组>>
5159 浏览 9 评论
1998 浏览 8 评论
1927 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3170 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2223 浏览 5 评论
724浏览 1评论
608浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
496浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
621浏览 0评论
520浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-19 21:24 , Processed in 1.395910 second(s), Total 98, Slave 82 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号