How well can you define the uart protocol

Projects Programming
41

Think about the "OSI Seven Layer model" in order to answer what a "protocol" is, where "UART" (vs. USART) is related to it.

UART is a layer 1 or 2: it just defines how to send bits, better a SINGLE byte. It is more a physical layer, e.g. to have a start bit, serials bits of a byte, a stop bit. Even UART does not define the real physical layer, e.g. if it is a V24 interface (-15V/+15V logic), RS232 (-5V/+5V logic) or even running with 3V3 digital logic (TTL-UART). Often, UART in MCU context means just: an ASYNCHRONOUS bit stream, up to 8...9 bits, with start and stop bit, based on 3V3 logic level for an MCU pin.

BTW: UART and USART are not really the same!
When you see an 'S' in name, it stands often for "synchronous". So, it tells you: there is also the clock provided. In an "asynchronous" interface: there is not a clock provided: it is assumed that sender and receiver have their own clock reference, trying to get the bits with their own clocks, with the risk that the clocks drift away and the bits are getting wrong. Therefore UART is limited to send just bursts of 8..9 data bits (BYTE plus parity), where the START_BIT tells receiver when to start fetching the bits with a free running clock. After a longer period - the clock would drift off so much that bits are not correct anymore.
Compare with SPI which is a synchronous interface (it has an SCLK signal!).
A "synchronous" interface, where the reference clock is provided - can transmit much faster, many more bits over a longer period of time, w/o to lose "synchronization" when to capture a bit. An "asynchronous" interface cannot be sure how accurate and "stable" the local reference clock is w/o to get bit errors after a while. Therefore, an "asynchronous" interface starts all the time again with a "sync bit" (or word), which is here the START_BIT.

When it comes to protocol, these are the higher layers: compare with TCP/IP. It is based on ETH (the physical layer) and the higher layers (IP and than TCP) define how to interpret the bits (or bytes) received by the physical layer. Now it comes to layers where a data packet is "interpreted" (decoded/encoded) in order to understand what the message was.

UART is not a protocol: UART is a physical interface. It is able to send a number of bits, mainly ONE SINGLE BYTE at a time. How do you interpret the sequence of bytes - this is your protocol.
You can use UART in order to send ASCII characters (often used as "UART", e.g. a terminal) but you can also send real 8bit bytes. How do you interpret such bytes - it is your protocol, e.g. acting on 0xA, 0xD as Line Feed, Carriage Return or on CTRL-Q/CTRL-S for SW flow control (start/stop) is part of your protocol.
E.g. do you want to send text strings or code bytes? And how do you want to display characters (language, character set)? This is your protocol.

A protocol is in general:

  • a definition about the byte sequence expected and how to decode (encode) it
  • the flow control (handshaking), e.g. a "ping-ping", when you receive something - respond with something
  • how to interpret a "string", e.g. as a value, as a name, as a command and how a value is encoded (e.g. LITTLE vs. BIG ENDIAN).

UART is just a physical interface, whereby the confusion comes when we talk about RS232, with TTL-Level, with V24 level, with MCU 3V3 voltage level. UART itself "guarantees" just to send and receive a SINGLE byte, nothing else (no interpretation = no protocol).

The protocol is "yours", e.g. TELNET, KERMIT, DFU ... - it is above the UART layer. It is the upper layer in your software/firmware (how to "understand" the bytes and what to do, e.g. how to respond, to take it as text or as code bytes for memory = firmware downloader).

42

Sorry, but asynchronous only applies to the byte arrival. The actual bits are synchronous with the clock signal.

43

We say "asynchronous transmission and reception" -- it refers to the fact that there is no timing relationship (time stamp) as to when a data byte is being sent and/or when it is being received.

44

NASA is an acronym (a new word built from first letters of many other words),
Corp. or Ltd. are abbreviations (shortened words)

So, UART is an acronym, for "Universal Asynchronous Receive and Transmit".
See, it does not say "interface" - so, the physical layer, e.g. which voltage level used, is not specified.
And in comparison to IP and TCP - where the 'P' stands for Protocol - UART is not a protocol.

45

NO!!!!!
The bit time is DIFFERENT in relation to the Tx and Rx clock!
Asynchronous means really: "a free running clock on both sides" and they are NOT IN SYNC (as synchronous would be).

46

There is a timing relationship: the "baudrate set on both sides" matters: you cannot send with 19200 baudrate and trying to receive with 9600!
Asynchronous means: "we assume both parties (Tx and Rx) have their own clock, free running clocks on both sides!, and the Rx clock is 'stable' enough for a short period of time so that sampling the bits with a drifting clock does not end up in bit errors".

There is a timing relationship and a mandatory minimal clock drift/offset. UART is just "in sync" for the period of ONE BYTE transmission. But during this period - the timing has a fix relation (assuming the "same" clock speed used).

Asynchronous means: no reference clock provided, "assuming" both sides run with the "same" clock speed (they can never do, there is drift, jitter ...).
And Asynchronous needs always a SYNC word or here with UART a SYNC BIT (= Start-Bit).

You do not have this "Sync-Bit" or word (BTW: ETH has Sync Bytes!) on a Synchronous interface, like SPI is.

47

I also want to add that "asynchronous" is a broadcast; it does not care if the receiver is ready or not to receive the message.

48

"hmmm": broadcast is to send from one to many: UART is NOT broadcast (only peer-to peer).
And: UART receiver is (should be) always ready to receive (the next byte) when the receiver drains the Rx FIFO fast enough. The Tx can assume the Rx is ready to receive - otherwise there has to be a flow control (HW or SW flow control). Assume: it takes the same time on Tx to send 8bits as the Rx needs to take 8bit from the input buffer. In general: UART Rx is "always ready" to receive next. Otherwise you have a performance problem (and you would need flow control, a "back pressure" to Tx).

Asynchronous is really just related about the clock references: are Tx and Rx in sync (using the same clock)? = synchronous, or are both sides running with their own local clocks? = asynchronous. Nothing else.

On SW implementation you can think in a similar way:

  • a "synchronous" function call returns just when the called party has finished (a regular sub-function called), so the caller is hard-synced with the called function
  • an "asynchronous" function call is like activating a thread/task and let it do: the caller keeps running and has no clue if and when the parallel thread/task has finished.
    It needs a "synchronization". Both parts are running in parallel, with decoupled speed and clock.

Asynchronous needs always a synchronization between both parties, synchronous system components run all on the same master clock, e.g. in audio applications as "World Clock", and "endless" synchronization, no sync bit or words needed.

This difference is just: "free running components" (with their own local clocks) or "forced to be in sync with a reference (master) clock"?
Synchro - means, I guess: to be at the same clock, same time (tick). A-synchro means: not at the same pace.

UART is for sure NOT broadcast, it is just "asynchronous" (decoupled clock references).

49

USART, in every case where I've seen it, means a peripheral that can be configured for either Asynchronous operation OR synchronous operation, not that the peripheral is fundamentally synchronous...

Hmm. The UART transmitter IS synchronous to the transmitter clock. But the receiver can be completely asynchronous - not only does it not share a clock with the transmitter, but the clock edges that it does use (of it's OWN clock) don't have to be in the same places as the transmitter clock.

Most of the dictionaries I looked at insist that an "acronym" is "pronounced as a word", not that it actually is an existing "word." NASA and ASCII were examples. "UART" qualifies. "URL" and "SMS" don't.

50

The very first IBM PCs used the Intel 8250 :wink: It changed later to more modern parts.

51
52

Neither does ‘synchronous’ transmission…

53

I saved the first two years issues. Anyone interested in them?

54

PS: The first IBM PC didn't include a Serial Port by default :slight_smile:
It was an optional Add-on card "IBM Asynchronous Communications Adaptor."

image
image600×516 56.1 KB

55

The next chip is the 8251A in Intel line, which we have extensively used in 8086 Based System Design.
8251A

56

Back to the original OP question "how to have a well defined protocol?".
UART is not a protocol.
UART is a serial (byte) transmission, in asynchronous mode
Therefore:

  • the baudrate of transmitter and receiver must be within a certain error range (close enough to avoid bit errors during a byte transmission)
  • each byte transfer is synchronized with the START_BIT (and STOP_BIT), so the clock can be drifting a bit, it can jitter a bit, the clocks can be off a bit ... as long as receiver can sample the last bit without error (not being "outside of clock" edges at the end)

There is not a protocol in terms of how to "interpret" the data sent. There is not any higher layer handshake, acknowledge etc.

The only thing to bear in mind is the "data byte format": how many bits per byte (the bits are "bauds"), with Parity Bit or not, HW or SW handshake (or no handshake), and a bit the number of stop bits can matter (1 or 2).

Nothing else.
Some chips have FIFOs inside, so, they can buffer a some bytes (e.g. up to 16 bytes). But this is just there to "relax" the receiver FW, to give the FW more time to drain the received bytes.
It does not have any effect in terms of "protocol", or when you get bit errors due to issue that Tx and Rx clocks are too far off (or "jittering", not stable enough).

UART is not a protocol, it is just a "serial interface" to transmit data words (bytes, where a word is actually a "baud") with an ASYNCHRONOUS approach (no clock synchronization, both sides with their own decoupled = asynchronous clocks).
The protocol sits on top of your transmitter and receiver (in your SW stack).

Even the signal levels (physical layer 1) are not defined: An UART can drive RS232, V24 or directly via 3V3 logic. So, UART: means just "asynchronous byte transfer".

The only "kind of protocol" defined is the "back pressure": if receiver is not ready to accept a new byte, it CAN (often it does not) use HW or SW flow control:
HW flow control uses DTS, DCR signals (hardware signals in addition to data lines) or SW flow control (using special CTRL-characters like CTRL-S, CTRL-Q sent as data) to stop the sender.

A FIFO does not speed up the transmission: it is there to give the receiver more time to drain/read the data from the chip. It does not have any impact on "protocol" (how to interpret the data bytes) neither the bandwidth (the fastest baudrate possible which depends on the clock drift/offset, cable length, wires used ... as well as the FW processing speed of the receiver).

57

==> UART is a serial (frame) transmission, in asynchronous mode? (The byte refers to 8-bit; whereas, a frame could be 10-bit to 12-bit.)

58

YES, a kind of:
a frame is a number of bits for a "baud" (which are like number of bits).
But UART can be configured for any number of bits, I think from 5 to 8 (5 because of the old capital letter only morse code).
And: plus Parity or not (so, an N+1 bit). The START and STOP bits are part of what you call "a frame". So, every frame starts with START_BIT, N number of bits, plus optional Parity bit, plus STOP_BIT (1 or 2).

So, for a byte, as 8bit, it has at least 10 bits, Parity could be optional (e.g. 8+1, or 7+1), and STOP bit at least 1, possible to send 2 (to give receiver more time).
I guess, a "baud" is this "frame" (one "character").

59

1. Frame: The chunk of total number of bits in a transmission cycle (Fig-1) bounded by START and STOP bits.

uartArch-2
uartArch-2997×607 16.6 KB

Figure-1:

2. Baud Rate (Bd): Number of bits/sec (in the case of UART Protocol of ATmega328P where there is no explicit carrier to modulate).

3. If transmission cycle of Fig-1 happens at Bd = 9600, then the time required for the frame to arrive at UNO (ignore propagation delay due to cable characteristics) is:

===> (1/9600)*10 
===> 41 us.
60

Bit Order.
Agreement of 0/1 voltage (or current) levels, and which is "idle."
Duplex.