15
\$\begingroup\$

I am reading about the standard protocol for UART and I think that if the receiving UART does not have any idea on what baud rate the data was transmitted, there would be lots of problems. If the assumed baud rate is lower than the baud rate in which the data is transmitted, there will be bits that would not be 'seen' by the receiving UART. On the other hand if the baud rate used by the receiver is higher than than the baud rate in which the data is transmitted, there will be bits that will be counted twice and would result the data being 'read' incorrectly.

My knowledge around UART is that when the line is idle, it is kept to a '1', the Start bit is a '0' and the Stop bit is a '1'. Also, the Stop bit being '1' does not have any difference with the '1' when the line is idle or is there a way to differentiate?

Do two communicating UART's first agree on which baud rate they will use? If yes, how do they do it?

\$\endgroup\$
6
  • \$\begingroup\$ The "stop bit" could equally well be called "return to idle state", but by making it a bit, it has a defined minimum length, but after that guaranteed minimum time, the line will remain in a "1" state unti the next character comes along. \$\endgroup\$
    – Peter Bennett
    Sep 28, 2016 at 6:19
  • \$\begingroup\$ They could randomly change common baud rates until something works XD. \$\endgroup\$
    – Bradman175
    Sep 28, 2016 at 11:18
  • 3
    \$\begingroup\$ Hayes initiated a way to let the UART in their modems set the same baud rate as the terminal talking to it by using a character sequence 'AT' at the start of their commands. This usually wasn't decoded by the UART, but by real-time firmware that would then configure the UART to receive the rest of the command line. It basically detected the width of the start bit, and how the parity was set. \$\endgroup\$
    – infixed
    Sep 28, 2016 at 16:22
  • \$\begingroup\$ @infix So if I plan to modify or create a Verilog code for UART, I can make it so that it would detect this 'AT' sequence and adjust its baud rate from there? I was thinking of initializing it at the highest baud rate so that it'd capture everything and from there, find the 'AT' sequence. \$\endgroup\$
    – Batibot323
    Sep 29, 2016 at 3:05
  • 1
    \$\begingroup\$ A UART-based communication protocol (named as LIN) which can be seen a lot in automotive industry has an auto-baud detection mechanism, but still master and slave nodes "have to" match in terms of data length and stop bits length. Which means, detecting only baud rate is not sufficient. \$\endgroup\$
    – Rohat Kılıç
    Sep 29, 2016 at 8:57

3 Answers 3

Reset to default
26
\$\begingroup\$

Ordinary UARTs have to be pre-configured with the desired baud rate (as well as word length, stop bits, parity, etc) traditionally by a human.

For several decades now though there have been implementations of "auto baud" detection found in some settings, which typically works by timing key features of the waveform to deduce the baud rate. Early versions needed a known character to be transmitted, but more sophisticated versions might be able to find the rate from more arbitrary data.

A receiving UART typically has a local clock that runs at a faster rate - typically 8 or 16 times the baud rate. This is used to sample the incoming signal and detect the bits within a word in a way that can tolerate a few percent of error. Even two crystal oscillators wouldn't match rates perfectly, but the error tolerance can permit use of some less precise sources, sometimes including trimmed on-chip oscillators, etc. It can also help accommodate the fact that dividing down popular oscillator frequencies may only produce an inaccurate approximation to certain baud rates - in the old days, UART master clocks sometimes needed particular frequencies to access popular baud rates, for example 11.0592 MHz on the 8051 family.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ My hypothesis on auto baud detection can be a timer and counter working simultaneously to find edges and time between edges? \$\endgroup\$
    – ammar.cma
    Sep 28, 2016 at 8:55
  • 2
    \$\begingroup\$ The problem is there is no algorithm that can take an arbitary "uart serial" waveform and reliablly determine the baudrate. You can find the minimum time between transitions easially enough but that doesn't nessacerally represent a single bit period. \$\endgroup\$
    – Peter Green
    Sep 29, 2016 at 0:00
  • \$\begingroup\$ An algorithm does exist (I've heard it called "auto-bauding" in various places) but when implemented in the resource-limited scope of a UART chip, sometimes the only way to do it is by consuming some of the sent data and using it for calibration that will persist for the rest of the session. This is often not desirable. If done in software and allowed a little latency then it's trivial to do this without consuming data (by temporarily storing it for analysis) at least for low speed comms (less than 200KB/s). Higher speeds present further difficulties. \$\endgroup\$
    – user98663
    Sep 29, 2016 at 10:48
8
\$\begingroup\$

Two UARTS "agree" on baud rate by means of documentation and by operator/user setting the baud rate by hands, including handshake protocol, stop bit size, etc.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ .....for both ends of the interface. \$\endgroup\$
    – Michael Karas
    Sep 28, 2016 at 6:22
2
\$\begingroup\$

Yea, everything is set up manually, which is often a bit of a pain, especially when systems are poorly documented (I'm looking at you, every embedded system ever).

I know USB, SATA, and most other modern data protocols start off after some reset or initialization event at the lowest speed with some standardized default configuration and negotiate with everyone else (or the just the master, depending on the protocol) up to higher speeds. Some also use pull-up or pull-down resistors on their data/power lines to indicate supported speeds.

See this website on USB negotiation if you're interested in delving a bit further in other protocols.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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