WiFi on Embedded Systems Development

WiFi Fundamentals for Embedded

Mon, 01 Jan 0001 00:00:00 +0000

WiFi Fundamentals for Embedded#

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.

Station Mode & Connection Management

Mon, 01 Jan 0001 00:00:00 +0000

Station Mode & Connection Management#

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.

SoftAP, Captive Portals & Provisioning

Mon, 01 Jan 0001 00:00:00 +0000

SoftAP, Captive Portals & Provisioning#

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.

WiFi Security on Constrained Devices

Mon, 01 Jan 0001 00:00:00 +0000

WiFi Security on Constrained Devices#

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.

WiFi Power Management

Mon, 01 Jan 0001 00:00:00 +0000

WiFi Power Management#

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.

mDNS, HTTP Servers & Local Discovery

Mon, 01 Jan 0001 00:00:00 +0000

mDNS, HTTP Servers & Local Discovery#

Many embedded WiFi devices need to be reachable on a local network without requiring the user to know the device’s IP address. mDNS (multicast DNS) provides hostname resolution — a device advertising itself as sensor-01.local 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.