Mplab XC16 Pic24F Timer interrupt uart issue - Page 1
Forum section: electronics / general

author: mrcrud5
author_rank: Contributor
timestamp: November 08, 2022, 07:48:23 pm
content: Hey folks,So I'm using XC16 in Mplab, and am trying to get a PIC24FJ64GU202 to transmit some data over uart1 every time the timer 1 overflows. However before the data is sent, I'd like to create a break and pull the line low for 88uS before the data is sent. I've found I'm able to generate a break by setting the UTXBRK bit in the U1Status register.here is the the interrupt routine I'm using which generates the a break before the data is sent, however Its only 12 uart clock pulses long, so its only roughly 50uS long.void __attribute__ ((weak)) TMR1_CallBack(void){U1STAbits.UTXBRK=1; //breakUART1_Write(1);UART1_Write(2);UART1_Write(3);}I'm trying to figure out a way to increase the break length to 88uS. I've tried disabling the uart and manually toggling the pin and generating the correct delays(code below). This seems to work when I used it in the main program loop, but it doesn't seem to work when I try to use the same code in the interrupt sub routine. It compiles, but they delays aren't there at all.U1MODEbits.UARTEN = 0; // disabling UARTU1STAbits.UTXEN = 0;Uart1out= 1;__delay_ms(1);Uart1out= 0;__delay_us(88);Uart1out = 1;U1MODEbits.UARTEN = 1; // enabling UART ON bitU1STAbits.UTXEN = 1;UART1_Write(1);UART1_Write(2);UART1_Write(3);Could use some help. This is getting quick aggravating. Thanks!

author: JPortici
author_rank: Super Contributor
timestamp: November 08, 2022, 08:00:23 pm
content: Please use code tags to post codeAs you measured, the break is going to be 12 baud long, as it should (actually, is there an UART peripheral that lets you set the length of the break character?)I see no reason why the software delay shouldn't work, so there must be something else in the code you're not showing. Try and post a complete source file that demonstrate the issue

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 08, 2022, 09:15:29 pm
content: You should probably look at how these __delay_xx() functions are implemented. I think they are macros but I don't have a XC16 compiler installed at the moment so I can't check the exact definition. Could they be using Timer1?

author: JPortici
author_rank: Super Contributor
timestamp: November 08, 2022, 09:25:25 pm
content: IF he used the functions in libpic30.h AND defined FCY to the appropriate value before including libpic30.h, they are functions that implement cycle accurate delays using NOPs, no timer involved. Obviously they work inside ISRs so the problem is somewhere else in the code.

author: DavidAlfa
author_rank: Super Contributor
timestamp: November 09, 2022, 02:21:09 am
content: Use a local flag, load the timer counter so it overflows again in 88us.Use that flag to know whether to send data or break.Code:void __attribute__ ((weak)) TMR1_CallBack(void){static uint8_t send_brk=1;if (send_brk) {set_Timer1_counter(for_88us); // pseudo code, overflow in 88us from now.U1STAbits.UTXBRK=1; //breaksend_brk=0;}else {send_brk=1;UART1_Write(1);UART1_Write(2);UART1_Write(3);}}

author: mrcrud5
author_rank: Contributor
timestamp: November 10, 2022, 07:36:56 pm
content: You we're totally correct. The issue wasn't the delay itself, but the speed I was sending data to the transmit register, while doing a bunch of other things. Fixed the issue by implementing a transmit buffer.Thanks for the help folks!