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?


I am using an ATMega2560.

Two timing diagrams are attached below.

~9600 Baud Rate - Baud9600_1

enter image description here

~115200 Baud Rate - enter image description here

  • 2
    \$\begingroup\$ Put more information. What device are you using? \$\endgroup\$ Commented Sep 10, 2013 at 18:10
  • 1
    \$\begingroup\$ Can your device keep feeding data to UART fast enough so that it can saturate it? To me it looks as if data isn't being sent to UART quickly enough. UARTs usually run asynchronously to the rest of the platform, so it will keep sending data in the background. They often have small buffers which may be only one or two bytes in length, so it could be that UART empties its buffer and has to wait for more data. \$\endgroup\$
    – AndrejaKo
    Commented Sep 10, 2013 at 18:12
  • \$\begingroup\$ What is the period between start bits? \$\endgroup\$ Commented Sep 10, 2013 at 18:17
  • \$\begingroup\$ The code the OP is using is here. It's an ATMega2560. \$\endgroup\$ Commented Sep 10, 2013 at 18:25
  • \$\begingroup\$ Interrupt context switching takes non-negligible time -- it may actually be faster to use polling. \$\endgroup\$
    – HL-SDK
    Commented Sep 10, 2013 at 19:14

1 Answer 1


The higher baudrate makes the UART module transmit faster, so you have more "spacing" between the bytes, but it seems to me that the rate at which you're transmitting the bytes is still the same. Your timing diagrams are missing total time so its hard to see if this is the case. Don't compare last edge to first edge. Compare the first edges of the the two bytes. Are these still the same?

  • 4
    \$\begingroup\$ This solved the issue. I was overlooking the actual delays. The scaling was off, and in truth it was sending faster. Error on my part reading the scales. \$\endgroup\$
    – user791953
    Commented Sep 10, 2013 at 18:45
  • \$\begingroup\$ @user791953: Glad to hear this solved it. \$\endgroup\$ Commented Sep 11, 2013 at 18:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.