UART001 Interrupt Delay

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
I tried the APP UART001 (19200 baud, Full Duplex, One Stop bit) with "Standard Receive Interrupt" (tried others as well - same result) and it seems that I get the interrupt too early.

Example: I send the message "12\n" (3 characters) and I receive 3 interrupt signals (correct). But I read the 3 characters "(NUL)12". When I send another 3 characters "34\n" afterwards I receive "\n34" where I saw that the "\n" ist the missing one from the first transfer which was remaining in the buffer. With some trials I saw that the first interrupt reads before the character seems available while all subsequent characters are read with the interrupt of the subsequent character. At least that's how I interpret my results.

The present workaround is a "delay" via "for" at the beginning of the interrupt handler - this works but this is not how I like it to be (see code). The Getflag/Clearflag commands don't change anything:

void ReceiveInterrupt()

{

for (j=0; j<2500; j++) // 2500 set by trial and error, not calculated
{x = x+1;
}


while(!(UART001_GetFlagStatus(&UART001_Handle0,UART001_RECV_IND_FLAG)))
{}

Data1 = UART001_ReadData(UART001_Handle0);


UART001_ClearFlag(&UART001_Handle0,UART001_RECV_IND_FLAG);

...aso


Is there any setting which makes the interrupt fire at the right time? Or is there anything wrong with the code?
0 Likes
1 Reply
oreste
Employee
Employee
Welcome! 50 replies posted 25 replies posted
Josimar wrote:
I tried the APP UART001 (19200 baud, Full Duplex, One Stop bit) with "Standard Receive Interrupt" (tried others as well - same result) and it seems that I get the interrupt too early.

Example: I send the message "12\n" (3 characters) and I receive 3 interrupt signals (correct). But I read the 3 characters "(NUL)12". When I send another 3 characters "34\n" afterwards I receive "\n34" where I saw that the "\n" ist the missing one from the first transfer which was remaining in the buffer. With some trials I saw that the first interrupt reads before the character seems available while all subsequent characters are read with the interrupt of the subsequent character. At least that's how I interpret my results.

The present workaround is a "delay" via "for" at the beginning of the interrupt handler - this works but this is not how I like it to be (see code). The Getflag/Clearflag commands don't change anything:

void ReceiveInterrupt()

{

for (j=0; j<2500; j++) // 2500 set by trial and error, not calculated
{x = x+1;
}


while(!(UART001_GetFlagStatus(&UART001_Handle0,UART001_RECV_IND_FLAG)))
{}

Data1 = UART001_ReadData(UART001_Handle0);


UART001_ClearFlag(&UART001_Handle0,UART001_RECV_IND_FLAG);

...aso


Is there any setting which makes the interrupt fire at the right time? Or is there anything wrong with the code?



Hi,
you problem is related to the fact that you are using the wrong interrupt events
You shall use Buffere Receive Interrupts.
This app is using the buffer (FIFO) and you get this interrupt as soon as the data in the FIFO is going to exceed the configured trigger limit (in case of receive viceversa for transmit).
You can have more details from the tooltip on trigger limit parameters.

UART001_Example3 is a very good example for receive and transmit data using interrupt routine.
You can download examples by following procedure:
Help -> Install Apps/Example Libraries
Select Dave Project Library Manager as Dave site.


The other UART interrupts are provided in case the user would liek to use different fucntionality of the USIC channel accessing the reigister at low level e..g


UART001_Handle1.UartRegs->CCFG

He can implement or use functionality not provided in this simple app but still using the connectivity configuration of Dave.

I hope this will answer to all your question.
Best Regards
Oreste Bernardi

0 Likes