By the end of this section, you will be able to:
UART is one of the oldest and simplest ways for two devices to communicate — it is like two tin cans connected by a string. One device sends data on a wire while the other listens, and vice versa. Many IoT projects use UART to connect a microcontroller to a GPS module, display, or computer for debugging.
“UART is the simplest protocol of all!” said Max the Microcontroller. “Just three wires: TX for sending, RX for receiving, and GND for ground. No clock wire needed — both sides just agree on the speed beforehand.”
“That speed is called the baud rate,” explained Sammy the Sensor. “Common ones are 9600 and 115200. If I talk at 9600 baud and Max listens at 115200, all he hears is garbage! Baud rate mismatch is the number one debugging headache with UART.”
Lila the LED added, “The trick with UART is it only connects TWO devices. No sharing like I2C’s 127-device bus. But that simplicity is an advantage — there is no addressing, no arbitration, no pull-up resistors. Just wire TX to RX, RX to TX, and start talking.”
“I use UART all the time for my serial debug console,” said Bella the Battery. “When something goes wrong in my IoT project, I print messages through UART to a computer screen. GPS modules speak UART, Bluetooth modules speak UART, and most microcontrollers have multiple UART ports. It has been around since the 1960s and it is still going strong because simple works!”
Before diving into this chapter, you should be familiar with:
When your ESP32 sends debug messages to your laptop, when a GPS module transmits location data, when a factory sensor reports temperature to a PLC — they are almost certainly using UART. It is the default “I need to send some bytes” protocol of the embedded world.
UART works by turning a byte into a sequence of voltage pulses on a single wire: a start pulse, eight data pulses (or five to nine), an optional parity check pulse, and a stop pulse. The receiver independently times each pulse using its own clock. No clock wire is needed, which is what makes UART so cheap to implement — just two wires and agreement on timing.
RS-232 is the electrical standard that defined how those voltage pulses should look when connecting a computer (DTE, Data Terminal Equipment) to a modem (DCE, Data Communication Equipment) in the 1960s. It specified +12V and −12V levels, a DB9 connector, and handshaking signals like RTS/CTS. Modern microcontrollers use TTL UART (0V/3.3V or 0V/5V) which carries the same protocol but at logic-level voltages — a MAX232 chip converts between the two when connecting legacy RS-232 equipment.
This chapter covers both: the RS-232 electrical standard and the UART framing protocol that runs on top of it.
RS-232 (Recommended Standard 232) is one of the oldest communication protocols, introduced in the 1960s to connect computers with modems.
Modern usage:
| Feature | Value |
|---|---|
| Wires | 3 minimum (TX, RX, GND), up to 9 for full implementation |
| Topology | Point-to-point |
| Sync/Async | Asynchronous |
| Duplex | Full-duplex (separate TX/RX wires) |
| Speed | 300 bps - 115,200 bps (typical) |
| Distance | Up to 15 meters |
| Voltage | ±3V to ±25V (typically ±12V) |
RS-232 uses inverted voltage logic:
| Logic Level | Voltage Range | Binary Value |
|---|---|---|
| Logic 1 (Mark) | -3V to -25V | 1 |
| Logic 0 (Space) | +3V to +25V | 0 |
Important: This is opposite of TTL logic (0V = 0, +5V = 1)!
Most modern devices use TTL UART, requiring level shifter (MAX232) for true RS-232.
DB9 Connector Pinout:
| Connector view | Upper row | Lower row | Pins most beginners need |
|---|---|---|---|
| Front of a male DB9 connector | 5 4 3 2 1 | 9 8 7 6 | Pin 2 = RX, Pin 3 = TX, Pin 5 = GND |
When troubleshooting, confirm whether the diagram is drawn from the front of the connector or the solder/cable side. Mirrored views are a common reason students accidentally swap pins.
Common signals:
| Pin | Signal | Direction | Purpose |
|---|---|---|---|
| 1 | DCD | Input | Data Carrier Detect |
| 2 | RX | Input | Receive Data |
| 3 | TX | Output | Transmit Data |
| 4 | DTR | Output | Data Terminal Ready |
| 5 | GND | - | Signal Ground |
| 6 | DSR | Input | Data Set Ready |
| 7 | RTS | Output | Request To Send |
| 8 | CTS | Input | Clear To Send |
| 9 | RI | Input | Ring Indicator |
Minimum connection: TX, RX, GND (3 wires)
| Frame part | Wire state | What the receiver does | Beginner note |
|---|---|---|---|
| Idle | HIGH / Mark | Waits for a falling edge | Nothing is being sent yet |
| Start bit | LOW / Space | Starts its bit timer | This is the receiver’s timing reference |
| Data bits | 5-9 bits, usually 8 | Samples one bit period at a time | Data is sent least-significant bit first |
| Optional parity | Even, odd, or none | Checks simple single-bit errors | The N in 8N1 means no parity bit |
| Stop bit(s) | HIGH / Mark | Confirms the byte ended cleanly | One stop bit is most common |
Frame components:
Common configurations:
Baud rate = Speed of communication in bits per second
Common baud rates:
Both devices must use the SAME baud rate!
UART’s baud rate tolerance comes from the cumulative timing error over one data frame.
For 8N1 format (1 start + 8 data + 1 stop = 10 bits), the receiver resyncs on the falling edge of the start bit, then samples each subsequent bit at 1.5, 2.5, 3.5 … 9.5 bit periods. At the last sample (9.5 bit periods), the cumulative clock drift must stay within ±50% of one bit period for the sample to land inside the correct bit:
| Timing idea | Meaning | Result |
|---|---|---|
| Last sample point | Receiver samples the last useful point about 9.5 bit periods after the start edge | Timing error accumulates across the whole frame |
| Theoretical limit | Drift must stay below half a bit period by that last sample | Combined error must be below about 5.26% |
| Practical design limit | Real signals have jitter, cable delay, and imperfect edges | Use 3.75% combined error or better |
| Per-device target | If both devices contribute equally | Keep each clock within about 1.875% |
The UART specification conservatively sets the practical limit at 3.75% combined (i.e., each device’s clock error should be ≤1.875%) to provide margin against jitter, cable delays, and rise-time imperfections. The 5% figure is the theoretical maximum; in practice, exceeding 3.75% leads to intermittent failures.
For example, at 115200 baud with 2% combined clock error:
| Step | Value | Interpretation |
|---|---|---|
| Bit period at 115200 baud | 8.68 μs | One bit is very short |
| Drift after 9.5 bits at 2% combined error | 1.65 μs | The sample is shifted but still inside the bit |
| Drift as a fraction of one bit | 19% | Below the 50% theoretical boundary |
| Practical result | Works | There is still useful sampling margin |
This 19% is well below the 50% theoretical limit, so communication works. At 921600 baud with the same 2% clock error, the percentage of a bit period drifted is identical (19%) because clock error is proportional. What makes high baud rates risky is the absolute net margin: at 115200 baud, the available sampling window is ±4.34 μs and the 19% drift consumes 1.65 μs of it, leaving 2.69 μs net margin. At 921600 baud, the sampling window is only ±0.543 μs and the same 19% drift (0.206 μs) leaves only 0.34 μs net margin — a margin that any cable capacitance, connector contact resistance, or EMI pulse can erase.
The calculators and diagrams above explain UART without hardware. When you are ready to connect an ESP32 to a real serial device, use this checklist before writing code.
| Step | What to check | Why it matters |
|---|---|---|
| 1 | Confirm the device uses TTL UART, true RS-232, or RS-485 | The wrong voltage standard can damage the microcontroller |
| 2 | Match the frame format, usually 9600 baud and 8N1 for GPS-style modules | Both sides must sample bits at the same moments |
| 3 | Cross the data wires: ESP32 TX to device RX, ESP32 RX to device TX | TX talks to RX; TX-to-TX does not communicate |
| 4 | Share ground between the two boards | The receiver needs the same voltage reference |
| 5 | Use GPIO 17 as ESP32 TX and GPIO 16 as ESP32 RX only after confirming your board pinout | Development boards sometimes label pins differently |
| 6 | Start with a short cable and a low-risk test message | This separates wiring mistakes from long-cable signal-quality problems |
Common use cases:
Choosing Baud Rate:
Common Errors:
Optimization:
Python’s pyserial library is a common tool for UART communication from a PC or Raspberry Pi, but beginners should first understand the workflow rather than copy a long script.
| Step | Student action | Expected observation |
|---|---|---|
| 1 | Connect the GPS module through a USB-UART adapter | The adapter appears as a serial port such as /dev/ttyUSB0 or COM3 |
| 2 | Open the port at 9600 baud, 8N1 | Most NMEA GPS modules use this default |
| 3 | Read one line at a time | You should see sentences beginning with $GP... or $GN... |
| 4 | Find a $GPGGA or $GNGGA sentence |
This line carries time, fix quality, satellite count, and position fields |
| 5 | If the text is garbage | Recheck baud rate before blaming the GPS module |
| Direction | What happens | Debug value |
|---|---|---|
| ESP32 to PC | ESP32 sends status messages over USB serial | Lets you see sensor values and errors without a display |
| PC to ESP32 | User types a short command and the ESP32 replies | Useful for changing modes or triggering a test reading |
| Both directions | Messages must end with a known delimiter such as newline | The receiver knows where one command ends |
| Failure sign | Text appears duplicated, partial, or garbled | Check baud rate, line endings, and buffer handling |
| Modbus setting | Typical value | Why students must verify it |
|---|---|---|
| Physical layer | RS-485 differential pair | It is not safe to connect directly to TTL UART pins |
| Frame format | 19200 baud, 8E1 is common | Many Modbus devices use even parity, not 8N1 |
| Device address | 1-247 | The query is ignored if the address is wrong |
| Register number | Manufacturer-specific | Temperature may be register 0 on one device and 40001 on another |
| Timeout symptom | No reply | Check address, A/B polarity, termination, and shared reference |
Scenario: A UART connection works correctly at 9600 baud but fails completely at 115200 baud with garbled data. Both devices use 8N1 configuration.
Think about:
Key Insight: UART is asynchronous (no clock signal), so TX and RX must independently time each bit using their internal clocks.
The Math:
Solution: Use precision crystals (<±0.5% per device, <±1% combined) or internal RC oscillators with factory calibration to UART-standard frequencies. This is why UART has standardized baud rates (9600, 115200, etc.) — they align with common crystal frequencies (16 MHz, 8 MHz) whose integer dividers produce these exact rates.
Scenario: An ESP32 communicates with an Arduino via UART at 115200 baud. The ESP32 runs at 3.3V logic, Arduino at 5V. Direct connection works sometimes but has intermittent errors.
Think about:
Key Insight: The problem is voltage level incompatibility.
Solution:
Direction matters: Arduino TX at 5V driving ESP32 RX can permanently damage the ESP32 (absolute max is 3.6V). Never directly connect 5V TX to a 3.3V-rated RX pin without protection.
Chevron’s Richmond, California refinery operates 4,200 Modbus RTU devices connected via RS-485 (electrically based on RS-232 signaling but with differential voltage for multi-drop networks). The Modbus RTU protocol — the most widely deployed UART-based industrial protocol — runs at 19200 baud with 8E1 framing across 380 instrument loops, each up to 1,200 meters.
Why UART/Modbus persists in a Wi-Fi world:
| Factor | UART/Modbus RTU | Modern alternatives (Ethernet/IP, Wi-Fi) |
|---|---|---|
| Installation cost per point | $45 (2-wire RS-485) | $180 (Ethernet) / $250 (industrial Wi-Fi) |
| Latency determinism | 3.5 character times (1.8 ms at 19200) guaranteed | 1-50 ms variable (Ethernet CSMA/CD) |
| EMI immunity | Differential RS-485 rejects common-mode noise up to +12V | Ethernet susceptible to ground loops, requires shielding |
| Cable distance | 1,200 m at 19200 baud (RS-485) | 100 m (Ethernet), 50 m typical (Wi-Fi in metal structures) |
| Intrinsic safety certification | IS-rated RS-485 transceivers available since 1990s | Limited certified Ethernet options for Zone 1/2 |
| Mean time between failure | 25+ years (no active components in cable) | 7-10 years (switches, access points) |
Chevron’s instrumentation engineering team evaluated replacing Modbus with Ethernet/IP in 2019. The projected cost for the Richmond refinery alone was $18.7M including new cable runs, Ethernet switches rated for Class I Division 2, and recertification of all safety instrumented systems. They opted instead to add Modbus-to-OPC-UA gateways at each control room ($340K total), preserving the existing 4,200-device wired infrastructure while enabling modern IT integration.
Baud rate selection matters more than you think:
The refinery originally standardized on 9600 baud in 1998. When a new gas chromatograph requiring 200-byte readings was added in 2012, the poll cycle for its 32-device loop exceeded the 1-second requirement:
| Design option | Per-device time | Full-loop time | Outcome |
|---|---|---|---|
| 9600 baud, 8E1 | 242 ms | 7.7 seconds for 32 devices | Far beyond the 1-second target |
| Upgrade to 19200 baud | 121 ms | 3.9 seconds for 32 devices | Faster, but still too slow |
| Split into two 16-device loops at 19200 baud | 121 ms | 1.9 seconds effective cycle | Acceptable only because both loops run in parallel |
| Hidden overhead | Value at 9600 baud, 8E1 | Why it matters |
|---|---|---|
| Query frame | 8 bytes x 11 bits = 9.2 ms | Short command frames still consume measurable time |
| 200-byte response | 200 bytes x 11 bits = 229 ms | Large readings dominate the cycle |
| Modbus silent gap | 3.5 character times = 4.0 ms | Every transaction needs quiet time before the next frame |
The key lesson: at 19200 baud with 8E1 framing, the raw byte rate is 19200/11 = 1,745 bytes/second — already 9% lower than the 1,920 B/s you would get with 8N1. On top of that, Modbus requires a 3.5-character silent gap between every frame (an additional ~4 ms pause at 19200 baud). For short messages this gap can represent 20-30% of total transaction time. Both overheads compound and are often overlooked in capacity planning.
| Criteria | Stay with UART/RS-485 | Migrate to Ethernet/Wi-Fi |
|---|---|---|
| Device count per loop | < 32 (Modbus limit) | > 32 or growing rapidly |
| Data per device | < 250 bytes/poll | > 250 bytes or streaming |
| Cable runs | Already installed, < 1.2 km | New installation, < 100 m |
| Update rate needed | > 500 ms acceptable | < 10 ms required |
| Environment | Explosive atmosphere (Zone 1/2) | Office/clean room |
| Budget | < $50/point available | > $150/point available |
| IT integration needed | Gateway bridge acceptable | Direct IP connectivity required |
Baud rate selection is more nuanced than “pick the fastest.” Higher baud rates reduce transfer time but increase sensitivity to clock accuracy, cable quality, and electromagnetic interference. For IoT devices, the trade-offs are quantifiable.
| Baud Rate | Effective Byte Rate (8N1) | Max Reliable Distance (RS-485) | Typical Use Case |
|---|---|---|---|
| 9,600 | 960 bytes/sec | 1,200 m | Modbus RTU sensors, building automation |
| 19,200 | 1,920 bytes/sec | 1,000 m | Industrial telemetry, flow meters |
| 38,400 | 3,840 bytes/sec | 500 m | Barcode scanners, weigh scales |
| 57,600 | 5,760 bytes/sec | 300 m | GPS modules (NMEA output) |
| 115,200 | 11,520 bytes/sec | 100 m | Debug consoles, MCU-to-MCU |
| 460,800 | 46,080 bytes/sec | 15 m | High-speed logging, camera triggers |
| 921,600 | 92,160 bytes/sec | 5 m | Same-board communication only |
UART has no clock line — both sides must generate the baud rate independently. If their clocks drift apart, bits are sampled at wrong times and data is corrupted.
Tolerance rule: The combined clock error of transmitter and receiver must be less than 3.75% for reliable communication (the sampling point must fall within the middle 50% of each bit period).
| Clock combination | Combined error | Reliability lesson |
|---|---|---|
| ESP32 crystal plus ATmega328P internal RC oscillator, rated worst case | About 10.01% | Fails the UART tolerance rule |
| Same pair at typical room temperature | Around 4% | Marginal; heat can push it over the limit |
| ESP32 crystal plus ATmega328P external 16 MHz crystal | About 0.015% | Works reliably with large timing margin |
Why 9,600 baud appears forgiving: At 9,600 baud, each bit period is 104 microseconds — there is 3.9 μs of absolute timing margin before a 3.75% error corrupts a sample. A marginal clock at ±5% error (above spec) still leaves only 0.4 μs of margin violation, so communication may limp along. At 921,600 baud, each bit period is 1.09 microseconds — the same 3.75% margin is just 41 ns absolute. Any connector delay, cable capacitance, or thermal drift consumes that margin instantly, causing immediate failure. The percentage tolerance is the same at all baud rates; the forgiving behavior at 9,600 comes from having more absolute nanoseconds of margin, not from any fundamentally different tolerance rule.
Design recommendation: For IoT devices connected by cables longer than 30 cm, stick to 115,200 baud or below. For same-board communication (MCU to radio module), higher rates are safe. Always verify with an oscilloscope if using baud rates above 115,200 with cables.
A factory needs to monitor 25 temperature sensors distributed across 800 meters using Modbus RTU over RS-485.
Given:
Step 1: Calculate time-on-air per sensor query at 9,600 baud
| Component | Time at 9600 baud, 8E1 | Notes |
|---|---|---|
| Query frame | 9.2 ms | 8 bytes x 11 bits |
| Response frame | 14.9 ms | 13 bytes x 11 bits |
| Inter-frame gap | 4.0 ms | 3.5 character times |
| Total per sensor | 28.1 ms | Query plus response plus required quiet time |
Step 2: Calculate total poll cycle time
| Poll-cycle check | Result |
|---|---|
| 25 sensors x 28.1 ms | 702.5 ms per complete cycle |
| Target | 2,000 ms |
| Outcome | 0.7 seconds, well within target |
Step 3: Evaluate faster baud rate (19,200)
| Baud rate | Per-sensor time | 25-sensor cycle |
|---|---|---|
| 9600 | 28.1 ms | 702.5 ms |
| 19200 | 14.1 ms | 352.5 ms |
Step 4: Check distance limitations
| Baud rate | Rule-of-thumb max distance | 800 m deployment |
|---|---|---|
| 9600 | 1200 m | Within limit |
| 19200 | 1000 m | Within limit, but less margin |
Step 5: Factor in retries for reliability
| Retry assumption | Cycle at 9600 | Cycle at 19200 |
|---|---|---|
| No retries | 702.5 ms | 352.5 ms |
| 5% packet loss requiring retries | 737 ms | 370 ms |
| Compared with 2-second target | Still passes | Passes with more speed but less distance/noise margin |
Recommendation: Use 9,600 baud because: - Meets 2-second polling requirement with margin (737 ms < 2,000 ms) - More reliable at 800 m distance (lower bit error rate) - Better EMI immunity in industrial environment - Standard rate with widest device compatibility
If requirements change to 1-second polling:
Key Insight: Don’t choose the fastest baud rate by default. Match baud rate to actual requirements, considering distance, reliability, and environmental factors.
| Application Type | Typical Data Size | Update Rate | Distance | Recommended Baud | Reasoning |
|---|---|---|---|---|---|
| GPS NMEA | 80 bytes/sentence | 1-5 Hz | <3 m | 9,600 | Industry standard, minimal latency requirement |
| Modbus RTU sensors | 20-200 bytes | 0.5-2 Hz | 10-1,200 m | 9,600 | Reliability over speed, long cable runs |
| Industrial flow meters | 50-100 bytes | 2-10 Hz | 100-800 m | 19,200 | Faster updates, moderate distance |
| Debug console | Variable | On-demand | <2 m | 115,200 | Fast log output, short cable, no reliability concern |
| Bluetooth module (HC-05) | 20-500 bytes | 10-100 Hz | <1 m | 9,600-115,200 | Factory default is 9600; reconfigurable via AT commands |
| MCU-to-MCU (same board) | Variable | 100+ Hz | <30 cm | 230,400-921,600 | Minimal noise, very short traces |
| Barcode scanner | 10-100 bytes | 1-10 scans/min | 1-3 m | 38,400 | Fast enough for human interaction |
| Legacy SCADA (1990s) | 10-50 bytes | 0.1-1 Hz | 500-1,200 m | 9,600 | Compatibility with old equipment |
Decision Factors:
Example Calculation (Industrial Temperature Logger):
| Requirement | Value | Design implication |
|---|---|---|
| Reading size | 100 bytes | Timestamp plus 20 sensor values |
| Update rate | 10 readings/second | Needs 1000 bytes/second before framing overhead |
| Frame overhead | 11 bits/byte for 8E1 | Raw throughput need becomes 11,000 bps |
| Utilization target | 70% maximum | Minimum baud is about 15,714 bps |
| Next standard baud | 19,200 bps | Meets throughput and distance |
| Cable environment | 250 m near motors and VFDs | Consider shielded cable or 38,400 bps only if extra throughput margin is needed |
Conclusion: Use 19,200 baud for the normal design. Use 38,400 baud only with good shielding and field testing, because the factory environment makes reliability more important than theoretical speed.
Trade-off Table:
| Factor | Choose Lower Baud (9,600) | Choose Higher Baud (115,200) |
|---|---|---|
| Cable length | >200 m | <50 m |
| Environment | Noisy (motors, RF) | Clean (lab, office) |
| Clock accuracy | Low-cost RC oscillator | Crystal oscillator |
| Throughput need | <1 KB/sec | >10 KB/sec |
| Existing infrastructure | Legacy 9,600 devices | Modern MCU-to-MCU |
The Error: “My ESP32 and Arduino both support 115,200 baud, so I’ll use that for maximum speed!”
What Actually Happens:
| Device | Clock accuracy | Effect |
|---|---|---|
| ESP32 | About ±0.01% with a crystal | Excellent timing source |
| Arduino Uno using ATmega328P internal RC oscillator | Up to ±10% factory rating | Too inaccurate for reliable UART |
| Combined error | About 10.01% worst case | Far beyond the 3.75% reliable UART limit |
| Result | Fails at 115200 baud | The receiver samples the wrong part of the bit |
Symptoms:
Real-World Example (Failed Smart Meter Project, 2021):
100 smart meters using ATmega328P (internal RC) communicating with Raspberry Pi gateway at 115,200 baud over RS-485:
| Deployment period | Observed result | Root cause |
|---|---|---|
| Day 1-30 | 12% packet error rate | Retries hid the problem at first |
| Summer temperature rise | 38% packet error rate | RC oscillator drift increased with heat |
| Later field state | 40% of meters unreachable | Some clocks drifted beyond the receiver’s tolerance |
| Remediation cost | $45,000 | Replacing meters was far more expensive than designing for clock accuracy |
The Fix They Should Have Used:
Option 1: Lower baud rate (no hardware change)
| Check | Result |
|---|---|
| Bit period at 9600 baud | 104 μs |
| 10% combined clock error over 9.5 bit periods | 95% of one bit period |
| Receiver behavior | Samples near the adjacent bit |
| Verdict | Lower baud rate does not fix a clock-accuracy problem |
Option 2: Add external crystal to Arduino (correct solution)
| Improvement | Result |
|---|---|
| Add 16 MHz crystal to ATmega328P | About ±0.005% accuracy |
| ESP32 plus Arduino crystal combined error | About 0.015% |
| UART tolerance comparison | Well within the 3.75% reliable limit |
| Cost lesson | A cheap crystal during design avoids expensive field replacement |
Option 3: Use 9,600 baud + protocol-level checksums
| Condition | What happens |
|---|---|
| Typical room-temperature unit around 3% actual error | Marginal; retransmission can hide occasional errors |
| Hot summer drift around 6-7% actual error | Sampling can move outside the intended bit |
| CRC-16 added to every message | Detects errors but cannot repair bad timing |
| Production verdict | Useful as a safety net, not a substitute for a proper clock |
Baud Rate vs Clock Accuracy Table:
The maximum combined clock error for reliable UART is 3.75% at any baud rate — this is a fixed spec, not baud-rate dependent. What changes with higher baud rates is that non-clock factors (cable propagation delay, capacitive loading, rise-time distortion) consume an increasing fraction of the shrinking bit period:
| Baud Rate | Bit Period | 3.75% Margin | Practical Limit (inc. cable effects) | Works With |
|---|---|---|---|---|
| 9,600 | 104 μs | 3.9 μs | 3.75% (clock dominates) | RC oscillator (calibrated) |
| 19,200 | 52 μs | 1.95 μs | 3.75% (clock dominates) | RC oscillator (tight calibration) OR crystal |
| 38,400 | 26 μs | 0.975 μs | 3.75% | Crystal required |
| 115,200 | 8.68 μs | 0.325 μs | 3.75% (cable delay eats margin fast) | Crystal + cable <15 m |
| 460,800 | 2.17 μs | 0.081 μs | 3.75% (10 ns cable delay = 0.5%) | Crystal + PCB traces only |
| 921,600 | 1.09 μs | 0.041 μs | 3.75% (any connector adds ~1%) | Crystal + same-board only |
Key Insight: UART clock tolerance is always 3.75% combined — but at high baud rates, the absolute time margin shrinks so much that connector resistance, cable capacitance, and PCB trace inductance each consume a measurable fraction of it. Use a crystal at any baud rate, and stay on-board for rates above 460,800.
A sender at 115200 bps and a receiver at 9600 bps produces garbled data. Fix: always explicitly configure both devices to the same baud rate; never assume the default matches.
RS-232 uses ±12 V; a 3.3 V microcontroller GPIO tolerates 0–5 V. Connecting them directly will permanently damage the microcontroller. Fix: always use a level-shifter (e.g., MAX3232) between RS-232 and 3.3 V TTL-level UART.
Sending continuous high-rate data over UART without flow control causes receiver buffer overflow and data loss. Fix: enable RTS/CTS flow control for streaming applications, or implement software buffering with XON/XOFF.
This chapter covered UART and RS-232 serial communication:
| Topic | Chapter | Description |
|---|---|---|
| Wired Communication Fundamentals | Wired Comm Fundamentals | Synchronous vs asynchronous, signal lines, and why wired protocols persist in IoT |
| I2C Protocol | I2C Protocol | Two-wire multi-device bus enabling up to 127 sensors and displays to share just SDA and SCL |
| SPI Protocol | SPI Protocol | Four-wire full-duplex interface for SD cards, displays, and fast ADCs |
| Wired Communication Overview | Wired Communication | Side-by-side comparison of UART, I2C, SPI, and Ethernet for IoT projects |
| Physical Layer and Ethernet | Physical Layer — Wired Ethernet | How Ethernet frames map onto physical cabling, MAC addressing, and collision domains |
| Network Fundamentals | Networking Fundamentals | IP addressing, switching, and routing concepts that sit above the physical serial layer |