What triggers a UART data overrun

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to figure out how much data I can feed into a micro-controller before I need to start worrying about flow control. I'm using an ATMEGA324A, which has a "Data Overrun" bit in the control and status register, but I don't understand when it is set. The datasheet says

Quote:
This bit is set if a Data OverRun condition is detected. A Data OverRun occurs when the receive
buffer is full (two characters), it is a new character waiting in the Receive Shift Register, and a new start bit is detected. This bit is valid until the receive buffer (UDRn) is read.

I've underlined the sentence that is giving me trouble. In particular the "it is" doesn't make any sense to me. If I were to make it "there is" (or just remove the "it is") I can make sense of the sentence. It would say that if I was transmitting data to the micro-controller without ever reading UDR then I would expect the chain of events to look like this:
1) The first byte is received and put into the buffer (UDR)
2) The 2nd byte is received and put into the buffer (UDR, but inaccessible in the FIFO till byte 1 is read)
3) The 3rd byte is received and stays in the receive shift register.
4) The start bit of the 4th byte triggers the data overrun condition.

Is that what happens? If you start with an empty buffer it's the start of the 4th byte that triggers the overrun?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my mind, it is not important how many bytes are stored where. The important thing is that it has run out of hardware buffer space. In turn, this says, that your code is waiting too long to read it.

My rule of thumb is to receive the character and copy to my own buffer before the next one is even close to its stop bit. The only way I see to get into the problem you describe is either (1) spend waaaaay too much time in an ISR somewhere, or (2) trying to handle data at the absolute fastest speed. Neither is very desirable.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lets say you are receiving chars at 115200bps... 83usec per char. You have two arrays... you fill one while processing the other. If the array is 100 chars, a buffer fills up every 8.3ms. That's how long you have to read the other buffer full and do whatever with it. So the idea is you can receive data seamlessly if you have two buffers and they are big enough to hold the chars per sec you are receiving. No flow control needed. But we can give xon xoff examples if you want...

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

another stab at it...
The hardware UART accepts a byte and signals it is ready to be retrievied - by setting a flag and/or causing an interrupt.
If the CPU does not retrieve that byte before n more bytes arrive, there is a data overrun error. The number n depends on the kind of UART. Older microprocessors have n=1, meaning 2 bytes can be held in hardware. Newer microprocessors, and all PCs dating back many years, have a FIFO on the UART, normally such that n=15, and the 16th byte is the one that can be retrieved. But that FIFO mode can be disabled.

This applies in reverse to the UART transmit as well. In such microprocessors- I fill the transmitter FIFO so that the transmit interrupt can occur every 16 bytes rather than every one byte. This helps reduce overhead for high baud rates, and minimizes the affect of interrupt latency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the other end of you connection is a Windows machine with a DMA UART even flow control may not be much help. It can queue up so much information that even if you send an XOFF after the first received character, it may still have a huge amount of data to transmit before it can stop the DMA engine. DMA UARTS are tricky when it comes to file transfers.

"Brother -- Ima hear ta testify!!"

We never have time to do it right,
but we always have time to do it over

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah, XOFF is not as useful as RTS/CTS in hardware.