<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>UART in Production on Embedded Systems Development</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/</link><description>Recent content in UART in Production on Embedded Systems Development</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/index.xml" rel="self" type="application/rss+xml"/><item><title>Baud Rate Generation &amp; Accuracy</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-baud-rate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-baud-rate/</guid><description>&lt;h1 id="baud-rate-generation--accuracy"&gt;Baud Rate Generation &amp;amp; Accuracy&lt;a class="anchor" href="#baud-rate-generation--accuracy"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every UART frame is clocked by the baud rate generator inside the USART peripheral. Unlike SPI or I2C, UART has no shared clock line — both transmitter and receiver must independently generate the same bit timing from their own clocks. The baud rate register (BRR) divides the peripheral clock down to the target rate, and the accuracy of that division determines whether communication works or produces garbled data. A mismatch beyond roughly 3% between transmitter and receiver causes bit-sampling errors that corrupt every frame.&lt;/p&gt;</description></item><item><title>Interrupt-Driven UART Reception</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-interrupt-reception/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-interrupt-reception/</guid><description>&lt;h1 id="interrupt-driven-uart-reception"&gt;Interrupt-Driven UART Reception&lt;a class="anchor" href="#interrupt-driven-uart-reception"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Polling the UART receive register works for bench demos but fails in production. Data arrives asynchronously, and if the firmware is busy doing anything else when a byte lands in the data register, the next byte overwrites it — silently. Interrupt-driven reception solves this by responding to each received byte immediately, copying it into a buffer that the main loop can process at its own pace. The gap between &amp;ldquo;polling works&amp;rdquo; and &amp;ldquo;interrupt-driven works&amp;rdquo; is the gap between a demo and a product.&lt;/p&gt;</description></item><item><title>DMA-Driven UART with Idle Line Detection</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-dma-idle/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-dma-idle/</guid><description>&lt;h1 id="dma-driven-uart-with-idle-line-detection"&gt;DMA-Driven UART with Idle Line Detection&lt;a class="anchor" href="#dma-driven-uart-with-idle-line-detection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Interrupt-driven UART reception works, but at high baud rates the per-byte ISR overhead becomes significant. At 1 Mbaud, a byte arrives every 10 us — an ISR that takes 1 us to execute consumes 10% of the CPU. DMA eliminates this overhead entirely by transferring received bytes directly from the USART data register into memory with zero CPU involvement. The challenge is that DMA requires a fixed transfer length, but most UART protocols send variable-length packets. Combining DMA circular mode with the IDLE line interrupt solves this: DMA handles the byte-level transfers, and IDLE signals when a packet has ended, regardless of its length. This is the gold-standard pattern for production UART reception.&lt;/p&gt;</description></item><item><title>RS-485 Half-Duplex &amp; Driver Enable</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-rs485/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/uart/uart-rs485/</guid><description>&lt;h1 id="rs-485-half-duplex--driver-enable"&gt;RS-485 Half-Duplex &amp;amp; Driver Enable&lt;a class="anchor" href="#rs-485-half-duplex--driver-enable"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;RS-485 uses differential signaling on a twisted pair, allowing multi-drop communication over distances up to 1200 meters with up to 32 standard-load nodes on a single bus. Unlike RS-232, which is point-to-point, RS-485 is a shared bus where only one transmitter drives the line at a time. The firmware challenge is controlling the transceiver direction — switching between transmit and receive at precisely the right moment to avoid data corruption and bus contention. STM32 parts with hardware Driver Enable (DE) support automate this timing in silicon. Parts without it require careful GPIO management in firmware.&lt;/p&gt;</description></item></channel></rss>