Purging UART data in the receive buffer

[kgng97ccs]

I will be using a PIC18LF46K22 MCU, and CCS PCWHD compiler v5.078 on MPLAB IDE v8.92.

I am planning to do the following:

1. Set up an ISR to read data from UART1 and enable int_rda interrupt to receive the data [command: enable_interrupts(int_rda);].

2. After reading the expected number of bytes, disable int_rda interrupt and process the data [command: disable_interrupts(int_rda);].

Questions:
Q1. After disabling the int_rda interrupt, how can I purge whatever data (which might be noise) that might be in the receive buffer, so that I know I will be receiving new data when I re-enable the interrupt in step 3?
Q2. After disabling the int_rda interrupt, do I need to clear the interrupt flag, that is, issue a command “clear_interrupt(int_rda);”?

3. Re-enable int_rda interrupt to receive new data only after the processing is complete [command: enable_interrupts(int_rda);].

I will appreciate any advice or suggestion. Thank you.

[Ttelmah]

Yes, and partially yes.

All you do is read the serial, while there is data.
So:

[kgng97ccs]

Thank you, Ttelmah, for the code.

Is it correct that this "wake_uart()" function will affect both UART1 and UART2?

If I wish to do this data flushing only for UART1, is that possible?

[PrinceNai]

One question: what if you happen to process your data and re-enable interrupt right when new data is already coming in? In that case you'd have noise in your buffer anyway. Can you afford to loose it or are the messages repeated? How is the incoming data structured? Does it have some combination of characters that are always the same at the start?

[PrinceNai]

What I'm getting at is: why disabling serial interrupt at all? With let's say 20MHz clock one instruction takes 0,2us. Serial communication is much, much slower, by orders of magnitude. Maybe your incoming data is 8 bytes long, which would mean 206us at 38.400 for every byte or 2,1ms for the message (didn't go through Excel, just copied the data from a website). Then the messages aren't just following one another without a pause. If you compare instruction time with the message time, you have more than 10.000 machine cycles (minus the time you spend inside various interrupts) at your disposal to process the data. A lot.

[Ttelmah]

What is posted is only for UART1. You were referring to INT_RDA.
To make a version for UART2, you would have to create new byte and
bit defines for this.

Have to agree, just leav the UART enabled, and have a flag to say
to drop the data.

[PrinceNai]

Record new "good" data. Drop only if you are not finished with processing of the old, at the end of recording. Which would in any case mean either a too slow clock, some fault in the structure of the program or how it handles the data.

[PrinceNai]

All academic questions and answers, of course. If you need a specific answer, you need to show some code. What are you expecting to receive? How do you parse it? What has to be done when you get the correct message? Mr. Ttelmah gave you an answer of how to flush the buffer, but you needed it flushed for a reason.

[kgng97ccs]

Thank you, PrinceNai and Ttelmah, for your comments.

Here is my application:
1. A master processor transmits a few bytes of data to UART1 of PIC18LF46K22 (secondary processor) at intervals determined by the master processor. The number of bytes may vary from transmission to transmission (no fixed number or pattern).
2. Each time an incoming byte triggers a UART1 interrupt on the PIC18, the PIC18 reads the byte. The PIC18 then reads the next byte when the interrupt is triggered again, and so on.
3. A while(1) loop in the main() routine checks whether UART1 data is still coming in and whether it has reached a preset maximum number of bytes. Once the loop has determined that no more data is coming in or the maximum number of bytes has been reached, the UART1 interrupt is disabled, and the routine starts to process the data. The processing incudes checking the validity of the data.
4. Upon completing the processing, the UART1 interrupt flag is cleared and the UART1 interrupt is re-enabled to receive new data.

As PrinceNai has also suggested, there is always a chance that at the time the UART1 interrupt is re-enabled, there could be data that has already started coming in to UART1. If this happens, the data validity check later will eventually fail.

I am thinking that if I can totally clear the UART1 receive buffer and interrupt flag just before I re-enable the UART1 interrupt to receive new data, the chances of receiving old data waiting in the receive buffer of UART1 will be reduced. I am not sure whether this thinking is correct.

One reason I am thinking of flushing the receive buffer of just the UART1 is to provide for the possibility of using UART2 for purposes that may not need such flushing.

My current code, before incorporating Ttelmah’s suggested code, goes like this:

[Ttelmah]

Don't
Just have two buffers. Have the UART always receiving into the 'unused'
buffer. When the 'full' condition is met, switch buffers and tell the code
to interpret the data in the buffer that has just been used.

[PrinceNai]

I happen to have a similar project going on. The way I did it is a bit different, no delays anywhere, everything is taken care of inside RDA and TIMER0 interrupts. The idea is to record all incoming data into a buffer. When you detect the line is idle and data is in there, parse the data in the buffer anyway you want. It always starts at position 0 in the buffer. I don't know the frequency with which master sends data, but it can't be too fast, speaking in processor terms. I'm too lazy to change the names to your nomenclature, but you'll get the idea.

[PrinceNai]

Ttelmah, I wanted to say that there is the code with two buffers floating around, it was last posted like two months ago. I have a question: if parsing code isn't fast enough to process one buffer in time, won't that eventually catch also the second one?

[PrinceNai]

One thing to mention: if master doesn't output null at the end of transmission, you'll have to manually insert it in the buffer when you detect idle line to be able to use any string related functions. Otherwise you'll have garbage there.

[Ttelmah]

Given that serial is normally something like 1mSec/char, you have tens
of thousands of instruction times to parse each character.
I run parsers running at 250Kbaud and can still merrily keep up.

[kgng97ccs]

Thank you, Ttelmah and PrinceNai. I will study your suggestions and code. Really appreciate your help.