Why does the delay between bytes increase when I increase UART baud rate?

Question

Something interesting to note, which I am not fully understanding. My UART is initialized with 9600 baud. I've looked at the TX on the line via logic analyzer, and the bytes I send have minimal delay. It is 36µs per byte, which is expected.

Now, if I initialize that UART with a different baud rate, say 115,200, the delay between each byte sent increases significantly. It jumps to 125µs per byte.

This is causing a problem, since I've got to increase my baud rate at some point, but have a time constraint on my response.

Shouldn't the delay decrease between bytes, since it should be sending more bits at the same frequency?

This blocking method is for writing to the UART.

static inline void uart2_putchar(uint8_t data)
{
    // Disable interrupts to get exclusive access to ring_buffer_out.
    cli();
    if (ring_buffer_is_empty(&ring_buffer_out2)) {
        // First data in buffer, enable data ready interrupt
        UCSR2B |=  (1 << UDRIE2);
    }
    // Put data in buffer
    ring_buffer_put(&ring_buffer_out2, data);

    // Re-enable interrupts
    sei();
}

Which is triggered based on an interrupt.

ISR(USART2_UDRE_vect)
{
    // if there is data in the ring buffer, fetch it and send it
    if (!ring_buffer_is_empty(&ring_buffer_out2)) {
        UDR2 = ring_buffer_get(&ring_buffer_out2);
    }
    else {
        // no more data to send, turn off data ready interrupt
        UCSR2B &= ~(1 << UDRIE2);
    }
}

Timing Diagrams below:

~9600 Baud Rate -- enter image description here

~115,200 Baud Rate -- enter image description here

It sounds like your problem has to do with handshaking delays and/or the ability for your program to provide data as fast as the pipe can handle it. — Robert Harvey
This is using an ATMega2560, and I am writing to the hardware UART on the device. There shouldn't be any handshaking issue. What doesn't make sense is why the delay increases as the baud rate increases, and vice versa. I thought it was supposed to be the other way around. — user791953
The folks over at electronics.stackexchange.com are probably in a better position to answer your question, unless you can show us the code you are using. Your code may be waiting on the UART to signal that it is ready, or there may be a blocking method call somewhere. — Robert Harvey
In any case, 125 microseconds corresponds to about 8K bytes per second (about 80K bits per second, give or take a parity bit), so you should already be pretty close to maximum theoretical throughput. — Robert Harvey
so you are using an interrupt not polling? Have you tried a polling loop that just transmits as fast as it can rather than this ring stuff? Basically divide the problem in half, and then half again, etc. Does the problem have anything at all to do with the uart? Is it strictly based on the amount of code? Is it based on interrupt overhead? Is it something specific in your code? Etc. — old_timer

ibschreiber ibschreiber · Accepted Answer · 2013-09-11T12:36:42

Three points to check:

Do you feed the buffer fast enough? If not, the increased gap is due to your data providing code, not due to an internal behaviour of the processor. (use a toggle pin to find out)
Is it possible that because of the increased speed, your code just switches off the data register empty interrupt every single time it transmits data? Instead of using a put_char to fill up your ringbuffer, you could use a put_string(array, length) to fill it up with multiple chars at once (using memcopy for example, think about splitting it up into two mwmcopy operations when data has to wrap at the end of the buffer). (again, use a toggle pin to find out).
Reduce the code wraped into cli() and sei() to a minimum. Switch filling up the buffer with the flag check and and exclude this part from the cli-sei part

good luck!

Why does the delay between bytes increase when I increase UART baud rate?

2 Answers