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\$ – Daniel Grillo Sep 10 '13 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 Sep 10 '13 at 18:12
  • \$\begingroup\$ What is the period between start bits? \$\endgroup\$ – Ignacio Vazquez-Abrams Sep 10 '13 at 18:17
  • \$\begingroup\$ The code the OP is using is here. It's an ATMega2560. \$\endgroup\$ – Robert Harvey Sep 10 '13 at 18:25
  • \$\begingroup\$ Interrupt context switching takes non-negligible time -- it may actually be faster to use polling. \$\endgroup\$ – HL-SDK Sep 10 '13 at 19:14

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 Sep 10 '13 at 18:45
  • \$\begingroup\$ @user791953: Glad to hear this solved it. \$\endgroup\$ – Gustavo Litovsky Sep 11 '13 at 18:08

protected by Kortuk Sep 10 '13 at 18:48

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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