完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
德赢Vwin官网
论坛|
您好，我用XC16芯片：DSPIC33 FJGP802。我正在使用一个在UART上使用MIDI的合成器。在一个波形被处理的时候，我做了一个需要禁用UART的函数，同时UART的数据也进来了。有时它在UART中断中挂起。UART中断，改变了它，所以它不会挂：只有这是不好的，其他问题出现。也许有人知道什么是错的？框架误差究竟是什么？有没有缺失数据的框架错误？提前感谢
以上来自于百度翻译 以下为原文 Hi, i am using this chip : DSPIC33FJGP802 with XC16. I am working on a synthesizer that uses MIDI on the UART. I made a function that need to disable the UART while a waveform is being processed, meanwhile UART data is incoming. Sometimes it hangs in the UART interrupt when doing this : _DAC1LIE = 0; _U1RXIE = 0; UARTEN = 0; BuildWaveform(); _OERR = 0; _U1RXIF = 0; _ENARTEN = 1; _U1RXIE = 1; _DAC1LIE = 1; Then i went to the UART interrupt and changed this so it wont hang : data = U1RXREG; if( !_FERR ) { // handle data } // changed into this : if( !_FERR ) { data = U1RXREG; // handle data } Only that is no good, other problems arise. Maybe someone has a clue on what can be wrong ? And what is a framing error exact ?, can there be a framing error without missing data ? thanks in advance 
0
|
|
相关推荐
19个回答
|
|
|
顺便说一下，我把我的UART代码放在某个地方，只是我找不到它，如果我点击论坛简介，我只看到最新的东西，而不是2岁的东西。有人知道如何找到旧的帖子吗？
以上来自于百度翻译 以下为原文 By the way i posted my UART code somewhere only i can not find it back, if i click on forum profile i only see the most recent things, not 2 year old stuff. Anyone knows how to find old posts ? |
|
|
|
|
|
“帧错误”基本上是一个丢失的停止位（而不是在停止BOT时隙中接收到1, 0）。如果波特率很好，通常不会出现问题。当发送器发送“中断”时故意引起。
以上来自于百度翻译 以下为原文 "Framing error" is basically a missing stop bit (instead of 1, 0 is received during the stop bot time slot). Usually no issue if baud rate is fine. Intentionally raised when a transmitter sends a "break". |
|
|
|
|
|
如果获得框架错误，则不能保证UART RX缓冲区中的数据是有效的。帧错误表示从开始位到停止位的一个“帧”数据的时间与UART所期望的不一致。这通常是由不匹配的波特率引起的。框架错误也可能发生在两个串行设备之间没有共同点，或者串行线路上的噪声。禁用UART，然后在串行数据流的中间重新启用几乎肯定会给您一个框架错误。有没有一个特定的原因，你不能让UART中断启用DurnBug波形？如果您需要禁用UART，则可能需要有一种方法来告诉串行流停止，然后一旦您准备接收更多数据，流量就再次开始。
以上来自于百度翻译 以下为原文 If you get a Framing Error there's no guarantee that the data in the UART RX buffer is valid. A framing error denotes that the amount of time for one "Frame" of data from start bit to stop bit did not line up with what the UART was expecting. This is usually caused by a mismatched baud rate. Framing errors can also occur from not having a common ground between the two serial devices, or noise on the serial line. Disabling the UART, then re-enabling in the middle of a stream of serial data coming in will almost certainly give you a framing error. Is there a specific reason you can't have the UART interrupt enabled during BuildWaveform? You may need to have a way to tell the serial stream to stop while you are processing data if you need to disable the UART, then have traffic begin again once you are ready to receive more data. |
|
|
|
|
|
问题是我为什么放弃UART：假设更多的相同的“构建波形”命令进来，而波形仍然在处理，最终用户只会越来越多地调整那个按钮，同时必须等待更长和更长的时间。
以上来自于百度翻译 以下为原文 The problem is why i di***le UART is : suppose more of the same "build waveform" commands are coming in while the waveform is still processing, the end user will only tweak that button more and more, meanwhile have to wait longer and longer. |
|
|
|
|
|
这是相关的HTTP://www. McCHIP.COM/FUMMS/FANDPOST/885656显示在谷歌搜索中吗？
以上来自于百度翻译 以下为原文 Is this related http://www.microchip.com/forums/FindPost/888856 Shows up in google search |
|
|
|
|
|
|
|
|
|
|
|
如果是这样的话，也许你可以建立一个消息队列来接收在忙的时候接收到的串行消息，并在前一个“构建波形”命令完成时处理它们，或者替换UART继续，但是在构建波形激活时不接受任何额外的命令。可以在构建波形被调用时设置一个标志，并在完成时清除。虽然这个标志被设置只是忽略传入字节。类似的是：这样一来，你将永远不必禁用UART，并可以简单地恢复处理传入字节一旦构建波形完成。
以上来自于百度翻译 以下为原文 If that's the case maybe you could possibly build up a message queue to take in serial messages received while busy and process them when the previous "build waveform" command has finished, or alternatively keep the UART on, but don't accept any additional commands while BuildWaveform is active. Could be done with a flag that sets when BuildWaveform is called and clears when finished. While this flag is set just ignore incoming bytes. Something like: while (U1STAbits.URXDA){ //While there is data in RX Buffer c_in=U1RXREG if (Waveform_Building){ //Do nothing with c_in data byte } else { //Process c_in data byte normally } } This way you would never have to disable the UART and can simply resume processing incoming bytes once BuildWaveform finishes. |
|
|
|
|
|
也许如果用户要求建立一个新的波形，你应该中止建立旧的波形，并开始建立新的波形。
以上来自于百度翻译 以下为原文 Perhaps if a user requested to build a new waveform, you should abort building the old waveform and begin building the new one. |
|
|
|
|
|
好的，我已经有一个队列，UART把命令放在一个循环缓冲器中，主循环处理来自循环缓冲器的这些命令，主回路正在构建波形。主循环不知道是否有新的消息，直到它完成波形生成，我不想在U中实现。艺术中断更多的代码来解决这个问题，这个芯片被编程到速度限制。我只想在UART上毫不费力地模仿，为什么不可能呢？
以上来自于百度翻译 以下为原文 Ok, i have a queue already, the UART places the commands in a circular buffer, the main loop handles these commands from the circular buffer, the mainloop is building the waveform. The main loop dont see if there is a new message until it finished generating waveform, i dont want to implement in the UART interrupt more code to solve this, this chip is programmed to the speed limit. I just want to pauze the UART without trouble, why is it not possible ? |
|
|
|
|
|
禁用，特别是使UART异步通信链路是一个坏主意（FRR问题）。简单地禁用UART中断将导致ORRR -没有别的。（虽然UART RX中断不需要太多的时间。因此，允许UART在完成当前波形时跳过过时的缓冲项。
以上来自于百度翻译 以下为原文 Disabling and especially enabling the UART asynchonous to the communication link is a bad idea (FERR issue). Simply disabling the UART interrupt would result in OERR - nothing else. (Although UART RX interrupts should not take much time. So it might be acceptable to let the UART receive - skipping outdated buffer entries upon completion of the current waveform.) |
|
|
|
|
|
但是你总是可以自由地射入你自己的脚。
以上来自于百度翻译 以下为原文 But you are always free to shoot into your own foot. |
|
|
|
|
|
当你禁用UART，然后随机地把它放回，你可以在中间的一个字节。这就是为什么你会得到框架错误。如果这是你选择的解决方案，那么你需要在它的修复中编码。反正你应该处理这些错误。你当然可以在信息的中间。然后，你需要找到那个消息的结尾并丢弃它。
以上来自于百度翻译 以下为原文 When you disable the uart then randomly turn it back on you can end up in the middle of a byte. That is why you are getting a framing error. If that is the solution you chose then you need to code in the fix for it. You should be handling the errors anyway. You could of course be in the middle of a message. You would then need to find the end of that message and discard it. |
|
|
|
|
|
问题是，如果我改变这个代码，它不会挂起：在这个CODESO中，UART的东西中一定有东西让它起作用。
以上来自于百度翻译 以下为原文 The thing is that it dont hangs if i change this code : void __attribute__ ((interrupt, no_auto_psv)) _U2RXInterrupt(void) { if( U1STAbits.OERR ) { U1STAbits.OERR = 0; }else while( U1STAbits.URXDA ) { if( !U1STAbits.FERR ) { data = U1RXREG; } } IFS1bits.U1RXIF = 0; } into this code void __attribute__ ((interrupt, no_auto_psv)) _U2RXInterrupt(void) { if( U1STAbits.OERR ) { U1STAbits.OERR = 0; }else while( U1STAbits.URXDA ) { data = U1RXREG; if( !U1STAbits.FERR ) { } } IFS1bits.U1RXIF = 0; } So there must be something in the UART stuff to make it work. |
|
|
|
|
|
你应该仔细检查代码。您正在读取UART2，但是检查UART1的错误标志位。[编辑：OP修正粘贴代码问题]第一个代码挂起框架错误，因为当出现帧错误时，您不读取RXReg。你只在费尔＝0时才阅读。UrxDA永远不会低，打破你从循环，因为你从来没有阅读RxReg当费尔= 1。当发生框架错误时，您仍然需要读取RXRG。理想情况下，你应该丢弃它，因为它可能是坏数据。
以上来自于百度翻译 以下为原文 That first code hangs up on the framing error because you aren't reading RXREG when a framing error occurs. You're only reading it when FERR == 0. URXDA will never go low and break you from the loop since you are never reading RXREG when FERR == 1. When a framing error occurs, you still need to read out of RXREG. Ideally you should then discard the it because it's likely bad data. |
|
|
|
|
|
|
|
|
|
|
|
你在中断中检查ORR，这意味着你希望中断会迟到。为什么？如果你的中断经常太晚，你可以接受，也许你根本不需要中断？关于费尔。忽略它们。帧错误不是字节错误的指示。也没有框架错误是保证字节是好的。
以上来自于百度翻译 以下为原文 You're checking for OERR in the interrupt - which means that you expect the interrupt to be late. Why? If your interrupt is often too late and you're Ok with this, perhaps you do not need an interrupt at all? About FERR. Just ignore them. Framing error is not an indication that the byte was bad. Nor the absence of the framing error is a guarantee that the byte was good. |
|
|
|
|
|
你能为我详细说明一下吗？我知道没有一个框架错误不需要表示一个有效的字节的数据，一大堆其他事情可能出错，而不是框架错误。我一直认为，框架错误是我应该处理的东西，扔掉产生问题的字节，因为（在我承认有限的经验），它总是波特率失配或我带来了UART在传入的传输。在这两种情况下，缓冲区中的字节对我来说都是不好用的。正如前面提到的那样，一个“中断”会有意引起一个帧错误，但我从来没有真正用过它。
以上来自于百度翻译 以下为原文 Can you elaborate on this for me? I understand the absence of a framing error doesn't necessary denote a valid byte of data, a whole slew of other things can go wrong that aren't framing errors. I had always been under the impression that a Framing Error is something I should handle by throwing out the byte that generated the problem because (in my admittedly limited experience) it's always been a baud rate mismatch or me having brought the UART up during an incoming transmission. In either case the byte in the buffer is no good for me to use. As was noted earlier in the thread, a "Break" will raise a framing error intentionally, but I've never actually used it for that purpose. |
|
|
|
|
|
他所说的是，一个具有框架错误的字节是可能的。框架是关于停止位。我个人会扔它，对待整个包坏。你真的应该只看到他们很少。
以上来自于百度翻译 以下为原文 What he is saying is that it is possible for a byte with a framing error to be good. The Framing is about the stop bit. Personally I would toss it and the treat the entire packet as bad. You really should only see them rarely. |
|
|
|
|
|
是的，我正在检查中断中的ORR，如果有ORR，UART需要重置，将ORR设置为0，此时我也重置所有MIDI，清除循环缓冲器。如果我删除ORR，如果它溢出，它将不会再次启动。更高的优先级。对于FRR，我认为你是正确的NordGee，我会删除它，看看会发生什么，忽略所有的帧错误。（包=当前字节i假设）丢弃不是读取字符，还是读取字符而不使用字符？也许所有的方面都需要被模拟来找出。然后我有一个问题：清除ORR位只做一些事情，如果它以前是1，并且不能被设置然后清除。那么我如何才能清除接收缓冲区呢？
以上来自于百度翻译 以下为原文 Yes i am checking the OERR in the interrupt, if there is OERR the UART needs to be reset with setting OERR to 0 again, at this point i am also resetting all MIDI, clearing the circular buffers. What if i remove the OERR, then if it overflows it wont start again. The UART can be late because the DAC has higher priority. For the FERR i think you are right Northguy, i will remove it and see what happens, ignoring all framing errors. Treating the packet as bad is not the correct thing i noticed. ( packet = current byte i assume ) Discarding is not reading the character or is it reading the character and not using it ? Maybe all aspects need to be simulated to find out. Then i have this question : clearing the OERR bit only does something if it was 1 before, and cant be set then cleared. How could i clear the receive buffer then ? |
|
|
|
|
只有小组成员才能发言，加入小组>>
5238 浏览 9 评论
2028 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3204 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
777浏览 1评论
666浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
595浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
676浏览 0评论
576浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1139
评论
淘帖
1041
