Re: Interrupt driven UART


Ico wrote:
goister@xxxxxxxxx <goister@xxxxxxxxx> wrote:
Hi,
I'm working with a Toshiba TMP91 series MCU that doesn't seem to have
any UART control/status bits to check for empty data register, rx/tx
ready, etc, but does have interrupt vectors for serial tx and rx, which
is why I think I have to use interrupt driven UART rather than polling
it.

I have functions that expect to receive and send a single byte by
calling receivebyte and sendbyte functions. However, since it's
interrupt based, receivebyte seems to be pretty redundant. What I have
now is a UART receive ISR that first does error checking, then copies
the rx buffer to a global rx byte variable, and setting a global
rx_ready flag to 1. Then my receivebyte function does nothing until the
rx ready flag is set, after which it just clears it. Does this make
sense?

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.


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?

.

Relevant Pages

  • Re: Interrupt driven UART
    ... is why I think I have to use interrupt driven UART rather than polling ... receivebyte seems to be pretty redundant. ... rx ready flag is set, after which it just clears it. ... consider using a ringbuffer aka 'circular buffer' aka fifo for this. ...
    (comp.arch.embedded)
  • Re: Interrupt driven UART
    ... is why I think I have to use interrupt driven UART rather than polling ... receivebyte seems to be pretty redundant. ... rx ready flag is set, after which it just clears it. ... consider using a ringbuffer aka 'circular buffer' aka fifo for this. ...
    (comp.arch.embedded)
  • Re: Interrupt driven UART
    ... is why I think I have to use interrupt driven UART rather than polling ... receivebyte seems to be pretty redundant. ... rx ready flag is set, after which it just clears it. ... consider using a ringbuffer aka 'circular buffer' aka fifo for this. ...
    (comp.arch.embedded)
  • Re: Interrupt driven UART
    ... is why I think I have to use interrupt driven UART rather than polling ... receivebyte seems to be pretty redundant. ... consider using a ringbuffer aka 'circular buffer' aka fifo for this. ...
    (comp.arch.embedded)
  • Re: Linux serial port dropping bytes
    ... UART is on a slow bus, you should be able to read out characters ... interrupt itself - context switches, cache misses, etc. That's ... why you use a UART with a buffer - it takes virtually the same ...
    (comp.arch.embedded)