Interrupt driven UART

This might work, but imagine what would happen if a byte is received on the uart while your code happens to be doing something else then calling the uart_receive function ? Instead of having only one 'global rx variable', consider using a ringbuffer aka 'circular buffer' aka fifo for this. The RX interrupt stores incoming bytes into the buffer and updates the head and tail pointers, while your uart_receive function reads one byte from the buffer, or - if the buffer is empty - waits until new data comes available.

--
:wq
^X^Cy^K^X^C^C^C^C

Thanks. I hadn't thought of that case since I'm only running the UART at 9600bps, but I guess better safe than sorry. To implement the fifo, wouldn't I need to either make a linked list and malloc/free in the ISR, or use a fixed array but with compression? Either way it seems like a lot of clock cycles will be taken up in the ISR trying to manage the FIFO, and I'm concerned with the timing of things due to these clock cycles used.

Hmm disregard my previous message. I think I know what you mean. I think I can implement the fifo with a fixed array size of n, and a head and tail index rather than pointer(both initialized to 0). The rx isr will move a byte from the rxbuffer to the fifo head, increment the head(wrapping back to 0 when head == n) and set the global rx ready flag, and the receivebyte function will simply wait for the rx ready flag set by the ISR, then move a byte from the the fifo tail to a local variable, and increment the tail(wrapping too). Makes sense?

arg, just realized after i hit the "post" button that this might not work if an rx interrupt occurs between the time the receivebyte function checks for the rx ready flag, and the time where it clears the flag. if it happens the be the last byte received in that time period, then the receivebyte will hang there since it has cleared the flag while the fifo is still not empty. Instead, I think a better check would be to compare the head and tail pointers, and if they're not the same then there's something in the fifo. so the psuedo code looks something like this

isr() { fifo[tail++] = rxbuffer; if (tail == buflen) tail = 0; }

receivebyte() while(head == tail); byte = fifo[head++] if (head == buflen) head = 0; return byte; }

This is probably not good enough, because you need to know both when the buffer is non-empty and when the buffer is full. The full condition is used to make a decision on how to proceed when an interrupt occurs, which may be either to discard the oldest or to discard the newest, while setting an overrun flag to signify data lost. With read and write indices into a single buffer you can decide this with modulo arithmetic, i.e. buffer empty corresponds to indices equal, and buffer full corresponds to write index one less than read index. With pointers the modulo arithmetic on the difference becomes harder.

--
 Some informative links:

Not really.

The two error situations with a ring buffer without critical section is that you get a premature "buffer full" when writing to the buffer, when there actually was one free byte in buffer (=extend the buffer by one byte) or you get "buffer empty", when actually one more byte would be available (=in a polling system read the byte at next poll).

This is valid for buffers less than 256 bytes for 8 bit data bus systems and 64 KiB buffers in 16 bit data bus systems.

Paul

or -

That's the general scheme. There are a few details to consider:

1. why not keep a counter of the bytes in the queue rather than a simple flag. That way, if your main application goes away for a long time, it can note that there are many byte in the buffer, rather than just an indication that one or more bytes are available.

1. You may need to keep track of the possibility of queue overflow.

2. An oft-used trick for circular buffers is to make the buffer length an exact power of two. Then you can skip the wraparound test and simply mask the index with an appropriate value to accomplish the wraparound.

#define BUFFERLENGTH 64

unsigned char buffer[BUFFERLENGTH]; short bufInputIndex, bufInputAvailable; // // add character to buffer and wrap as required buffer[bufInputIndex++] = ch; bufInputAvailable++; bufInputIndex &= (BUFFERLENGTH-1); // masking handles wrap

You can find the source code for a ring buffer, interrupt driven, serial handler at

Look for the U4SCFX library link. The code is for an M68K system, but the source is pretty generic C.

Mark Borgerson

ch

he

the

le',

e RX

d tail

er, or -

hadn't thought of that case since I'm only running the UART

Ico is right thats the way to do it. Email me and I'll send you some code to show you how.

tail

or -

1/2) Point taken, but at 9600bps and the amount of data that I intend to send, I don't think queue overflow is going to be a big problem, if at all. Still, it's good practice to handle any possible errors. I'll probably do that. 3) Makes sense. I don't know why I didn't think of the powers of 2 solution. Anyway, if I set my buflen to 256 and set the index to unsigned char, I wouldn't even need do any wraparound check would I? It'd automatically wrap :)

Hmm, error checking gets complicated though because the receive buffer is structured as a double buffer. buffer1 gets pumped into buffer2 when all 8bits are received, and this also generates the interrupt. A buffer overrun occurs(and appropriate status bit set in status register) when buffer2 isn't read by the isr before all 8 bits of buffer1 are received. only buffer2 is accessible.

So there seems to be a couple of errors I have to take care of

1) buffer overrun 2) parity error 3) frame error 4) fifo overrun error

The first 3 I can check by cpu status bits, and the 4th one I can check by comparing indices, but I'm not sure of the order to check them, how to organize them, and how to handle them(discarding newest and requesting for a retransmit?). Here's how I was doing it in my receive isr:

fifo(tail++) = buffer2; tail&= buflen - 1; errFlag = statusregister & mask // check for framing/parity/overrun error if (errFlag != 0) { // error // pulldown I/O line to signal error and request retransmission }

I'm wondering how the retransmission will occur. Should I have a while loop that keeps looping within the isr to wait for the retransmission or should i exit the isr and reenter? And then there's the fifo overrun error case, not sure how to integrate that in either.

the

RX

tail

buffer, or -

If your processor has 16 or 32-bit registers, it will probably do a masking operation after the increment in any case. It will just be hidden from you by the compiler.

Mark Borgerson

I wouldn't wait inside the interrupt routine for the retransmission. You don't know how long that will take. It will be at least one character time, though. You probably don't want to wait in the interrupt routine that long.

Mark Borgerson

So how about this pseudocode in my ISR then

if (tail+1 == head) { // fifo overflow! overflow_flag = 1; // disable UART RX here and handle retransmission junk = (unsigned char) buffer2; // clears buffer2 // enable RX here } else { // no fifo overflow! // check parity error from status reg here if (parity_error) { // disable RX here and handle retransmission junk = (unsigned char) buffer2; // clears buffer2 // enable RX here } else { fifo[Tail++] = (unsigned char) buffer2; Tail &= BUFFLEN - 1; // handles wraparound } }

head

local

At first glance it looks OK to me. Just remember to decide whether 'tail' starts with an upper or lower case 'T'! ;-)

The devil will be in the details of "disable RX here and handle retransmission"

I have also found it instructive to increment an error counter for each type of error. They can be very handy if you have to try to diagnose line and communications problems.

Another thing to watch out for is how the UART handles break signals.

Mark Borgerson

head

isr

ready

local

the

period,

the

Thanks...

Since I'll be emulating iso7816 over UART, my retransmission handling will consist of pulling the TX line low for 1 bit period during the 2 stop bits to indicate to the smart card an error and request for a retransmission.

What do you mean by break signals though?

Another thing I'm not too sure of - my MCU provides 2 interrupt vectors for the handling of UARTs - INTTX and INTRX. INTTX occurs when the buffer has been sent, right after the parity bit, and INTRX occurs when the buffer has been received, right before the parity bit. There is also a control register bit that enables or disables receiving. I didn't see much elaboration on that in the datasheet, but I'm assuming that it enables/disables the receiving into the 2 rx buffers of the MCU. Currently in my sendbyte and receivebyte functions as well as ISRs, I'm not actually turning the interrupts on and off, i.e. the interrupts are always enabled. I do however disable the receive bit when I'm handling retransmission and enable it again afterwards. I don't suppose this would be a problem right?

I

a head

rx isr

the

ready

ready

a local

not

clears the

period,

the

The BREAK signal is a signal that stays in the start bit state for several character times. Some systems use it for resynchronizing or interrupting transmissions. Many standard UARTS will detect this condition and set a flag in the status register.

Since you had to ask, I assume that you don't have to worry about it in your system.

That depends on what is happening on the other end of the link. If it can be sending at any time you are likely to get an error character if you turn on your receiver when the other end is in the middle of a transmisssion.

Turning off your transmitter can also be dangerous. You need to make sure that you don't turn it off until the terminating parity bit of your last output character is complete.

I would probably leave the transmitter and receiver on all the time. That way you won't miss characters and you won't mess up your output.

I must have missed the type of link you are using. Is it only half-duplex? Can you not have the transmitter and receiver enabled at the same time?

Mark Borgerson

mean. I

and a head

rx isr

the

ready

ready

to a local

not

clears the

period,

flag

check

not the

buffer

when

buffer

when

check

how

receive

while

overrun

Sorry for not stating it earlier. I'm actually emulating the ISO7816 smart card interface, so it will be half duplex, so like you said I will probably leave the TX and RX on all the time since they will never clash.

On 17/10/2006 the venerable snipped-for-privacy@gmail.com etched in runes:

. . .

Be careful as this code may fail in two places:

if(tail+1 == head)

will not work when 'head' is less than 'tail'. That situation will arise as soon as the buffer wraps around.

tail &= BUFFLEN - 1;

will only work if BUFFLEN is a power of 2. For example it will fail if BUFFLEN is 10.

--
John B

Hi John,

I don't really get you on your first point. fyi I'm adding to the tail of the fifo and removing from the head of the fifo. The tail naturally has to wrap around for an overflow to occur. For example, if head is say 5 and the tail wraps around back to 0 and then to 4, then this would indicated a fifo overflow since there are no more available spaces in the fifo to add to. You do bring up a good point about overflow though, and my tail+1 doesn't take into account of that, since if my tail is the sizeof of the fifo then tail+1 wouldn't wrap back to

1. I'll have to take care of that.

Anyway, I do realize that BUFFLEN has to be a power of 2. The idea was suggested by another member in an earlier post, but thanks for reminding me of the wonders of powers of 2 arithmetic :)