How Do You Choose a Wi-Fi Module for an Embedded Product?

Detailed Explanation

Choosing a Wi-Fi module is primarily an architecture decision, not a feature checklist — the real question is whether Wi-Fi drives the platform choice (use an integrated SoC) or gets added to a platform already chosen for other reasons (use a companion chip). For Wi-Fi protocol fundamentals, see What Is Wi-Fi?; for provisioning flows once a module is selected, see Wi-Fi provisioning for embedded IoT products.

Integrated Wi-Fi SoC vs Companion Chip

Integrated Wi-Fi SoC (ESP32, RTL8720D): the Wi-Fi radio, MAC, and an application-capable CPU core all live on one die. Your application firmware runs directly on this chip — there is no separate host MCU. This is the lower-BOM-cost, lower-board-complexity option for products where Wi-Fi is central to the design and the application's resource needs (RAM, flash, peripheral count) fit within what the SoC offers.

Companion Wi-Fi chip (ATWINC1510, most CYW43xx variants): the Wi-Fi radio and MAC live on a separate die from your application processor, connected over SPI or SDIO. Your existing (or independently chosen) host MCU runs the application and communicates with the Wi-Fi chip through a driver and command protocol. This is the right choice when the host MCU is fixed by other requirements — a specific peripheral set, an existing certified codebase, or a supply-chain commitment — and Wi-Fi needs to be layered onto it without forcing a platform change.

Module Comparison

ESP32 has the largest community, the most mature SDK (ESP-IDF), and the broadest module ecosystem (from bare chip to fully certified modules with onboard antennas). Its dual-core architecture allows dedicating one core to networking and one to application logic, which simplifies real-time behaviour compared to a single-core alternative. See how do you choose between ESP32 variants? for the S2/S3/C3 family breakdown, and ESP-IDF vs Arduino for ESP32 for the firmware framework decision.

ATWINC1510 is a Wi-Fi-only (no BLE) companion chip aimed at adding basic Wi-Fi connectivity to an existing 8-bit (AVR, PIC) or 32-bit host design at low cost. It handles the full TCP/IP stack internally, reducing the host-side firmware burden compared to a bare radio chip, but its throughput and feature set are more limited than a modern SoC.

CYW43439/CYW4343W combines Wi-Fi and BLE in a single companion die, commonly used where an existing host MCU (notably the RP2040 in the Raspberry Pi Pico W) needs both radios without an integrated application processor of its own. SDIO variants offer meaningfully higher throughput than SPI-only alternatives, at the cost of requiring an SDIO-capable host peripheral.

RTL8720D is a less common but credible ESP32 alternative with a genuinely dual-core architecture (a dedicated Wi-Fi/BLE core plus a separate application core), which can simplify timing-sensitive application code that would otherwise compete with networking tasks for CPU time on a more tightly coupled single-core design.

Design Considerations

• Decide the architecture question first, before comparing chip specifications. If Wi-Fi is central to the product, default to an integrated SoC (ESP32 is the default choice given its ecosystem maturity) unless a specific requirement rules it out. If the host MCU is already fixed, a companion chip is the only realistic option regardless of feature comparisons.
• Budget host-side firmware footprint for companion chips. SPI-connected companion chips still require flash and RAM budget on the host for the driver and, in some cases, the TCP/IP stack — this is not "free" connectivity from the host MCU's resource perspective.
• Check antenna and certification status before committing. A pre-certified module (with RCM/FCC/CE marking already obtained for the module itself) significantly simplifies the compliance path versus a bare die requiring your own certification — see the Compliance topic for what a module's certification does and doesn't cover for your complete product.
• Confirm SDK and toolchain maturity for your target volume and support horizon. ESP-IDF has the deepest community support; companion-chip vendor SDKs (Microchip, Infineon) are typically narrower in scope but adequate for straightforward connectivity requirements. Zeus Design selects and integrates Wi-Fi modules as part of embedded hardware and firmware development for IoT products.
• Plan for Wi-Fi/BLE coexistence from the start if both radios are needed — see how do Wi-Fi and BLE coexist in the 2.4 GHz band? for the throughput and jitter trade-offs of running both simultaneously.

Common Mistakes

• Selecting a companion chip when an integrated SoC would eliminate a whole MCU from the BOM. If nothing else constrains the host MCU choice, defaulting to a companion-chip architecture out of familiarity adds unnecessary board complexity and cost.
• Underestimating the SPI/SDIO driver integration effort for companion chips. Vendor SDKs vary significantly in maturity; budget real integration time, not just BOM cost, when comparing a companion chip against an integrated SoC.
• Assuming all companion chips include BLE. The ATWINC1510 is Wi-Fi-only; a design that later needs BLE alongside Wi-Fi on that platform will need an additional BLE chip or a platform change.
• Choosing based on a feature table without checking module-level certification. A bare radio die requires the product manufacturer to obtain radio certification directly, which is a materially different (and slower) compliance path than using a pre-certified module.
• Not validating real-world throughput and coexistence behaviour early, especially for companion chips over SPI, where achievable throughput is often well below the radio's theoretical maximum once host-side driver overhead is accounted for.