<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Embedded Systems Development</title><link>https://applied-ee.github.io/embedded/</link><description>Recent content on Embedded Systems Development</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://applied-ee.github.io/embedded/index.xml" rel="self" type="application/rss+xml"/><item><title>Accelerometer Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/accelerometer-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/accelerometer-fundamentals/</guid><description>&lt;h1 id="accelerometer-fundamentals"&gt;Accelerometer Fundamentals&lt;a class="anchor" href="#accelerometer-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;MEMS accelerometers are the most common inertial sensor in embedded systems — found in everything from wearable step counters and drone flight controllers to industrial vibration monitors. At the firmware level, the challenge is not merely reading a value but configuring the device for the right balance of noise floor, bandwidth, power consumption, and data rate. A poorly configured accelerometer can produce data that looks plausible but is dominated by noise, aliased vibration, or gravitational offset errors that corrupt downstream algorithms.&lt;/p&gt;</description></item><item><title>ADC Configuration &amp; Sampling Strategy</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/adc-configuration-and-sampling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/adc-configuration-and-sampling/</guid><description>&lt;h1 id="adc-configuration--sampling-strategy"&gt;ADC Configuration &amp;amp; Sampling Strategy&lt;a class="anchor" href="#adc-configuration--sampling-strategy"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The ADC peripheral is the bridge between the analog world and firmware. Configuring it correctly — resolution, sample time, channel sequencing, reference voltage, and data transfer — determines whether the digitized values represent the sensor signal or an artifact of the measurement setup. A 12-bit ADC on an STM32 can theoretically resolve 0.8 mV steps on a 3.3 V range, but only if the input signal has time to settle, the reference is stable, and the conversion results reach memory without CPU bottlenecks.&lt;/p&gt;</description></item><item><title>ADC for Audio Capture</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/adc-for-audio/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/adc-for-audio/</guid><description>&lt;h1 id="adc-for-audio-capture"&gt;ADC for Audio Capture&lt;a class="anchor" href="#adc-for-audio-capture"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most Cortex-M microcontrollers include a successive-approximation (SAR) ADC capable of sampling at rates well above audio requirements — a 12-bit ADC running at 1 MSPS is far faster than the 8–48 kHz needed for audio. The question is not whether the ADC is fast enough, but whether it is clean enough. Audio demands sustained, evenly spaced conversions with minimal noise over thousands of consecutive samples, while most MCU ADC specifications are optimized for single-shot or burst measurements of slowly changing signals. The gap between &amp;ldquo;ADC can sample at 48 kHz&amp;rdquo; and &amp;ldquo;ADC produces usable audio at 48 kHz&amp;rdquo; is measured in ENOB, noise floor, and clock jitter.&lt;/p&gt;</description></item><item><title>Audio Feature Extraction for ML</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/audio-feature-extraction/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/audio-feature-extraction/</guid><description>&lt;h1 id="audio-feature-extraction-for-ml"&gt;Audio Feature Extraction for ML&lt;a class="anchor" href="#audio-feature-extraction-for-ml"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Raw PCM audio is a poor direct input to machine learning models. A single second of 16 kHz mono audio produces 16,000 samples — a 16,000-dimensional input vector that contains temporal structure the model cannot easily exploit. Adjacent samples are highly correlated, frequency information is implicit rather than explicit, and the sheer dimensionality demands unnecessarily large models. The standard approach is to transform raw audio into a compact frequency-domain representation — typically a mel spectrogram or a set of MFCCs — that captures the perceptually relevant information in far fewer dimensions.&lt;/p&gt;</description></item><item><title>AWS IoT Core</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/aws-iot-core/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/aws-iot-core/</guid><description>&lt;h1 id="aws-iot-core"&gt;AWS IoT Core&lt;a class="anchor" href="#aws-iot-core"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;AWS IoT Core is Amazon&amp;rsquo;s managed MQTT broker and device management service for IoT workloads. It handles device authentication, message routing, and state synchronization for fleets ranging from a handful of prototypes to millions of production devices. The service is built around a registry of &amp;ldquo;things,&amp;rdquo; X.509 certificate-based mutual TLS authentication, a device shadow mechanism for state synchronization, and a rules engine that routes messages to downstream AWS services. Understanding the provisioning models, topic namespace, shadow document structure, and policy language is necessary for building firmware that connects reliably and securely at scale.&lt;/p&gt;</description></item><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>BLDC Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/bldc-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/bldc-fundamentals/</guid><description>&lt;h1 id="bldc-fundamentals"&gt;BLDC Fundamentals&lt;a class="anchor" href="#bldc-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A brushless DC motor (BLDC) replaces the mechanical commutator of a brushed motor with electronic switching. The rotor carries permanent magnets, and the stator has three sets of windings arranged 120° apart. By energizing the windings in the correct sequence at the correct rotor angle, the stator field continuously pulls the rotor forward. The result is higher efficiency (85–95 % vs 70–85 % for brushed), longer life (no brush wear), and better power density — at the cost of requiring a controller that knows the rotor position and drives a three-phase inverter.&lt;/p&gt;</description></item><item><title>BLE Advertising &amp; GAP</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-advertising-gap/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-advertising-gap/</guid><description>&lt;h1 id="ble-advertising--gap"&gt;BLE Advertising &amp;amp; GAP&lt;a class="anchor" href="#ble-advertising--gap"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;BLE advertising is the mechanism by which devices announce their presence to the world. Unlike WiFi, where a station actively searches for access points, BLE reverses the model — the peripheral broadcasts short packets at regular intervals, and any nearby central or observer can receive them without establishing a connection. The Generic Access Profile (GAP) defines the roles, modes, and procedures that govern this discovery process. Understanding advertising at the packet level is essential because every byte matters: the legacy advertising payload is limited to 31 bytes, and the choices made in configuring advertising parameters directly determine power consumption, discovery latency, and connection speed.&lt;/p&gt;</description></item><item><title>Bluetooth Classic for Audio</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/bluetooth-classic-overview/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/bluetooth-classic-overview/</guid><description>&lt;h1 id="bluetooth-classic-for-audio"&gt;Bluetooth Classic for Audio&lt;a class="anchor" href="#bluetooth-classic-for-audio"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) is the transport layer behind wireless headphones, car audio, and hands-free calling. BLE (Bluetooth Low Energy) was not designed for continuous audio streaming — its connection intervals, packet sizes, and lack of guaranteed throughput make it unsuitable for real-time audio at acceptable quality. Bluetooth Classic&amp;rsquo;s ACL (Asynchronous Connection-Less) and SCO (Synchronous Connection-Oriented) links provide the bandwidth and timing guarantees that audio demands. The ESP32 is the dominant MCU platform for Bluetooth Classic audio, with both Bluedroid and NimBLE stacks available, though NimBLE supports only BLE — Bluetooth Classic audio requires Bluedroid or BTstack.&lt;/p&gt;</description></item><item><title>Buck Converters in Practice</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/buck-converters-in-practice/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/buck-converters-in-practice/</guid><description>&lt;h1 id="buck-converters-in-practice"&gt;Buck Converters in Practice&lt;a class="anchor" href="#buck-converters-in-practice"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A single lithium-ion cell delivers 4.2 V at full charge and sags to about 3.0 V at cutoff. Most MCU systems need a regulated 3.3 V rail, making the buck (step-down) converter the default topology for the upper portion of the discharge curve — from 4.2 V down to roughly 3.5 V, where the converter still maintains dropout headroom. Modern micro-buck ICs achieve 90–96 % efficiency in this range, draw sub-microamp quiescent currents in sleep, and fit in packages smaller than 2 mm × 2 mm. Selecting the right IC, inductor, and capacitors — and placing them correctly on the PCB — determines whether the system meets its efficiency, noise, and thermal targets.&lt;/p&gt;</description></item><item><title>CAN Bit Timing &amp; Baud Rate</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-bit-timing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-bit-timing/</guid><description>&lt;h1 id="can-bit-timing--baud-rate"&gt;CAN Bit Timing &amp;amp; Baud Rate&lt;a class="anchor" href="#can-bit-timing--baud-rate"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;CAN bit timing determines whether nodes on a bus can communicate at all. Unlike UART, where baud rate mismatches produce garbled data, a CAN baud rate mismatch prevents any communication entirely &amp;ndash; the receiving node never sees a valid frame, and the transmitting node receives no ACK. Every node on a CAN bus must agree on the bit rate to within approximately 0.5%, and achieving that precision requires understanding how the CAN peripheral synthesizes its bit clock from the MCU&amp;rsquo;s peripheral clock.&lt;/p&gt;</description></item><item><title>Cell Selection &amp; Ratings</title><link>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/cell-selection-and-ratings/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/cell-selection-and-ratings/</guid><description>&lt;h1 id="cell-selection--ratings"&gt;Cell Selection &amp;amp; Ratings&lt;a class="anchor" href="#cell-selection--ratings"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Selecting a lithium-ion cell for an embedded project involves balancing energy density, discharge capability, physical size, and safety margins. The datasheet numbers — nominal voltage, capacity in milliamp-hours, maximum discharge current — only tell part of the story. Real-world performance depends on temperature, age, internal resistance, and how closely the system&amp;rsquo;s load profile matches the cell&amp;rsquo;s design envelope. A cell that performs well on a bench at 25 degrees C may sag below the regulator&amp;rsquo;s dropout voltage in a cold enclosure, or overheat when pulsed at its rated maximum.&lt;/p&gt;</description></item><item><title>Centralized Logging with ELK</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/centralized-logging-elk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/centralized-logging-elk/</guid><description>&lt;h1 id="centralized-logging-with-elk"&gt;Centralized Logging with ELK&lt;a class="anchor" href="#centralized-logging-with-elk"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Embedded devices produce logs that are sparse, irregular, and arrive over constrained links — a fundamentally different ingestion profile than web servers generating gigabytes of access logs per hour. A fleet of 5,000 devices each emitting 50 log entries per day produces roughly 250,000 entries and 50 MB of raw data daily. That volume is modest by cloud-logging standards, but the operational value per entry is high: a single &lt;code&gt;ERR&lt;/code&gt; log from a remote sensor node may be the only clue to a hardware failure that cannot be reproduced in the lab. Centralized logging infrastructure must ingest these entries reliably, index them for fast search, and retain them long enough to support forensic analysis of failures that may not be investigated for weeks.&lt;/p&gt;</description></item><item><title>Common TFT Controllers</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/tft-controllers-overview/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/tft-controllers-overview/</guid><description>&lt;h1 id="common-tft-controllers"&gt;Common TFT Controllers&lt;a class="anchor" href="#common-tft-controllers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Once monochrome OLEDs are outgrown and color is needed, TFT territory begins. The display modules aimed at hobbyists and embedded projects almost all use a handful of controller ICs, each with its own quirks. Knowing which controller is on the module is the first step — it determines the driver choice, SPI configuration, initialization sequence, and color format options.&lt;/p&gt;
&lt;h2 id="ili9341"&gt;ILI9341&lt;a class="anchor" href="#ili9341"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The ILI9341 is the workhorse of small color TFTs. It drives 240x320 displays (typically 2.2&amp;quot; or 2.4&amp;quot; modules) with 262K colors. SPI interface up to 10MHz for reads and higher for writes (most setups push it to 40-80MHz successfully). It&amp;rsquo;s well-documented, well-supported by every major graphics library, and the most &amp;ldquo;just works&amp;rdquo; option in this category. For a first color display, a 2.4&amp;quot; ILI9341 module is the safe default.&lt;/p&gt;</description></item><item><title>Constant-Current LED Drivers</title><link>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/constant-current-drivers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/constant-current-drivers/</guid><description>&lt;h1 id="constant-current-led-drivers"&gt;Constant-Current LED Drivers&lt;a class="anchor" href="#constant-current-led-drivers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;LEDs are current-driven devices — their brightness is proportional to the current flowing through them, and their forward voltage is a consequence of that current, not a control parameter. Driving an LED from a voltage source with just a resistor works for basic applications, but the brightness varies with supply voltage, temperature, and the LED&amp;rsquo;s own forward voltage tolerance. Constant-current driver ICs eliminate this variability by regulating the current through each LED string regardless of supply voltage fluctuations, LED forward voltage variation, or temperature drift.&lt;/p&gt;</description></item><item><title>Cross-Compilation Basics</title><link>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/cross-compilation-basics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/cross-compilation-basics/</guid><description>&lt;h1 id="cross-compilation-basics"&gt;Cross-Compilation Basics&lt;a class="anchor" href="#cross-compilation-basics"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Cross-compilation is the process of building code on one machine (the host) that will run on a different machine (the target). In embedded development, the host is typically an x86_64 Linux or Windows workstation, while the target is an ARM Cortex-M microcontroller with no operating system, no filesystem, and a fraction of the host&amp;rsquo;s memory. The toolchain bridges this gap — it knows the target&amp;rsquo;s instruction set, memory layout, and calling conventions, and produces binaries that the host cannot execute directly.&lt;/p&gt;</description></item><item><title>Current Sensing Methods</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/current-sensing-methods/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/current-sensing-methods/</guid><description>&lt;h1 id="current-sensing-methods"&gt;Current Sensing Methods&lt;a class="anchor" href="#current-sensing-methods"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every power measurement begins with converting a current into a voltage that can be digitized. The dominant technique in embedded systems is the shunt resistor — a low-value, precision resistor placed in the current path so that the voltage drop across it is proportional to the current flowing through it. The fundamental relationship is Ohm&amp;rsquo;s law: V = I × R. A 100mA current through a 100mΩ shunt produces a 10mV signal. The entire accuracy of the measurement chain depends on the shunt resistor value, its tolerance, its placement on the board, and how the resulting voltage is amplified and digitized.&lt;/p&gt;</description></item><item><title>Digital Filtering Basics (Moving Average, IIR, FIR)</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/digital-filtering-basics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/digital-filtering-basics/</guid><description>&lt;h1 id="digital-filtering-basics-moving-average-iir-fir"&gt;Digital Filtering Basics (Moving Average, IIR, FIR)&lt;a class="anchor" href="#digital-filtering-basics-moving-average-iir-fir"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Raw sensor readings from ADCs, accelerometers, temperature sensors, and other peripherals contain noise — thermal noise from the sensor element, quantization noise from the ADC, electrical interference from switching regulators, and mechanical vibration coupling through the PCB. Digital filtering removes or attenuates this noise in firmware before the data reaches higher-level algorithms like sensor fusion or control loops. The choice of filter type determines the tradeoff between noise rejection, latency, memory usage, and computational cost — all of which matter on resource-constrained microcontrollers.&lt;/p&gt;</description></item><item><title>DMA Channel &amp; Stream Architecture</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-channel-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-channel-architecture/</guid><description>&lt;h1 id="dma-channel--stream-architecture"&gt;DMA Channel &amp;amp; Stream Architecture&lt;a class="anchor" href="#dma-channel--stream-architecture"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;DMA controllers move data between peripherals and memory without CPU involvement, but the internal routing between a peripheral request and the DMA hardware that services it varies significantly across MCU families. Getting the mapping right is a prerequisite — configuring the wrong stream or channel produces no transfer and no error flag, just silence on the bus.&lt;/p&gt;
&lt;h2 id="stm32f4-streams-channels-and-fixed-mapping"&gt;STM32F4: Streams, Channels, and Fixed Mapping&lt;a class="anchor" href="#stm32f4-streams-channels-and-fixed-mapping"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The STM32F4 has two DMA controllers (DMA1 and DMA2), each with 8 streams (0–7). Each stream has a channel multiplexer that selects one of 8 channel inputs (0–7). The combination of controller, stream, and channel determines which peripheral request is serviced. These mappings are fixed in silicon and listed in the reference manual (RM0090, Table 42/43).&lt;/p&gt;</description></item><item><title>Ethernet PHY, MAC &amp; RMII/MII</title><link>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/ethernet-phy-mac/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/ethernet-phy-mac/</guid><description>&lt;h1 id="ethernet-phy-mac--rmiimii"&gt;Ethernet PHY, MAC &amp;amp; RMII/MII&lt;a class="anchor" href="#ethernet-phy-mac--rmiimii"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Wired Ethernet on a microcontroller requires two functional blocks: a MAC (Media Access Controller) that handles frame construction, CRC generation, and DMA transfers, and a PHY (Physical Layer Transceiver) that converts digital signals to analog levels on the wire. Some MCUs integrate the MAC as a peripheral — STM32F4/F7/H7, i.MX RT1060, ESP32, SAM E70 — while others lack Ethernet entirely and rely on SPI-attached modules (covered separately). The PHY is almost always a discrete external chip, connected to the MAC through either the MII or RMII interface.&lt;/p&gt;</description></item><item><title>First Boot Checklist</title><link>https://applied-ee.github.io/embedded/docs/development/project-bring-up/first-boot-checklist/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/project-bring-up/first-boot-checklist/</guid><description>&lt;h1 id="first-boot-checklist"&gt;First Boot Checklist&lt;a class="anchor" href="#first-boot-checklist"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The first power-on of a new board is the highest-risk moment in a project. Applying power without a methodical pre-check risks damaging components, masking assembly errors, and wasting hours debugging firmware when the real problem is hardware. A disciplined bring-up sequence — visual inspection, current-limited power, rail verification, and debug probe contact — catches most issues before they cascade. No firmware should run until the board is proven electrically sound.&lt;/p&gt;</description></item><item><title>Fixed-Point Audio Arithmetic</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fixed-point-audio-arithmetic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fixed-point-audio-arithmetic/</guid><description>&lt;h1 id="fixed-point-audio-arithmetic"&gt;Fixed-Point Audio Arithmetic&lt;a class="anchor" href="#fixed-point-audio-arithmetic"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most MCUs used for audio — Cortex-M4, Cortex-M7, ESP32 — have hardware integer multipliers but no floating-point unit fast enough for real-time audio DSP (Cortex-M4F has single-precision FPU, but Q15/Q31 fixed-point on the DSP extensions is still faster for multiply-accumulate-heavy workloads). Fixed-point arithmetic represents fractional values as scaled integers, trading dynamic range for deterministic execution time and efficient use of the DSP instruction set. A 16-bit audio sample is already a fixed-point number — Q15 format, where the full-scale range [-1.0, +1.0) maps to [-32768, +32767]. Understanding Q-format arithmetic is not optional for embedded audio DSP; it is the foundation every filter, mixer, and dynamics processor is built on.&lt;/p&gt;</description></item><item><title>Flash &amp; SRAM Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/flash-and-sram-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/flash-and-sram-fundamentals/</guid><description>&lt;h1 id="flash--sram-fundamentals"&gt;Flash &amp;amp; SRAM Fundamentals&lt;a class="anchor" href="#flash--sram-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every MCU has two primary memory regions: flash for non-volatile storage and SRAM for runtime data. On a typical Cortex-M device — say an STM32F407 — the flash holds 1 MB of compiled firmware starting at 0x08000000, while 192 KB of SRAM at 0x20000000 holds variables, the stack, and the heap. The entire address space, including peripheral registers, is memory-mapped into a single flat 32-bit space, which means reading a GPIO register and reading a variable in SRAM use the same load instruction.&lt;/p&gt;</description></item><item><title>Framebuffer Patterns for LED Strips</title><link>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/framebuffer-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/framebuffer-patterns/</guid><description>&lt;h1 id="framebuffer-patterns-for-led-strips"&gt;Framebuffer Patterns for LED Strips&lt;a class="anchor" href="#framebuffer-patterns-for-led-strips"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An LED strip is a one-dimensional display — a linear array of pixels that gets rewritten every frame. The framebuffer is the in-memory representation of the current pixel state, and how it&amp;rsquo;s structured determines the flexibility, performance, and memory cost of the animation system. On a resource-constrained microcontroller, the framebuffer pattern choice directly impacts how many LEDs can be driven and how complex the animations can be.&lt;/p&gt;</description></item><item><title>Gamma Correction</title><link>https://applied-ee.github.io/embedded/docs/led-systems/color-management/gamma-correction/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/color-management/gamma-correction/</guid><description>&lt;h1 id="gamma-correction"&gt;Gamma Correction&lt;a class="anchor" href="#gamma-correction"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Human vision perceives brightness logarithmically, but LEDs emit light linearly with PWM duty cycle. Without gamma correction, a fade from 0 to 255 looks like it jumps to &amp;ldquo;almost full brightness&amp;rdquo; in the first quarter and then barely changes for the remaining three-quarters. Applying a gamma curve transforms linear PWM values into perceptually uniform brightness steps — making a value of 128 actually look like &amp;ldquo;half brightness&amp;rdquo; to the eye.&lt;/p&gt;</description></item><item><title>GPS/GNSS Module Integration</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/gps-gnss-module-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/gps-gnss-module-integration/</guid><description>&lt;h1 id="gpsgnss-module-integration"&gt;GPS/GNSS Module Integration&lt;a class="anchor" href="#gpsgnss-module-integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;GPS and GNSS modules provide absolute position on the Earth&amp;rsquo;s surface by receiving satellite signals and computing a navigation solution. In embedded systems, the module handles all the RF and DSP work internally — the MCU&amp;rsquo;s job is to configure the module, parse its output, and react to fix data. The u-blox NEO series (NEO-6M, NEO-M8N, NEO-M9N) dominates hobbyist and mid-tier commercial designs due to wide availability, solid documentation, and a consistent UART/I2C interface across generations. Integration involves two main data paths: NMEA sentences for standard position/velocity/time data, and the proprietary UBX binary protocol for configuration and advanced features.&lt;/p&gt;</description></item><item><title>Graphics Library Landscape</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/graphics-library-landscape/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/graphics-library-landscape/</guid><description>&lt;h1 id="graphics-library-landscape"&gt;Graphics Library Landscape&lt;a class="anchor" href="#graphics-library-landscape"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Choosing a graphics library for an embedded display is one of those decisions that shapes an entire project. The library determines the API, what displays can be supported, how much RAM and flash are needed, and whether features like touch input or widgets come built-in. Here is a practical overview of the major options.&lt;/p&gt;
&lt;h2 id="lvgl-light-and-versatile-graphics-library"&gt;LVGL (Light and Versatile Graphics Library)&lt;a class="anchor" href="#lvgl-light-and-versatile-graphics-library"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;LVGL is the most feature-rich option and the closest thing to a &amp;ldquo;real GUI framework&amp;rdquo; for MCUs. It provides widgets (buttons, sliders, charts, lists), a layout engine, themes, animations, and even a font converter. The tradeoff is resource usage: LVGL wants at least 64KB of flash and 16KB of RAM as a minimum, and realistically more like 128KB+ flash and 32KB+ RAM for a usable UI. It&amp;rsquo;s overkill for a simple sensor readout on a 128x64 OLED, but for a thermostat with a touchscreen TFT, LVGL is probably the right tool.&lt;/p&gt;</description></item><item><title>HD44780 &amp; Compatible Controllers</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/hd44780-and-compatible/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/hd44780-and-compatible/</guid><description>&lt;h1 id="hd44780--compatible-controllers"&gt;HD44780 &amp;amp; Compatible Controllers&lt;a class="anchor" href="#hd44780--compatible-controllers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The HD44780 is the controller behind nearly every cheap character LCD in the embedded world — the 16x2 and 20x4 modules that have been around since the 1980s. It&amp;rsquo;s genuinely the &amp;ldquo;hello world&amp;rdquo; of embedded displays. The blue or green LCDs with white or black text found at hackerspaces are almost certainly HD44780-based. The controller is so ubiquitous that dozens of manufacturers clone it, and the interface has become a de facto standard.&lt;/p&gt;</description></item><item><title>How E-Ink Works</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/how-e-ink-works/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/how-e-ink-works/</guid><description>&lt;h1 id="how-e-ink-works"&gt;How E-Ink Works&lt;a class="anchor" href="#how-e-ink-works"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;E-Ink displays (more precisely, electrophoretic displays) are fundamentally different from LCDs and OLEDs. They don&amp;rsquo;t emit light, they don&amp;rsquo;t need constant refreshing, and they look like printed paper. Understanding the physics explains why they behave so differently from every other display technology encountered in embedded work — especially the slow refresh rates that surprise on first encounter.&lt;/p&gt;
&lt;h2 id="the-electrophoretic-principle"&gt;The Electrophoretic Principle&lt;a class="anchor" href="#the-electrophoretic-principle"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;An E-Ink display consists of millions of tiny microcapsules, each about the diameter of a human hair. Each capsule contains positively charged white particles and negatively charged black particles suspended in a clear fluid. When an electric field is applied across a capsule, one color of particle migrates to the top (visible) surface and the other moves to the bottom. Reverse the field, and the particles swap positions. By controlling the field at each pixel, the controller creates a pattern of black and white dots — an image.&lt;/p&gt;</description></item><item><title>I²C Initialization &amp; Clock Configuration</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-initialization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-initialization/</guid><description>&lt;h1 id="ic-initialization--clock-configuration"&gt;I²C Initialization &amp;amp; Clock Configuration&lt;a class="anchor" href="#ic-initialization--clock-configuration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every I²C transaction depends on the peripheral being correctly initialized: GPIO pins configured as open-drain with alternate function, the I²C clock enabled via RCC, and the timing registers set to produce the desired SCL frequency. Getting any of these wrong produces symptoms that range from no activity on the bus to intermittent NACKs that appear device-dependent but are actually timing violations. The initialization code is typically short — 10 to 20 lines — but the details inside those lines determine whether the bus works reliably at 400 kHz or silently falls back to unpredictable behavior.&lt;/p&gt;</description></item><item><title>I2S DMA Buffer Management</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/i2s-dma-buffer-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/i2s-dma-buffer-management/</guid><description>&lt;h1 id="i2s-dma-buffer-management"&gt;I2S DMA Buffer Management&lt;a class="anchor" href="#i2s-dma-buffer-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;DMA is what makes continuous audio possible on a microcontroller. Without it, the CPU would need to service an interrupt for every sample — at 48 kHz stereo, that means 96,000 interrupts per second, leaving almost no time for actual audio processing. DMA transfers blocks of samples between the I2S peripheral and memory autonomously, and the CPU only needs to act when an entire buffer (or half-buffer) is ready. The engineering challenge is choosing the right buffer structure, size, and alignment to guarantee glitch-free audio while keeping latency within application requirements.&lt;/p&gt;</description></item><item><title>Image Classification</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/image-classification/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/image-classification/</guid><description>&lt;h1 id="image-classification"&gt;Image Classification&lt;a class="anchor" href="#image-classification"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Image classification assigns a single label to an entire image from a fixed set of classes, producing top-K predictions with associated confidence scores. A model trained on ImageNet outputs a 1000-element probability vector; the highest-scoring entry is the predicted class. On edge devices, the challenge is achieving useful accuracy within severe compute, memory, and power budgets — which has driven the development of model families specifically architected for efficient inference on ARM cores and neural accelerators.&lt;/p&gt;</description></item><item><title>Inference on Cortex-M</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/cortex-m-inference/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/cortex-m-inference/</guid><description>&lt;h1 id="inference-on-cortex-m"&gt;Inference on Cortex-M&lt;a class="anchor" href="#inference-on-cortex-m"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Arm Cortex-M family is the dominant target for TinyML inference. These processors have no operating system, no virtual memory, and no heap allocator in typical deployments. Execution is deterministic — a given model on a given input produces the same result in the same number of cycles every time, provided memory placement is controlled. All memory management is static: model weights reside in flash, the tensor arena occupies a fixed region of SRAM, and the application firmware shares both address spaces. The entire inference pipeline — from sensor input to classification output — runs in a single-threaded main loop or a pinned RTOS task with no context-switch overhead affecting latency.&lt;/p&gt;</description></item><item><title>IPv6 on Embedded Devices</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/ipv6-embedded/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/ipv6-embedded/</guid><description>&lt;h1 id="ipv6-on-embedded-devices"&gt;IPv6 on Embedded Devices&lt;a class="anchor" href="#ipv6-on-embedded-devices"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;IPv4 was never designed for billions of endpoints, and the workarounds — NAT, port forwarding, application-layer gateways — impose complexity that embedded devices should not carry. IPv6 eliminates NAT entirely. Every device gets a globally routable 128-bit address, end-to-end reachability becomes the default, and Stateless Address Autoconfiguration (SLAAC) removes the dependency on a DHCP server. For a sensor node behind three layers of NAT, the difference is fundamental: IPv6 means the device is addressable from anywhere without tunneling hacks.&lt;/p&gt;</description></item><item><title>Layout Strategies for Small Screens</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/small-screen-layout/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/small-screen-layout/</guid><description>&lt;h1 id="layout-strategies-for-small-screens"&gt;Layout Strategies for Small Screens&lt;a class="anchor" href="#layout-strategies-for-small-screens"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Designing for a 128x64 OLED or a 240x320 TFT is nothing like designing for a phone screen. Every pixel matters, text choices are constrained, and there&amp;rsquo;s no room for decorative padding. But small doesn&amp;rsquo;t mean primitive — with careful layout, these tiny screens can communicate a surprising amount of information clearly.&lt;/p&gt;
&lt;h2 id="information-hierarchy"&gt;Information Hierarchy&lt;a class="anchor" href="#information-hierarchy"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The first question for any small screen UI is: what needs to be visible &lt;em&gt;right now&lt;/em&gt;? On a 128x64 display, roughly 4 lines of medium text fit or 8 lines of tiny text. That&amp;rsquo;s the entire information budget. Prioritize ruthlessly:&lt;/p&gt;</description></item><item><title>Logic-Level Shifting</title><link>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/logic-level-shifting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/logic-level-shifting/</guid><description>&lt;h1 id="logic-level-shifting"&gt;Logic-Level Shifting&lt;a class="anchor" href="#logic-level-shifting"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most modern microcontrollers operate at 3.3V logic levels, but the WS2812B and many other addressable LEDs are specified for 5V logic — with a minimum high-level input voltage (VIH) of 0.7×VDD, which at 5V power is 3.5V. A 3.3V GPIO output is below this threshold. In practice, many WS2812B strips work at 3.3V drive due to manufacturing margin, but &amp;ldquo;works on the bench&amp;rdquo; is not the same as &amp;ldquo;works reliably across temperature, voltage, and LED batch variation.&amp;rdquo; Level shifting ensures the data signal meets the LED&amp;rsquo;s input specifications regardless of conditions.&lt;/p&gt;</description></item><item><title>MCU vs MPU — When to Use Which</title><link>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/mcu-vs-mpu/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/mcu-vs-mpu/</guid><description>&lt;h1 id="mcu-vs-mpu--when-to-use-which"&gt;MCU vs MPU — When to Use Which&lt;a class="anchor" href="#mcu-vs-mpu--when-to-use-which"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The split between microcontrollers and microprocessors is the first fork in any embedded design. An MCU like the STM32F405 integrates 1 MB of flash, 192 KB of SRAM, and dozens of peripherals onto a single chip — power on and code executes in microseconds. An MPU like the Raspberry Pi CM4 (BCM2711, quad-core Cortex-A72) needs external DDR, an SD card or eMMC for storage, and boots a full Linux kernel in seconds. These are fundamentally different computing models, and picking the wrong one either over-constrains the software or over-complicates the hardware.&lt;/p&gt;</description></item><item><title>MEMS Microphone Selection &amp; Interfacing</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/mems-microphone-interfacing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/mems-microphone-interfacing/</guid><description>&lt;h1 id="mems-microphone-selection--interfacing"&gt;MEMS Microphone Selection &amp;amp; Interfacing&lt;a class="anchor" href="#mems-microphone-selection--interfacing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;MEMS microphones have largely replaced electret condenser microphones (ECMs) in embedded systems. The key advantage is integration: a MEMS microphone contains the acoustic transducer, a charge amplifier, and — in digital variants — a sigma-delta ADC and digital interface, all in a single surface-mount package typically 3.5 x 2.65 x 1 mm. The result is a microphone that solders directly to a PCB with no external biasing components, no analog signal routing concerns, and consistent part-to-part sensitivity. Understanding the output format (analog, PDM, or I2S), the critical specifications, and the power supply requirements determines whether a given MEMS microphone will deliver clean audio or an unusable noise floor.&lt;/p&gt;</description></item><item><title>MOSFET Selection &amp; Gate Drive</title><link>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/mosfet-selection-and-gate-drive/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/mosfet-selection-and-gate-drive/</guid><description>&lt;h1 id="mosfet-selection--gate-drive"&gt;MOSFET Selection &amp;amp; Gate Drive&lt;a class="anchor" href="#mosfet-selection--gate-drive"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The MOSFET is the workhorse switch in every motor drive, solenoid circuit, and power stage covered in this section. Selecting the right MOSFET means matching its voltage, current, and thermal ratings to the load — and then ensuring the gate drive circuit can switch it on and off fast enough to keep switching losses low. A MOSFET that looks perfect on the datasheet can fail in practice if the gate is driven too slowly, the thermal path is inadequate, or the parasitic inductance in the layout causes voltage spikes.&lt;/p&gt;</description></item><item><title>MQTT</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/mqtt/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/mqtt/</guid><description>&lt;h1 id="mqtt"&gt;MQTT&lt;a class="anchor" href="#mqtt"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks. Originally developed by IBM in 1999 for SCADA systems over satellite links, it has become the dominant messaging protocol in IoT deployments. The protocol operates over TCP, uses a central broker to decouple publishers from subscribers, and provides three levels of delivery guarantee. A minimal MQTT CONNECT packet is 14 bytes, and a typical publish with a short topic and small payload fits in under 100 bytes — roughly 10x smaller than an equivalent HTTP POST with headers. This low overhead makes MQTT viable on devices with as little as 10 KB of RAM and on networks where every byte costs money (cellular, satellite, LPWAN).&lt;/p&gt;</description></item><item><title>NPUs, DSPs &amp; Accelerator Architectures</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/npu-dsp-overview/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/npu-dsp-overview/</guid><description>&lt;h1 id="npus-dsps--accelerator-architectures"&gt;NPUs, DSPs &amp;amp; Accelerator Architectures&lt;a class="anchor" href="#npus-dsps--accelerator-architectures"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Neural network inference is dominated by a small set of compute-intensive operations — matrix multiplications, convolutions, and element-wise activations. A single layer of a modest convolutional network may require tens of millions of multiply-accumulate (MAC) operations. Running these on a general-purpose CPU means cycling through scalar or narrow SIMD instructions, burning power on instruction fetch, decode, and branch prediction that contributes nothing to the actual math. Dedicated hardware accelerators exist to collapse these operations into massively parallel, energy-efficient execution — but each accelerator architecture makes different trade-offs in flexibility, model constraints, and power efficiency.&lt;/p&gt;</description></item><item><title>NVIC Configuration &amp; Priority Grouping</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/nvic-configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/nvic-configuration/</guid><description>&lt;h1 id="nvic-configuration--priority-grouping"&gt;NVIC Configuration &amp;amp; Priority Grouping&lt;a class="anchor" href="#nvic-configuration--priority-grouping"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Nested Vectored Interrupt Controller (NVIC) is the hardware block on every ARM Cortex-M processor that arbitrates between interrupt sources, determines which handler runs next, and manages preemption. On STM32F4 and STM32H7 devices, the NVIC implements 4 priority bits per interrupt, yielding 16 priority levels (0-15). Understanding how those bits divide between preemption priority and sub-priority — and what that division means for real-time behavior — is essential to building firmware that responds deterministically under load.&lt;/p&gt;</description></item><item><title>Oscillator Sources — Internal RC vs External Crystal</title><link>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/oscillator-sources/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/oscillator-sources/</guid><description>&lt;h1 id="oscillator-sources--internal-rc-vs-external-crystal"&gt;Oscillator Sources — Internal RC vs External Crystal&lt;a class="anchor" href="#oscillator-sources--internal-rc-vs-external-crystal"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every microcontroller needs a clock source, and the choice between internal RC oscillators, external crystals, and MEMS oscillators determines accuracy, startup speed, cost, and board complexity. The tradeoffs are well-defined: internal RC is free and fast to start but imprecise, while an external crystal is accurate but adds components and startup delay. Understanding when each source is sufficient — and when it is not — prevents both over-engineering simple projects and under-specifying timing-critical ones.&lt;/p&gt;</description></item><item><title>OTA Firmware Updates</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/</guid><description>&lt;h1 id="ota-firmware-updates"&gt;OTA Firmware Updates&lt;a class="anchor" href="#ota-firmware-updates"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Over-the-air (OTA) firmware updates allow deployed devices to receive new firmware without physical access or debug probes. The update lifecycle spans far more than the actual flash write — it involves delivery infrastructure, transport protocols, image verification, partition management, and rollback strategies that determine whether a fleet of thousands stays healthy or bricks itself simultaneously. The low-level bootloader mechanics (dual-bank flash, boot swap, vector table relocation) are covered in &lt;a href="https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/flash-and-boot/"&gt;Flashing &amp;amp; Boot Modes&lt;/a&gt;. This page focuses on the system-level update pipeline: how firmware images move from a build server to a running device and what happens when something goes wrong along the way.&lt;/p&gt;</description></item><item><title>PCM, WAV &amp; Raw Audio</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/pcm-wav-raw-audio/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/pcm-wav-raw-audio/</guid><description>&lt;h1 id="pcm-wav--raw-audio"&gt;PCM, WAV &amp;amp; Raw Audio&lt;a class="anchor" href="#pcm-wav--raw-audio"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;PCM (Pulse Code Modulation) is the standard representation of uncompressed digital audio — a sequence of numeric samples, each representing the instantaneous amplitude of the audio waveform at a regular time interval. Every other audio format either is PCM (WAV, AIFF) or compresses PCM (MP3, Opus, ADPCM). On an MCU, PCM is the native format: I2S peripherals produce and consume PCM, DMA buffers hold PCM, and DSP functions operate on PCM. Understanding PCM encoding conventions — signedness, endianness, bit depth, and channel interleaving — prevents the class of bugs where audio plays but sounds like static, plays at the wrong pitch, or has swapped channels.&lt;/p&gt;</description></item><item><title>Photodiodes &amp; Phototransistors</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/photodiodes-and-phototransistors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/photodiodes-and-phototransistors/</guid><description>&lt;h1 id="photodiodes--phototransistors"&gt;Photodiodes &amp;amp; Phototransistors&lt;a class="anchor" href="#photodiodes--phototransistors"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Photodiodes and phototransistors are the fundamental transducers for converting optical radiation into electrical signals. A photodiode generates a photocurrent proportional to incident light intensity, while a phototransistor amplifies that photocurrent internally, trading bandwidth for higher output. Choosing between them — and designing the analog front-end correctly — determines the sensitivity, speed, and linearity of the entire optical measurement chain.&lt;/p&gt;
&lt;h2 id="photodiode-operating-modes"&gt;Photodiode Operating Modes&lt;a class="anchor" href="#photodiode-operating-modes"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A silicon photodiode can operate in two distinct modes, each with different characteristics.&lt;/p&gt;</description></item><item><title>Pin Configuration Across HALs</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/pin-configuration-across-hals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/pin-configuration-across-hals/</guid><description>&lt;h1 id="pin-configuration-across-hals"&gt;Pin Configuration Across HALs&lt;a class="anchor" href="#pin-configuration-across-hals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every GPIO pin on every MCU needs at least three decisions before it does anything useful: direction (input or output), output type (push-pull or open-drain), and pull resistor state (up, down, or none). Some families add speed class and alternate function mapping. The register layouts differ wildly across vendors, and the HAL abstractions differ even more. Understanding what each layer actually configures — and what it silently defaults — prevents the class of bugs where a pin &amp;ldquo;should work&amp;rdquo; but the mode register is wrong.&lt;/p&gt;</description></item><item><title>PWM Speed Control</title><link>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/pwm-speed-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/pwm-speed-control/</guid><description>&lt;h1 id="pwm-speed-control"&gt;PWM Speed Control&lt;a class="anchor" href="#pwm-speed-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A brushed DC motor&amp;rsquo;s speed is approximately proportional to the average voltage across its terminals. Rather than varying a supply voltage directly — which wastes power as heat in a linear regulator — the standard embedded approach is pulse-width modulation: a transistor switches the full supply voltage on and off at a fixed frequency, and the motor&amp;rsquo;s inductance smooths the pulsed current into a nearly steady flow. The duty cycle sets the effective voltage, and therefore the speed.&lt;/p&gt;</description></item><item><title>Quantization</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/quantization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/quantization/</guid><description>&lt;h1 id="quantization"&gt;Quantization&lt;a class="anchor" href="#quantization"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Quantization reduces the numerical precision of a neural network&amp;rsquo;s weights and activations from the default float32 representation to a lower-precision format — typically int8, float16, or int4. A float32 model stores each parameter as a 32-bit IEEE 754 floating-point number. Converting those parameters to int8 reduces model size by 4x (from 4 bytes per weight to 1 byte), decreases memory bandwidth during inference by the same factor, and enables hardware-accelerated integer arithmetic on devices with int8 support — including Arm Cortex-M with CMSIS-NN, dedicated NPUs (Ethos-U55/U65, Hailo-8), Edge TPU, and GPU int8 tensor cores on Jetson platforms.&lt;/p&gt;</description></item><item><title>RC Servo Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/rc-servo-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/rc-servo-fundamentals/</guid><description>&lt;h1 id="rc-servo-fundamentals"&gt;RC Servo Fundamentals&lt;a class="anchor" href="#rc-servo-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An RC servo is a self-contained position actuator: a small DC motor, a gear train, a position-sensing potentiometer, and a control circuit — all in one package. The control interface is a single PWM signal where the pulse width commands a shaft angle. No encoder, no PID tuning, no motor driver — just a pulse and the servo moves. This simplicity makes RC servos the standard actuator for hobby robotics, pan/tilt camera mounts, valve control, and any application needing moderate-precision angular positioning without a custom servo loop.&lt;/p&gt;</description></item><item><title>Regulators — LDO vs Switching</title><link>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/regulators-ldo-vs-switching/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/regulators-ldo-vs-switching/</guid><description>&lt;h1 id="regulators--ldo-vs-switching"&gt;Regulators — LDO vs Switching&lt;a class="anchor" href="#regulators--ldo-vs-switching"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every embedded system needs at least one voltage regulator to convert a supply rail into the clean, stable voltage the MCU and its peripherals require. The two fundamental topologies — linear (LDO) and switching — differ in efficiency, noise, size, and cost. Choosing the wrong one wastes power, introduces noise into sensitive circuits, or generates more heat than the board can dissipate.&lt;/p&gt;
&lt;h2 id="ldo-fundamentals"&gt;LDO Fundamentals&lt;a class="anchor" href="#ldo-fundamentals"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A low-dropout regulator (LDO) works by burning excess voltage as heat. The power dissipated is straightforward: P = (Vin - Vout) * Iload. Converting 5V to 3.3V at 200mA dissipates (5 - 3.3) * 0.2 = 340mW — manageable in a SOT-223 package. Converting 12V to 3.3V at the same current dissipates 1.74W, which exceeds most small-package thermal limits without a copper pour or heatsink.&lt;/p&gt;</description></item><item><title>Reverse Polarity Protection</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/reverse-polarity-protection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/reverse-polarity-protection/</guid><description>&lt;h1 id="reverse-polarity-protection"&gt;Reverse Polarity Protection&lt;a class="anchor" href="#reverse-polarity-protection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A reversed power connection — swapped battery leads, a barrel jack plugged into the wrong supply, or a miswired harness — drives current backward through the regulator and downstream ICs, often destroying them in milliseconds. Reverse polarity protection prevents this by blocking or redirecting the reversed current path before it reaches any active component. The choice of protection method involves a direct trade-off between voltage drop, power dissipation, cost, and quiescent current.&lt;/p&gt;</description></item><item><title>SBC &amp; Compute Module Selection Guide</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/sbc-selection-guide/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/sbc-selection-guide/</guid><description>&lt;h1 id="sbc--compute-module-selection-guide"&gt;SBC &amp;amp; Compute Module Selection Guide&lt;a class="anchor" href="#sbc--compute-module-selection-guide"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Once a project points toward an MPU or SBC rather than a bare-metal MCU — see
&lt;a href="https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/mcu-vs-mpu/"&gt;MCU vs MPU&lt;/a&gt; for the decision boundary — the next
question becomes which platform fits the application requirements. The
single-board computer and compute module market has expanded well beyond the
Raspberry Pi, and different boards optimize for different axes: raw compute,
GPU/NPU acceleration, real-time I/O, power efficiency, production readiness, or
simply ecosystem maturity and community support.&lt;/p&gt;</description></item><item><title>Single-End Injection</title><link>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/single-end-injection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/single-end-injection/</guid><description>&lt;h1 id="single-end-injection"&gt;Single-End Injection&lt;a class="anchor" href="#single-end-injection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Single-end injection is the default wiring approach: power enters the LED strip at one end, and current flows through the strip&amp;rsquo;s copper traces to reach every LED. It works well for short strips at moderate brightness, but voltage drop along the thin PCB traces creates a brightness gradient that becomes visible surprisingly quickly — often within the first meter at full white.&lt;/p&gt;
&lt;h2 id="how-voltage-drop-manifests"&gt;How Voltage Drop Manifests&lt;a class="anchor" href="#how-voltage-drop-manifests"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;An addressable LED strip is effectively a long, thin copper trace carrying the full current load of every LED downstream. The WS2812B&amp;rsquo;s copper power traces are typically 1oz (35µm) copper, roughly 10mm wide, giving a resistance of approximately 0.1–0.2Ω per meter depending on the strip manufacturer. A 60 LED/m strip at full white draws about 3.6A per meter. By Ohm&amp;rsquo;s law, a 2-meter run drops 0.72–1.44V across the power traces — enough to pull the far end below the WS2812B&amp;rsquo;s minimum operating voltage of ~3.5V.&lt;/p&gt;</description></item><item><title>Sleep Modes &amp; Wake Sources</title><link>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/sleep-modes-and-wake-sources/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/sleep-modes-and-wake-sources/</guid><description>&lt;h1 id="sleep-modes--wake-sources"&gt;Sleep Modes &amp;amp; Wake Sources&lt;a class="anchor" href="#sleep-modes--wake-sources"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Modern microcontrollers offer a hierarchy of sleep modes, each trading off recovery time and peripheral availability against current draw. An STM32L4 running at 80 MHz draws roughly 100 µA/MHz in Run mode — around 8 mA — but can drop below 1 µA in Standby and under 30 nA in Shutdown. An ESP32-S3 consuming 240 mA during Wi-Fi TX settles to 8 µA in deep sleep and 5 µA in hibernation. An nRF52840 pulling 4.6 mA at 64 MHz in active mode drops to 1.5 µA in System ON idle with RAM retained, and 0.4 µA in System OFF. The key to a power-optimized design is selecting the deepest sleep mode that still preserves enough state to resume quickly when a wake event arrives.&lt;/p&gt;</description></item><item><title>Solar Cell Integration</title><link>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/solar-cell-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/solar-cell-integration/</guid><description>&lt;h1 id="solar-cell-integration"&gt;Solar Cell Integration&lt;a class="anchor" href="#solar-cell-integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Small solar panels — ranging from thumbnail-sized 25mm x 25mm indoor cells to 100mm x 150mm outdoor modules — serve as the primary energy source for most harvesting-powered embedded systems. Unlike utility-scale photovoltaics where peak wattage dominates the specification, embedded solar integration revolves around matching the panel&amp;rsquo;s output voltage and current to the input requirements of a harvesting IC under the actual illumination conditions the product will encounter. A panel that delivers 200mW under full sun may produce only 200uW under office lighting, a 1000:1 reduction that changes every design decision downstream.&lt;/p&gt;</description></item><item><title>Solenoid Drive Circuits</title><link>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/solenoid-drive-circuits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/solenoid-drive-circuits/</guid><description>&lt;h1 id="solenoid-drive-circuits"&gt;Solenoid Drive Circuits&lt;a class="anchor" href="#solenoid-drive-circuits"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A solenoid is an electromagnet with a movable plunger — apply current and the plunger pulls in (or pushes out); remove current and a return spring resets it. The electrical interface is simple (a coil), but the drive circuit must handle the inductive energy stored in the coil when current is interrupted. A solenoid coil storing even modest energy (½LI²) can generate voltage spikes of hundreds of volts when the drive transistor turns off — enough to destroy MOSFETs, upset nearby logic, and weld relay contacts.&lt;/p&gt;</description></item><item><title>SPI Mode Configuration &amp; Clock Polarity</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-mode-configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-mode-configuration/</guid><description>&lt;h1 id="spi-mode-configuration--clock-polarity"&gt;SPI Mode Configuration &amp;amp; Clock Polarity&lt;a class="anchor" href="#spi-mode-configuration--clock-polarity"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;SPI communication hinges on two clock parameters — polarity and phase — that together define four operating modes. Every SPI device datasheet specifies which mode the device expects, and a mismatch by even one bit produces garbled data or complete silence. The mode must be set before the first clock edge leaves the master, and once a transfer is in progress, the mode cannot change until the bus returns to idle.&lt;/p&gt;</description></item><item><title>SSD1306 — The Ubiquitous OLED</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/ssd1306-basics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/ssd1306-basics/</guid><description>&lt;h1 id="ssd1306--the-ubiquitous-oled"&gt;SSD1306 — The Ubiquitous OLED&lt;a class="anchor" href="#ssd1306--the-ubiquitous-oled"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The SSD1306 is to OLEDs what the HD44780 is to character LCDs — the one that shows up first in every embedded project. These tiny monochrome OLED modules (usually 0.96&amp;quot; at 128x64 or 0.91&amp;quot; at 128x32) appear in every &amp;ldquo;getting started with displays&amp;rdquo; tutorial for good reason: they&amp;rsquo;re cheap (often under $3), need no backlight since OLEDs are self-emitting, have excellent contrast, and work over I²C with just four wires. For small status displays, sensor readouts, or debug output, they&amp;rsquo;re hard to beat.&lt;/p&gt;</description></item><item><title>Stepper Types &amp; Wiring</title><link>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/stepper-types-and-wiring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/stepper-types-and-wiring/</guid><description>&lt;h1 id="stepper-types--wiring"&gt;Stepper Types &amp;amp; Wiring&lt;a class="anchor" href="#stepper-types--wiring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Stepper motors come in several physical constructions — permanent magnet, variable reluctance, and hybrid — but in embedded practice, the vast majority are &lt;strong&gt;hybrid steppers&lt;/strong&gt; in NEMA 17 or NEMA 23 frames, with 200 steps per revolution (1.8° per step). The critical distinction for wiring and drive electronics is between &lt;strong&gt;unipolar&lt;/strong&gt; and &lt;strong&gt;bipolar&lt;/strong&gt; configurations, which determine how many wires the motor has and what type of driver is required.&lt;/p&gt;</description></item><item><title>Sub-GHz Radio Modules (LoRa, FSK)</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/sub-ghz-radio-modules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/sub-ghz-radio-modules/</guid><description>&lt;h1 id="sub-ghz-radio-modules-lora-fsk"&gt;Sub-GHz Radio Modules (LoRa, FSK)&lt;a class="anchor" href="#sub-ghz-radio-modules-lora-fsk"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Sub-GHz radios occupy the frequency bands below 1 GHz — typically 433 MHz, 868 MHz (EU), and 915 MHz (US/AU) — where RF propagation favors long range over high data rate. The dominant IC family in this space is Semtech&amp;rsquo;s SX127x (SX1276, SX1278) and the newer SX1262, found on popular breakout modules like the HopeRF RFM95W and RFM96W. These devices communicate with a host MCU over SPI and support two distinct modulation schemes: LoRa (a proprietary CSS — chirp spread spectrum — modulation) and traditional FSK/OOK packet engines. The firmware integration pattern is similar across the family: configure registers over SPI, load a FIFO buffer, trigger transmission, and wait for a DIO interrupt to signal completion.&lt;/p&gt;</description></item><item><title>SWD, JTAG &amp; Debug Probes</title><link>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/swd-jtag-and-debug-probes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/swd-jtag-and-debug-probes/</guid><description>&lt;h1 id="swd-jtag--debug-probes"&gt;SWD, JTAG &amp;amp; Debug Probes&lt;a class="anchor" href="#swd-jtag--debug-probes"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Debug access to a microcontroller requires a physical interface between the host toolchain and the target silicon. The two dominant protocols — SWD and JTAG — differ in pin count, capability, and ecosystem support. Choosing the right debug probe and wiring it correctly determines whether breakpoints, flash programming, and register inspection work reliably or not at all.&lt;/p&gt;
&lt;h2 id="swd--serial-wire-debug"&gt;SWD — Serial Wire Debug&lt;a class="anchor" href="#swd--serial-wire-debug"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;SWD is an ARM-specific two-wire protocol using SWDIO (bidirectional data) and SWCLK (clock). It provides full debug access — breakpoints, watchpoints, flash programming, and register read/write — over just two signal lines plus ground. SWD clock speeds typically run at 1-4 MHz for reliable operation, though many probes support up to 10 MHz on short traces. The protocol also carries SWO (Serial Wire Output) on an optional third pin, enabling trace output without additional UART hardware.&lt;/p&gt;</description></item><item><title>Temperature Sensing (NTC, RTD, Digital)</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/temperature-sensing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/temperature-sensing/</guid><description>&lt;h1 id="temperature-sensing-ntc-rtd-digital"&gt;Temperature Sensing (NTC, RTD, Digital)&lt;a class="anchor" href="#temperature-sensing-ntc-rtd-digital"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Temperature is the most commonly measured physical quantity in embedded systems. The sensor choices span a wide range — from a 5-cent NTC thermistor read through an ADC to a calibrated digital IC reporting millidegree resolution over I2C. Each technology carries distinct tradeoffs in accuracy, cost, interface complexity, and self-heating. Selecting the right sensor for a given application depends on understanding these tradeoffs at the hardware level, not just the headline accuracy number from a datasheet.&lt;/p&gt;</description></item><item><title>TensorFlow Lite Micro</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-micro/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-micro/</guid><description>&lt;h1 id="tensorflow-lite-micro"&gt;TensorFlow Lite Micro&lt;a class="anchor" href="#tensorflow-lite-micro"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;TensorFlow Lite for Microcontrollers (TFLM) is an inference runtime designed for bare-metal environments where there is no operating system, no heap allocator, and as little as 16 KB of RAM. The runtime loads a pre-trained model stored as a FlatBuffer in flash memory, allocates all intermediate tensor storage from a single pre-allocated byte array (the tensor arena), and executes the model&amp;rsquo;s operations sequentially through a lightweight interpreter. There is no dynamic memory allocation at any point during inference — every byte comes from the arena, and the arena size is fixed at compile time. This makes TFLM deterministic and suitable for hard real-time systems, but it also means the developer bears full responsibility for sizing the arena correctly and registering exactly the operators the model requires.&lt;/p&gt;</description></item><item><title>Time-Series Classification</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/time-series-classification/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/time-series-classification/</guid><description>&lt;h1 id="time-series-classification"&gt;Time-Series Classification&lt;a class="anchor" href="#time-series-classification"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Time-series classification maps a fixed-length window of sensor data to a discrete class label — a gesture type, an activity state, a machine operating condition. The input is a sequence of sensor readings sampled at a known rate, and the output is a categorical decision: swipe left, swipe right, walking, running, bearing fault, normal operation. Unlike image classification where spatial structure is the dominant signal, time-series classification depends on temporal patterns — the shape, frequency content, and evolution of the signal over the window duration.&lt;/p&gt;</description></item><item><title>Timer Prescaler &amp; Auto-Reload Arithmetic</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/timer-prescaler-arithmetic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/timer-prescaler-arithmetic/</guid><description>&lt;h1 id="timer-prescaler--auto-reload-arithmetic"&gt;Timer Prescaler &amp;amp; Auto-Reload Arithmetic&lt;a class="anchor" href="#timer-prescaler--auto-reload-arithmetic"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every timer application on an MCU — whether generating a 50 Hz servo pulse, triggering a 1 ms systick interrupt, or counting encoder edges — begins with two registers: the prescaler (PSC) and the auto-reload (ARR). Together with the timer clock source, these two values determine the timer&amp;rsquo;s overflow frequency. Getting the arithmetic wrong produces timing errors that compile cleanly, run without faults, and silently generate the wrong frequency.&lt;/p&gt;</description></item><item><title>USB Power Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-power-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-power-fundamentals/</guid><description>&lt;h1 id="usb-power-fundamentals"&gt;USB Power Fundamentals&lt;a class="anchor" href="#usb-power-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;USB power delivery has evolved through several specification revisions, each increasing the available current and introducing new detection mechanisms. What started as a simple 5V bus with a 100mA default has grown into a system that can advertise up to 3A at 5V through passive resistor configuration alone — before any digital negotiation takes place. Understanding each layer of this evolution is essential for embedded power design, because a device that fails to detect its source type correctly may draw too little current (leaving charging performance on the table) or attempt to draw too much (causing the source to shut down or the cable to overheat).&lt;/p&gt;</description></item><item><title>VLAN Segmentation</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/vlan-segmentation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/vlan-segmentation/</guid><description>&lt;h1 id="vlan-segmentation"&gt;VLAN Segmentation&lt;a class="anchor" href="#vlan-segmentation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Virtual LANs (VLANs) partition a single physical network into multiple isolated broadcast domains at Layer 2. For IoT deployments, VLAN segmentation is the primary mechanism for keeping device traffic separate from enterprise systems, guest networks, and management infrastructure. Without segmentation, every device on the network shares a single broadcast domain — a compromised temperature sensor can ARP-scan the entire subnet and reach file servers, printers, and databases. IEEE 802.1Q is the standard that makes this isolation possible by inserting a 4-byte tag into Ethernet frames to identify which VLAN each frame belongs to.&lt;/p&gt;</description></item><item><title>WiFi Fundamentals for Embedded</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-fundamentals/</guid><description>&lt;h1 id="wifi-fundamentals-for-embedded"&gt;WiFi Fundamentals for Embedded&lt;a class="anchor" href="#wifi-fundamentals-for-embedded"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;WiFi on a microcontroller is a fundamentally different engineering problem than WiFi on a laptop or phone. The same 802.11 protocol runs, but the MCU operates with 256–520 KB of SRAM instead of gigabytes, a single-core processor running at 160–240 MHz instead of multi-GHz multi-core CPUs, and a power budget measured in milliamps from a coin cell or small LiPo. The result is that theoretical 802.11n throughput of 150 Mbps has no relevance — real MCU throughput ceilings sit between 2 and 20 Mbps depending on the platform, and the practical bottleneck is almost always the TCP/IP stack, TLS overhead, or available heap, not the radio.&lt;/p&gt;</description></item><item><title>Wireless Protocol Selection Guide</title><link>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/protocol-comparison/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/protocol-comparison/</guid><description>&lt;h1 id="wireless-protocol-selection-guide"&gt;Wireless Protocol Selection Guide&lt;a class="anchor" href="#wireless-protocol-selection-guide"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Selecting a wireless protocol for an embedded product is a binding decision — it determines the radio silicon, antenna design, firmware stack, certification requirements, and ongoing infrastructure costs. Changing protocols after PCB layout means a board respin, new certifications, and months of rework. The right choice emerges from understanding the trade-off axes that differ across WiFi, BLE, Thread, Zigbee, Sub-GHz (LoRa, Sigfox, Z-Wave), and cellular (LTE-M, NB-IoT), then matching those trade-offs to the specific application&amp;rsquo;s constraints.&lt;/p&gt;</description></item><item><title>WS2812B &amp; SK6812 — One-Wire Protocol</title><link>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/ws2812b-and-sk6812/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/ws2812b-and-sk6812/</guid><description>&lt;h1 id="ws2812b--sk6812--one-wire-protocol"&gt;WS2812B &amp;amp; SK6812 — One-Wire Protocol&lt;a class="anchor" href="#ws2812b--sk6812--one-wire-protocol"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The WS2812B is the LED that launched a thousand LED projects. Each package integrates a controller and RGB (or RGBW in the SK6812 variant) emitters in a single 5050-size SMD footprint, with data cascading from one LED to the next over a single wire. The protocol is dead simple in concept — timed high/low pulses encode bits — but the tight timing requirements make it one of the more demanding peripherals to drive from a microcontroller.&lt;/p&gt;</description></item><item><title>2.4 GHz Radio Coexistence</title><link>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/radio-coexistence/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/radio-coexistence/</guid><description>&lt;h1 id="24-ghz-radio-coexistence"&gt;2.4 GHz Radio Coexistence&lt;a class="anchor" href="#24-ghz-radio-coexistence"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The 2.4 GHz ISM band (2.400–2.4835 GHz) is shared by WiFi, BLE, Thread, Zigbee, proprietary radios, microwave ovens, and USB 3.0 interference. When a single product incorporates two or more 2.4 GHz radios — WiFi+BLE on an ESP32, BLE+Thread on an nRF5340, or all three on a SiLabs EFR32 — those radios must coordinate access to avoid mutual interference that degrades throughput, increases latency, and raises power consumption through retransmissions.&lt;/p&gt;</description></item><item><title>2.4 GHz RF (nRF24, Zigbee, Thread)</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/2.4ghz-rf-modules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/2.4ghz-rf-modules/</guid><description>&lt;h1 id="24-ghz-rf-nrf24-zigbee-thread"&gt;2.4 GHz RF (nRF24, Zigbee, Thread)&lt;a class="anchor" href="#24-ghz-rf-nrf24-zigbee-thread"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The 2.4 GHz ISM band is globally available without regional frequency planning, making it the default choice for short-to-medium range embedded RF links. The nRF24L01+ from Nordic Semiconductor is the most widely used standalone 2.4 GHz transceiver in hobbyist and low-volume commercial projects — a simple SPI interface, built-in packet handling, and auto-acknowledgment make it straightforward to integrate. For mesh networking and standards-based interoperability, IEEE 802.15.4 radios (used by Zigbee and Thread) provide a more capable but more complex protocol stack. The firmware integration challenge shifts from raw radio configuration (as with sub-GHz LoRa modules) toward protocol management, address filtering, and network topology.&lt;/p&gt;</description></item><item><title>6LoWPAN: IPv6 over 802.15.4</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/6lowpan/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/6lowpan/</guid><description>&lt;h1 id="6lowpan-ipv6-over-802154"&gt;6LoWPAN: IPv6 over 802.15.4&lt;a class="anchor" href="#6lowpan-ipv6-over-802154"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The fundamental problem is arithmetic. An IPv6 header is 40 bytes. A UDP header is 8 bytes. That is 48 bytes of protocol overhead before a single byte of application data. An IEEE 802.15.4 frame has a maximum size of 127 bytes, and after the MAC header (9–23 bytes depending on addressing mode), frame check sequence (2 bytes), and optional security headers (5–14 bytes), the remaining payload is typically 72–102 bytes. Fitting a 48-byte IPv6+UDP header into an 80-byte payload leaves only 32 bytes for application data — barely enough for a sensor reading.&lt;/p&gt;</description></item><item><title>A2DP Audio Streaming</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/a2dp-audio-streaming/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/a2dp-audio-streaming/</guid><description>&lt;h1 id="a2dp-audio-streaming"&gt;A2DP Audio Streaming&lt;a class="anchor" href="#a2dp-audio-streaming"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A2DP (Advanced Audio Distribution Profile) is the Bluetooth Classic profile for streaming high-quality stereo audio — it is the protocol behind every wireless headphone and Bluetooth speaker. A2DP defines two roles: the &lt;strong&gt;source&lt;/strong&gt; (SRC) sends audio (phone, MCU, media player) and the &lt;strong&gt;sink&lt;/strong&gt; (SNK) receives and plays it (headphones, speaker). An ESP32 can act as either role, enabling projects that stream audio to Bluetooth headphones (source) or receive audio from a phone (sink).&lt;/p&gt;</description></item><item><title>Ambient Light &amp; UV Sensors</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/ambient-light-and-uv-sensors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/ambient-light-and-uv-sensors/</guid><description>&lt;h1 id="ambient-light--uv-sensors"&gt;Ambient Light &amp;amp; UV Sensors&lt;a class="anchor" href="#ambient-light--uv-sensors"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Integrated ambient light sensors (ALS) combine a photodiode, amplifier, ADC, and digital interface into a single package, eliminating the need for external transimpedance amplifier design. These devices report light intensity in raw counts or calibrated lux over I2C, with automatic gain and integration time control for dynamic ranges spanning from fractions of a lux (moonlight) to over 100,000 lux (direct sunlight). UV sensors add UVA/UVB measurement for sunlight exposure monitoring, UV index calculation, and material curing applications.&lt;/p&gt;</description></item><item><title>Anomaly Detection</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/anomaly-detection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/anomaly-detection/</guid><description>&lt;h1 id="anomaly-detection"&gt;Anomaly Detection&lt;a class="anchor" href="#anomaly-detection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Anomaly detection learns what &amp;ldquo;normal&amp;rdquo; looks like and flags deviations. Unlike classification, which requires labeled examples of every category, anomaly detection requires only normal data for training — a form of one-class learning. The model builds a representation of normal operating conditions, and anything that falls outside that representation is flagged as anomalous. This property makes anomaly detection particularly valuable for industrial and embedded applications where collecting labeled fault data is expensive, dangerous, or impossible (a machine cannot be intentionally run to failure just to collect training data).&lt;/p&gt;</description></item><item><title>APA102 &amp; SK9822 — SPI-Based Addressable LEDs</title><link>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/apa102-and-sk9822/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/apa102-and-sk9822/</guid><description>&lt;h1 id="apa102--sk9822--spi-based-addressable-leds"&gt;APA102 &amp;amp; SK9822 — SPI-Based Addressable LEDs&lt;a class="anchor" href="#apa102--sk9822--spi-based-addressable-leds"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The APA102 (and its widely available clone, the SK9822) solves the biggest headache of the WS2812B: timing-critical bit-banging. Instead of a single self-clocking data line, the APA102 uses a standard two-wire SPI interface — clock and data — which means any SPI peripheral can drive it at arbitrary speeds without worrying about nanosecond-level pulse widths. The tradeoff is an extra wire and slightly higher per-LED cost.&lt;/p&gt;</description></item><item><title>Atomic Port Access &amp; Bit-Banding</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/atomic-port-access/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/atomic-port-access/</guid><description>&lt;h1 id="atomic-port-access--bit-banding"&gt;Atomic Port Access &amp;amp; Bit-Banding&lt;a class="anchor" href="#atomic-port-access--bit-banding"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Setting or clearing a GPIO pin seems trivial — until an interrupt fires between the read and the write. The read-modify-write pattern that every C programmer reaches for (&lt;code&gt;GPIOA-&amp;gt;ODR |= (1 &amp;lt;&amp;lt; 5)&lt;/code&gt;) is a concurrency hazard on any system where interrupts can touch the same port. ARM Cortex-M provides two hardware mechanisms to eliminate this: set/clear registers (BSRR) and bit-banding. Understanding when each applies — and what replaces them on newer cores — prevents race conditions that produce intermittent glitches no debugger can catch.&lt;/p&gt;</description></item><item><title>Audio Codec Integration</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/audio-codec-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/audio-codec-integration/</guid><description>&lt;h1 id="audio-codec-integration"&gt;Audio Codec Integration&lt;a class="anchor" href="#audio-codec-integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An external audio codec IC combines an ADC, DAC, headphone/speaker amplifiers, microphone preamplifiers, and analog mixing — all controlled through a digital register interface. The MCU connects to the codec over two separate buses: I2S (or TDM) for audio data, and I2C (sometimes SPI) for configuration and control. Getting both buses configured correctly, with the right clock relationships and power-up sequence, is the core integration challenge. The audio data path is straightforward once the codec is properly initialized; most integration failures trace back to clock misconfiguration or incorrect register settings during startup.&lt;/p&gt;</description></item><item><title>Audio Compression Codecs</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/audio-compression-codecs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/audio-compression-codecs/</guid><description>&lt;h1 id="audio-compression-codecs"&gt;Audio Compression Codecs&lt;a class="anchor" href="#audio-compression-codecs"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Uncompressed PCM audio consumes storage and bandwidth at a fixed, often inconvenient rate — 176 KB/s for CD-quality stereo, 32 KB/s for 16 kHz mono voice. Audio compression codecs reduce this by 4x to 20x, trading CPU cycles for smaller files and lower bitrates. On an MCU, the choice of codec is constrained by CPU budget, RAM availability, and licensing: decoding MP3 on a Cortex-M4 is practical, but encoding Opus in real time requires careful optimization and typically 80+ KB of RAM. The right codec depends on whether the MCU is encoding (recording), decoding (playback), or both, and on the acceptable quality loss.&lt;/p&gt;</description></item><item><title>Azure IoT Hub</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/azure-iot-hub/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/azure-iot-hub/</guid><description>&lt;h1 id="azure-iot-hub"&gt;Azure IoT Hub&lt;a class="anchor" href="#azure-iot-hub"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Azure IoT Hub is Microsoft&amp;rsquo;s managed service for bidirectional communication between IoT devices and the cloud. It provides device authentication, message routing, state synchronization via device twins, command-and-control through direct methods, and fleet-scale provisioning through the Device Provisioning Service (DPS). IoT Edge extends the hub&amp;rsquo;s capabilities to gateway devices running containerized workloads. The platform&amp;rsquo;s device model differs from AWS IoT Core in significant ways — authentication options are broader (connection strings, X.509, TPM), the messaging architecture is built around Event Hubs rather than a pure MQTT broker, and the twin/direct method split separates state management from imperative commands more explicitly.&lt;/p&gt;</description></item><item><title>Blinky &amp; Serial Hello World</title><link>https://applied-ee.github.io/embedded/docs/development/project-bring-up/blinky-and-serial-hello/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/project-bring-up/blinky-and-serial-hello/</guid><description>&lt;h1 id="blinky--serial-hello-world"&gt;Blinky &amp;amp; Serial Hello World&lt;a class="anchor" href="#blinky--serial-hello-world"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Once the hardware is electrically verified, the first firmware milestones are a blinking LED and a serial message. These two tests are not trivial — they validate the entire chain from source code through compiler, linker, flash programming, clock configuration, and GPIO/peripheral initialization. A working blinky proves the MCU is executing code from flash, the system clock is running, and at least one GPIO is correctly configured. A serial hello world adds UART peripheral setup, baud rate generation, and confirms that the toolchain&amp;rsquo;s printf retargeting or low-level write path is functional.&lt;/p&gt;</description></item><item><title>Boost &amp; Buck-Boost Topologies</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/boost-and-buck-boost-topologies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/boost-and-buck-boost-topologies/</guid><description>&lt;h1 id="boost--buck-boost-topologies"&gt;Boost &amp;amp; Buck-Boost Topologies&lt;a class="anchor" href="#boost--buck-boost-topologies"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A single lithium-ion cell delivers 4.2 V at full charge but sags to 3.0 V — or lower under heavy load — at end of discharge. A buck converter regulating 3.3 V output loses regulation once the cell drops below roughly 3.5 V, discarding 15–20 % of the battery&amp;rsquo;s usable energy. Boost converters step voltage up, enabling operation from deeply discharged cells. Buck-boost converters handle both cases — seamlessly stepping down when the cell is above 3.3 V and stepping up when it drops below — extracting nearly the full capacity of the cell. Choosing between boost, buck-boost, and plain buck determines how much runtime the system can extract from a given battery.&lt;/p&gt;</description></item><item><title>Build Systems — Make, CMake &amp; Beyond</title><link>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/build-systems-make-cmake/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/build-systems-make-cmake/</guid><description>&lt;h1 id="build-systems--make-cmake--beyond"&gt;Build Systems — Make, CMake &amp;amp; Beyond&lt;a class="anchor" href="#build-systems--make-cmake--beyond"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A build system turns source files into flashable firmware reproducibly. Without one, every build requires remembering the exact compiler flags, include paths, linker scripts, and object file order — a process that breaks the moment the project moves to a different machine or a new developer. Even a 10-file embedded project benefits from a Makefile; larger projects with multiple libraries and configuration variants need something more structured like CMake or PlatformIO.&lt;/p&gt;</description></item><item><title>Charging ICs &amp; Profiles</title><link>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/charging-ics-and-profiles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/charging-ics-and-profiles/</guid><description>&lt;h1 id="charging-ics--profiles"&gt;Charging ICs &amp;amp; Profiles&lt;a class="anchor" href="#charging-ics--profiles"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Lithium-ion cells require a precise charging algorithm to reach full capacity without exceeding the voltage limits that cause electrolyte decomposition, lithium plating, or thermal runaway. The standard CC/CV (constant-current / constant-voltage) profile has been the industry norm since the early 1990s, and dedicated charging ICs implement this profile with minimal external components. The difference between a safe, long-lived battery system and one that degrades rapidly or catches fire often comes down to the charging IC selection and configuration.&lt;/p&gt;</description></item><item><title>Chip-Select Management</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-chip-select/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-chip-select/</guid><description>&lt;h1 id="chip-select-management"&gt;Chip-Select Management&lt;a class="anchor" href="#chip-select-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The chip-select (CS) line determines which device on a shared SPI bus is active for a given transaction. CS is active-low by convention — asserting CS means driving the pin low, and deasserting means driving it high. Getting CS timing right is the difference between clean SPI communication and intermittent data corruption that only appears under load or at higher clock speeds. Most SPI bugs that appear random are actually CS timing issues.&lt;/p&gt;</description></item><item><title>Clock Gating &amp; Peripheral Power</title><link>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/clock-gating-and-peripheral-power/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/clock-gating-and-peripheral-power/</guid><description>&lt;h1 id="clock-gating--peripheral-power"&gt;Clock Gating &amp;amp; Peripheral Power&lt;a class="anchor" href="#clock-gating--peripheral-power"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Sleep modes reduce current by halting the CPU, but the CPU is only part of the power budget. On an STM32L476 at 80 MHz, the CPU core draws roughly 4.5 mA while the peripheral clocks — GPIO ports, SPI controllers, timers, DMA — collectively draw another 3–4 mA even when idle. Disabling peripheral clocks when not in use, controlling power domains, and configuring GPIO pins for minimal leakage are essential techniques that can cut active-mode current by 30–50% and shave microamps from sleep current that would otherwise dominate the battery budget.&lt;/p&gt;</description></item><item><title>Clock Trees &amp; PLL Configuration</title><link>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/clock-trees-and-plls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/clock-trees-and-plls/</guid><description>&lt;h1 id="clock-trees--pll-configuration"&gt;Clock Trees &amp;amp; PLL Configuration&lt;a class="anchor" href="#clock-trees--pll-configuration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The clock tree is the distribution network that transforms a base oscillator frequency into the various clock domains an MCU needs: a fast system clock for the CPU core, slower bus clocks for peripherals, and dedicated clocks for USB, ADC, and other subsystems. At the center of most clock trees sits a PLL (Phase-Locked Loop) that multiplies the input frequency up to the desired system clock speed. Getting the clock tree wrong produces symptoms ranging from peripherals running at the wrong speed to hard faults from flash access violations.&lt;/p&gt;</description></item><item><title>CoAP</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/coap/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/coap/</guid><description>&lt;h1 id="coap"&gt;CoAP&lt;a class="anchor" href="#coap"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Constrained Application Protocol (CoAP) is a lightweight request/response protocol designed for machine-to-machine communication on constrained networks. Specified in RFC 7252, CoAP runs over UDP instead of TCP, uses a compact binary header (4 bytes fixed, versus HTTP&amp;rsquo;s variable-length text headers that commonly exceed 200 bytes), and maps naturally to REST semantics (GET, PUT, POST, DELETE). A typical CoAP request with a short URI path and small payload fits in a single UDP datagram under 100 bytes — small enough to transmit in a single IEEE 802.15.4 frame (127 bytes maximum at the link layer). This makes CoAP the protocol of choice for devices on 6LoWPAN, Thread, and other constrained networks where MQTT&amp;rsquo;s TCP requirement is either impractical or impossible.&lt;/p&gt;</description></item><item><title>Complementary Filters</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/complementary-filters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/complementary-filters/</guid><description>&lt;h1 id="complementary-filters"&gt;Complementary Filters&lt;a class="anchor" href="#complementary-filters"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A complementary filter fuses two sensor measurements of the same physical quantity by trusting each sensor in its reliable frequency band. The classic application is tilt estimation from a gyroscope and accelerometer: the gyroscope provides accurate short-term angle changes but drifts over time (low-frequency error), while the accelerometer provides a stable long-term gravity reference but is corrupted by vibration and linear acceleration (high-frequency error). Passing the gyroscope through a high-pass filter and the accelerometer through a low-pass filter, with the two filters summing to unity at all frequencies, produces an estimate that rejects both drift and vibration noise. The result is surprisingly effective for a filter that requires only a single tuning parameter.&lt;/p&gt;</description></item><item><title>DAC Audio Output</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/dac-audio-output/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/dac-audio-output/</guid><description>&lt;h1 id="dac-audio-output"&gt;DAC Audio Output&lt;a class="anchor" href="#dac-audio-output"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An on-chip DAC converts digital audio samples back into an analog voltage waveform — the final step before an amplifier drives a speaker or headphone. Many Cortex-M MCUs include one or two 12-bit DAC channels (STM32F4, STM32H7, ESP32, RP2350), which can produce audio output without any external converter IC. The quality ceiling is set by the DAC resolution and output characteristics: a 12-bit DAC provides ~72 dB of theoretical dynamic range (10–11 ENOB in practice), sufficient for voice, notification sounds, and casual audio playback, but noticeably below CD quality for critical listening.&lt;/p&gt;</description></item><item><title>Decoupling &amp; Bypass Capacitors</title><link>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/decoupling-and-bypass/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/decoupling-and-bypass/</guid><description>&lt;h1 id="decoupling--bypass-capacitors"&gt;Decoupling &amp;amp; Bypass Capacitors&lt;a class="anchor" href="#decoupling--bypass-capacitors"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every digital IC draws short, sharp bursts of current on each clock edge as internal transistors switch. These transient demands — often lasting only nanoseconds — cannot be met by a distant voltage regulator through long PCB traces. Decoupling capacitors, placed immediately next to the power pins, act as local charge reservoirs that supply current during these transients and prevent the supply voltage from drooping below the IC&amp;rsquo;s minimum operating level.&lt;/p&gt;</description></item><item><title>Device Provisioning</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/device-provisioning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/device-provisioning/</guid><description>&lt;h1 id="device-provisioning"&gt;Device Provisioning&lt;a class="anchor" href="#device-provisioning"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Device provisioning is the process of assigning a unique identity and initial credentials to a device so it can authenticate to cloud services, peer devices, or local gateways. Provisioning spans from the factory floor — where silicon serial numbers and cryptographic keys are first bound together — through field activation, where a device autonomously enrolls itself into a fleet. A provisioning failure leaves a device either unable to connect at all or, worse, connected with weak or shared credentials that compromise the entire fleet. The low-level secure boot chain and hardware trust anchors overlap with &lt;a href="https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/"&gt;OTA Firmware Updates&lt;/a&gt;, but this page focuses on the identity lifecycle: how a device goes from bare silicon to an authenticated member of a managed fleet.&lt;/p&gt;</description></item><item><title>Embedded OS Landscape</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/embedded-os-landscape/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/embedded-os-landscape/</guid><description>&lt;h1 id="embedded-os-landscape"&gt;Embedded OS Landscape&lt;a class="anchor" href="#embedded-os-landscape"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Once an MPU-class platform is chosen, the operating system defines how applications interact with hardware. The choice spans from full Linux distributions to lightweight RTOSes running on MPU-capable chips. Each option makes tradeoffs across boot time, image size, real-time capability, package availability, and long-term maintainability. Understanding the practical characteristics of each OS option — not just the marketing pitch — is essential for avoiding costly migrations later in a project.&lt;/p&gt;</description></item><item><title>Encoder Feedback</title><link>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/encoder-feedback/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/encoder-feedback/</guid><description>&lt;h1 id="encoder-feedback"&gt;Encoder Feedback&lt;a class="anchor" href="#encoder-feedback"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A rotary encoder converts shaft rotation into electrical signals that the MCU can count, providing real-time position and velocity feedback. In motor control, encoders close the loop between the commanded position and the actual shaft angle — the essential ingredient for servo control, stall detection, and precision positioning. The most common type in embedded systems is the &lt;strong&gt;incremental quadrature encoder&lt;/strong&gt;, which produces two square waves 90° out of phase.&lt;/p&gt;</description></item><item><title>FIR &amp; IIR Filters for Audio</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fir-iir-audio-filters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fir-iir-audio-filters/</guid><description>&lt;h1 id="fir--iir-filters-for-audio"&gt;FIR &amp;amp; IIR Filters for Audio&lt;a class="anchor" href="#fir--iir-filters-for-audio"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Audio filtering on an MCU is dominated by two filter types: FIR (Finite Impulse Response) and IIR (Infinite Impulse Response). FIR filters offer linear phase and unconditional stability but require many taps for sharp cutoffs — a 48 kHz low-pass filter with a narrow transition band may need 200+ taps, each costing one multiply-accumulate per sample. IIR filters achieve equivalent frequency shaping with 5 coefficients (a single biquad section), but introduce phase distortion and can become unstable with quantized fixed-point coefficients. In embedded audio, IIR biquads handle the bulk of the work — EQ, crossovers, high-pass DC removal — while FIR filters appear in sample rate conversion, linear-phase requirements, and anti-aliasing.&lt;/p&gt;</description></item><item><title>Firewalls &amp; ACLs</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/firewall-and-acls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/firewall-and-acls/</guid><description>&lt;h1 id="firewalls--acls"&gt;Firewalls &amp;amp; ACLs&lt;a class="anchor" href="#firewalls--acls"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;VLAN segmentation isolates IoT traffic at Layer 2, but without Layer 3 and Layer 4 enforcement, any device that can route between VLANs has unrestricted access. Firewalls and Access Control Lists (ACLs) enforce what traffic is permitted between IoT subnets, the enterprise network, the internet, and cloud services. The fundamental principle for IoT network security is deny-by-default: no traffic flows between VLANs unless an explicit rule permits it. This inverts the typical enterprise approach where internal networks are broadly trusted, because IoT devices — running firmware that may be months behind on patches, with limited TLS capability, and often deployed in physically accessible locations — represent a fundamentally different threat profile than managed workstations.&lt;/p&gt;</description></item><item><title>Flyback &amp; Snubber Protection</title><link>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/flyback-and-snubber-protection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/flyback-and-snubber-protection/</guid><description>&lt;h1 id="flyback--snubber-protection"&gt;Flyback &amp;amp; Snubber Protection&lt;a class="anchor" href="#flyback--snubber-protection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every inductive load in this section — motors, solenoids, relays, and actuators — stores energy in a magnetic field. When the current through the inductance is interrupted (FET turns off, relay opens), the stored energy (E = ½LI²) must go somewhere. Without a designed dissipation path, the inductance forces the voltage across the switch to spike upward until it finds a path: avalanche breakdown of the MOSFET, arcing across relay contacts, or conduction through parasitic paths. Protection circuits provide a controlled energy dissipation path that clamps the voltage to a safe level.&lt;/p&gt;</description></item><item><title>Font Rendering on Embedded Displays</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/font-rendering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/font-rendering/</guid><description>&lt;h1 id="font-rendering-on-embedded-displays"&gt;Font Rendering on Embedded Displays&lt;a class="anchor" href="#font-rendering-on-embedded-displays"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Text is the most common thing displayed on embedded screens, and the font rendering approach directly affects readability, aesthetics, and memory consumption. There&amp;rsquo;s a surprising amount of depth here beyond the default 5x7 pixel font that ships with every beginner library.&lt;/p&gt;
&lt;h2 id="bitmap-fonts"&gt;Bitmap Fonts&lt;a class="anchor" href="#bitmap-fonts"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The simplest and most common approach on MCUs: each glyph is stored as a fixed grid of pixels (a bitmap). A 5x7 font uses 7 bytes per character (one byte per row, with 5 bits used). A full 96-character ASCII set in 5x7 takes about 672 bytes of flash — trivial. Larger fonts consume more: a 16x24 font for the same character set is about 4.5KB. Bitmap fonts render fast (just copy pixels), scale poorly (they look terrible at non-native sizes), and have fixed spacing.&lt;/p&gt;</description></item><item><title>Full vs. Partial Refresh</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/full-vs-partial-refresh/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/full-vs-partial-refresh/</guid><description>&lt;h1 id="full-vs-partial-refresh"&gt;Full vs. Partial Refresh&lt;a class="anchor" href="#full-vs-partial-refresh"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The refresh behavior of E-Ink displays is where most of the practical complexity lives. Understanding the difference between full and partial refresh — and the tradeoffs involved — is essential for building E-Ink projects that look good and preserve display health.&lt;/p&gt;
&lt;h2 id="full-refresh"&gt;Full Refresh&lt;a class="anchor" href="#full-refresh"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A full refresh cycles every pixel through a complete sequence: typically white → black → white → target color (or a similar multi-step waveform). This takes 2-4 seconds on most modules and produces the characteristic &amp;ldquo;flash&amp;rdquo; effect. The advantage is that every pixel is fully driven to its correct state — no ghosting, no artifacts, crisp contrast. Full refresh is the &amp;ldquo;clean slate&amp;rdquo; operation.&lt;/p&gt;</description></item><item><title>GATT Services &amp; Characteristics</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/gatt-services/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/gatt-services/</guid><description>&lt;h1 id="gatt-services--characteristics"&gt;GATT Services &amp;amp; Characteristics&lt;a class="anchor" href="#gatt-services--characteristics"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Generic Attribute Profile (GATT) is the framework that organizes all data exchange over a BLE connection. Every piece of information — a temperature reading, a firmware version string, a configuration parameter — is exposed through a structured hierarchy of services, characteristics, and descriptors. GATT determines how a central discovers what a peripheral offers, how data is read and written, and how the peripheral pushes updates without being polled. Getting GATT design right is the difference between a device that pairs seamlessly with phone apps and one that requires custom protocol documentation and fragile byte-level parsing.&lt;/p&gt;</description></item><item><title>Gyroscopes &amp; Angular Rate</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/gyroscopes-and-angular-rate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/gyroscopes-and-angular-rate/</guid><description>&lt;h1 id="gyroscopes--angular-rate"&gt;Gyroscopes &amp;amp; Angular Rate&lt;a class="anchor" href="#gyroscopes--angular-rate"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;MEMS gyroscopes measure angular rate — degrees per second (dps) — rather than absolute angle. This distinction is the central firmware challenge: to obtain an angle, the angular rate must be integrated over time, and every integration step accumulates error from bias drift, noise, and timing jitter. Understanding gyroscope error sources and their magnitudes is essential before attempting any orientation estimation, whether for a drone flight controller, a robotic arm, or an inertial navigation unit.&lt;/p&gt;</description></item><item><title>H-Bridge Circuits</title><link>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/h-bridge-circuits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/h-bridge-circuits/</guid><description>&lt;h1 id="h-bridge-circuits"&gt;H-Bridge Circuits&lt;a class="anchor" href="#h-bridge-circuits"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An H-bridge is four switches arranged in an &amp;ldquo;H&amp;rdquo; topology around a motor, allowing current to flow through the motor in either direction. By activating diagonal pairs of switches, the bridge reverses the motor&amp;rsquo;s polarity without changing the supply wiring. This is the standard circuit for bidirectional DC motor control, and it appears in everything from toy cars to industrial drives.&lt;/p&gt;
&lt;h2 id="basic-h-bridge-topology"&gt;Basic H-Bridge Topology&lt;a class="anchor" href="#basic-h-bridge-topology"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt; V+
 │
 ┌────┴────┐
 │ │
 Q1(HS) Q3(HS)
 │ │
 ├── Motor ─┤
 │ │
 Q2(LS) Q4(LS)
 │ │
 └────┬────┘
 │
 GND&lt;/code&gt;&lt;/pre&gt;&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;State&lt;/th&gt;
 &lt;th&gt;Q1&lt;/th&gt;
 &lt;th&gt;Q2&lt;/th&gt;
 &lt;th&gt;Q3&lt;/th&gt;
 &lt;th&gt;Q4&lt;/th&gt;
 &lt;th&gt;Motor&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Forward&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;CW rotation&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Reverse&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;CCW rotation&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Brake (low-side)&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;ON&lt;/td&gt;
 &lt;td&gt;Shorted to GND — dynamic braking&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Coast&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;OFF&lt;/td&gt;
 &lt;td&gt;Freewheeling — motor coasts&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;h2 id="shoot-through-protection"&gt;Shoot-Through Protection&lt;a class="anchor" href="#shoot-through-protection"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;If both the high-side and low-side switches in the same leg turn on simultaneously, a dead short appears across the supply — often called shoot-through. This can destroy MOSFETs in microseconds. Protection requires &lt;strong&gt;dead time&lt;/strong&gt;: a brief interval (typically 0.5–2 µs) where both switches in a leg are off before the complementary switch turns on.&lt;/p&gt;</description></item><item><title>Harvesting ICs &amp; MPPT</title><link>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/harvesting-ics-and-mppt/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/harvesting-ics-and-mppt/</guid><description>&lt;h1 id="harvesting-ics--mppt"&gt;Harvesting ICs &amp;amp; MPPT&lt;a class="anchor" href="#harvesting-ics--mppt"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Energy harvesting ICs sit between the transducer (solar cell, TEG, piezo element) and the storage element (supercapacitor or battery), performing three critical functions: maximum power point tracking to extract the most energy from the source, voltage conversion to match the storage element&amp;rsquo;s requirements, and power path management to protect the storage element from overcharge and undercharge. The distinction between a generic boost converter and a harvesting IC lies in the ability to operate from microwatt-level inputs, cold-start from sub-volt sources, and consume nanoamp-level quiescent current when no harvestable energy is available.&lt;/p&gt;</description></item><item><title>High-Side vs Low-Side Sensing</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/high-side-vs-low-side-sensing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/high-side-vs-low-side-sensing/</guid><description>&lt;h1 id="high-side-vs-low-side-sensing"&gt;High-Side vs Low-Side Sensing&lt;a class="anchor" href="#high-side-vs-low-side-sensing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The shunt resistor must go somewhere in the current path — either between the supply and the load (high-side) or between the load and ground (low-side). This choice determines the common-mode voltage the measurement circuit must handle, the complexity of the amplifier, and whether the load&amp;rsquo;s ground connection remains undisturbed. Both topologies are widely used, and each has distinct advantages and failure modes.&lt;/p&gt;
&lt;h2 id="low-side-sensing"&gt;Low-Side Sensing&lt;a class="anchor" href="#low-side-sensing"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;In low-side sensing, the shunt resistor sits between the load&amp;rsquo;s ground return and the system ground plane. The voltage across the shunt is referenced to ground, making it straightforward to measure with a ground-referenced op-amp or a single-ended ADC input.&lt;/p&gt;</description></item><item><title>HSV &amp; Color Spaces</title><link>https://applied-ee.github.io/embedded/docs/led-systems/color-management/hsv-and-color-spaces/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/color-management/hsv-and-color-spaces/</guid><description>&lt;h1 id="hsv--color-spaces"&gt;HSV &amp;amp; Color Spaces&lt;a class="anchor" href="#hsv--color-spaces"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;RGB is the native language of addressable LEDs — each pixel takes a red, green, and blue value — but it&amp;rsquo;s a terrible color space for humans to think in. Asking &amp;ldquo;what RGB values make a slightly warmer orange at half brightness?&amp;rdquo; is unintuitive. HSV (Hue, Saturation, Value) separates color identity from brightness and saturation, making it the natural choice for LED animation and color design. Understanding the mapping between color spaces — and the tradeoffs of each — is fundamental to producing predictable LED output.&lt;/p&gt;</description></item><item><title>Humidity &amp; Barometric Pressure</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/humidity-and-barometric-pressure/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/humidity-and-barometric-pressure/</guid><description>&lt;h1 id="humidity--barometric-pressure"&gt;Humidity &amp;amp; Barometric Pressure&lt;a class="anchor" href="#humidity--barometric-pressure"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Humidity and barometric pressure sensors share a common integration story: a MEMS sensing element bonded to a small ASIC that handles excitation, digitization, and compensation, all accessible over I2C or SPI. The BME280 from Bosch is the de facto standard for combined temperature/humidity/pressure measurement in hobbyist and commercial designs alike. Understanding its configuration registers, compensation algorithm, and measurement modes is essential — the same patterns reappear across dozens of similar devices from Sensirion, TE Connectivity, and others.&lt;/p&gt;</description></item><item><title>I2C Backpack Modules</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/i2c-backpacks/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/i2c-backpacks/</guid><description>&lt;h1 id="ic-backpack-modules"&gt;I²C Backpack Modules&lt;a class="anchor" href="#ic-backpack-modules"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most character LCD projects in the last decade use an I²C backpack rather than wiring up the parallel interface directly. These tiny PCBs solder onto the back of a standard HD44780 module and reduce the connection down to four wires: &lt;code&gt;VCC&lt;/code&gt;, &lt;code&gt;GND&lt;/code&gt;, &lt;code&gt;SDA&lt;/code&gt;, and &lt;code&gt;SCL&lt;/code&gt;. The most common chip on these boards is the PCF8574 (or PCF8574A), an 8-bit I/O expander that bit-bangs the HD44780&amp;rsquo;s parallel interface over I²C.&lt;/p&gt;</description></item><item><title>Inference on ESP32</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/esp32-inference/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/esp32-inference/</guid><description>&lt;h1 id="inference-on-esp32"&gt;Inference on ESP32&lt;a class="anchor" href="#inference-on-esp32"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The ESP32 family from Espressif offers a different trade-off from the Cortex-M ecosystem: built-in Wi-Fi and Bluetooth, dual-core processors, external PSRAM support, and a FreeRTOS-based runtime — all at a price point under $5. These features make the ESP32 a natural platform for ML inference applications that need to collect data, run a model, and transmit results over a wireless link without additional networking hardware. The cost is a less deterministic execution environment than bare-metal Cortex-M: FreeRTOS scheduling, Wi-Fi stack interrupts, and shared-bus memory access all introduce latency variability that must be managed through careful task partitioning.&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>ISR Design Rules</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/isr-design-rules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/isr-design-rules/</guid><description>&lt;h1 id="isr-design-rules"&gt;ISR Design Rules&lt;a class="anchor" href="#isr-design-rules"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An interrupt service routine (ISR) runs in exception context with elevated privileges and a hard constraint: every cycle spent inside the handler is a cycle that no other equal-or-lower-priority interrupt can execute. The fundamental design rule is to do the minimum work necessary — capture the event, copy the data, clear the flag — and defer everything else to the main loop or an RTOS task. Violating this rule produces systems that appear to work on the bench but fail under load, miss deadlines, or corrupt shared state in ways that only surface weeks into deployment.&lt;/p&gt;</description></item><item><title>Key Specs That Actually Matter</title><link>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/key-specs-that-matter/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/key-specs-that-matter/</guid><description>&lt;h1 id="key-specs-that-actually-matter"&gt;Key Specs That Actually Matter&lt;a class="anchor" href="#key-specs-that-actually-matter"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;MCU datasheets list hundreds of parameters, but most projects are decided by a handful of specifications that interact with each other. A 200 MHz clock means little if the flash has 5 wait states and no cache. A 12-bit ADC sounds capable until the effective number of bits (ENOB) turns out to be 9.5 at full speed. Learning to read past the headline numbers and focus on the specs that constrain real designs separates productive part selection from spec-sheet paralysis.&lt;/p&gt;</description></item><item><title>Keyword Spotting &amp; Wake Words</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/keyword-spotting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/keyword-spotting/</guid><description>&lt;h1 id="keyword-spotting--wake-words"&gt;Keyword Spotting &amp;amp; Wake Words&lt;a class="anchor" href="#keyword-spotting--wake-words"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Keyword spotting (KWS) is the task of continuously monitoring an audio stream for a small set of target words — typically 1 to 10 commands — while rejecting all other speech, noise, and silence. It is the foundation of voice-activated systems: the always-on listener that decides whether a full &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/speech-recognition/"&gt;speech recognition&lt;/a&gt; pipeline should activate. The engineering challenge is not classification accuracy in isolation — it is achieving high accuracy while running continuously at microwatt-level power for months on a coin cell or years on a small battery.&lt;/p&gt;</description></item><item><title>Linear Actuator Control</title><link>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/linear-actuator-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/linear-actuator-control/</guid><description>&lt;h1 id="linear-actuator-control"&gt;Linear Actuator Control&lt;a class="anchor" href="#linear-actuator-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A linear actuator converts rotary motor motion into linear push/pull motion — typically using a DC motor driving a leadscrew or ball screw inside a sealed tube. The external interface is two wires (motor+ and motor−), and the actuator extends or retracts depending on polarity. Stroke lengths range from 50 mm to 1000+ mm, with force ratings from 50 N (light duty) to 10,000+ N (industrial). From the embedded control perspective, a linear actuator is a bidirectional DC motor with end stops — the control circuitry is an H-bridge, and the primary challenges are knowing the current position and protecting the actuator at end of travel.&lt;/p&gt;</description></item><item><title>Long-Run Data Lines</title><link>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/long-run-data-lines/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/long-run-data-lines/</guid><description>&lt;h1 id="long-run-data-lines"&gt;Long-Run Data Lines&lt;a class="anchor" href="#long-run-data-lines"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The data signal from an MCU to the first LED in a strip — and between distant strip segments — degrades over distance. Capacitance, inductance, and resistance in the cable attenuate edges, reduce voltage swing, and introduce ringing. For WS2812B strips with their tight timing windows, even a few meters of unshielded wire can turn a clean signal into unreliable garbage. Understanding what happens to the signal over distance, and how to mitigate it, is essential for any installation where the controller isn&amp;rsquo;t mounted right next to the strip.&lt;/p&gt;</description></item><item><title>Memory-to-Peripheral &amp; Peripheral-to-Memory</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-transfer-directions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-transfer-directions/</guid><description>&lt;h1 id="memory-to-peripheral--peripheral-to-memory"&gt;Memory-to-Peripheral &amp;amp; Peripheral-to-Memory&lt;a class="anchor" href="#memory-to-peripheral--peripheral-to-memory"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every DMA transfer has a source, a destination, and a set of rules governing how addresses advance and how data widths are matched. The three fundamental directions — peripheral-to-memory, memory-to-peripheral, and memory-to-memory — cover nearly every use case in embedded firmware. Getting the direction, increment mode, or data alignment wrong produces transfers that appear to work but deliver corrupted or shifted data.&lt;/p&gt;
&lt;h2 id="transfer-directions"&gt;Transfer Directions&lt;a class="anchor" href="#transfer-directions"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;DMA direction is configured from the perspective of the DMA controller:&lt;/p&gt;</description></item><item><title>Menus &amp; Navigation Patterns</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/menus-and-navigation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/menus-and-navigation/</guid><description>&lt;h1 id="menus--navigation-patterns"&gt;Menus &amp;amp; Navigation Patterns&lt;a class="anchor" href="#menus--navigation-patterns"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Once an embedded display shows more than a single static value, navigation is needed — a way to access different screens, change settings, or trigger actions. The input devices on embedded projects (typically buttons and rotary encoders) are far more limited than a touchscreen, which makes the navigation design both more important and more constrained.&lt;/p&gt;
&lt;h2 id="rotary-encoder--button"&gt;Rotary Encoder + Button&lt;a class="anchor" href="#rotary-encoder--button"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The rotary encoder with an integrated push button is the most versatile input device for small-screen UIs. Rotation scrolls through options, and the button confirms a selection. This maps naturally to list menus: rotate to highlight an item, press to enter. For value editing, the same pattern works: press to start editing a parameter, rotate to change the value, press to confirm.&lt;/p&gt;</description></item><item><title>Message Filtering &amp; FIFO Management</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-filtering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-filtering/</guid><description>&lt;h1 id="message-filtering--fifo-management"&gt;Message Filtering &amp;amp; FIFO Management&lt;a class="anchor" href="#message-filtering--fifo-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A busy CAN bus carries hundreds of distinct message IDs at rates exceeding 5,000 frames per second. Without hardware filtering, firmware must inspect every frame in software, consuming CPU cycles and risking FIFO overruns during high-load bursts. The STM32 bxCAN peripheral provides configurable hardware filter banks that discard irrelevant messages before they reach the receive FIFOs, ensuring the CPU only processes frames the application actually needs.&lt;/p&gt;</description></item><item><title>Metrics &amp; Dashboards</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/metrics-dashboards/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/metrics-dashboards/</guid><description>&lt;h1 id="metrics--dashboards"&gt;Metrics &amp;amp; Dashboards&lt;a class="anchor" href="#metrics--dashboards"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Metrics are numeric measurements sampled at regular intervals — CPU usage, battery voltage, RSSI, heap free bytes, message throughput. Unlike logs (discrete events with variable content), metrics are structured, compact, and designed for time-series aggregation. A fleet of 10,000 devices reporting 8 metrics every 60 seconds generates 480,000 data points per minute, or roughly 700 million per day. This write-heavy, append-only workload demands infrastructure purpose-built for time-series data: efficient ingestion, columnar compression, and query engines optimized for range scans and aggregations over time windows.&lt;/p&gt;</description></item><item><title>Multi-Byte Read/Write Patterns</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-multi-byte-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-multi-byte-patterns/</guid><description>&lt;h1 id="multi-byte-readwrite-patterns"&gt;Multi-Byte Read/Write Patterns&lt;a class="anchor" href="#multi-byte-readwrite-patterns"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most I²C devices expose a register-based interface: a write transaction sends the register address, and a read transaction retrieves the data at that address. The protocol detail that makes this work is the repeated start condition — a start without a preceding stop — which allows the master to switch from write mode (sending the register address) to read mode (receiving data) without releasing the bus. Nearly every sensor, EEPROM, and I/O expander uses this pattern, and understanding the transaction structure at the byte level is essential for debugging transfers that silently return stale or incorrect data.&lt;/p&gt;</description></item><item><title>Multi-Point Injection</title><link>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/multi-point-injection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/multi-point-injection/</guid><description>&lt;h1 id="multi-point-injection"&gt;Multi-Point Injection&lt;a class="anchor" href="#multi-point-injection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Multi-point injection adds power connections at multiple locations along a strip, reducing the maximum distance any LED sits from a power feed point. This is the standard approach for any installation longer than about a meter at full brightness, and it&amp;rsquo;s the single most effective technique for eliminating the color shift and dimming caused by voltage drop.&lt;/p&gt;
&lt;h2 id="how-it-works"&gt;How It Works&lt;a class="anchor" href="#how-it-works"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Instead of relying on the strip&amp;rsquo;s thin PCB traces to carry current for the entire run, additional VDD and GND wires are soldered to the strip at regular intervals. Each injection point creates a &amp;ldquo;zone&amp;rdquo; where current flows from the nearest power tap rather than traveling through the full length of the strip&amp;rsquo;s internal copper. The data line remains a single continuous chain — only power is injected at multiple points, not signal.&lt;/p&gt;</description></item><item><title>Object Detection</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/object-detection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/object-detection/</guid><description>&lt;h1 id="object-detection"&gt;Object Detection&lt;a class="anchor" href="#object-detection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Object detection localizes and classifies multiple objects within a single image, producing a set of bounding boxes, each with a class label and confidence score. Unlike &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/image-classification/"&gt;image classification&lt;/a&gt;, which assigns one label to the entire frame, detection answers both &amp;ldquo;what&amp;rdquo; and &amp;ldquo;where&amp;rdquo; for every object of interest. This makes it the foundation for camera-based counting, tracking, safety monitoring, and autonomous navigation on edge platforms. The computational cost is substantially higher than classification — a detection model must evaluate spatial features at multiple scales and apply post-processing to filter and deduplicate predictions — making model selection and pipeline optimization critical for real-time performance on constrained hardware.&lt;/p&gt;</description></item><item><title>Overvoltage &amp; TVS Diodes</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/overvoltage-and-tvs-diodes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/overvoltage-and-tvs-diodes/</guid><description>&lt;h1 id="overvoltage--tvs-diodes"&gt;Overvoltage &amp;amp; TVS Diodes&lt;a class="anchor" href="#overvoltage--tvs-diodes"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Voltage transients — ESD strikes, inductive load switching, cable plugging, and lightning-induced surges — routinely exceed the absolute maximum ratings of microcontrollers and interface ICs. A 3.3V GPIO rated for 4.0V absolute maximum will not survive a 15kV ESD event that couples through a connector. TVS (transient voltage suppressor) diodes clamp these transients to safe levels in nanoseconds, absorbing the energy before it reaches the protected IC. Proper TVS selection and placement is one of the most cost-effective reliability investments in embedded hardware.&lt;/p&gt;</description></item><item><title>Palette-Based Animation</title><link>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/palette-based-animation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/palette-based-animation/</guid><description>&lt;h1 id="palette-based-animation"&gt;Palette-Based Animation&lt;a class="anchor" href="#palette-based-animation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Instead of storing full RGB values for every pixel in every animation, palette-based systems store a small set of colors (the palette) and reference those colors by index. This reduces memory consumption, simplifies color scheme changes, and enables smooth gradient effects with minimal computation. The technique is borrowed from 8-bit and 16-bit era graphics systems, where limited memory made full-color framebuffers impractical, and it maps naturally to the constraints of LED programming on microcontrollers.&lt;/p&gt;</description></item><item><title>PDM &amp; I2S Audio Interfaces</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/pdm-and-i2s-audio-interfaces/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/pdm-and-i2s-audio-interfaces/</guid><description>&lt;h1 id="pdm--i2s-audio-interfaces"&gt;PDM &amp;amp; I2S Audio Interfaces&lt;a class="anchor" href="#pdm--i2s-audio-interfaces"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Streaming audio data from a digital microphone to an MCU requires a well-defined serial protocol. Two dominate embedded audio: PDM (Pulse Density Modulation), which carries a 1-bit sigma-delta bitstream at megahertz clock rates, and I2S (Inter-IC Sound), which carries multi-bit PCM samples in a synchronous frame format. The choice between them affects peripheral selection, CPU load, memory bandwidth, and firmware complexity. PDM is simpler in hardware (two wires) but requires decimation filtering that consumes either a dedicated hardware peripheral or significant CPU cycles. I2S delivers ready-to-use PCM samples but requires three signal lines and a more complex peripheral configuration.&lt;/p&gt;</description></item><item><title>Pruning &amp; Knowledge Distillation</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/pruning-distillation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/pruning-distillation/</guid><description>&lt;h1 id="pruning--knowledge-distillation"&gt;Pruning &amp;amp; Knowledge Distillation&lt;a class="anchor" href="#pruning--knowledge-distillation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Quantization reduces the precision of every weight in a model. Pruning and knowledge distillation take a different approach: they reduce the &lt;strong&gt;number&lt;/strong&gt; of computations the model performs — pruning by removing redundant weights or structures, and distillation by training a smaller model to approximate a larger one. Both techniques require some form of retraining, which makes them more involved than post-training &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/quantization/"&gt;quantization&lt;/a&gt;, but they address cases where quantization alone cannot meet the latency or size target.&lt;/p&gt;</description></item><item><title>PWM Controllers</title><link>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/pwm-controllers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/pwm-controllers/</guid><description>&lt;h1 id="pwm-controllers"&gt;PWM Controllers&lt;a class="anchor" href="#pwm-controllers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Pulse-width modulation is the universal technique for dimming LEDs. Rather than reducing the current (which shifts the LED&amp;rsquo;s color), PWM switches the LED fully on and fully off at a frequency high enough that the eye perceives an average brightness proportional to the duty cycle. A 50% duty cycle at 1kHz looks like half brightness — the LED flickers 1000 times per second, far faster than the eye can track. Dedicated PWM controller ICs generate these signals precisely, freeing the MCU from timing-critical output tasks.&lt;/p&gt;</description></item><item><title>PWM Generation Patterns</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/pwm-generation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/pwm-generation/</guid><description>&lt;h1 id="pwm-generation-patterns"&gt;PWM Generation Patterns&lt;a class="anchor" href="#pwm-generation-patterns"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;PWM output is the most common timer application in embedded systems — LED dimming, motor speed control, servo positioning, and switch-mode power supply gate drive all rely on precisely timed high/low transitions. The STM32 timer peripheral generates hardware PWM without CPU intervention once configured: the counter free-runs, the output compare unit toggles the pin, and the CPU only intervenes to change the duty cycle. Getting from &amp;ldquo;a PWM signal exists&amp;rdquo; to &amp;ldquo;a production-quality PWM driver&amp;rdquo; requires understanding output compare modes, complementary outputs, dead-time insertion, and the break input — all of which live in timer registers, not software loops.&lt;/p&gt;</description></item><item><title>Raspberry Pi AI HAT+</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/raspberry-pi-ai-hat/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/raspberry-pi-ai-hat/</guid><description>&lt;h1 id="raspberry-pi-ai-hat"&gt;Raspberry Pi AI HAT+&lt;a class="anchor" href="#raspberry-pi-ai-hat"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Raspberry Pi AI HAT+ adds a Hailo-8L NPU to the Raspberry Pi 5, delivering 13 TOPS of INT8 inference throughput in an M.2 form factor mounted on a HAT+ (Hardware Attached on Top) board. The NPU connects over PCIe Gen 2 x1 — the first Pi to expose a PCIe lane for add-on hardware. This combination transforms the Pi 5 from a platform that struggles with real-time neural network inference into one that runs YOLOv8n object detection at 30+ FPS while the Arm CPU handles camera capture, display, and application logic.&lt;/p&gt;</description></item><item><title>Rotary &amp; Linear Encoders</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/rotary-and-linear-encoders/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/rotary-and-linear-encoders/</guid><description>&lt;h1 id="rotary--linear-encoders"&gt;Rotary &amp;amp; Linear Encoders&lt;a class="anchor" href="#rotary--linear-encoders"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Encoders convert mechanical motion into digital signals that an MCU can count, enabling precise measurement of position, angle, and velocity. Incremental encoders produce a stream of pulses as the shaft or carriage moves — the MCU counts pulses for position and measures pulse timing for velocity. Absolute encoders report the current angle or position directly as a digital word, requiring no power-on homing cycle. The interface ranges from simple quadrature pulse trains (two GPIO pins) to SPI/SSI serial buses for multi-turn absolute encoders. STM32 timers have dedicated encoder mode hardware that handles quadrature decoding entirely in hardware, eliminating software overhead and missed-count risks at high speeds.&lt;/p&gt;</description></item><item><title>Serial Debug Output — UART, SWO &amp; RTT</title><link>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/serial-debug-output/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/serial-debug-output/</guid><description>&lt;h1 id="serial-debug-output--uart-swo--rtt"&gt;Serial Debug Output — UART, SWO &amp;amp; RTT&lt;a class="anchor" href="#serial-debug-output--uart-swo--rtt"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Getting runtime information out of a microcontroller is fundamental to firmware development. Three approaches dominate: UART-based printf, ARM&amp;rsquo;s SWO trace output, and SEGGER&amp;rsquo;s RTT memory-based transfer. Each trades off pin usage, throughput, timing distortion, and toolchain dependency differently. Understanding these tradeoffs determines whether debug output is helpful or actively misleading.&lt;/p&gt;
&lt;h2 id="uart-debug-output"&gt;UART Debug Output&lt;a class="anchor" href="#uart-debug-output"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The most common debug channel uses a UART peripheral retargeted to &lt;code&gt;printf()&lt;/code&gt; via a syscall stub (e.g., &lt;code&gt;_write()&lt;/code&gt; on GCC/Newlib or &lt;code&gt;fputc()&lt;/code&gt; on Keil). Typical baud rates range from 115200 to 921600. At 115200 baud, a 64-byte message takes roughly 5.5 ms to transmit — long enough to distort millisecond-scale timing. A USB-to-serial adapter (CP2102, CH340, FTDI FT232) bridges the UART to the host. DMA-backed UART transmission reduces CPU blocking: the firmware queues a buffer and returns immediately, but the output still occupies the wire at baud-rate speed. UART debug requires two dedicated pins (TX/RX) and is available on virtually every MCU.&lt;/p&gt;</description></item><item><title>SH1106 &amp; Other Controllers</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/sh1106-and-alternatives/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/sh1106-and-alternatives/</guid><description>&lt;h1 id="sh1106--other-controllers"&gt;SH1106 &amp;amp; Other Controllers&lt;a class="anchor" href="#sh1106--other-controllers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The SSD1306 gets all the attention, but it&amp;rsquo;s not the only OLED controller out there. The SH1106 is probably the second most common, and there are a handful of others worth knowing about — especially beyond the 128x64 monochrome sweet spot. Understanding the differences matters because using the wrong driver for a controller produces garbled output or nothing at all, and the modules often look physically identical.&lt;/p&gt;</description></item><item><title>Signal Conditioning Circuits</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/signal-conditioning-circuits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/signal-conditioning-circuits/</guid><description>&lt;h1 id="signal-conditioning-circuits"&gt;Signal Conditioning Circuits&lt;a class="anchor" href="#signal-conditioning-circuits"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The voltage at a sensor&amp;rsquo;s output is rarely in the right form for direct connection to an ADC pin. It may exceed the ADC&amp;rsquo;s reference voltage, have too high an output impedance, carry noise at frequencies that alias into the measurement band, or swing below ground. Signal conditioning — the analog circuitry between the sensor and the ADC — scales, buffers, filters, and protects the signal so that the digitized result faithfully represents the physical quantity being measured.&lt;/p&gt;</description></item><item><title>Six-Step Commutation</title><link>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/six-step-commutation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/six-step-commutation/</guid><description>&lt;h1 id="six-step-commutation"&gt;Six-Step Commutation&lt;a class="anchor" href="#six-step-commutation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Six-step (trapezoidal) commutation is the simplest method for driving a BLDC motor. At any instant, two of the three phases are energized (one high, one low) while the third floats. As the rotor advances through 60° electrical increments, the firmware switches to the next commutation state. The sequence repeats every 360° electrical — six states per electrical revolution, hence the name. This approach requires only six discrete switching states and can be driven from three Hall-effect sensors or sensorless back-EMF detection.&lt;/p&gt;</description></item><item><title>SPI Configuration &amp; Wiring</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/spi-configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/spi-configuration/</guid><description>&lt;h1 id="spi-configuration--wiring"&gt;SPI Configuration &amp;amp; Wiring&lt;a class="anchor" href="#spi-configuration--wiring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;TFT displays over SPI involve more wires and more configuration choices than I²C OLEDs. Getting the SPI mode, clock speed, and control pins right is essential — misconfiguring any one of them produces a white screen, garbled colors, or nothing at all.&lt;/p&gt;
&lt;h2 id="pin-connections"&gt;Pin Connections&lt;a class="anchor" href="#pin-connections"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A typical TFT SPI module exposes these pins:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;SCK / CLK&lt;/strong&gt; — SPI clock&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;MOSI / SDA / DIN&lt;/strong&gt; — data from MCU to display (naming varies wildly across modules)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;CS / SS&lt;/strong&gt; — chip select, active low&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;DC / RS / A0&lt;/strong&gt; — data/command select; high = pixel data, low = command bytes&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;RST / RES&lt;/strong&gt; — hardware reset, active low&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;BLK / LED&lt;/strong&gt; — backlight control&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;MISO / SDO&lt;/strong&gt; — data from display to MCU (optional, often unused)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The &lt;code&gt;DC&lt;/code&gt; pin is the one that distinguishes TFT SPI from normal SPI peripherals. The display needs to know whether each byte is a command (like &amp;ldquo;set column address&amp;rdquo;) or data (like pixel values). This pin toggles between the two, and the driver must manage it in sync with the SPI transfers. Libraries handle this, but it means TFT displays don&amp;rsquo;t play nicely with generic SPI abstraction layers that don&amp;rsquo;t account for the DC pin.&lt;/p&gt;</description></item><item><title>SPI Ethernet Modules</title><link>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/spi-ethernet-modules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/spi-ethernet-modules/</guid><description>&lt;h1 id="spi-ethernet-modules"&gt;SPI Ethernet Modules&lt;a class="anchor" href="#spi-ethernet-modules"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Not every MCU has an integrated Ethernet MAC. Many popular platforms — RP2040, STM32F1/L4, nRF52, ATmega — lack native Ethernet. SPI-attached Ethernet controllers bridge this gap by providing a complete MAC + PHY + magnetics interface accessible over a standard 4-wire SPI bus. Two chips dominate this space: the WIZnet W5500, which offloads the entire TCP/IP stack into hardware, and the Microchip ENC28J60, which provides only raw Ethernet frame access and relies on the host MCU to run a software TCP/IP stack like lwIP.&lt;/p&gt;</description></item><item><title>Stack, Heap &amp; Static Allocation</title><link>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/stack-heap-and-static/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/stack-heap-and-static/</guid><description>&lt;h1 id="stack-heap--static-allocation"&gt;Stack, Heap &amp;amp; Static Allocation&lt;a class="anchor" href="#stack-heap--static-allocation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;All runtime data on a Cortex-M lives in SRAM, and it gets divided into three categories: static allocations (globals and statics, known at link time), the stack (function calls and local variables, growing downward), and the heap (dynamic allocations via malloc, growing upward). On a device with 64 KB of SRAM, these three regions share the space with no MMU and no protection — when one grows into another, the result is silent data corruption, not a clean segfault.&lt;/p&gt;</description></item><item><title>Station Mode &amp; Connection Management</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/station-mode/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/station-mode/</guid><description>&lt;h1 id="station-mode--connection-management"&gt;Station Mode &amp;amp; Connection Management&lt;a class="anchor" href="#station-mode--connection-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Station mode (STA) is the most common WiFi operating mode for embedded devices — the MCU acts as a client connecting to an existing access point, just like a laptop or phone. The engineering challenge is not the initial connection but everything that follows: handling disconnections gracefully, reconnecting without user intervention, adapting to changing RF conditions, and managing the connection lifecycle across power states. A device that connects once on the bench is a demo. A device that maintains connectivity through AP reboots, channel changes, signal fading, and DHCP lease renewals over months of unattended operation is a product.&lt;/p&gt;</description></item><item><title>Step/Direction Interface</title><link>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/step-direction-interface/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/step-direction-interface/</guid><description>&lt;h1 id="stepdirection-interface"&gt;Step/Direction Interface&lt;a class="anchor" href="#stepdirection-interface"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The step/direction interface is the standard control protocol between a microcontroller and a stepper driver IC. Two signals control motion: a &lt;strong&gt;STEP&lt;/strong&gt; pulse advances the motor by one (micro)step, and a &lt;strong&gt;DIR&lt;/strong&gt; level sets the rotation direction. A third signal, &lt;strong&gt;ENABLE&lt;/strong&gt;, activates or deactivates the driver&amp;rsquo;s output stage. This simple protocol decouples motion planning in firmware from the power electronics in the driver, and it is used by virtually every stepper driver from the A4988 to industrial servo drives.&lt;/p&gt;</description></item><item><title>TensorFlow Lite for Linux</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-linux/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-linux/</guid><description>&lt;h1 id="tensorflow-lite-for-linux"&gt;TensorFlow Lite for Linux&lt;a class="anchor" href="#tensorflow-lite-for-linux"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;TensorFlow Lite (TFLite) on Linux is the full-featured inference runtime for edge devices with an operating system, a filesystem, and megabytes to gigabytes of RAM. Unlike &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-micro/"&gt;TensorFlow Lite Micro&lt;/a&gt;, which targets bare-metal microcontrollers with static memory allocation, TFLite for Linux uses dynamic memory, supports multi-threaded inference, and — critically — provides a &lt;strong&gt;delegate architecture&lt;/strong&gt; that offloads computation to hardware accelerators like GPUs, NPUs, and DSPs. This delegate system is what makes TFLite viable on platforms ranging from a Raspberry Pi 4 running object detection on the CPU to a Jetson Orin Nano offloading an entire model graph to TensorRT.&lt;/p&gt;</description></item><item><title>USB PD Negotiation</title><link>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-pd-negotiation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-pd-negotiation/</guid><description>&lt;h1 id="usb-pd-negotiation"&gt;USB PD Negotiation&lt;a class="anchor" href="#usb-pd-negotiation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;USB Power Delivery (PD) is a digital protocol that runs over the CC pin of a USB Type-C connection, enabling source and sink to negotiate voltage and current levels far beyond the 5V default. PD uses Biphase Mark Coding (BMC) at 300 kbaud to exchange structured messages that describe what the source can provide and what the sink wants to consume. The protocol is layered — a physical layer handles encoding and signaling, a protocol layer manages message framing and CRC, and a policy layer implements the negotiation state machine.&lt;/p&gt;</description></item><item><title>Alerting</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/alerting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/alerting/</guid><description>&lt;h1 id="alerting"&gt;Alerting&lt;a class="anchor" href="#alerting"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Alerting bridges the gap between passive dashboards and active incident response. A Grafana dashboard showing that 200 devices went offline is useful only if someone happens to be looking at it. An alerting pipeline detects the condition automatically, evaluates whether it warrants human attention, routes the notification to the right team through the right channel, and provides enough context for the responder to act without first spending 20 minutes reconstructing what happened. For IoT fleets, alerting must handle both individual device failures (a single sensor node with a dead battery) and fleet-wide events (a firmware rollout causing boot loops across 5% of devices) — two very different patterns that require different routing, grouping, and suppression strategies.&lt;/p&gt;</description></item><item><title>AMQP</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/amqp/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/messaging-protocols/amqp/</guid><description>&lt;h1 id="amqp"&gt;AMQP&lt;a class="anchor" href="#amqp"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Advanced Message Queuing Protocol (AMQP) is an open standard for message-oriented middleware that provides reliable, broker-mediated messaging with sophisticated routing capabilities. AMQP 0-9-1 (the version implemented by RabbitMQ and most IoT-relevant deployments) defines a rich model of &lt;strong&gt;exchanges&lt;/strong&gt;, &lt;strong&gt;queues&lt;/strong&gt;, and &lt;strong&gt;bindings&lt;/strong&gt; that gives the broker fine-grained control over how messages flow from producers to consumers. Where MQTT provides a simple topic-based publish/subscribe model, AMQP offers programmable routing logic at the broker level — direct routing, pattern matching, fan-out, and header-based filtering are all native protocol features. This flexibility comes at a cost: AMQP&amp;rsquo;s minimum frame overhead is 8 bytes (versus MQTT&amp;rsquo;s 2 bytes), a typical connection handshake exchanges ~7 frames before the first message can flow, and the protocol assumes a reliable TCP transport with sufficient memory for queue management. For IoT, AMQP occupies a specific niche: it is rarely the right choice for constrained end devices, but it excels at edge gateways and backend processing stages where message routing complexity justifies the overhead.&lt;/p&gt;</description></item><item><title>Analog Microphone Front-Ends</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/analog-microphone-front-ends/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/analog-microphone-front-ends/</guid><description>&lt;h1 id="analog-microphone-front-ends"&gt;Analog Microphone Front-Ends&lt;a class="anchor" href="#analog-microphone-front-ends"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Electret condenser microphones (ECMs) remain relevant in embedded systems despite the rise of MEMS alternatives. ECMs are inexpensive ($0.10-0.50), available in a wide range of form factors (6 mm capsules through large-diaphragm studio types), and produce an analog signal that can be read by any MCU with an ADC channel. The challenge is that the raw output from an ECM is tiny — typically 5-50 mV peak for normal speech — and rides on a DC bias that must be stripped before amplification. A proper analog front-end includes biasing, coupling, preamplification, DC offset for single-supply operation, and anti-alias filtering before the ADC. Each stage has concrete design choices that determine whether the captured audio is clean or buried in noise.&lt;/p&gt;</description></item><item><title>Arduino &amp; Edge Impulse</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/arduino-edge-impulse/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/arduino-edge-impulse/</guid><description>&lt;h1 id="arduino--edge-impulse"&gt;Arduino &amp;amp; Edge Impulse&lt;a class="anchor" href="#arduino--edge-impulse"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Edge Impulse is an end-to-end development platform for embedded machine learning. It provides a web-based Studio interface that covers the entire pipeline: data collection from physical sensors, signal processing configuration, neural network training, model validation, and deployment as a compiled library for Arduino, ESP32, STM32, Nordic nRF, and other microcontroller targets. The platform abstracts much of the complexity of quantization, memory fitting, and operator optimization, making it possible to go from raw sensor data to a running inference on an Arduino Nano 33 BLE Sense or an ESP32-S3 DevKit without writing any training code or manually configuring TensorFlow Lite.&lt;/p&gt;</description></item><item><title>BLE Bonding &amp; Security</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-bonding-security/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-bonding-security/</guid><description>&lt;h1 id="ble-bonding--security"&gt;BLE Bonding &amp;amp; Security&lt;a class="anchor" href="#ble-bonding--security"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;BLE security is frequently misunderstood and frequently misconfigured. The protocol provides a layered security model — pairing establishes trust, encryption protects data in transit, and bonding stores keys for future reconnections without re-pairing. The challenge is that BLE&amp;rsquo;s default mode (Just Works pairing) provides encryption but no authentication, meaning a man-in-the-middle (MITM) attack is trivially possible during the pairing process. Understanding the security model at the protocol level is essential for choosing the right trade-off between usability, security, and firmware complexity.&lt;/p&gt;</description></item><item><title>Charge Pumps &amp; Rail Generation</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/charge-pumps-and-rail-generation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/charge-pumps-and-rail-generation/</guid><description>&lt;h1 id="charge-pumps--rail-generation"&gt;Charge Pumps &amp;amp; Rail Generation&lt;a class="anchor" href="#charge-pumps--rail-generation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Not every rail in an embedded system needs an inductor-based converter. Charge pumps generate auxiliary voltages — doubled, inverted, or fractionally scaled — using only capacitors and switches. When current requirements are modest (under 100–200 mA) and magnetic EMI is a concern, charge pumps offer a smaller, quieter, and often cheaper alternative to inductors. Negative voltage rails for op-amp symmetric supplies, boosted rails for LED gate drivers, and bias voltages for MEMS sensors are classic charge-pump applications in battery-powered systems.&lt;/p&gt;</description></item><item><title>Choosing an LED Strip</title><link>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/choosing-led-strips/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/addressable-led-architectures/choosing-led-strips/</guid><description>&lt;h1 id="choosing-an-led-strip"&gt;Choosing an LED Strip&lt;a class="anchor" href="#choosing-an-led-strip"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Picking the right addressable LED strip means balancing pixel density, color capability, protocol complexity, power requirements, and budget. The decision isn&amp;rsquo;t just about which chip is &amp;ldquo;best&amp;rdquo; — it&amp;rsquo;s about which constraints matter most for a given project. A POV display has different needs than a room ambient light, and a battery-powered wearable has different needs than a permanent architectural installation.&lt;/p&gt;
&lt;h2 id="led-density-and-package-size"&gt;LED Density and Package Size&lt;a class="anchor" href="#led-density-and-package-size"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Addressable strips come in standard densities: 30, 60, 96, 144, and occasionally 200 LEDs per meter. Higher density means smoother color gradients and fewer visible gaps between pixels, but also higher power draw per meter and higher data throughput requirements. A 144 LED/m WS2812B strip at full white draws roughly 8.6A per meter at 5V — a 5-meter run would need over 43A, which is impractical without power injection.&lt;/p&gt;</description></item><item><title>Circular &amp; Double-Buffer Modes</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-circular-double-buffer/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-circular-double-buffer/</guid><description>&lt;h1 id="circular--double-buffer-modes"&gt;Circular &amp;amp; Double-Buffer Modes&lt;a class="anchor" href="#circular--double-buffer-modes"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Single-shot DMA transfers work for one-time operations like sending a command over SPI, but continuous data streams — ADC sampling, audio I/O, sensor logging — require the DMA controller to keep running indefinitely. Circular mode and double-buffer mode solve this by automatically reloading the transfer and providing mechanisms to process completed data without stopping the stream.&lt;/p&gt;
&lt;h2 id="circular-mode"&gt;Circular Mode&lt;a class="anchor" href="#circular-mode"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;In circular mode, the DMA stream automatically reloads the transfer count (NDTR) and resets the memory pointer to the buffer base address when the current transfer completes. The stream never stops — it wraps around to the beginning of the buffer and continues filling.&lt;/p&gt;</description></item><item><title>Clock Output &amp; Measurement</title><link>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/clock-output-and-measurement/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/clock-output-and-measurement/</guid><description>&lt;h1 id="clock-output--measurement"&gt;Clock Output &amp;amp; Measurement&lt;a class="anchor" href="#clock-output--measurement"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Verifying that the clock tree is configured correctly requires measuring actual frequencies, not just trusting register settings. Most STM32 and other ARM Cortex-M microcontrollers provide MCO (Microcontroller Clock Output) pins that route internal clock signals to a GPIO, making them directly measurable with an oscilloscope or frequency counter. This capability turns clock debugging from guesswork into straightforward measurement.&lt;/p&gt;
&lt;h2 id="mco-pin-configuration"&gt;MCO Pin Configuration&lt;a class="anchor" href="#mco-pin-configuration"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;MCO pins output a selectable internal clock source on a standard GPIO. On STM32F4 devices, MCO1 (PA8) can output HSI, HSE, LSE, or the PLL clock, while MCO2 (PC9) can output SYSCLK, PLLI2S, HSE, or the PLL clock. Each MCO has a configurable prescaler (1, 2, 3, 4, or 5) to bring high-frequency clocks within range of measurement equipment.&lt;/p&gt;</description></item><item><title>Color Formats &amp; Pixel Packing</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/color-formats/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/color-formats/</guid><description>&lt;h1 id="color-formats--pixel-packing"&gt;Color Formats &amp;amp; Pixel Packing&lt;a class="anchor" href="#color-formats--pixel-packing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Color representation on embedded displays is surprisingly tricky beyond &amp;ldquo;set this pixel to red.&amp;rdquo; The display controller expects pixels in a specific binary format, and getting the byte ordering or bit packing wrong produces psychedelic but incorrect output. Understanding RGB565, RGB666, and the endianness gotchas saves real debugging time.&lt;/p&gt;
&lt;h2 id="rgb565"&gt;RGB565&lt;a class="anchor" href="#rgb565"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;RGB565 is the most common color format for embedded TFTs. Each pixel is 16 bits: 5 bits red, 6 bits green, 5 bits blue (green gets the extra bit because human eyes are more sensitive to green). The bit layout in a 16-bit value is:&lt;/p&gt;</description></item><item><title>Common E-Ink Modules</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/common-modules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/e-ink/common-modules/</guid><description>&lt;h1 id="common-e-ink-modules"&gt;Common E-Ink Modules&lt;a class="anchor" href="#common-e-ink-modules"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The E-Ink module market is dominated by a few manufacturers who package electrophoretic display panels with driver boards aimed at hobbyists and product developers. Knowing the major players and their module conventions saves time when selecting hardware and finding compatible libraries.&lt;/p&gt;
&lt;h2 id="waveshare"&gt;Waveshare&lt;a class="anchor" href="#waveshare"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Waveshare is probably the most visible E-Ink module brand in the hobbyist space. They offer a wide range of sizes (1.54&amp;quot;, 2.13&amp;quot;, 2.9&amp;quot;, 4.2&amp;quot;, 7.5&amp;quot; and larger), colors (black/white, black/white/red, black/white/yellow), and interface options. Their modules typically come with an FPC cable and a breakout board with SPI pins clearly labeled. Documentation quality varies but is generally adequate, and they provide example code for Arduino, Raspberry Pi, and STM32.&lt;/p&gt;</description></item><item><title>Common Wiring Problems</title><link>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/common-wiring-problems/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/signal-integrity/common-wiring-problems/</guid><description>&lt;h1 id="common-wiring-problems"&gt;Common Wiring Problems&lt;a class="anchor" href="#common-wiring-problems"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most LED project failures are wiring failures, not firmware failures. The symptoms are often confusing — random colors, flickering, partial strip operation, intermittent glitches — and they lead to hours of software debugging before someone finally puts a multimeter on the power rail and discovers a 1.5V drop. Understanding the common failure modes, their symptoms, and their root causes saves enormous amounts of troubleshooting time.&lt;/p&gt;
&lt;h2 id="missing-common-ground"&gt;Missing Common Ground&lt;a class="anchor" href="#missing-common-ground"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The single most common wiring mistake: forgetting to connect the ground of the MCU to the ground of the LED strip when they&amp;rsquo;re powered from separate supplies. The data signal is referenced to ground — if the MCU&amp;rsquo;s ground and the strip&amp;rsquo;s ground are at different potentials, the effective signal voltage seen by the first LED is unpredictable. Symptoms range from complete non-operation to erratic random colors that change with touch (a human body provides a capacitive ground path).&lt;/p&gt;</description></item><item><title>Current Profiling Techniques</title><link>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/current-profiling-techniques/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/current-profiling-techniques/</guid><description>&lt;h1 id="current-profiling-techniques"&gt;Current Profiling Techniques&lt;a class="anchor" href="#current-profiling-techniques"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Measuring the current consumption of a battery-powered embedded device is not as simple as reading a multimeter. A typical firmware duty cycle involves sub-microsecond transitions between sleep (1 µA), active processing (5 mA), and radio transmission (120 mA) — a dynamic range of 100,000:1 that no single instrument captures perfectly. Dedicated current profiling tools like the Nordic Power Profiler Kit II (PPK2) and Qoitech Otii Arc exist specifically for this problem, while a shunt resistor and oscilloscope remain the most flexible approach for capturing fast transients. The goal is always the same: correlate every feature in the current waveform to a specific firmware state, so that each microamp in the power budget is accounted for.&lt;/p&gt;</description></item><item><title>Current Sensing &amp; Limiting</title><link>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/current-sensing-and-limiting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/current-sensing-and-limiting/</guid><description>&lt;h1 id="current-sensing--limiting"&gt;Current Sensing &amp;amp; Limiting&lt;a class="anchor" href="#current-sensing--limiting"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Knowing how much current a motor draws — and being able to limit it — is essential for protecting both the motor and the drive electronics. Stall current in a brushed DC motor can be 5–10× the running current; a 12 V motor with 1 Ω winding resistance pulls 12 A at stall, even if it runs at 1–2 A under normal load. Without current limiting, a stall event can overheat windings, saturate H-bridge MOSFETs, blow fuses, or trip power supplies.&lt;/p&gt;</description></item><item><title>Current Sensing Techniques</title><link>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/current-sensing-techniques/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/current-sensing-techniques/</guid><description>&lt;h1 id="current-sensing-techniques"&gt;Current Sensing Techniques&lt;a class="anchor" href="#current-sensing-techniques"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Measuring the current flowing through a motor, solenoid, or actuator serves three purposes: protection (overcurrent shutdown), regulation (current-loop control), and diagnostics (load monitoring, stall detection). The choice of sensing method depends on the current range, accuracy requirements, bandwidth, and whether the measurement is on the low side (ground-referenced) or high side (supply-referenced) of the load.&lt;/p&gt;
&lt;h2 id="low-side-shunt-sensing"&gt;Low-Side Shunt Sensing&lt;a class="anchor" href="#low-side-shunt-sensing"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A low-value resistor between the load and ground measures current as a ground-referenced voltage:&lt;/p&gt;</description></item><item><title>Custom Characters &amp; CGRAM</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/custom-characters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/character-lcds/custom-characters/</guid><description>&lt;h1 id="custom-characters--cgram"&gt;Custom Characters &amp;amp; CGRAM&lt;a class="anchor" href="#custom-characters--cgram"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The HD44780 has a lesser-known feature that&amp;rsquo;s surprisingly useful: it supports up to 8 custom characters displayed alongside the built-in font. These live in CGRAM (Character Generator RAM), a small writable area separate from the main character ROM. Each custom character is a 5x8 pixel bitmap, referenced using character codes &lt;code&gt;0x00&lt;/code&gt; through &lt;code&gt;0x07&lt;/code&gt;. It&amp;rsquo;s not much, but it&amp;rsquo;s enough for battery icons, signal bars, custom arrows, or mini progress bars.&lt;/p&gt;</description></item><item><title>Data Visualization on MCUs</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/data-visualization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/ui-layout-patterns/data-visualization/</guid><description>&lt;h1 id="data-visualization-on-mcus"&gt;Data Visualization on MCUs&lt;a class="anchor" href="#data-visualization-on-mcus"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Displaying raw numbers on a screen is useful, but visualizing data as charts, gauges, or graphs makes patterns immediately obvious. The challenge on MCUs is doing this with limited resolution, limited RAM (no floating-point-heavy chart libraries), and limited CPU time. The good news: even simple visualizations are surprisingly effective on small screens.&lt;/p&gt;
&lt;h2 id="sparklines"&gt;Sparklines&lt;a class="anchor" href="#sparklines"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A sparkline is a minimal line chart without axes or labels — just the data trend rendered as a thin line across a small area. It&amp;rsquo;s perfect for showing &amp;ldquo;what has this value been doing recently?&amp;rdquo; in a compact space. Implementation is straightforward: keep a circular buffer of N recent values (where N equals the pixel width of the sparkline), scale the values to the pixel height, and draw a line connecting adjacent points.&lt;/p&gt;</description></item><item><title>Distributed Bus Bar / Power Rail Architecture</title><link>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/distributed-bus-bar/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/distributed-bus-bar/</guid><description>&lt;h1 id="distributed-bus-bar--power-rail-architecture"&gt;Distributed Bus Bar / Power Rail Architecture&lt;a class="anchor" href="#distributed-bus-bar--power-rail-architecture"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;For large-scale LED installations — long architectural runs, LED matrices, or multi-strip arrays — individual point-to-point injection wires become unwieldy. A distributed bus bar replaces the spaghetti of individual injection runs with a continuous heavy-gauge copper rail that runs parallel to the LED strips, providing a low-resistance power backbone that any strip segment can tap into at any point.&lt;/p&gt;
&lt;h2 id="concept"&gt;Concept&lt;a class="anchor" href="#concept"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A bus bar is simply a thick conductor — copper busbar, heavy-gauge wire (10AWG or heavier), or copper tape — that carries the full installation current alongside the LED strips. Short, lightweight tap wires connect from the bus bar to each strip segment at regular intervals. The bus bar&amp;rsquo;s cross-section is chosen so that voltage drop along its length is minimal even at full load, effectively making the entire installation look like it has a single power feed point.&lt;/p&gt;</description></item><item><title>DMA-Driven SPI Transfers</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-dma-transfers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-dma-transfers/</guid><description>&lt;h1 id="dma-driven-spi-transfers"&gt;DMA-Driven SPI Transfers&lt;a class="anchor" href="#dma-driven-spi-transfers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Polled and interrupt-driven SPI transfers consume CPU cycles for every byte moved. For bulk operations — reading a 4 KB page from flash, streaming pixel data to a display, or capturing 1000 samples from an ADC — DMA (Direct Memory Access) offloads the byte-shuffling to dedicated hardware, freeing the CPU to run application code or sleep. On STM32F4, a DMA-driven SPI transfer at 10.5 MHz can move 4096 bytes in approximately 3.1 ms with near-zero CPU involvement after the initial setup.&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>Drawing Primitives &amp; Sprites</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/drawing-primitives/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/graphics-libraries-and-fonts/drawing-primitives/</guid><description>&lt;h1 id="drawing-primitives--sprites"&gt;Drawing Primitives &amp;amp; Sprites&lt;a class="anchor" href="#drawing-primitives--sprites"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every embedded graphics library provides a core set of drawing primitives — the basic shapes and operations combined to build interfaces. Understanding what&amp;rsquo;s available and how the underlying algorithms work helps produce efficient display code and debug visual issues when things don&amp;rsquo;t look right.&lt;/p&gt;
&lt;h2 id="basic-primitives"&gt;Basic Primitives&lt;a class="anchor" href="#basic-primitives"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The standard set found in virtually every library:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Pixel&lt;/strong&gt; — &lt;code&gt;drawPixel(x, y, color)&lt;/code&gt; — the atomic operation everything else builds on&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Line&lt;/strong&gt; — &lt;code&gt;drawLine(x0, y0, x1, y1, color)&lt;/code&gt; — usually Bresenham&amp;rsquo;s algorithm; watch out for endpoint handling at screen boundaries&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Rectangle&lt;/strong&gt; — &lt;code&gt;drawRect()&lt;/code&gt; for outline, &lt;code&gt;fillRect()&lt;/code&gt; for solid — the fastest fill operation since it maps directly to row/column writes on most display controllers&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Circle&lt;/strong&gt; — &lt;code&gt;drawCircle()&lt;/code&gt; and &lt;code&gt;fillCircle()&lt;/code&gt; — midpoint circle algorithm; filled circles are noticeably slower than filled rectangles&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Triangle&lt;/strong&gt; — &lt;code&gt;drawTriangle()&lt;/code&gt; and &lt;code&gt;fillTriangle()&lt;/code&gt; — filled triangles use scanline algorithms and are useful for arrow indicators and custom shapes&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Rounded rectangle&lt;/strong&gt; — &lt;code&gt;drawRoundRect()&lt;/code&gt; — quarter-circle corners connected by straight lines&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;On most display controllers, &lt;code&gt;fillRect()&lt;/code&gt; is special because a column/row address window can be set and stream pixel data directly, which is much faster than setting individual pixels. Prefer rectangles for clearing regions and drawing backgrounds.&lt;/p&gt;</description></item><item><title>Edge Gateway Topologies</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/edge-gateway-topologies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/network-architecture/edge-gateway-topologies/</guid><description>&lt;h1 id="edge-gateway-topologies"&gt;Edge Gateway Topologies&lt;a class="anchor" href="#edge-gateway-topologies"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An edge gateway sits between field-level IoT devices and upstream infrastructure — cloud platforms, on-premises servers, or enterprise networks. The gateway performs protocol translation (converting BLE, Zigbee, or Modbus into MQTT or HTTPS), aggregates data from multiple devices, applies local logic, and manages the upstream connection. Gateway topology — where gateways are placed, how many are deployed, and what role each one plays — determines the fault tolerance, latency, bandwidth consumption, and operational complexity of the entire IoT system. A poor topology choice shows up as single points of failure, data gaps during connectivity loss, or gateways that become bottlenecks as the device count grows.&lt;/p&gt;</description></item><item><title>Error Handling &amp; Bus-Off Recovery</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-error-handling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-error-handling/</guid><description>&lt;h1 id="error-handling--bus-off-recovery"&gt;Error Handling &amp;amp; Bus-Off Recovery&lt;a class="anchor" href="#error-handling--bus-off-recovery"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;CAN&amp;rsquo;s reliability reputation comes from its built-in error detection and fault confinement. The protocol detects five distinct error types at the hardware level and uses two error counters to progressively isolate a faulty node from the bus. Understanding this state machine is essential for firmware that must recover gracefully from bus faults &amp;ndash; a node that enters bus-off state without automatic recovery enabled will remain silent until the MCU is reset.&lt;/p&gt;</description></item><item><title>Error Recovery &amp; Bus Reset</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-error-recovery/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-error-recovery/</guid><description>&lt;h1 id="error-recovery--bus-reset"&gt;Error Recovery &amp;amp; Bus Reset&lt;a class="anchor" href="#error-recovery--bus-reset"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;I²C errors fall into two categories: protocol-level errors that the hardware peripheral detects (NACK, arbitration loss, bus error) and bus-level failures that the peripheral cannot self-recover from (stuck SDA, phantom busy flag). The first category is handled by error callbacks and retry logic. The second requires manual intervention — toggling GPIOs, resetting the peripheral, or power-cycling the bus. Firmware that does not handle both categories will eventually lock up in the field, because every I²C bus will eventually encounter a stuck condition, and no amount of software reset will clear a slave device that is holding SDA low mid-byte.&lt;/p&gt;</description></item><item><title>FFT &amp; Spectral Analysis</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fft-spectral-analysis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/fft-spectral-analysis/</guid><description>&lt;h1 id="fft--spectral-analysis"&gt;FFT &amp;amp; Spectral Analysis&lt;a class="anchor" href="#fft--spectral-analysis"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Fast Fourier Transform converts a block of time-domain audio samples into a frequency-domain representation — a set of complex values (or magnitude/phase pairs) at discrete frequency bins. On an MCU, spectral analysis is used for audio visualization (LED spectrum displays, VU meters), pitch detection, feedback suppression, and as a preprocessor for more complex algorithms. The FFT itself is computationally tractable on Cortex-M4 and ESP32 (a 1024-point Q15 FFT takes roughly 70,000 cycles on Cortex-M4 using CMSIS-DSP), but the choices surrounding it — block size, window function, overlap, and magnitude calculation — determine whether the result is musically useful or misleading.&lt;/p&gt;</description></item><item><title>Field-Oriented Control</title><link>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/field-oriented-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/field-oriented-control/</guid><description>&lt;h1 id="field-oriented-control"&gt;Field-Oriented Control&lt;a class="anchor" href="#field-oriented-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Field-oriented control (FOC), also called vector control, is the gold standard for BLDC and PMSM motor control. Instead of switching between six discrete commutation states, FOC treats the motor as a DC machine by transforming the three-phase stator currents into a two-component rotating reference frame aligned with the rotor. This allows independent control of torque-producing current (Iq) and field-weakening current (Id), producing smooth, ripple-free torque at all speeds. The trade-off is significantly more math per control cycle — Clarke and Park transforms, two PID loops, inverse transforms, and space-vector PWM — all running at 10–40 kHz.&lt;/p&gt;</description></item><item><title>Flashing &amp; Boot Modes</title><link>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/flash-and-boot/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/flash-and-boot/</guid><description>&lt;h1 id="flashing--boot-modes"&gt;Flashing &amp;amp; Boot Modes&lt;a class="anchor" href="#flashing--boot-modes"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Getting compiled firmware into a microcontroller&amp;rsquo;s flash memory — and ensuring it boots correctly — is the final step between a successful build and a running system. Multiple flashing methods exist, each with different hardware requirements, speed, and use cases. The boot sequence itself is deterministic on Cortex-M: the processor reads the vector table, loads the stack pointer, and jumps to the reset handler, all within microseconds of power-on. Understanding both the flashing path and the boot path is essential for reliable bring-up.&lt;/p&gt;</description></item><item><title>Fleet Monitoring</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/fleet-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/fleet-monitoring/</guid><description>&lt;h1 id="fleet-monitoring"&gt;Fleet Monitoring&lt;a class="anchor" href="#fleet-monitoring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Fleet monitoring is the practice of continuously collecting, transmitting, and analyzing health telemetry from deployed embedded devices to detect failures, performance degradation, and anomalous behavior before they escalate to outages. Unlike server monitoring — where agents run on machines with gigabytes of RAM and gigabit network links — embedded fleet monitoring operates under severe constraints: microcontrollers with 64–512 KB of RAM, cellular connections billed per kilobyte, and battery budgets measured in milliamp-hours. The challenge is extracting enough observability from each device to manage a fleet of thousands without the monitoring overhead itself becoming the dominant consumer of bandwidth, power, and flash wear.&lt;/p&gt;</description></item><item><title>Framebuffer Strategies for Small OLEDs</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/framebuffer-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/oled-graphic-displays/framebuffer-strategies/</guid><description>&lt;h1 id="framebuffer-strategies-for-small-oleds"&gt;Framebuffer Strategies for Small OLEDs&lt;a class="anchor" href="#framebuffer-strategies-for-small-oleds"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;On a desktop, allocating a framebuffer is trivial — but on a microcontroller with 2-20KB of RAM, a 1024-byte buffer for a 128x64 monochrome display is a meaningful chunk of total memory. For larger or grayscale displays, the buffer grows fast. How drawing and flushing and flushing pixels to the display has real implications for both RAM usage and update speed.&lt;/p&gt;
&lt;h2 id="full-framebuffer"&gt;Full Framebuffer&lt;a class="anchor" href="#full-framebuffer"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The simplest approach: allocate a buffer in RAM that mirrors the entire display contents. Draw everything into the buffer using the graphics library, then flush the whole thing to the display in one transfer. For a 128x64 monochrome OLED, that&amp;rsquo;s 1024 bytes — very manageable on most modern MCUs. The advantage is simplicity: pixels can be drawn in any order, text layered over graphics, and the library handles all the pixel math in RAM before anything touches the bus.&lt;/p&gt;</description></item><item><title>Gas &amp; Air Quality Sensors</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/gas-and-air-quality/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/gas-and-air-quality/</guid><description>&lt;h1 id="gas--air-quality-sensors"&gt;Gas &amp;amp; Air Quality Sensors&lt;a class="anchor" href="#gas--air-quality-sensors"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Gas and air quality sensing in embedded systems spans a wide range of technologies — from simple heated metal-oxide elements that change resistance in the presence of volatile organic compounds, to sophisticated MEMS devices that compute air quality indices on-chip. The common thread is that all gas sensors require careful attention to warm-up time, baseline calibration, cross-sensitivity, and long-term drift. Firmware that treats a gas sensor like a simple ADC read-and-convert device produces unreliable data.&lt;/p&gt;</description></item><item><title>GCP IoT</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/gcp-iot/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/gcp-iot/</guid><description>&lt;h1 id="gcp-iot"&gt;GCP IoT&lt;a class="anchor" href="#gcp-iot"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Google Cloud IoT Core was Google&amp;rsquo;s managed service for connecting and managing IoT devices. It was retired on August 16, 2023, after less than six years in production. The shutdown is significant not because of the service itself — its feature set was narrower than AWS IoT Core or Azure IoT Hub — but because it demonstrated the real cost of platform dependency in IoT deployments where device lifetimes routinely exceed 5–10 years. This page documents what IoT Core provided, why it was retired, the migration paths that emerged, and the architectural patterns for building IoT workloads on GCP without a dedicated managed service.&lt;/p&gt;</description></item><item><title>GPIO Abstraction Layers</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/gpio-abstraction-layers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/gpio-abstraction-layers/</guid><description>&lt;h1 id="gpio-abstraction-layers"&gt;GPIO Abstraction Layers&lt;a class="anchor" href="#gpio-abstraction-layers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A project with four GPIO pins rarely needs abstraction. A project with forty — spread across status LEDs, relay outputs, button inputs, chip selects, and enable lines — needs a system. Without one, pin assignments scatter across the codebase, active-low logic inverts in some places but not others, and a board revision that swaps two pins requires changes in a dozen files. A thin GPIO abstraction layer, built around a pin descriptor table and a handful of wrapper functions, contains all hardware-specific detail in one place and makes the rest of the firmware pin-agnostic.&lt;/p&gt;</description></item><item><title>HFP &amp; Hands-Free Voice</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/hfp-voice-calls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/hfp-voice-calls/</guid><description>&lt;h1 id="hfp--hands-free-voice"&gt;HFP &amp;amp; Hands-Free Voice&lt;a class="anchor" href="#hfp--hands-free-voice"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Hands-Free Profile (HFP) carries bidirectional voice audio over Bluetooth Classic — it is the protocol behind car hands-free systems, Bluetooth headsets for phone calls, and any device that handles voice communication over Bluetooth. Unlike A2DP (which streams high-quality unidirectional audio), HFP provides a simultaneous two-way voice channel: microphone audio flows from the hands-free unit (HF) to the phone (audio gateway, AG), and downlink audio flows from the phone to the hands-free unit. The audio quality is lower than A2DP (narrowband or wideband voice rather than music), but the bidirectional real-time nature is what makes voice calls work.&lt;/p&gt;</description></item><item><title>Input Capture &amp; Frequency Measurement</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/input-capture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/input-capture/</guid><description>&lt;h1 id="input-capture--frequency-measurement"&gt;Input Capture &amp;amp; Frequency Measurement&lt;a class="anchor" href="#input-capture--frequency-measurement"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Input capture mode turns a timer into a measurement instrument: on each selected edge of an input signal, the hardware latches the current counter value (CNT) into the Capture/Compare Register (CCRx). No interrupt latency affects the measurement — the capture happens in hardware at the timer clock resolution. By comparing successive captures, firmware can compute the period, frequency, or duty cycle of an external signal. The technique applies to tachometer pulses, ultrasonic echo timing, infrared decoder protocols, and any application where the timing of external events matters.&lt;/p&gt;</description></item><item><title>Inrush Limiting &amp; eFuses</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/inrush-limiting-and-efuses/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/inrush-limiting-and-efuses/</guid><description>&lt;h1 id="inrush-limiting--efuses"&gt;Inrush Limiting &amp;amp; eFuses&lt;a class="anchor" href="#inrush-limiting--efuses"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;When a power source connects to a circuit with large capacitors on the input rail, the initial charging current can spike to tens of amps for a brief period. A 1000µF capacitor bank charged through a 50mΩ source impedance path draws an initial peak current of I = V/R = 5V / 0.05Ω = 100A. This inrush current welds connector pins, trips upstream fuses, causes voltage sags on shared power buses, and stresses input capacitors beyond their ripple current rating. Inrush limiting circuits control the rate of current rise during power-on to keep peak current within safe bounds.&lt;/p&gt;</description></item><item><title>IR Proximity &amp; Gesture Detection</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/ir-proximity-and-gesture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/ir-proximity-and-gesture/</guid><description>&lt;h1 id="ir-proximity--gesture-detection"&gt;IR Proximity &amp;amp; Gesture Detection&lt;a class="anchor" href="#ir-proximity--gesture-detection"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;IR proximity sensors work by emitting infrared light from an LED and measuring the reflected intensity with a co-located photodiode. The closer the target object, the stronger the reflected signal. Integrated proximity sensor ICs combine the IR emitter driver, photodiode receiver, ADC, ambient light cancellation, and I2C interface in a single package. More sophisticated devices like the APDS-9960 add a multi-directional photodiode array and onboard gesture engine that can detect swipe directions without host processor intervention.&lt;/p&gt;</description></item><item><title>Kalman Filtering for Embedded Systems</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/kalman-filtering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/kalman-filtering/</guid><description>&lt;h1 id="kalman-filtering-for-embedded-systems"&gt;Kalman Filtering for Embedded Systems&lt;a class="anchor" href="#kalman-filtering-for-embedded-systems"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Kalman filter is an optimal recursive estimator that fuses a process model (how the system evolves over time) with noisy measurements to produce an estimate that is statistically better than either source alone. Unlike the complementary filter, which uses a fixed blending ratio, the Kalman filter dynamically adjusts how much it trusts the model versus the measurement based on the estimated uncertainty of each. This adaptive behavior makes it more accurate but also more complex to implement and tune.&lt;/p&gt;</description></item><item><title>Linker Scripts Demystified</title><link>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/linker-scripts-demystified/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/linker-scripts-demystified/</guid><description>&lt;h1 id="linker-scripts-demystified"&gt;Linker Scripts Demystified&lt;a class="anchor" href="#linker-scripts-demystified"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The linker script is the contract between the compiled firmware and the physical memory of the target MCU. It tells the linker where flash begins, how large SRAM is, and which sections of the program go where. On a Cortex-M, the linker script also controls the vector table placement, the stack pointer initialization, and the data that the startup code must copy or zero before calling main(). When this file is wrong, the firmware may link successfully but crash immediately at runtime — or worse, run with subtle corruption.&lt;/p&gt;</description></item><item><title>Logic Analyzers &amp; Oscilloscopes at the Bench</title><link>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/logic-analyzers-and-oscilloscopes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/logic-analyzers-and-oscilloscopes/</guid><description>&lt;h1 id="logic-analyzers--oscilloscopes-at-the-bench"&gt;Logic Analyzers &amp;amp; Oscilloscopes at the Bench&lt;a class="anchor" href="#logic-analyzers--oscilloscopes-at-the-bench"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Software debugging reveals what firmware thinks is happening. Logic analyzers and oscilloscopes reveal what is actually happening on the wire. Protocol mismatches, signal integrity failures, and power delivery problems are invisible to software tools but immediately apparent with the right instrument and trigger configuration.&lt;/p&gt;
&lt;h2 id="logic-analyzers-for-protocol-decoding"&gt;Logic Analyzers for Protocol Decoding&lt;a class="anchor" href="#logic-analyzers-for-protocol-decoding"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;A logic analyzer captures digital signals and decodes them into human-readable protocol transactions. The Saleae Logic Pro 8 (8 channels, 500 MS/s digital, $480) and Logic 8 (8 channels, 100 MS/s, $200) are the most common bench tools for embedded work. Budget alternatives using Cypress FX2-based clones ($10-15) work with the open-source sigrok/PulseView software at sample rates up to 24 MHz. For SPI decoding, sample at least 4x the clock rate — a 10 MHz SPI bus needs 40 MS/s or higher. I2C, running at 100-400 kHz, is comfortably captured at 1-2 MS/s. Protocol decoders overlay the raw waveform with decoded bytes, addresses, and ACK/NACK status, making it straightforward to confirm whether the MCU is sending what the firmware intends.&lt;/p&gt;</description></item><item><title>lwIP &amp; Embedded TCP/IP Stacks</title><link>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/lwip-tcpip-stack/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/lwip-tcpip-stack/</guid><description>&lt;h1 id="lwip--embedded-tcpip-stacks"&gt;lwIP &amp;amp; Embedded TCP/IP Stacks&lt;a class="anchor" href="#lwip--embedded-tcpip-stacks"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;lwIP (lightweight IP) is the dominant TCP/IP stack for bare-metal and RTOS-based microcontrollers. Written by Adam Dunkels and maintained as an open-source project, it runs on platforms with as little as 40 KB of RAM and provides a functional IPv4/IPv6 stack with TCP, UDP, DHCP, DNS, ICMP, IGMP, and ARP. ESP-IDF, STM32 CubeMX, NXP MCUXpresso, and TI SimpleLink all ship lwIP as their default network stack. Understanding its internal architecture — particularly the three API levels, memory management, and RTOS integration — is essential for debugging the throughput bottlenecks, memory leaks, and connection failures that inevitably arise in embedded networking.&lt;/p&gt;</description></item><item><title>Magnetometers &amp; Heading</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/magnetometers-and-heading/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/magnetometers-and-heading/</guid><description>&lt;h1 id="magnetometers--heading"&gt;Magnetometers &amp;amp; Heading&lt;a class="anchor" href="#magnetometers--heading"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Magnetometers measure the local magnetic field vector, which in undisturbed conditions is dominated by Earth&amp;rsquo;s field — typically 25–65 µT depending on geographic location (strongest at the poles, weakest near the equator). From this vector, a compass heading can be computed. The firmware challenge is that the magnetic field seen by the sensor is almost always corrupted by nearby ferrous materials and current-carrying traces on the PCB, requiring careful calibration before the heading output is usable.&lt;/p&gt;</description></item><item><title>Microstepping</title><link>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/microstepping/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/microstepping/</guid><description>&lt;h1 id="microstepping"&gt;Microstepping&lt;a class="anchor" href="#microstepping"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Full-step drive produces 200 discrete positions per revolution (1.8° each) with abrupt current transitions between steps. This causes audible noise, vibration, and resonance problems — particularly at low speeds. Microstepping divides each full step into smaller increments by shaping the coil currents as sine/cosine waveforms, producing smoother motion and reducing acoustic noise. Nearly every modern stepper driver supports microstepping, and it is the default operating mode for 3D printers, CNC machines, and most embedded motion systems.&lt;/p&gt;</description></item><item><title>Model Conversion Pipelines</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/model-conversion/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/model-conversion/</guid><description>&lt;h1 id="model-conversion-pipelines"&gt;Model Conversion Pipelines&lt;a class="anchor" href="#model-conversion-pipelines"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Training frameworks produce models in their native format — PyTorch saves &lt;code&gt;.pt&lt;/code&gt; or &lt;code&gt;.pth&lt;/code&gt; files with Python-pickled state dictionaries, TensorFlow saves SavedModel directories or &lt;code&gt;.keras&lt;/code&gt; files, and ONNX stores models as protobuf &lt;code&gt;.onnx&lt;/code&gt; files. None of these formats run directly on edge inference runtimes. TFLite Micro expects &lt;code&gt;.tflite&lt;/code&gt; FlatBuffers. TensorRT requires serialized &lt;code&gt;.trt&lt;/code&gt; engine files built for the specific GPU architecture. Hailo&amp;rsquo;s Dataflow Compiler produces &lt;code&gt;.hef&lt;/code&gt; files for the Hailo-8/8L NPU. The conversion pipeline bridges this gap — transforming a trained model from its source format into the target runtime&amp;rsquo;s format while preserving numerical correctness.&lt;/p&gt;</description></item><item><title>Multiplexing &amp; Charlieplexing</title><link>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/multiplexing-and-charlieplexing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/led-driver-ics/multiplexing-and-charlieplexing/</guid><description>&lt;h1 id="multiplexing--charlieplexing"&gt;Multiplexing &amp;amp; Charlieplexing&lt;a class="anchor" href="#multiplexing--charlieplexing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Driving a large number of individual LEDs — not addressable strip LEDs, but discrete LEDs in a custom matrix or indicator array — quickly exhausts available GPIO pins. Multiplexing exploits persistence of vision to drive N×M LEDs from N+M pins by scanning through rows (or columns) fast enough that the eye perceives all LEDs as simultaneously lit. Charlieplexing pushes this further, exploiting the tri-state capability of GPIO pins to drive N×(N−1) LEDs from just N pins.&lt;/p&gt;</description></item><item><title>NVIDIA Jetson Orin Nano</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/jetson-orin-nano/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/jetson-orin-nano/</guid><description>&lt;h1 id="nvidia-jetson-orin-nano"&gt;NVIDIA Jetson Orin Nano&lt;a class="anchor" href="#nvidia-jetson-orin-nano"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Jetson Orin Nano is NVIDIA&amp;rsquo;s entry-level module in the Orin family, delivering up to 40 TOPS of AI inference throughput from an Ampere-architecture GPU combined with a Deep Learning Accelerator (DLA). Unlike NPU-based platforms that restrict models to INT8 quantized operators from a fixed set, the Jetson&amp;rsquo;s GPU-centric architecture runs arbitrary CUDA workloads — meaning virtually any model that can be expressed as a computational graph can execute on this hardware, with TensorRT providing the optimization layer between framework models and GPU execution.&lt;/p&gt;</description></item><item><title>ONNX Runtime &amp; Edge Variants</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/onnx-runtime/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/onnx-runtime/</guid><description>&lt;h1 id="onnx-runtime--edge-variants"&gt;ONNX Runtime &amp;amp; Edge Variants&lt;a class="anchor" href="#onnx-runtime--edge-variants"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;ONNX (Open Neural Network Exchange) is an open model interchange format that allows models trained in one framework — PyTorch, TensorFlow, scikit-learn, XGBoost — to run on a shared inference runtime. The format defines a standard set of operators (organized into versioned &amp;ldquo;opsets&amp;rdquo;), a graph-based computation representation, and a serialization scheme using Protocol Buffers. ONNX Runtime (ORT) is Microsoft&amp;rsquo;s high-performance inference engine for ONNX models, supporting execution on CPUs, GPUs, NPUs, and DSPs through a pluggable &lt;strong&gt;execution provider&lt;/strong&gt; architecture.&lt;/p&gt;</description></item><item><title>Oversampling &amp; Noise Reduction</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/oversampling-and-noise-reduction/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/oversampling-and-noise-reduction/</guid><description>&lt;h1 id="oversampling--noise-reduction"&gt;Oversampling &amp;amp; Noise Reduction&lt;a class="anchor" href="#oversampling--noise-reduction"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A 12-bit ADC does not always deliver 12 bits of useful information. Noise — from the power supply, the analog front end, the ADC&amp;rsquo;s own quantization process, and thermal agitation in resistors — fills the least significant bits with random variation. Oversampling and averaging are firmware techniques that trade sample rate for effective resolution, pushing the noise floor down and extracting meaningful information from those lower bits. But oversampling is not magic: it only works when the noise has the right statistical properties, and it cannot fix systematic errors like offset drift or nonlinearity.&lt;/p&gt;</description></item><item><title>Peripheral Smoke Tests</title><link>https://applied-ee.github.io/embedded/docs/development/project-bring-up/peripheral-smoke-tests/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/project-bring-up/peripheral-smoke-tests/</guid><description>&lt;h1 id="peripheral-smoke-tests"&gt;Peripheral Smoke Tests&lt;a class="anchor" href="#peripheral-smoke-tests"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;After blinky and serial output confirm that the core system works, each peripheral subsystem needs individual verification before building application firmware on top of it. Testing one peripheral at a time isolates failures — if SPI and I2C are both initialized simultaneously and neither works, the root cause could be a shared clock misconfiguration, a pin conflict, or two independent problems. A smoke test for each peripheral should produce a clear pass/fail result with minimal code, and the expected output should be documented before running the test.&lt;/p&gt;</description></item><item><title>PID for Motor Control</title><link>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/pid-for-motor-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/pid-for-motor-control/</guid><description>&lt;h1 id="pid-for-motor-control"&gt;PID for Motor Control&lt;a class="anchor" href="#pid-for-motor-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A PID (Proportional–Integral–Derivative) controller is the standard algorithm for closed-loop motor control. It compares the measured position or velocity to the commanded setpoint and computes a drive output that minimizes the error. In motor control, PID loops close the gap between open-loop guesswork and precise, repeatable positioning — but only if they are tuned correctly. A poorly tuned PID produces oscillation, overshoot, or sluggish response that can be worse than no feedback at all.&lt;/p&gt;</description></item><item><title>PMIC Selection &amp; Integration</title><link>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/pmic-selection-and-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/pmic-selection-and-integration/</guid><description>&lt;h1 id="pmic-selection--integration"&gt;PMIC Selection &amp;amp; Integration&lt;a class="anchor" href="#pmic-selection--integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A Power Management IC (PMIC) integrates multiple power functions — battery charger, DC-DC converters, LDOs, power path management, and supervisory logic — into a single package. For battery-powered embedded systems that charge via USB, a PMIC replaces what would otherwise be three to six discrete ICs: a charger controller, a boost converter, one or two buck regulators, an LDO, and a fuel gauge. The integration reduces BOM count, PCB area, and design risk, since the PMIC vendor has already verified the interactions between the charger, power path, and voltage regulators in a tested reference design.&lt;/p&gt;</description></item><item><title>Popular MCU Families Compared</title><link>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/popular-mcu-families/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/popular-mcu-families/</guid><description>&lt;h1 id="popular-mcu-families-compared"&gt;Popular MCU Families Compared&lt;a class="anchor" href="#popular-mcu-families-compared"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;No single MCU family is best for everything. Each has a core strength — wireless integration, toolchain maturity, price, or community momentum — and a set of tradeoffs that make it a poor fit for certain projects. Understanding what each family does well, and where it struggles, prevents the common mistake of choosing a chip based on familiarity rather than fit.&lt;/p&gt;
&lt;h2 id="family-overview"&gt;Family Overview&lt;a class="anchor" href="#family-overview"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Family&lt;/th&gt;
 &lt;th&gt;Core&lt;/th&gt;
 &lt;th&gt;Clock (MHz)&lt;/th&gt;
 &lt;th&gt;Flash&lt;/th&gt;
 &lt;th&gt;RAM&lt;/th&gt;
 &lt;th&gt;Wireless&lt;/th&gt;
 &lt;th&gt;Typical Price (1K)&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;STM32F4&lt;/td&gt;
 &lt;td&gt;Cortex-M4F&lt;/td&gt;
 &lt;td&gt;168&lt;/td&gt;
 &lt;td&gt;256 KB–2 MB&lt;/td&gt;
 &lt;td&gt;128–256 KB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$3–6&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;STM32H7&lt;/td&gt;
 &lt;td&gt;Cortex-M7&lt;/td&gt;
 &lt;td&gt;480&lt;/td&gt;
 &lt;td&gt;128 KB–2 MB&lt;/td&gt;
 &lt;td&gt;1 MB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$7–12&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;ESP32-S3&lt;/td&gt;
 &lt;td&gt;Xtensa LX7 (dual)&lt;/td&gt;
 &lt;td&gt;240&lt;/td&gt;
 &lt;td&gt;8 MB (ext)&lt;/td&gt;
 &lt;td&gt;512 KB&lt;/td&gt;
 &lt;td&gt;WiFi + BLE 5&lt;/td&gt;
 &lt;td&gt;$2–3&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;nRF52840&lt;/td&gt;
 &lt;td&gt;Cortex-M4F&lt;/td&gt;
 &lt;td&gt;64&lt;/td&gt;
 &lt;td&gt;1 MB&lt;/td&gt;
 &lt;td&gt;256 KB&lt;/td&gt;
 &lt;td&gt;BLE 5.3, 802.15.4&lt;/td&gt;
 &lt;td&gt;$3–5&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;nRF5340&lt;/td&gt;
 &lt;td&gt;Cortex-M33 + M4&lt;/td&gt;
 &lt;td&gt;128/64&lt;/td&gt;
 &lt;td&gt;1 MB&lt;/td&gt;
 &lt;td&gt;512 KB&lt;/td&gt;
 &lt;td&gt;BLE 5.4, direction finding&lt;/td&gt;
 &lt;td&gt;$4–6&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;RP2040&lt;/td&gt;
 &lt;td&gt;Cortex-M0+ (dual)&lt;/td&gt;
 &lt;td&gt;133&lt;/td&gt;
 &lt;td&gt;16 MB (ext)&lt;/td&gt;
 &lt;td&gt;264 KB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$0.70&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;ATmega328P&lt;/td&gt;
 &lt;td&gt;AVR (8-bit)&lt;/td&gt;
 &lt;td&gt;20&lt;/td&gt;
 &lt;td&gt;32 KB&lt;/td&gt;
 &lt;td&gt;2 KB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$1.50&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;PIC18F&lt;/td&gt;
 &lt;td&gt;PIC (8-bit)&lt;/td&gt;
 &lt;td&gt;64&lt;/td&gt;
 &lt;td&gt;128 KB&lt;/td&gt;
 &lt;td&gt;4 KB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$1–2&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;ESP32-C3&lt;/td&gt;
 &lt;td&gt;RISC-V&lt;/td&gt;
 &lt;td&gt;160&lt;/td&gt;
 &lt;td&gt;4 MB (ext)&lt;/td&gt;
 &lt;td&gt;400 KB&lt;/td&gt;
 &lt;td&gt;WiFi + BLE 5&lt;/td&gt;
 &lt;td&gt;$1–2&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;CH32V003&lt;/td&gt;
 &lt;td&gt;RISC-V&lt;/td&gt;
 &lt;td&gt;48&lt;/td&gt;
 &lt;td&gt;16 KB&lt;/td&gt;
 &lt;td&gt;2 KB&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;$0.10&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;h2 id="stm32--the-broad-range"&gt;STM32 — The Broad Range&lt;a class="anchor" href="#stm32--the-broad-range"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;ST&amp;rsquo;s STM32 line spans from the ultra-low-power L0 (Cortex-M0+, 32 MHz, sub-uA stop) to the H7 (Cortex-M7, 480 MHz, 1 MB RAM). CubeMX generates peripheral initialization code, and the HAL library covers most peripherals. The ecosystem is mature: Keil, IAR, GCC, and CubeIDE all work. The weakness is complexity — the HAL is verbose, CubeMX-generated code can be opaque, and the sheer number of part variants (over 1,000 SKUs) makes selection itself a project. Supply chain exposure became a headline issue during 2021–2023: STM32F4 and STM32H7 lead times stretched to 52+ weeks, and spot pricing for some parts exceeded 10x the normal rate. ST manufactures primarily through a small number of fabs, making the line vulnerable to single-source disruption. Designing with pin-compatible alternatives (GD32, AT32 from Artery) or maintaining a firmware HAL that can retarget to a different family provides insurance.&lt;/p&gt;</description></item><item><title>Power Analyzer Tools</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/power-analyzer-tools/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/power-analyzer-tools/</guid><description>&lt;h1 id="power-analyzer-tools"&gt;Power Analyzer Tools&lt;a class="anchor" href="#power-analyzer-tools"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Measuring embedded power consumption requires instruments that can capture both the microamp sleep currents and the hundred-milliamp active bursts that characterize modern low-power firmware. A standard benchtop DMM, sampling at a few readings per second, averages out the brief transmit bursts and deep-sleep intervals — reporting a single number that represents neither the peak nor the baseline. Dedicated power analyzers solve this by combining high-speed sampling with wide dynamic range, continuous capture, and software tools for analyzing energy over time.&lt;/p&gt;</description></item><item><title>Power Sequencing &amp; Reset Circuits</title><link>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/power-sequencing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/power-sequencing/</guid><description>&lt;h1 id="power-sequencing--reset-circuits"&gt;Power Sequencing &amp;amp; Reset Circuits&lt;a class="anchor" href="#power-sequencing--reset-circuits"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;When a board has multiple voltage rails — a common scenario with modern MCUs that require separate core, I/O, and analog supplies — the order and timing of those rails coming up determines whether the system starts cleanly or enters an undefined state. Incorrect sequencing can cause latch-up (a potentially destructive parasitic SCR condition), excessive current draw during startup, or peripheral buses that lock up before firmware even begins executing.&lt;/p&gt;</description></item><item><title>Predictive Maintenance</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/predictive-maintenance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/predictive-maintenance/</guid><description>&lt;h1 id="predictive-maintenance"&gt;Predictive Maintenance&lt;a class="anchor" href="#predictive-maintenance"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Predictive maintenance estimates when a machine component will fail, enabling maintenance scheduling after most useful life is consumed but before failure occurs. The distinction from reactive maintenance (fix after failure) and preventive maintenance (replace on a fixed schedule regardless of condition) is that predictive maintenance uses actual sensor measurements to forecast the remaining useful life (RUL) of a component, optimizing the trade-off between maintenance cost and downtime risk.&lt;/p&gt;</description></item><item><title>Proportional Solenoid Control</title><link>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/proportional-solenoid-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/proportional-solenoid-control/</guid><description>&lt;h1 id="proportional-solenoid-control"&gt;Proportional Solenoid Control&lt;a class="anchor" href="#proportional-solenoid-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Standard solenoids are binary — fully energized or fully off. Proportional solenoid control uses PWM to regulate the average current through the coil, producing variable force or variable plunger position. This technique is essential for proportional hydraulic/pneumatic valves, variable-force clamping, and any application requiring analog-like force control from a digital drive signal. The key challenge is linearizing the force-position-current relationship, which is inherently nonlinear in most solenoid designs.&lt;/p&gt;</description></item><item><title>Protection Circuits &amp; PCMs</title><link>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/protection-circuits-and-pcms/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/protection-circuits-and-pcms/</guid><description>&lt;h1 id="protection-circuits--pcms"&gt;Protection Circuits &amp;amp; PCMs&lt;a class="anchor" href="#protection-circuits--pcms"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A lithium-ion cell without protection circuitry is one fault away from a fire. The cell itself has no internal mechanism to prevent overcharge, overdischarge, or overcurrent — those limits exist only in the cell&amp;rsquo;s chemistry, and violating them causes irreversible damage, capacity loss, or thermal runaway. A protection circuit module (PCM) — sometimes called a battery protection board or BMS for single-cell systems — enforces hard voltage and current limits by switching a pair of MOSFETs in series with the cell. These circuits operate autonomously, using analog comparators rather than programmable registers, and require no firmware interaction. They are the last line of defense when the charging IC malfunctions, the firmware crashes, or the load shorts.&lt;/p&gt;</description></item><item><title>PWM Audio Output</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/pwm-audio-output/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/pwm-audio-output/</guid><description>&lt;h1 id="pwm-audio-output"&gt;PWM Audio Output&lt;a class="anchor" href="#pwm-audio-output"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Not every MCU has a DAC, but nearly every MCU has a PWM-capable timer. A PWM signal whose duty cycle is modulated by audio sample values, followed by a low-pass filter to remove the carrier frequency, produces an analog audio output. This technique is widely used on Cortex-M0 (no DAC), ATtiny/ATmega, RP2040 (which has PWM but no DAC), and other low-cost MCUs. The quality ceiling is lower than a dedicated DAC — limited by PWM resolution, carrier frequency harmonics, and reconstruction filter design — but for voice prompts, alarms, notification sounds, and simple music playback, PWM audio is a practical zero-cost solution.&lt;/p&gt;</description></item><item><title>Real-Time Constraints on Linux</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/real-time-linux/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/real-time-linux/</guid><description>&lt;h1 id="real-time-constraints-on-linux"&gt;Real-Time Constraints on Linux&lt;a class="anchor" href="#real-time-constraints-on-linux"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Standard Linux is not a real-time operating system. The kernel can preempt user tasks at any time, but kernel code itself has sections that run with preemption disabled — creating unbounded worst-case latencies. For embedded applications that need deterministic timing (motor control, audio processing, high-speed data acquisition), this matters. The difference between a 15 µs average scheduling latency and a 2000 µs worst-case spike is the difference between a control loop that tracks its setpoint and one that overshoots into a mechanical stop.&lt;/p&gt;</description></item><item><title>SDR Receiver Integration</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/sdr-receiver-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/rf-sdr-peripherals/sdr-receiver-integration/</guid><description>&lt;h1 id="sdr-receiver-integration"&gt;SDR Receiver Integration&lt;a class="anchor" href="#sdr-receiver-integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Software-defined radio (SDR) replaces fixed analog signal processing stages with software — tuning, filtering, decimation, and demodulation happen in code rather than in hardware. For embedded systems, SDR integration ranges from connecting a USB dongle to a Linux SBC (the RTL-SDR approach) to driving a small SPI/I2C receiver IC from an MCU (Si4732, RDA5807). The dividing line is processing power: demodulating wideband signals requires sustained DSP throughput that MCUs cannot deliver, while narrowband applications (FM broadcast, weather stations, simple ASK/FSK decoding) fit comfortably on a microcontroller with a dedicated receiver front-end.&lt;/p&gt;</description></item><item><title>Semantic Segmentation</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/semantic-segmentation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/semantic-segmentation/</guid><description>&lt;h1 id="semantic-segmentation"&gt;Semantic Segmentation&lt;a class="anchor" href="#semantic-segmentation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Semantic segmentation assigns a class label to every pixel in an image, producing a dense class map rather than sparse bounding boxes. Where &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/object-detection/"&gt;object detection&lt;/a&gt; answers &amp;ldquo;what objects are present and roughly where,&amp;rdquo; segmentation answers &amp;ldquo;which class does this exact pixel belong to.&amp;rdquo; This pixel-level precision is essential for tasks like autonomous navigation (identifying drivable surface vs obstacle at the boundary), agricultural robotics (distinguishing crop from weed at the stem level), and industrial inspection (measuring defect area in square millimeters rather than bounding box approximations).&lt;/p&gt;</description></item><item><title>Shared Data &amp; Volatile Semantics</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/shared-data-and-volatile/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/shared-data-and-volatile/</guid><description>&lt;h1 id="shared-data--volatile-semantics"&gt;Shared Data &amp;amp; Volatile Semantics&lt;a class="anchor" href="#shared-data--volatile-semantics"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;When a variable is written inside an ISR and read in the main loop (or vice versa), the compiler has no visibility into the asynchronous relationship between those two execution contexts. Without explicit annotation, the optimizer treats the main-loop code as the only thread of execution and may cache the variable in a register, reorder reads and writes, or eliminate accesses entirely. The &lt;code&gt;volatile&lt;/code&gt; qualifier is the primary tool for preventing these optimizations, but it is both necessary in more places than most firmware expects and insufficient in others. Getting this right is the difference between firmware that works reliably and firmware that works only at &lt;code&gt;-O0&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>SoftAP, Captive Portals &amp; Provisioning</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/softap-captive-portal/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/softap-captive-portal/</guid><description>&lt;h1 id="softap-captive-portals--provisioning"&gt;SoftAP, Captive Portals &amp;amp; Provisioning&lt;a class="anchor" href="#softap-captive-portals--provisioning"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every WiFi device faces a bootstrapping problem: it needs network credentials to connect, but it has no network connection through which to receive them. SoftAP provisioning solves this by temporarily turning the MCU into an access point, serving a credential-entry web page to a phone or laptop, and then switching back to station mode with the received SSID and password. This approach requires no companion app, no cloud account, and no Bluetooth — just a web browser. It has become the de facto provisioning method for consumer IoT devices, from smart plugs to environmental sensors.&lt;/p&gt;</description></item><item><title>Speech Recognition</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/speech-recognition/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/speech-recognition/</guid><description>&lt;h1 id="speech-recognition"&gt;Speech Recognition&lt;a class="anchor" href="#speech-recognition"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Speech recognition at the edge spans a vast range of complexity — from a Cortex-M4 classifying one of 20 fixed commands in 50 milliseconds, to an NVIDIA Jetson running the full OpenAI Whisper model for open-vocabulary transcription in multiple languages. The right approach depends on vocabulary size, acceptable latency, available hardware, and whether network connectivity is reliable enough for a cloud fallback.&lt;/p&gt;
&lt;p&gt;The architecture decision is not just about accuracy. A 100-command voice interface that responds in 200 ms with 95% accuracy feels better to use than one that achieves 99% accuracy but takes 3 seconds. Latency, power, and reliability — not just word error rate — determine whether a speech recognition system is practical at the edge.&lt;/p&gt;</description></item><item><title>Streaming Audio Protocols</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/streaming-audio-protocols/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-formats/streaming-audio-protocols/</guid><description>&lt;h1 id="streaming-audio-protocols"&gt;Streaming Audio Protocols&lt;a class="anchor" href="#streaming-audio-protocols"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Streaming audio from an MCU to a server (or between devices) over an IP network introduces challenges that do not exist in local playback: variable network latency, packet loss, jitter, and the need to maintain a continuous audio stream despite an unreliable transport. The protocol choice determines whether the system achieves low-latency monitoring (tens of milliseconds), reliable recording (no lost samples), or efficient broadcast to multiple listeners. Most embedded audio streaming runs over UDP (for low latency) or HTTP/WebSocket (for simplicity and firewall traversal).&lt;/p&gt;</description></item><item><title>Supercapacitor Buffering</title><link>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/supercapacitor-buffering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/supercapacitor-buffering/</guid><description>&lt;h1 id="supercapacitor-buffering"&gt;Supercapacitor Buffering&lt;a class="anchor" href="#supercapacitor-buffering"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Supercapacitors bridge the gap between conventional capacitors and rechargeable batteries, offering cycle life measured in hundreds of thousands of cycles, charge and discharge rates limited only by ESR, and energy storage proportional to the square of the terminal voltage. In energy harvesting systems, supercapacitors serve as the primary storage element — absorbing energy from the harvesting IC during periods of availability and delivering it to the load during darkness, shade, or other interruptions. Unlike lithium-ion cells, supercapacitors tolerate deep discharge to 0V without damage, require no charge management IC, and introduce no fire or swelling risk. The trade-off is dramatically lower energy density: a 1F, 5.5V supercapacitor stores roughly 15 millijoules, while a 40mAh LIR2032 coin cell stores 530 joules — a 35,000:1 ratio.&lt;/p&gt;</description></item><item><title>TDM &amp; Multi-Channel Audio</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/tdm-multichannel-audio/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/tdm-multichannel-audio/</guid><description>&lt;h1 id="tdm--multi-channel-audio"&gt;TDM &amp;amp; Multi-Channel Audio&lt;a class="anchor" href="#tdm--multi-channel-audio"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Standard I2S carries two channels (left and right) in a single frame. TDM (Time-Division Multiplexing) extends this by packing multiple channels into the same frame — 4, 8, or even 16 slots on a single data line, each carrying one channel of audio. This is the standard approach for microphone arrays, multi-channel mixers, and any application that needs more than two channels without adding physical I2S buses. The I2S peripheral on many MCUs (STM32 SAI, ESP32 I2S, nRF52 I2S) supports TDM natively, though the configuration differs substantially between platforms.&lt;/p&gt;</description></item><item><title>Thread &amp; OpenThread</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/thread-openthread/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/thread-openthread/</guid><description>&lt;h1 id="thread--openthread"&gt;Thread &amp;amp; OpenThread&lt;a class="anchor" href="#thread--openthread"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Thread is a mesh networking protocol built on 802.15.4 and 6LoWPAN, designed specifically for reliable, secure, low-power device-to-device communication in buildings. Where 6LoWPAN provides the compression and fragmentation layer, Thread adds mesh routing, self-healing topology management, device roles, and a complete security model. The result is an IP-based mesh network where every node has a routable IPv6 address and the network reconfigures itself when nodes join, leave, or fail.&lt;/p&gt;</description></item><item><title>Time-of-Flight &amp; LIDAR Ranging</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/time-of-flight-and-lidar-ranging/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/time-of-flight-and-lidar-ranging/</guid><description>&lt;h1 id="time-of-flight--lidar-ranging"&gt;Time-of-Flight &amp;amp; LIDAR Ranging&lt;a class="anchor" href="#time-of-flight--lidar-ranging"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Time-of-Flight (ToF) sensors measure distance by timing the round-trip of emitted light — either a modulated IR signal (phase-detection ToF) or a laser pulse (direct ToF / LIDAR). The ST VL53L0X and VL53L1X are the most widely used phase-detection ToF sensors in embedded projects, communicating over I2C and providing millimeter-resolution ranging in a tiny package. For longer ranges (2-12 meters), single-point LIDAR modules like the Benewake TFmini and TF-Luna use direct time-of-flight with a pulsed laser. Both classes of sensor offload all the optical signal processing internally — the MCU simply requests a measurement and reads back a distance value.&lt;/p&gt;</description></item><item><title>Timing &amp; Frame Rate</title><link>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/timing-and-frame-rate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/animations-and-frame-rendering/timing-and-frame-rate/</guid><description>&lt;h1 id="timing--frame-rate"&gt;Timing &amp;amp; Frame Rate&lt;a class="anchor" href="#timing--frame-rate"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;LED animation is a real-time rendering problem. Each frame must be computed and transmitted within a fixed time budget to maintain smooth motion. The frame rate depends on three factors: how long the animation computation takes, how long the strip transmission takes, and how much time is left for other firmware tasks. Getting the timing architecture wrong leads to either dropped frames (jerky animation) or starved peripherals (missed sensor reads, unresponsive inputs).&lt;/p&gt;</description></item><item><title>TLS &amp; DTLS on Constrained Devices</title><link>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/embedded-tls-dtls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/protocol-selection/embedded-tls-dtls/</guid><description>&lt;h1 id="tls--dtls-on-constrained-devices"&gt;TLS &amp;amp; DTLS on Constrained Devices&lt;a class="anchor" href="#tls--dtls-on-constrained-devices"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Transport Layer Security (TLS) on a constrained microcontroller is a fundamentally different problem than TLS on a server or desktop. A server completes a TLS 1.3 handshake in under 1 ms with negligible memory impact. A Cortex-M4 at 120 MHz without hardware crypto takes 1–3 seconds for the same handshake, consuming 30–50 KB of RAM at peak — potentially half the available SRAM on a mid-range MCU. Every design decision in the TLS stack — cipher suite selection, certificate format, session management, buffer sizing — has measurable impact on performance, memory, and power consumption.&lt;/p&gt;</description></item><item><title>White Balance &amp; Color Temperature</title><link>https://applied-ee.github.io/embedded/docs/led-systems/color-management/white-balance-and-color-temperature/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/color-management/white-balance-and-color-temperature/</guid><description>&lt;h1 id="white-balance--color-temperature"&gt;White Balance &amp;amp; Color Temperature&lt;a class="anchor" href="#white-balance--color-temperature"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Driving an RGB LED at (255, 255, 255) rarely produces what the eye perceives as &amp;ldquo;white.&amp;rdquo; Most WS2812B strips produce a distinctly cool, bluish white because the blue die is typically the most efficient and the green-to-red phosphor balance varies by manufacturer. Achieving a consistent, pleasing white — or matching a specific color temperature — requires per-channel scaling that compensates for the LED&amp;rsquo;s spectral characteristics.&lt;/p&gt;</description></item><item><title>Acceleration Profiles</title><link>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/acceleration-profiles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/acceleration-profiles/</guid><description>&lt;h1 id="acceleration-profiles"&gt;Acceleration Profiles&lt;a class="anchor" href="#acceleration-profiles"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A stepper motor cannot instantly jump from standstill to high speed — the rotor has inertia, and the available torque decreases as speed increases. If the step rate ramps too quickly, the rotor cannot keep up with the rotating magnetic field and the motor stalls. Acceleration profiles define how the step rate changes over time, balancing move speed against the risk of stall and the mechanical smoothness required by the application.&lt;/p&gt;</description></item><item><title>AHRS &amp; Multi-Sensor Fusion</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/ahrs-and-multi-sensor-fusion/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/sensor-fusion-and-filtering/ahrs-and-multi-sensor-fusion/</guid><description>&lt;h1 id="ahrs--multi-sensor-fusion"&gt;AHRS &amp;amp; Multi-Sensor Fusion&lt;a class="anchor" href="#ahrs--multi-sensor-fusion"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An AHRS (Attitude and Heading Reference System) fuses accelerometer, gyroscope, and magnetometer data to produce a continuous, drift-free estimate of 3D orientation — pitch, roll, and yaw. While complementary and Kalman filters handle one or two axes well, full 3D orientation requires algorithms that operate on quaternion representations to avoid the singularities (gimbal lock) inherent in Euler angles. The two most widely used open-source AHRS algorithms for embedded systems are the Madgwick filter and the Mahony filter, both designed to run efficiently on Cortex-M microcontrollers.&lt;/p&gt;</description></item><item><title>Audio Event Classification</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/audio-classification/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/audio-classification/</guid><description>&lt;h1 id="audio-event-classification"&gt;Audio Event Classification&lt;a class="anchor" href="#audio-event-classification"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Audio event classification identifies environmental sounds — not speech — from an audio stream: glass breaking, dog barking, siren wailing, machine operating normally versus abnormally. The task differs from &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/audio-speech/speech-recognition/"&gt;speech recognition&lt;/a&gt; in several important ways: events are often short and non-stationary, multiple events can overlap in time, and the &amp;ldquo;vocabulary&amp;rdquo; of sounds is defined by the physical environment rather than a language. The dominant approach is a convolutional neural network operating on mel spectrograms, either trained from scratch for a narrow domain or fine-tuned from a pre-trained model like YAMNet.&lt;/p&gt;</description></item><item><title>AVRCP Playback Control</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/avrcp-playback-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/bluetooth-audio/avrcp-playback-control/</guid><description>&lt;h1 id="avrcp-playback-control"&gt;AVRCP Playback Control&lt;a class="anchor" href="#avrcp-playback-control"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;AVRCP (Audio/Video Remote Control Profile) provides the control channel that accompanies A2DP audio streaming. While A2DP handles the audio data, AVRCP handles play/pause, next/previous track, volume adjustment, and track metadata (title, artist, album). Every Bluetooth speaker and headphone uses AVRCP alongside A2DP — the play/pause button on a headphone sends an AVRCP command to the phone, and the track name displayed on a car stereo arrives via AVRCP metadata notifications.&lt;/p&gt;</description></item><item><title>Back-EMF &amp; Braking</title><link>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/back-emf-and-braking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/dc-motors/back-emf-and-braking/</guid><description>&lt;h1 id="back-emf--braking"&gt;Back-EMF &amp;amp; Braking&lt;a class="anchor" href="#back-emf--braking"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A spinning DC motor is also a generator. The rotating armature produces a voltage proportional to speed — the back-EMF (electromotive force). This voltage opposes the applied voltage and is the fundamental mechanism that regulates motor current: as speed increases, back-EMF rises, net voltage across the winding drops, and current decreases. Understanding back-EMF is essential for speed measurement without encoders, controlled deceleration, and preventing voltage spikes from damaging drive electronics.&lt;/p&gt;</description></item><item><title>Battery Life Estimation</title><link>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/battery-life-estimation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/low-power-design/battery-life-estimation/</guid><description>&lt;h1 id="battery-life-estimation"&gt;Battery Life Estimation&lt;a class="anchor" href="#battery-life-estimation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Predicting battery life requires more than dividing capacity by current. A CR2032 coin cell rated at 230 mAh does not deliver 230 mA for one hour — it delivers 230 mAh only under specific conditions (typically 15 kΩ load to 2.0 V cutoff at 23°C). At higher loads, lower temperatures, or higher cutoff voltages, the usable capacity drops significantly. Accurate estimation integrates the measured current profile over the full duty cycle, accounts for self-discharge, derates for temperature and aging, and applies safety margins for production variance. The result is a prediction within 10–20% of real-world runtime — close enough to make informed battery sizing decisions.&lt;/p&gt;</description></item><item><title>BLE Connection Parameters &amp; Throughput</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-connection-parameters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-connection-parameters/</guid><description>&lt;h1 id="ble-connection-parameters--throughput"&gt;BLE Connection Parameters &amp;amp; Throughput&lt;a class="anchor" href="#ble-connection-parameters--throughput"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;BLE connection parameters determine three fundamental trade-offs: power consumption, latency, and throughput. Unlike WiFi, where the radio stays on continuously, BLE operates in discrete &lt;strong&gt;connection events&lt;/strong&gt; — short windows during which the central and peripheral exchange data, then both radios power down until the next event. The timing of these events, the amount of data exchanged per event, and the physical layer data rate collectively determine what is achievable. A misconfigured connection can waste 10x the power necessary or deliver 10x less throughput than the hardware supports.&lt;/p&gt;</description></item><item><title>Cache Coherency &amp; DMA on Cortex-M7</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-cache-coherency/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-cache-coherency/</guid><description>&lt;h1 id="cache-coherency--dma-on-cortex-m7"&gt;Cache Coherency &amp;amp; DMA on Cortex-M7&lt;a class="anchor" href="#cache-coherency--dma-on-cortex-m7"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Cortex-M7 processors (STM32F7, STM32H7) include separate instruction and data caches — typically 16 KB I-cache and 16 KB D-cache — that dramatically improve execution speed by reducing access latency to main SRAM. But DMA controllers operate on the physical bus, bypassing the CPU cache entirely. When DMA writes data to SRAM, the CPU cache may still hold stale values at those addresses. When the CPU writes data that DMA will read, the cache may hold updated values that have not been flushed to SRAM. This coherency problem is the single most common source of intermittent, hard-to-diagnose data corruption on Cortex-M7 systems.&lt;/p&gt;</description></item><item><title>Calibration &amp; Linearization</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/calibration-and-linearization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/analog-front-end/calibration-and-linearization/</guid><description>&lt;h1 id="calibration--linearization"&gt;Calibration &amp;amp; Linearization&lt;a class="anchor" href="#calibration--linearization"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Raw ADC codes are not physical measurements. Converting code 2048 on a 12-bit ADC into &amp;ldquo;25.3 C&amp;rdquo; or &amp;ldquo;101.2 kPa&amp;rdquo; requires a calibration model — a mapping from raw digital values to real-world units. The simplest sensors have a linear transfer function that needs only an offset and a gain correction. Others — NTC thermistors, photodiodes, pH probes — have nonlinear responses that require lookup tables, polynomial fits, or physics-based equations. Getting calibration right is the difference between a sensor reading that is &amp;ldquo;approximately correct&amp;rdquo; and one that is traceable to a known reference.&lt;/p&gt;</description></item><item><title>CAN-FD &amp; Extended Frames</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-fd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/can-bus/can-fd/</guid><description>&lt;h1 id="can-fd--extended-frames"&gt;CAN-FD &amp;amp; Extended Frames&lt;a class="anchor" href="#can-fd--extended-frames"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;CAN-FD (Flexible Data-Rate) extends classic CAN in two directions: larger payloads (up to 64 bytes per frame versus 8) and a faster data-phase bit rate (up to 5 Mbps or higher, versus the 1 Mbps ceiling of classic CAN). These improvements address the growing bandwidth demands of automotive ECUs and industrial systems without replacing the CAN physical layer or arbitration mechanism. The tradeoff is increased peripheral complexity &amp;ndash; dual bit-rate configuration, message RAM management, and careful attention to transceiver and bus topology limitations.&lt;/p&gt;</description></item><item><title>Closed-Loop Stepper &amp; Servo</title><link>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/closed-loop-stepper-and-servo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/servo-position-control/closed-loop-stepper-and-servo/</guid><description>&lt;h1 id="closed-loop-stepper--servo"&gt;Closed-Loop Stepper &amp;amp; Servo&lt;a class="anchor" href="#closed-loop-stepper--servo"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Open-loop stepper control works until it does not — a missed step goes undetected, and every subsequent position is wrong by that amount. Closing the loop with an encoder transforms a stepper into a servo-like system: the controller knows the actual shaft position and can correct for missed steps, stalls, and load disturbances. The trade-off is additional hardware (encoder), firmware complexity (feedback loop), and the need to reconcile two fundamentally different control approaches: the discrete step-counting world of stepper drivers and the continuous feedback world of servo control.&lt;/p&gt;</description></item><item><title>Color &amp; Spectral Sensors</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/color-and-spectral-sensors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/color-and-spectral-sensors/</guid><description>&lt;h1 id="color--spectral-sensors"&gt;Color &amp;amp; Spectral Sensors&lt;a class="anchor" href="#color--spectral-sensors"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Color sensors measure the spectral composition of light by splitting it across filtered channels — typically red, green, blue, and clear (unfiltered). Spectral sensors extend this concept to 8 or more channels spanning the visible and near-IR spectrum, enabling applications beyond simple color matching: plant health monitoring, material identification, skin tone measurement, and precise colorimetry. The firmware challenge lies in configuring gain and integration time for the lighting conditions, then converting raw channel counts into meaningful color coordinates or spectral power distributions.&lt;/p&gt;</description></item><item><title>Common Bring-Up Failures &amp; Recovery</title><link>https://applied-ee.github.io/embedded/docs/development/project-bring-up/common-bring-up-failures/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/project-bring-up/common-bring-up-failures/</guid><description>&lt;h1 id="common-bring-up-failures--recovery"&gt;Common Bring-Up Failures &amp;amp; Recovery&lt;a class="anchor" href="#common-bring-up-failures--recovery"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every board bring-up encounters failures. The difference between a frustrating multi-day debug session and a quick recovery is recognizing common failure patterns and knowing the standard recovery procedure for each. Most bring-up failures fall into a small number of categories: power shorts, boot configuration errors, debug access problems, clock issues, and passive component mistakes. Learning to classify the symptom quickly — before reaching for the oscilloscope — saves significant time.&lt;/p&gt;</description></item><item><title>Critical Sections &amp; Interrupt Masking</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/critical-sections/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/interrupts/critical-sections/</guid><description>&lt;h1 id="critical-sections--interrupt-masking"&gt;Critical Sections &amp;amp; Interrupt Masking&lt;a class="anchor" href="#critical-sections--interrupt-masking"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A critical section is a region of code that must execute without interruption — either to protect shared data from concurrent access or to enforce timing guarantees on a sequence of operations. On Cortex-M, critical sections are implemented by masking interrupts: temporarily preventing the processor from responding to interrupt requests while the protected code executes. The cost is interrupt latency — every cycle spent with interrupts disabled is a cycle that incoming interrupts must wait. The design challenge is making critical sections as short as possible while still protecting everything that needs protection.&lt;/p&gt;</description></item><item><title>Debouncing in Firmware</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/debouncing-in-firmware/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/gpio-patterns/debouncing-in-firmware/</guid><description>&lt;h1 id="debouncing-in-firmware"&gt;Debouncing in Firmware&lt;a class="anchor" href="#debouncing-in-firmware"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A mechanical switch does not produce a clean digital transition. When the contacts close, they bounce — making and breaking contact multiple times over a period of 1-20 ms (some switches bounce for 50 ms or more). A single button press can produce 5-50 edge transitions before settling. Without debounce logic, a single press registers as multiple presses, a rotary encoder skips counts, and an interrupt-driven input floods the system with spurious events. Firmware debouncing filters this mechanical noise using time-domain analysis — waiting for the signal to remain stable before accepting the new state.&lt;/p&gt;</description></item><item><title>Designing for Memory Constraints</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/memory-constrained-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/tinyml/memory-constrained-design/</guid><description>&lt;h1 id="designing-for-memory-constraints"&gt;Designing for Memory Constraints&lt;a class="anchor" href="#designing-for-memory-constraints"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;On microcontrollers, memory is the first constraint and the last. A model that achieves 95% accuracy on a desktop means nothing if it requires 200 KB of SRAM on a device with 128 KB. Unlike cloud or even mobile ML, where memory is abundant and dynamically allocated, MCU inference demands that every byte be accounted for at compile time. There is no virtual memory, no swap space, no fallback. The model weights must fit in flash, the tensor arena must fit in SRAM, and both must coexist with the firmware, peripheral drivers, communication stacks, and application logic. A design process that starts with the memory budget and works backward to the model architecture avoids the costly iteration of training a model that cannot deploy.&lt;/p&gt;</description></item><item><title>DMA &amp; Throughput Optimization</title><link>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/dma-and-performance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/screens-displays/tft-color-displays/dma-and-performance/</guid><description>&lt;h1 id="dma--throughput-optimization"&gt;DMA &amp;amp; Throughput Optimization&lt;a class="anchor" href="#dma--throughput-optimization"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A 240x320 display at RGB565 is 153,600 bytes per frame. At 10MHz SPI, that&amp;rsquo;s about 123ms per full-screen update — barely 8fps, and that&amp;rsquo;s assuming the MCU does nothing but push pixels. For smooth UI or any kind of animation, either reducing how much gets sent or sending it faster is required. DMA (Direct Memory Access) is the key enabler, but there are several other strategies worth understanding.&lt;/p&gt;</description></item><item><title>Dynamics Processing</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/dynamics-processing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/dynamics-processing/</guid><description>&lt;h1 id="dynamics-processing"&gt;Dynamics Processing&lt;a class="anchor" href="#dynamics-processing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Dynamics processors — compressors, limiters, gates, and expanders — control the volume envelope of an audio signal in real time. A compressor reduces the level of loud passages to prevent clipping and even out volume. A limiter is a compressor with a very high ratio, acting as a hard ceiling. A gate silences signals below a threshold to suppress background noise. These are not exotic effects; they are essential building blocks for any audio system that must handle variable input levels, from a conference microphone that switches between soft and loud speakers to a music player that must not overdrive a small speaker amplifier.&lt;/p&gt;</description></item><item><title>Edge Runtime Selection Guide</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/runtime-selection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/runtime-selection/</guid><description>&lt;h1 id="edge-runtime-selection-guide"&gt;Edge Runtime Selection Guide&lt;a class="anchor" href="#edge-runtime-selection-guide"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Selecting an inference runtime for edge deployment is a multi-dimensional decision that involves the target hardware, model format, operator coverage, memory budget, and the training framework that produced the model. There is no single &amp;ldquo;best&amp;rdquo; runtime — the choice is constrained by the intersection of what the hardware supports, what the model requires, and what the deployment environment allows. A model that runs perfectly on &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-linux/"&gt;TensorFlow Lite for Linux&lt;/a&gt; with the XNNPACK delegate on a Raspberry Pi 4 cannot run on a Cortex-M4 microcontroller, where &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/tflite-micro/"&gt;TensorFlow Lite Micro&lt;/a&gt; is the only viable option. Conversely, a PyTorch model that exports cleanly to &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/inference-frameworks/onnx-runtime/"&gt;ONNX Runtime&lt;/a&gt; may have no path to TFLite without an intermediate conversion step that risks operator compatibility issues.&lt;/p&gt;</description></item><item><title>Encoder Mode &amp; Quadrature Decoding</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/encoder-mode/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/timers/encoder-mode/</guid><description>&lt;h1 id="encoder-mode--quadrature-decoding"&gt;Encoder Mode &amp;amp; Quadrature Decoding&lt;a class="anchor" href="#encoder-mode--quadrature-decoding"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Rotary encoders are the primary position feedback device in motor control, CNC machines, robotic joints, and manual input knobs. A quadrature encoder outputs two square waves (Channel A and Channel B) with a 90° phase offset — the phase relationship between the two signals encodes both position and direction. STM32 timers include a dedicated encoder mode that decodes these signals entirely in hardware: the timer&amp;rsquo;s CNT register tracks absolute position, incrementing or decrementing on each edge, with no CPU involvement per edge. This eliminates the interrupt overhead and timing sensitivity that software-based quadrature decoding requires.&lt;/p&gt;</description></item><item><title>Environmental Sensor Bus Patterns</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/environmental-sensor-bus-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/environmental-sensors/environmental-sensor-bus-patterns/</guid><description>&lt;h1 id="environmental-sensor-bus-patterns"&gt;Environmental Sensor Bus Patterns&lt;a class="anchor" href="#environmental-sensor-bus-patterns"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A typical environmental monitoring node integrates three to six sensors — temperature, humidity, pressure, VOC, particulate matter, light — almost all of which communicate over I2C. This concentration of devices on a single two-wire bus creates practical challenges: address collisions, bus loading, power sequencing, and the question of whether to poll continuously or sleep between measurements. The firmware architecture for multi-sensor systems follows repeating patterns that, once understood, apply to nearly any combination of environmental sensors.&lt;/p&gt;</description></item><item><title>ESC Integration</title><link>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/esc-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/esc-integration/</guid><description>&lt;h1 id="esc-integration"&gt;ESC Integration&lt;a class="anchor" href="#esc-integration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An electronic speed controller (ESC) is a self-contained BLDC driver that handles commutation, current regulation, and protection — reducing the firmware interface to a single control signal. ESCs originated in the RC hobby world but are now used in drones, robots, electric vehicles, and any application where the complexity of building a custom three-phase inverter is not justified. The MCU sends a throttle command; the ESC manages everything else.&lt;/p&gt;</description></item><item><title>Estimating Power Budgets</title><link>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/power-budgets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/power-architecture/power-budgets/</guid><description>&lt;h1 id="estimating-power-budgets"&gt;Estimating Power Budgets&lt;a class="anchor" href="#estimating-power-budgets"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A power budget accounts for every source of current draw in a system, across all operating modes, and compares the total against what the supply can deliver and what the thermal design can dissipate. Skipping this step leads to regulators that overheat, batteries that die in hours instead of days, and intermittent brownouts that masquerade as firmware bugs. The budget should be a living document — started at schematic time and revised as bench measurements replace datasheet estimates.&lt;/p&gt;</description></item><item><title>External Audio ADCs &amp; DACs</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/external-audio-converters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-conversion/external-audio-converters/</guid><description>&lt;h1 id="external-audio-adcs--dacs"&gt;External Audio ADCs &amp;amp; DACs&lt;a class="anchor" href="#external-audio-adcs--dacs"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;When on-chip conversion is not enough — the noise floor is too high, the resolution is too coarse, or the application demands audiophile-grade specifications — a dedicated external audio converter IC bridges the gap. These devices are purpose-built for audio: 24-bit sigma-delta converters with 100+ dB SNR, integrated anti-aliasing and reconstruction filters, ultra-low jitter clock circuitry, and precisely matched analog front-ends. The trade-off is additional board complexity (I2S bus, clock routing, power supply filtering) and cost ($1–10 per IC).&lt;/p&gt;</description></item><item><title>Flash Wear &amp; Persistent Storage</title><link>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/flash-wear-and-persistent-storage/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/memory-and-linker/flash-wear-and-persistent-storage/</guid><description>&lt;h1 id="flash-wear--persistent-storage"&gt;Flash Wear &amp;amp; Persistent Storage&lt;a class="anchor" href="#flash-wear--persistent-storage"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Internal MCU flash is designed for firmware storage, but it also serves as the only non-volatile memory on many low-cost designs. Using it for runtime data — calibration values, configuration, event counters — is common but comes with hard constraints. Flash has limited erase endurance (typically 10,000 cycles on STM32, up to 100,000 on some NOR flash parts), erase must happen at sector granularity (not byte-level), and writes can only clear bits from 1 to 0. Working within these constraints requires deliberate strategies to avoid wearing out sectors that the firmware also depends on.&lt;/p&gt;</description></item><item><title>Fuel Gauging &amp; SOC</title><link>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/fuel-gauging-and-soc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/li-ion-integration/fuel-gauging-and-soc/</guid><description>&lt;h1 id="fuel-gauging--soc"&gt;Fuel Gauging &amp;amp; SOC&lt;a class="anchor" href="#fuel-gauging--soc"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Reporting battery state of charge (SOC) to a user — as a percentage, a bar graph, or a runtime estimate — requires translating raw electrochemical measurements into a meaningful number. The fundamental challenge is that no single measurement directly reveals how much energy remains in a lithium-ion cell. Voltage correlates with SOC but nonlinearly and with heavy dependence on load current and temperature. Current integration (Coulomb counting) tracks charge flow precisely but accumulates drift errors over time. Production fuel gauge ICs combine both methods with impedance tracking and learned cell models to achieve 1–3% accuracy, but even simple firmware-only approaches can produce usable results with appropriate calibration.&lt;/p&gt;</description></item><item><title>Google Coral Edge TPU</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/coral-edge-tpu/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/hardware-accelerators/coral-edge-tpu/</guid><description>&lt;h1 id="google-coral-edge-tpu"&gt;Google Coral Edge TPU&lt;a class="anchor" href="#google-coral-edge-tpu"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The Google Coral Edge TPU is a purpose-built ASIC for neural network inference, delivering 4 TOPS of INT8 throughput at just 2 W of power. It occupies the low-power, low-cost end of the hardware accelerator spectrum — simpler and more constrained than the Hailo-8L or Jetson Orin Nano, but extremely efficient for models that fit within its operator and quantization requirements. The key design philosophy is that the Edge TPU runs &lt;em&gt;fully quantized INT8 models&lt;/em&gt; with &lt;em&gt;supported operations only&lt;/em&gt; — anything outside those bounds falls back to the host CPU, often with dramatic performance consequences.&lt;/p&gt;</description></item><item><title>GPIO &amp; Peripheral Access: Linux vs Bare-Metal</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/gpio-peripherals-linux-vs-mcu/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/gpio-peripherals-linux-vs-mcu/</guid><description>&lt;h1 id="gpio--peripheral-access-linux-vs-bare-metal"&gt;GPIO &amp;amp; Peripheral Access: Linux vs Bare-Metal&lt;a class="anchor" href="#gpio--peripheral-access-linux-vs-bare-metal"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;On a bare-metal MCU, toggling a GPIO pin means writing directly to a memory-mapped register — a single instruction, deterministic, and immediate. On Linux, that same operation passes through kernel drivers, userspace APIs, and scheduling layers. The abstraction provides safety and portability but introduces latency and non-determinism that fundamentally changes what GPIO can and cannot do.&lt;/p&gt;
&lt;p&gt;Understanding the available access methods, their performance characteristics, and their limitations is essential for choosing the right approach on a Linux-based SBC. Some tasks that are trivial on a bare-metal MCU — bit-banging a custom protocol, generating a precisely-timed PWM signal — become difficult or impossible through a standard Linux GPIO interface. Other tasks — managing dozens of I²C sensors, driving SPI displays while running a network stack — become dramatically easier with a full OS underneath.&lt;/p&gt;</description></item><item><title>Hard Faults &amp; Crash Analysis</title><link>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/hard-faults-and-crash-analysis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/debugging-and-observability/hard-faults-and-crash-analysis/</guid><description>&lt;h1 id="hard-faults--crash-analysis"&gt;Hard Faults &amp;amp; Crash Analysis&lt;a class="anchor" href="#hard-faults--crash-analysis"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;When an ARM Cortex-M processor encounters an unrecoverable error, it triggers a fault exception. Without a proper fault handler, the default behavior is an infinite loop — the system appears frozen with no indication of what went wrong. Implementing fault capture and understanding the fault registers transforms a mysterious hang into a diagnosable event with a precise faulting instruction and root cause.&lt;/p&gt;
&lt;h2 id="cortex-m-fault-types"&gt;Cortex-M Fault Types&lt;a class="anchor" href="#cortex-m-fault-types"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The Cortex-M fault architecture defines four exception types. &lt;strong&gt;HardFault&lt;/strong&gt; (exception 3) is the catch-all — any fault that cannot be handled by a more specific handler escalates here. &lt;strong&gt;BusFault&lt;/strong&gt; fires on invalid memory accesses: reads from unmapped addresses, writes to read-only regions, or peripheral access with clocks disabled. &lt;strong&gt;UsageFault&lt;/strong&gt; catches illegal instructions, unaligned access (when not permitted), and divide-by-zero (if enabled via CCR.DIV_0_TRP). &lt;strong&gt;MemManage&lt;/strong&gt; triggers on MPU violations — access to regions forbidden by the Memory Protection Unit configuration. On Cortex-M0/M0+, only HardFault exists; the other three require Cortex-M3 or higher and must be explicitly enabled via the SHCSR register.&lt;/p&gt;</description></item><item><title>High Current Safety &amp; Thermal Management</title><link>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/high-current-safety/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/led-systems/power-injection/high-current-safety/</guid><description>&lt;h1 id="high-current-safety--thermal-management"&gt;High Current Safety &amp;amp; Thermal Management&lt;a class="anchor" href="#high-current-safety--thermal-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;LED projects are deceptively high-current. A single meter of 144 LED/m WS2812B strip at full white draws over 8A at 5V — comparable to a small space heater in terms of the current flowing through the wiring. The low voltage creates a false sense of safety: 5V won&amp;rsquo;t shock anyone, but 30A at 5V melts undersized wires, overheats connectors, and starts fires just as effectively as high-voltage systems. Every connection, wire, and component in the power path must be rated for the actual current flowing through it.&lt;/p&gt;</description></item><item><title>IMU Configuration &amp; Data Readout</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/imu-configuration-and-data-readout/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/inertial-and-motion/imu-configuration-and-data-readout/</guid><description>&lt;h1 id="imu-configuration--data-readout"&gt;IMU Configuration &amp;amp; Data Readout&lt;a class="anchor" href="#imu-configuration--data-readout"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An Inertial Measurement Unit (IMU) combines multiple inertial sensors — typically a 3-axis accelerometer and a 3-axis gyroscope — into a single package with shared registers, clocking, and data output. The firmware benefits are significant: a single bus transaction can read all 6 axes, the sensors share a common sample clock (eliminating synchronization issues), and the package count drops from 2–3 to 1. The trade-off is more complex register maps, multi-sensor FIFO management, and vendor-specific initialization sequences that must be followed precisely.&lt;/p&gt;</description></item><item><title>In-Circuit Current Monitoring</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/in-circuit-current-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-measurement/in-circuit-current-monitoring/</guid><description>&lt;h1 id="in-circuit-current-monitoring"&gt;In-Circuit Current Monitoring&lt;a class="anchor" href="#in-circuit-current-monitoring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;External power analyzers provide detailed captures during development, but many applications need continuous current and power measurement in the deployed product — battery fuel gauging, over-current protection, load profiling, and energy budgeting across subsystems. The INA219 and INA226 from Texas Instruments are the standard I2C-based current and power monitors for this purpose. Each integrates a programmable-gain ADC, a multiplexer for shunt and bus voltage, and on-chip calibration and power calculation registers, providing milliwatt-resolution power data through a two-wire bus with no external amplifier.&lt;/p&gt;</description></item><item><title>Matter Protocol: Network Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/matter-network-layer/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/matter-network-layer/</guid><description>&lt;h1 id="matter-protocol-network-fundamentals"&gt;Matter Protocol: Network Fundamentals&lt;a class="anchor" href="#matter-protocol-network-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Matter is an application-layer protocol for smart home devices that runs over three transport networks: WiFi, Thread, and Ethernet. BLE is used exclusively for commissioning — the initial pairing process that provisions network credentials — and is not used for runtime communication. This multi-transport approach means a Matter light bulb on Thread and a Matter thermostat on WiFi can communicate through a shared controller without protocol translation, because both speak the same IPv6-based application protocol.&lt;/p&gt;</description></item><item><title>Multi-Device SPI Buses</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-multi-device/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/spi/spi-multi-device/</guid><description>&lt;h1 id="multi-device-spi-buses"&gt;Multi-Device SPI Buses&lt;a class="anchor" href="#multi-device-spi-buses"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A single SPI peripheral can communicate with multiple devices by sharing MOSI, MISO, and SCK while providing a dedicated CS line for each device. This saves peripheral count and GPIO pins, but introduces constraints: devices with different speed requirements, different SPI modes, or conflicting MISO drive behavior must all coexist on the same three wires. Knowing when shared-bus topology works — and when separate SPI peripherals are the safer choice — prevents subtle bugs that only appear when two devices interact.&lt;/p&gt;</description></item><item><title>Multi-Master &amp; Arbitration</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-multi-master/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/i2c/i2c-multi-master/</guid><description>&lt;h1 id="multi-master--arbitration"&gt;Multi-Master &amp;amp; Arbitration&lt;a class="anchor" href="#multi-master--arbitration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;I²C was designed from the start to support multiple masters on the same bus. Arbitration — the mechanism that resolves contention when two masters transmit simultaneously — is built into the protocol at the electrical level, not as an optional extension. In practice, multi-master I²C is uncommon in small embedded systems because the firmware complexity it introduces rarely justifies the architectural benefit. Understanding the arbitration mechanism is still essential, because arbitration loss can occur even in systems that were not designed as multi-master — a stuck slave or a bus fault can trigger arbitration loss interrupts that firmware must handle gracefully.&lt;/p&gt;</description></item><item><title>Packages &amp; Solderability</title><link>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/packages-and-solderability/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/packages-and-solderability/</guid><description>&lt;h1 id="packages--solderability"&gt;Packages &amp;amp; Solderability&lt;a class="anchor" href="#packages--solderability"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The package a microcontroller comes in determines how the board is assembled, how prototyping works, and whether rework is feasible. A design that requires BGA reflow is not getting hand-assembled in a home lab. Conversely, choosing a DIP package for production adds unnecessary board area and limits MCU selection to a shrinking set of legacy parts. Package choice is a design constraint that affects the entire project lifecycle from first prototype to volume manufacturing.&lt;/p&gt;</description></item><item><title>Pose Estimation</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/pose-estimation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/pose-estimation/</guid><description>&lt;h1 id="pose-estimation"&gt;Pose Estimation&lt;a class="anchor" href="#pose-estimation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Pose estimation localizes body keypoints — joints, facial landmarks, or extremities — within an image, producing a skeleton that describes a person&amp;rsquo;s body configuration. Unlike &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/object-detection/"&gt;object detection&lt;/a&gt;, which outputs a bounding box around the whole person, or &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/computer-vision/semantic-segmentation/"&gt;semantic segmentation&lt;/a&gt;, which labels every pixel as &amp;ldquo;person&amp;rdquo; or &amp;ldquo;not person,&amp;rdquo; pose estimation outputs the spatial coordinates of anatomically meaningful points: shoulders, elbows, wrists, hips, knees, ankles, and others. This enables applications that depend on understanding body posture — fitness form analysis, gesture control interfaces, fall detection in elder care, and sign language recognition.&lt;/p&gt;</description></item><item><title>Power over Ethernet: PD Design</title><link>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/poe-pd-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/poe-pd-design/</guid><description>&lt;h1 id="power-over-ethernet-pd-design"&gt;Power over Ethernet: PD Design&lt;a class="anchor" href="#power-over-ethernet-pd-design"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Power over Ethernet (PoE) delivers both data and DC power over standard Ethernet cabling, eliminating the need for a separate power supply at the device. For embedded systems — IP cameras, access points, industrial sensors, building automation controllers — PoE simplifies installation to a single cable drop. The Powered Device (PD) is the equipment that receives power from the cable. Designing the PD side involves selecting the correct IEEE 802.3 power class, choosing a PD controller IC, implementing the detection and classification handshake, converting 48 V to the board&amp;rsquo;s operating voltages, meeting isolation requirements, and managing thermal dissipation.&lt;/p&gt;</description></item><item><title>Power Path &amp; Load Switching</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/power-path-and-load-switching/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-protection/power-path-and-load-switching/</guid><description>&lt;h1 id="power-path--load-switching"&gt;Power Path &amp;amp; Load Switching&lt;a class="anchor" href="#power-path--load-switching"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Embedded systems frequently need to switch power to subsystems — turning off a GPS module during sleep, selecting between battery and USB power, or sequencing multiple voltage domains during startup. While a discrete MOSFET can switch a load, dedicated load switch ICs add controlled slew rate, thermal shutdown, quick output discharge, and reverse current blocking — features that prevent the transient glitches and ground bounce that cause downstream ICs to latch up or fail to initialize.&lt;/p&gt;</description></item><item><title>Power Sequencing — Multi-Rail</title><link>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/power-sequencing-multi-rail/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/power-supply-design/power-sequencing-multi-rail/</guid><description>&lt;h1 id="power-sequencing--multi-rail"&gt;Power Sequencing — Multi-Rail&lt;a class="anchor" href="#power-sequencing--multi-rail"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most embedded systems require more than one supply voltage. A typical Cortex-M7 design needs 1.8 V for the core, 3.3 V for I/O, and possibly 5 V for external peripherals. The order in which these rails turn on — and off — matters. Powering I/O pins before the core is ready can drive current into unpowered logic through ESD protection diodes, triggering latch-up. Removing core power while I/O rails remain active can force outputs into undefined states, back-driving connected devices. Power sequencing ensures every rail comes up and goes down in the correct order, with the correct timing, to prevent damage and undefined behavior.&lt;/p&gt;</description></item><item><title>Profiling &amp; Benchmarking Inference</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/profiling-benchmarking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/profiling-benchmarking/</guid><description>&lt;h1 id="profiling--benchmarking-inference"&gt;Profiling &amp;amp; Benchmarking Inference&lt;a class="anchor" href="#profiling--benchmarking-inference"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A model that meets its accuracy target after &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/quantization/"&gt;quantization&lt;/a&gt; and &lt;a href="https://applied-ee.github.io/embedded/docs/edge-ai/model-optimization/model-conversion/"&gt;conversion&lt;/a&gt; is only half deployed. The other half is meeting latency, memory, and power constraints on the target hardware. A MobileNetV2 int8 model that achieves 71% top-1 accuracy is useless for a 30 fps video pipeline if it takes 50 ms per inference on the target SBC — that leaves only 16 ms for preprocessing, postprocessing, and frame capture. Profiling and benchmarking on the actual deployment hardware — not on a development workstation — is the only way to validate that the optimized model meets its operational requirements.&lt;/p&gt;</description></item><item><title>Relay Drive Patterns</title><link>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/relay-drive-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/linear-actuators-solenoids/relay-drive-patterns/</guid><description>&lt;h1 id="relay-drive-patterns"&gt;Relay Drive Patterns&lt;a class="anchor" href="#relay-drive-patterns"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A relay is a solenoid that switches electrical contacts rather than moving a mechanical load. The coil circuit (driven by the MCU through a transistor) and the contact circuit (carrying the load current) are galvanically isolated — this is the relay&amp;rsquo;s primary value. Relays switch mains power, high-current DC loads, and analog signals that semiconductors cannot handle or where isolation is required. The drive considerations are identical to solenoid circuits (inductive coil, flyback protection), with the added complexity of contact management: bounce, arcing, and welding.&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><item><title>RTC &amp; Low-Speed Clock Domains</title><link>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/rtc-and-low-speed-clocks/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/clocks-and-timing/rtc-and-low-speed-clocks/</guid><description>&lt;h1 id="rtc--low-speed-clock-domains"&gt;RTC &amp;amp; Low-Speed Clock Domains&lt;a class="anchor" href="#rtc--low-speed-clock-domains"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The low-speed clock domain operates independently of the main system clock, providing timekeeping and watchdog functionality that persists through sleep modes, resets, and even main power loss (with battery backup). The 32.768 kHz crystal frequency is not arbitrary — it equals 2^15, which divides down to exactly 1 Hz using a simple 15-stage binary counter. This domain is home to the RTC (Real-Time Clock), wakeup timers, and the independent watchdog.&lt;/p&gt;</description></item><item><title>Sample Rate Conversion</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/sample-rate-conversion/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/sample-rate-conversion/</guid><description>&lt;h1 id="sample-rate-conversion"&gt;Sample Rate Conversion&lt;a class="anchor" href="#sample-rate-conversion"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Sample rate conversion (SRC) becomes necessary whenever two audio components in a system operate at different sample rates — a 16 kHz voice capture feeding a 48 kHz playback pipeline, a USB audio interface at 44.1 kHz connected to an I2S codec at 48 kHz, or two I2S buses clocked from independent oscillators that drift relative to each other. On a desktop, SRC is a library call with negligible CPU cost. On a Cortex-M4, a high-quality sample rate converter can consume 30–50% of the available cycles, making the choice of algorithm and quality level a direct engineering trade-off.&lt;/p&gt;</description></item><item><title>Self-Hosted MQTT Brokers</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/self-hosted-mqtt-brokers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/self-hosted-mqtt-brokers/</guid><description>&lt;h1 id="self-hosted-mqtt-brokers"&gt;Self-Hosted MQTT Brokers&lt;a class="anchor" href="#self-hosted-mqtt-brokers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Self-hosted MQTT brokers provide the same publish/subscribe messaging layer that cloud IoT platforms offer — but under full operational control. The broker runs on private infrastructure (bare metal, VMs, containers, or Kubernetes), handles device authentication and authorization locally, and delivers messages without routing through a cloud provider&amp;rsquo;s endpoint. This eliminates per-message cloud fees, keeps data on-premises for sovereignty requirements, and removes dependency on external service availability. The tradeoff is operational responsibility: scaling, patching, monitoring, TLS certificate management, and persistence all shift to the deploying organization.&lt;/p&gt;</description></item><item><title>Sensor Preprocessing for ML</title><link>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/sensor-preprocessing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/edge-ai/sensor-ml-pipelines/sensor-preprocessing/</guid><description>&lt;h1 id="sensor-preprocessing-for-ml"&gt;Sensor Preprocessing for ML&lt;a class="anchor" href="#sensor-preprocessing-for-ml"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Sensor preprocessing is the bridge between raw sensor hardware and the ML model input tensor. The sensor produces a continuous stream of ADC samples or digital readings at a fixed rate. The model expects a specific fixed-size, normalized tensor at each inference cycle. Between these two endpoints lies a pipeline of buffering, windowing, normalization, and format conversion — and any mismatch between the preprocessing applied during training (in Python on a desktop) and the preprocessing applied during deployment (in C on an MCU) silently degrades model accuracy without producing any error message.&lt;/p&gt;</description></item><item><title>Thermal Management for Drives</title><link>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/thermal-management-for-drives/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/thermal-management-for-drives/</guid><description>&lt;h1 id="thermal-management-for-drives"&gt;Thermal Management for Drives&lt;a class="anchor" href="#thermal-management-for-drives"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Power MOSFETs, motor driver ICs, and shunt resistors in motor drive circuits dissipate significant heat. A MOSFET switching a 5 A motor at 20 kHz with 20 mΩ RDS(on) dissipates 0.5 W in conduction alone — add switching losses and the total can reach 1–3 W per device. In an H-bridge with four FETs, that is 2–12 W of heat in a small area. Without adequate thermal design, junction temperatures rise until the device derate, malfunction, or fail. Thermal management is not an afterthought — it determines the practical current limit of the drive circuit.&lt;/p&gt;</description></item><item><title>Time-Series Databases</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/time-series-databases/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/time-series-databases/</guid><description>&lt;h1 id="time-series-databases"&gt;Time-Series Databases&lt;a class="anchor" href="#time-series-databases"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Time-series databases (TSDBs) are purpose-built for storing and querying timestamped data: sensor readings, device metrics, event counters, and environmental measurements that arrive continuously and are almost always queried by time range. Relational databases can store time-series data, but they struggle with the write throughput, compression ratios, and time-range query performance that IoT workloads demand. A fleet of 10,000 devices reporting 8 metrics every 60 seconds generates 480,000 writes per minute — a sustained write load that requires storage engines optimized for append-heavy, rarely-updated data with natural time-based partitioning.&lt;/p&gt;</description></item><item><title>Ultra-Low-Power Harvesting Budgets</title><link>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/ultra-low-power-harvesting-budgets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/energy-harvesting/ultra-low-power-harvesting-budgets/</guid><description>&lt;h1 id="ultra-low-power-harvesting-budgets"&gt;Ultra-Low-Power Harvesting Budgets&lt;a class="anchor" href="#ultra-low-power-harvesting-budgets"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An energy harvesting system achieves indefinite operation only when the energy harvested over every relevant time period (day, week, worst-case month) equals or exceeds the energy consumed. This energy balance equation governs every design decision — panel size, storage capacity, duty cycle, and transmit strategy. Violating the balance even slightly causes the storage element to trend toward depletion, eventually crossing the undervoltage threshold and shutting the system down. Building a reliable harvesting budget requires quantifying both sides of the equation with realistic numbers, accounting for seasonal variation, weather, component degradation, and the gap between datasheet values and field measurements.&lt;/p&gt;</description></item><item><title>Ultrasonic Distance Measurement</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/ultrasonic-distance-measurement/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/position-and-navigation/ultrasonic-distance-measurement/</guid><description>&lt;h1 id="ultrasonic-distance-measurement"&gt;Ultrasonic Distance Measurement&lt;a class="anchor" href="#ultrasonic-distance-measurement"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Ultrasonic distance sensors measure the round-trip time of a burst of sound pulses to determine the distance to a reflective surface. The HC-SR04 is the ubiquitous ultrasonic ranging module in embedded projects — inexpensive (~$1-2), simple to interface (two GPIO pins), and effective over a 2 cm to 400 cm range. The sensor emits an 8-cycle burst of 38 kHz ultrasound from one transducer and listens for the echo on a paired receiver transducer. The module handles all the analog signal processing internally, presenting the MCU with a single digital echo pulse whose width is proportional to distance. More capable variants like the JSN-SR04T provide waterproof operation for outdoor and liquid-level sensing applications.&lt;/p&gt;</description></item><item><title>Ultrasonic Transducers &amp; Ranging</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/ultrasonic-transducers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/audio-and-acoustic/ultrasonic-transducers/</guid><description>&lt;h1 id="ultrasonic-transducers--ranging"&gt;Ultrasonic Transducers &amp;amp; Ranging&lt;a class="anchor" href="#ultrasonic-transducers--ranging"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Ultrasonic ranging measures distance by timing the round-trip of a sound pulse — the same principle as sonar and radar, scaled down to centimeter-resolution distances using 40 kHz piezoelectric transducers. The technique is conceptually simple: transmit a burst, start a timer, listen for the echo, and compute distance from the elapsed time. The implementation details, however, involve transmit driver circuits, receive amplifier chains, envelope detection, blanking intervals, and careful timing — all within firmware running on a general-purpose MCU. The HC-SR04 module hides most of this complexity behind a trigger/echo interface, but understanding the underlying signal chain is essential for building custom ranging systems with better performance, multiple channels, or integration into space-constrained designs.&lt;/p&gt;</description></item><item><title>USB OTG &amp; Source Mode</title><link>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-otg-and-source-mode/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/power-battery/usb-power-and-pmics/usb-otg-and-source-mode/</guid><description>&lt;h1 id="usb-otg--source-mode"&gt;USB OTG &amp;amp; Source Mode&lt;a class="anchor" href="#usb-otg--source-mode"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;USB On-The-Go (OTG) allows a battery-powered device to switch from its normal role as a USB peripheral (sink) to acting as a USB host (source), providing 5V power and data connectivity to downstream devices. In the legacy Micro-B connector world, OTG detection used the ID pin — grounding the ID pin through a special OTG cable signaled the device to assume the host role. With USB Type-C, OTG is subsumed into the broader concept of Dual Role Port (DRP), where the CC pin resistor configuration determines whether a port acts as source or sink, and roles can be swapped dynamically through USB PD role-swap messages.&lt;/p&gt;</description></item><item><title>Vendor SDKs &amp; Hardware Abstraction Layers</title><link>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/vendor-sdks-and-hals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/vendor-sdks-and-hals/</guid><description>&lt;h1 id="vendor-sdks--hardware-abstraction-layers"&gt;Vendor SDKs &amp;amp; Hardware Abstraction Layers&lt;a class="anchor" href="#vendor-sdks--hardware-abstraction-layers"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;A Hardware Abstraction Layer (HAL) sits between application code and peripheral registers, providing an API that describes intent (configure UART at 115200 baud) rather than mechanism (write 0x00000068 to USART1-&amp;gt;BRR). Vendor SDKs bundle a HAL with startup code, linker scripts, middleware, and example projects. The choice of SDK — or the decision to bypass it — affects code size, performance, portability, and debugging difficulty throughout the life of a project.&lt;/p&gt;</description></item><item><title>WiFi Security on Constrained Devices</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-security/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-security/</guid><description>&lt;h1 id="wifi-security-on-constrained-devices"&gt;WiFi Security on Constrained Devices&lt;a class="anchor" href="#wifi-security-on-constrained-devices"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;WiFi security on microcontrollers involves a different set of trade-offs than on desktop or server platforms. The available RAM limits which TLS cipher suites can be negotiated, the absence of a filesystem complicates certificate management, and the need to store network credentials in flash creates a persistent attack surface. A device shipping with a hardcoded WPA2 PSK in plaintext firmware is trivially compromised by anyone with a UART adapter or a flash dump tool — yet this remains the default pattern in a surprising number of production IoT products.&lt;/p&gt;</description></item><item><title>Audio Effects &amp; Mixing</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/audio-effects-mixing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/audio-dsp/audio-effects-mixing/</guid><description>&lt;h1 id="audio-effects--mixing"&gt;Audio Effects &amp;amp; Mixing&lt;a class="anchor" href="#audio-effects--mixing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Time-domain audio effects — delay, echo, reverb, chorus — all depend on storing audio samples and playing them back later, mixed with the current input. The fundamental data structure is the circular buffer (ring buffer), and the primary constraint is memory: a one-second delay at 48 kHz / 16-bit mono requires 96 KB of RAM. On Cortex-M4 devices with 128–256 KB of SRAM, this leaves little room for anything else. ESP32 and ESP32-S3 with external PSRAM (2–8 MB) open up long delays and reverb networks that are impractical on SRAM-only MCUs.&lt;/p&gt;</description></item><item><title>BLE Power Optimization</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-power-optimization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-power-optimization/</guid><description>&lt;h1 id="ble-power-optimization"&gt;BLE Power Optimization&lt;a class="anchor" href="#ble-power-optimization"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Power consumption is the defining advantage of BLE over other wireless protocols. A BLE peripheral can operate for years on a coin cell battery — but only if the firmware is designed around the protocol&amp;rsquo;s duty-cycling nature. The radio consumes 5–8 mA when transmitting and 5–7 mA when receiving on a typical nRF52 SoC, which means even brief radio activity dominates the total power budget. The difference between a well-optimized and a naively configured BLE device can be 10x in average current draw, translating directly to 10x battery life.&lt;/p&gt;</description></item><item><title>Cameras &amp; Image Capture</title><link>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/cameras-and-image-capture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/sensor-integration/optical-and-proximity/cameras-and-image-capture/</guid><description>&lt;h1 id="cameras--image-capture"&gt;Cameras &amp;amp; Image Capture&lt;a class="anchor" href="#cameras--image-capture"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Camera modules are optical sensors operating at far higher data rates than photodiodes or color sensors — a single 320×240 RGB565 frame is 150 KB, and a 640×480 frame reaches 600 KB. This shifts the engineering challenge from analog front-end design to high-speed digital interfaces, memory management, and image compression. The underlying sensor is a CMOS image array (typically with a Bayer color filter), but the firmware and hardware surrounding it look nothing like a simple I²C light sensor.&lt;/p&gt;</description></item><item><title>Distributed Tracing</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/distributed-tracing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/distributed-tracing/</guid><description>&lt;h1 id="distributed-tracing"&gt;Distributed Tracing&lt;a class="anchor" href="#distributed-tracing"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Distributed tracing tracks a single request or event as it flows through multiple services in a pipeline. In traditional microservice architectures, a trace follows an HTTP request from API gateway through authentication, business logic, and database layers. In IoT, the &amp;ldquo;request&amp;rdquo; is a telemetry message or command that traverses a fundamentally different path: from a constrained device through an MQTT broker, a message router or rule engine, a cloud function, and into a time-series database or command-and-control service. When a sensor reading fails to appear in a dashboard, the question is: did the device fail to publish, did the broker drop the message, did the rule engine misroute it, did the cloud function error, or did the database reject the write? Without distributed tracing, answering this question requires manually correlating logs across 4–6 independent systems.&lt;/p&gt;</description></item><item><title>Ecosystem &amp; Vendor Lock-In</title><link>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/ecosystem-and-vendor-lock-in/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/choosing-the-right-mcu/ecosystem-and-vendor-lock-in/</guid><description>&lt;h1 id="ecosystem--vendor-lock-in"&gt;Ecosystem &amp;amp; Vendor Lock-In&lt;a class="anchor" href="#ecosystem--vendor-lock-in"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The silicon is only half the decision. The toolchain, HAL, documentation, community, and long-term supply chain behind an MCU determine whether development moves quickly or bogs down in obscure register configurations and unanswered forum posts. A technically superior chip with a broken IDE and sparse documentation costs more in engineering time than a slightly less capable part with a polished ecosystem. Vendor lock-in compounds this: firmware written against a proprietary HAL does not port to a different vendor without substantial rewriting.&lt;/p&gt;</description></item><item><title>Image-Based Deployments &amp; System Updates</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/image-based-deployments/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/image-based-deployments/</guid><description>&lt;h1 id="image-based-deployments--system-updates"&gt;Image-Based Deployments &amp;amp; System Updates&lt;a class="anchor" href="#image-based-deployments--system-updates"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Deploying software to an embedded Linux device is fundamentally different from deploying firmware to an MCU. Instead of flashing a single binary, the deployment unit is an entire OS image — kernel, root filesystem, configuration, and application — or a carefully managed set of packages. How that image gets built, written to storage, and updated in the field determines the reliability and maintainability of the product. A device that can be updated safely and rolled back on failure is a device that can survive years of field deployment. A device that cannot is a device that eventually becomes e-waste.&lt;/p&gt;</description></item><item><title>Link Management &amp; Diagnostics</title><link>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/ethernet-link-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ethernet-poe/ethernet-link-management/</guid><description>&lt;h1 id="link-management--diagnostics"&gt;Link Management &amp;amp; Diagnostics&lt;a class="anchor" href="#link-management--diagnostics"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An Ethernet link is not a fire-and-forget connection. Cables get unplugged, switches reboot, duplex mismatches degrade throughput silently, and long cable runs develop faults over time. On MCU-based devices that often run unattended for months or years, robust link management — detecting link state changes, diagnosing failures, and recovering automatically — is as important as getting the initial connection working. The PHY provides the raw link status and diagnostic capabilities through MDIO registers; the firmware must poll or react to these signals and take appropriate action.&lt;/p&gt;</description></item><item><title>Mesh Networking Topologies &amp; Trade-offs</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/mesh-topologies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/mesh-topologies/</guid><description>&lt;h1 id="mesh-networking-topologies--trade-offs"&gt;Mesh Networking Topologies &amp;amp; Trade-offs&lt;a class="anchor" href="#mesh-networking-topologies--trade-offs"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Mesh networking enables devices to relay messages for each other, extending coverage beyond the range of any single radio. The appeal is obvious: no single point of failure, self-healing paths, and coverage that scales with device count rather than AP placement. The cost is equally real: higher power consumption for routing devices, increased latency per hop, protocol complexity, and failure modes that are harder to diagnose than a simple star topology.&lt;/p&gt;</description></item><item><title>Power Layout &amp; Decoupling</title><link>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/power-layout-and-decoupling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/drive-circuitry/power-layout-and-decoupling/</guid><description>&lt;h1 id="power-layout--decoupling"&gt;Power Layout &amp;amp; Decoupling&lt;a class="anchor" href="#power-layout--decoupling"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Motor drive circuits switch amps of current at tens of kHz through inductive loads — the resulting high dI/dt produces voltage transients, ground bounce, and radiated EMI that can reset the MCU, corrupt ADC readings, and interfere with communication buses. The PCB layout of the power stage is as important as the schematic. A motor drive that works on a breadboard may fail on a PCB with poor layout, and vice versa — the difference is parasitic inductance, ground impedance, and capacitor placement.&lt;/p&gt;</description></item><item><title>S/PDIF Digital Audio</title><link>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/spdif-digital-audio/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/audio-projects/i2s-audio-pipelines/spdif-digital-audio/</guid><description>&lt;h1 id="spdif-digital-audio"&gt;S/PDIF Digital Audio&lt;a class="anchor" href="#spdif-digital-audio"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;S/PDIF (Sony/Philips Digital Interface) carries stereo PCM audio over a single unidirectional connection — either a coaxial cable or a TOSLINK optical fiber. Unlike I2S, which uses separate clock and data lines, S/PDIF embeds the clock in the data stream using biphase mark coding. This self-clocking property means only one signal wire is needed, but it also means the receiver must recover the clock from the incoming bitstream, introducing jitter sensitivity that does not exist in I2S links.&lt;/p&gt;</description></item><item><title>Self-Hosted Device Management</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/self-hosted-device-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/self-hosted-device-management/</guid><description>&lt;h1 id="self-hosted-device-management"&gt;Self-Hosted Device Management&lt;a class="anchor" href="#self-hosted-device-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Cloud IoT platforms bundle device management as a suite of managed services — AWS IoT Core provides thing registries and fleet provisioning, Azure DPS handles zero-touch enrollment, and both offer device shadows/twins for state synchronization. Self-hosted deployments must build each of these capabilities from individual components: a provisioning server for device enrollment, a certificate authority for identity management, an OTA update server for firmware delivery, and a state synchronization mechanism for configuration management. The operational surface area is significantly larger, but the architecture is fully customizable and free from cloud vendor constraints.&lt;/p&gt;</description></item><item><title>Sensorless Back-EMF</title><link>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/sensorless-back-emf/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/brushless-motors/sensorless-back-emf/</guid><description>&lt;h1 id="sensorless-back-emf"&gt;Sensorless Back-EMF&lt;a class="anchor" href="#sensorless-back-emf"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Eliminating Hall sensors from a BLDC motor reduces cost, connector count, and failure points — but the controller must determine rotor position from the motor&amp;rsquo;s own electrical signals. The dominant technique for trapezoidal (six-step) sensorless drives is &lt;strong&gt;back-EMF zero-crossing detection&lt;/strong&gt;: when one phase is floating (undriven), its terminal voltage crosses the virtual neutral point at a predictable rotor angle. Detecting this crossing provides the timing reference for the next commutation event.&lt;/p&gt;</description></item><item><title>Stepper Driver ICs</title><link>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/stepper-driver-ics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/motor-control/stepper-motors/stepper-driver-ics/</guid><description>&lt;h1 id="stepper-driver-ics"&gt;Stepper Driver ICs&lt;a class="anchor" href="#stepper-driver-ics"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Dedicated stepper driver ICs handle the complex task of regulating coil current, generating microstep waveforms, and protecting the motor and driver from overcurrent, overtemperature, and short circuits. The three most common drivers in hobbyist and light-industrial embedded work are the Allegro A4988, Texas Instruments DRV8825, and Trinamic TMC2209. Each occupies a different point in the cost/feature/performance space.&lt;/p&gt;
&lt;h2 id="feature-comparison"&gt;Feature Comparison&lt;a class="anchor" href="#feature-comparison"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Feature&lt;/th&gt;
 &lt;th&gt;A4988&lt;/th&gt;
 &lt;th&gt;DRV8825&lt;/th&gt;
 &lt;th&gt;TMC2209&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Max voltage&lt;/td&gt;
 &lt;td&gt;35 V&lt;/td&gt;
 &lt;td&gt;45 V&lt;/td&gt;
 &lt;td&gt;29 V&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Max current (RMS)&lt;/td&gt;
 &lt;td&gt;2.0 A&lt;/td&gt;
 &lt;td&gt;2.5 A&lt;/td&gt;
 &lt;td&gt;2.0 A (with heatsink)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Microstep resolution&lt;/td&gt;
 &lt;td&gt;1/16&lt;/td&gt;
 &lt;td&gt;1/32&lt;/td&gt;
 &lt;td&gt;1/256 (interpolated)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Current regulation&lt;/td&gt;
 &lt;td&gt;Fixed off-time chopper&lt;/td&gt;
 &lt;td&gt;Slow/mixed/fast decay&lt;/td&gt;
 &lt;td&gt;SpreadCycle / StealthChop&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;UART/SPI interface&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;UART (single-wire)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Stall detection&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;StallGuard&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Automatic current reduction&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;No&lt;/td&gt;
 &lt;td&gt;CoolStep&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Thermal shutdown&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Package&lt;/td&gt;
 &lt;td&gt;QFN-28&lt;/td&gt;
 &lt;td&gt;QFN-28&lt;/td&gt;
 &lt;td&gt;QFN-28&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Typical module cost&lt;/td&gt;
 &lt;td&gt;$1–2&lt;/td&gt;
 &lt;td&gt;$2–3&lt;/td&gt;
 &lt;td&gt;$4–7&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;h2 id="a4988-configuration"&gt;A4988 Configuration&lt;a class="anchor" href="#a4988-configuration"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The A4988 is the entry-level chopper driver. Current limit is set with a trimpot that adjusts the reference voltage:&lt;/p&gt;</description></item><item><title>WiFi Power Management</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-power-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/wifi-power-management/</guid><description>&lt;h1 id="wifi-power-management"&gt;WiFi Power Management&lt;a class="anchor" href="#wifi-power-management"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;WiFi is the most power-hungry radio option available on low-cost microcontrollers. An ESP32 transmitting at full power draws 240 mA — enough to drain a 1000 mAh LiPo battery in about four hours of continuous use. Battery-powered WiFi devices are only viable through aggressive duty cycling: keeping the radio off for the vast majority of the time and minimizing the duration of each active period. The 802.11 standard includes power save mechanisms that allow a station to sleep between beacon intervals, but these were designed for laptops, not microcontrollers — getting them to work reliably on constrained devices requires careful tuning of listen intervals, DTIM settings, and AP compatibility.&lt;/p&gt;</description></item><item><title>BLE Central Role &amp; Scanning</title><link>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-scanning-central/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/bluetooth-ble/ble-scanning-central/</guid><description>&lt;h1 id="ble-central-role--scanning"&gt;BLE Central Role &amp;amp; Scanning&lt;a class="anchor" href="#ble-central-role--scanning"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Most BLE tutorials focus on the peripheral role — advertising a service and waiting for a phone to connect. But many embedded applications require the MCU to act as a &lt;strong&gt;central&lt;/strong&gt;: scanning for peripherals, initiating connections, and managing ongoing data exchange with one or more remote devices. The gateway pattern — an MCU central aggregating data from a fleet of BLE sensor peripherals — is one of the most common architectures in commercial IoT deployments. Running a BLE central on an MCU introduces scheduling challenges, memory constraints, and scanning trade-offs that do not exist in phone-based central implementations.&lt;/p&gt;</description></item><item><title>Boot Process &amp; System Configuration</title><link>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/boot-process-and-configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/foundations/embedded-os-sbc/boot-process-and-configuration/</guid><description>&lt;h1 id="boot-process--system-configuration"&gt;Boot Process &amp;amp; System Configuration&lt;a class="anchor" href="#boot-process--system-configuration"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;An embedded Linux device goes through multiple firmware stages before the application code runs. Understanding this sequence — and where each stage can be configured, measured, and optimized — is essential for reducing boot time, debugging startup failures, and building reliable systems that recover from faults.&lt;/p&gt;
&lt;p&gt;The boot chain is deterministic: each stage loads and validates the next, handing off control in a fixed order. A failure at any stage halts the process, and the symptoms observed at the serial console directly indicate which stage failed. Knowing the chain makes root-cause analysis straightforward.&lt;/p&gt;</description></item><item><title>Hybrid Architectures</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/hybrid-architectures/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/platform-architecture/hybrid-architectures/</guid><description>&lt;h1 id="hybrid-architectures"&gt;Hybrid Architectures&lt;a class="anchor" href="#hybrid-architectures"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Hybrid IoT architectures split infrastructure between local (on-premises or edge) and cloud components. A local MQTT broker handles device-facing traffic — low-latency messaging, store-and-forward during connectivity gaps, and data that must stay on-premises — while cloud services provide analytics, long-term storage, fleet-wide dashboards, and integrations that benefit from elastic scale. This is not a compromise between cloud-managed and self-hosted; it is a distinct architectural pattern that addresses requirements neither approach satisfies alone.&lt;/p&gt;</description></item><item><title>mDNS, HTTP Servers &amp; Local Discovery</title><link>https://applied-ee.github.io/embedded/docs/networking/wifi/mdns-http-local/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/wifi/mdns-http-local/</guid><description>&lt;h1 id="mdns-http-servers--local-discovery"&gt;mDNS, HTTP Servers &amp;amp; Local Discovery&lt;a class="anchor" href="#mdns-http-servers--local-discovery"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Many embedded WiFi devices need to be reachable on a local network without requiring the user to know the device&amp;rsquo;s IP address. mDNS (multicast DNS) provides hostname resolution — a device advertising itself as &lt;code&gt;sensor-01.local&lt;/code&gt; can be reached by name from any machine on the same subnet. DNS-SD (DNS Service Discovery) extends this by advertising available services, so a configuration tool can discover all devices of a given type without scanning IP ranges. Running a lightweight HTTP server on the MCU itself enables web-based configuration pages, REST APIs for local control, and status dashboards — all without any cloud dependency.&lt;/p&gt;</description></item><item><title>SIEM &amp; Security Monitoring</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/siem-security-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/monitoring-telemetry/siem-security-monitoring/</guid><description>&lt;h1 id="siem--security-monitoring"&gt;SIEM &amp;amp; Security Monitoring&lt;a class="anchor" href="#siem--security-monitoring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Security Information and Event Management (SIEM) applies to IoT fleets differently than to traditional IT infrastructure. Enterprise SIEM monitors user logins, firewall logs, endpoint detection alerts, and application audit trails. IoT SIEM monitors device authentication events, firmware integrity, anomalous traffic patterns, and communication between constrained devices and cloud endpoints — a fundamentally different telemetry profile with different threat models. A compromised web server exfiltrates data; a compromised IoT device may become part of a botnet, physically manipulate an actuator, or provide a lateral entry point into an enterprise network. Detecting and responding to these threats requires security monitoring infrastructure tuned to the unique characteristics of embedded device fleets.&lt;/p&gt;</description></item></channel></rss>