完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
你好,我正在努力让PIC24EP512GU814设备上的UART发射机工作。我使用了一些代码,这些代码是在PIC 18上运行的一个以前的项目移植的,所以代码本身应该是全功能的。我很满意UART的RX部分运行良好,但Tx只是不想玩球。即使当我将数据加载到TXRG中时,TrMT位也总是被设置。当我启用模块时,中断标志被设置,但是一旦我清除它,它就不会重置。我没有看到任何传输的数据。我已经修改了代码,尝试使用一个备用UART,但是它对操作没有任何影响。我已经着手具体地设置模式和状态寄存器中的每一位,以防万一。我看了勘误表。我故意尝试启用、禁用和重新启用UART,以防万一复位时出现问题。我现在有点失落。谁能看清做错了什么?影响UART的代码部分如下。我必须键入它们,以原谅任何可能的TypPrimalIsAcsidio代码来开始传输中断。
以上来自于百度翻译 以下为原文 Hi All. I'm struggling to get the UART transmitters on the PIC24EP512GU814 device to operate. I'm using some code that's been ported form a previous project that ran on a PIC 18 so know that the code itself should be fully functional. I'm content that the Rx section of the UART is operating fine, but the Tx just doesn't want to play ball. The TRMT bit is always set even when I've loaded data into the TXREG. The interrupt flag is being set when i enable the module but once I've cleared it it never resets. and I'm not seeing any transmitted data. I've altered the code to try using a spare UART but it's had absolutely no effect on the operation. I've gone to the point of specifically setting every bit in the mode and status registers just in case. I've looked at the errata. I've deliberately tried enabling, disabling and re-enabling the UART just in case it was problem on Reset. and I'm now at a totl loss. can anybody see what's been done wrong? The sections of code that affect the UART are as follows. I've had to type them in to please forgive any possible typos Initialisation __builtin_write_OSCCONL(0); RPINR27bits.U3RXR = 127; RPOR15bits.RP126R = 0x1B; __builtin_write_OSSCONL(0x40); U3MODEbits.BRGH = 0; U3MODEbits.STSEL = 0; U3MODEbits.PDSEL = 0; U3MODEbits.IREN = 0; U3MODEbits.UEN = 0; U3MODEbits.LPBACK = 0; U3MODEbits.ABAUD = 0; U3MODEbits.URXINV = 0; U3STAbits.UTXISEL1 = 0; U3STAbits.UTXISEL0 = 0; U3STAbits.UTXINV = 0; U3STAbits.URXISEL = 0; U3STAbits.ADDEN = 0; U3BRG = 63; IFS5bits.U3RXIF = 0; IEC5bits.U3RXIE = 1; //enable U3MODEbits.UARTEN = 1; U3STAbits.UTXEN = 1; Code to begin a transmission //message and system initialisation code //wait for reception of the status via UART Rx while ((RxStatus & 0x01) == 1); //send the first byte U3TXREG = txFrameData[0]; //wait for the Tx to finish while(U3STAbits.TRMT == 0); txRequestPin = 1; //enable the Interrupt and let the ISR do the work now the timing critical phase is over IEC5bits.U3TXIE = 1; Interrupt void TxISR(void) { U3TXREG = txFrameData[txFrameRead]; if (txFrameRead == txFrameWrite) { //last byte has been sent IEC5bits.U3TXIE = 0; txFrameRead = 0; } else txFrameRead++; } void __attribute__ ((__interrupt__, auto_psv)) _U3TXInterrupt (void) { TxISR(); IFS5bits.U3TXIF = 0; } Cheers Russell |
|
相关推荐
5个回答
|
|
如果无效TxISR(空)是一个中断处理程序,您可能需要一些属性。
以上来自于百度翻译 以下为原文 If void TxISR(void) is an interrupt handler, you may need some attribute(s) to it. Also, who is setting txFrameRead and txFrameWrite? |
|
|
|
感谢DarioTxISR是原来的功能,是在原来的PIC 18,它使用不同的中断架构到PIC 24。当移植时,这样做的家伙决定从专用的U3TxBuffic函数(在中断代码块的底部给出)调用原始函数,该函数具有适当的属性,而不是重命名原来的中断函数。我不知道WH.TXFRAMEAD/Wrad是与软件缓冲区相对位置的缓冲指针。它们都是正确的。由于代码是从工作代码移植的,所以没有理由假定这样的事情在任何时候都是不正确的。我已经检查过,因为这已经证明是如此混乱,什么是错了。再次如在OP中说,中断被称为一次ISR启用后,第一次消息发送代码被调用,但再也没有我没有说的是中断启用左设置,因此可能是一个康福锡安。读指针以预期的方式保留在2,写在预期消息的6处。
以上来自于百度翻译 以下为原文 Thanks Dario TxISR is the original function that was used on the original PIC 18, which uses a different interrupt architecture to PIC 24. When ported the guy who did so decided to call the original function from the dedicated U3TXInterrupt function (given at the bottom of the interrupt code block) which has the appropriate attributes rather than rename the original interrupt function. I don't know why. txFrameRead/Write are buffer pointers to relative positions with the software buffer. They are all correct. As the code has been ported from working code there is no reason to assume that things like this are incorrect at any point. I have however checked as this has proved so confusing as to what's gone wrong. Again as said in the OP the interrupt is called once after the ISR is enabled the first time the message send code is called but never again what I didn't say is that interrupt enable is left set so that might be a confusion. The read pointer is left at 2 as expected and write is at 6 as would be expected for the message being sent. Regards Russell |
|
|
|
我明白了,奇怪的是,如果你在主循环中重新启用U3TXEY,只是为了测试?
以上来自于百度翻译 以下为原文 I see, strange then. What if you reenable U3TXIE in your main loop, just to test? |
|
|
|
是奇怪的,无论如何…回答你的问题。幸运的是,我有一个阻塞代码,测试是否在新的插入Tx缓冲区之前发送了一条消息。我已经修改了它,使中断设置在一到三次之间。ISR总是被调用一次多于我的代码设置标志的次数(正如从上面所示的症状预期的那样),因为ISR被调用,我不认为这是编译器问题。U3/U1 TXIF被设置为一个模块上下的电源。作为另一个测试,我设置了一个调试代码,在该代码中尽可能快地加载一个循环中的TXReg,在U3STA中搜索缓冲区满标志。我把断点放在一点,因为它被封锁了。完全出乎意料的是,它被阻塞了,表明事情比我在OP中给出的要好得多。我认为这一点的混乱似乎是调试器监视只在变量被访问或断点时更新,所以TRMT在我通过COD时已经过时了。当我跨过代码时,E已经过时了。看来,唯一的问题是在这种情况下使用ISR。
以上来自于百度翻译 以下为原文 Yep strange indeed. any way.... to answer you question. As luck would have it i have piece of blocking code that tests to see if a message has been sent before a new one gets inserted into the Tx buffers. I've modified this to make it set the Interrupt flat between one and three times. The ISR was always called once more than the number of times my code set the flag (as would be expected from the symptoms shown above) As the ISR is being called i don't think this is a compiler issue. The U3 / U1 TXIF is being set and cleared as a power the module up and down. As another test I put a piece of debug code in which loaded the TXREG in a loop as fast as it could go, polling the buffer full flag in U3STA. I put a break point in at the point were it blocked. To my complete surprise it blocked indicating that the things were working better than I'd given in my OP. I think the confusion on this would appear to be that the debugger watches are only updated if the variable is accessed or on a break point so TRMT was out of date as I stepped through the code out of date as I stepped through the code. It would appear that the only problem is to do with the ISR in that case. |
|
|
|
达里奥,我想把这封信关掉,最终我发现了错误。这是非常复杂的,所以我没有发现它。这是因为在ISR结束时中断中断标志,而不是在开始时是我的首选项。B TXIF只设置在传输到USRT移位寄存器上,而不是设置在缓冲区中真正的容量。因为ISR只加载一个字节i。NTO缓冲器(来自PIC18的遗产),这被立即转移到移位寄存器中,导致第二中断。然后,在ISR结束时,通过清除来清除中断,因为缓冲区中没有更多的数据能够被移位。一个简单的移动,故意填充缓冲器,直到完全解决。
以上来自于百度翻译 以下为原文 Dario, thought I'd close this one down. I found the fault, eventually. It was quite intricate, hence I hadn't spotted it. It was caused by two things A the clearing of the interrupt flag at the end of the ISR rather than at the beginning as is my preference. B the TxIF only being set on a transfer to the USRT shift register rather than if there was truly capacity in the buffer. As the ISR was only loading a single byte into the buffer (legacy from PIC18) this was being instantly transferred into the shift register causing a second interrupt. This was then being cleared by the clear at the end of the ISR preventing the interrupt re occurring as the was no more data in the buffer able to be shifted. a simple move around and deliberately filling the buffer until full solved it all. Thanks for the help Russell |
|
|
|
只有小组成员才能发言,加入小组>>
5162 浏览 9 评论
2000 浏览 8 评论
1928 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3172 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2226 浏览 5 评论
731浏览 1评论
613浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
503浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
629浏览 0评论
527浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-23 12:25 , Processed in 1.262242 second(s), Total 86, Slave 69 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号