MCU or Linux SoC for an AI Wearable: The Decision

Concept render

Start with standby power. Espressif lists 240 µA for ESP32-S3 light sleep. NXP measured 122.4 mW for Linux suspend on an i.MX 93 evaluation kit. On a hypothetical 300 mAh, 3.7 V cell, that is about 52 days against about 9 hours. The parts are not like-for-like, so measure your own board.

An AI wearable needs a processor platform before it needs a model. A microcontroller with an RTOS sleeps cheaply. A Linux processor gives you a large software base and costs more power while idle. This guide puts published sleep figures side by side, shows the battery arithmetic, lists the traps that follow from the documentation and gives a measurement checklist for your own board. It is an engineering explainer. It reports no benchmark and no Duobay price.

What do the published sleep figures say?

These figures come from the vendors' own documents, read on October 31, 2026. They are not like-for-like. One is a datasheet table for a bare chip, and the other is a measurement on an evaluation kit. Use them for the order of magnitude only.

The ESP32-S3 sleep values are typical values with Wi-Fi powered down. The NXP table is an application note for the MCIMX93-EVK. NXP also describes its Suspend mode as the deepest saving state, with the Cortex-A55 fully power gated and the PHYs power gated. It adds that the mode takes longer to exit than Idle and uses far less energy (NXP AN13917, as of October 31, 2026).

What does the battery arithmetic look like?

Battery life is stored energy divided by average power, so hours = battery_mWh / average_power_mW, and mW = mA × V at the battery voltage you assume. The example uses a hypothetical 300 mAh cell at 3.7 V, which is 1110 mWh. It is an assumption for the arithmetic and not a Duobay product.

• Linux suspend row on the NXP kit: 1110 / 122.4 gives about 9 hours of standby.
• ESP32-S3 light-sleep floor: 300 mAh / 0.24 mA gives 1250 hours, which is about 52 days.

Both runtimes are sleep-state figures. They leave out the radio, sensors, microphones, PSRAM and regulator losses, and they come from different boards. The example shows scale and does not predict your product. The published figures set only the order of magnitude. The DSM and BBSM rows are much lower, but the NXP table does not say whether either state can be used with Linux resumable.

Which platform fits which workload?

The sources do not rank the platforms for you, and this page sets no threshold. Three patterns follow from what they publish.

• Mostly capture, wake and a link. When the model runs in a cloud API, the device mostly needs audio capture, a BLE or Wi-Fi link and a secure connection. That workload often fits an MCU class part, and the published sleep figures favor it for standby.
• Features that need a Linux processor. A rich UI, a camera pipeline or a full network stack push toward Linux, and then standby behavior on your own board decides whether the product can keep its promise.
• Hybrid. The NXP table lists an M33 core in WFI while Linux is suspended, so that chip family has a small core beside the application cores. Whether such a core can carry your always-on work is something to measure.

On the software side, the Zephyr documentation describes an RTOS built on a small-footprint kernel for resource-constrained systems, with resources defined at compile time to reduce code size (Zephyr introduction, as of October 31, 2026). The page gives no kernel footprint or boot-time numbers, so boot time needs a measurement on your board.

What are the common traps?

These follow from the published facts above. They are engineering reasoning about how the numbers behave. None describes an incident at any company.

• The Linux suspend figure. NXP measured 122.4 mW for Linux suspend with the M33 in WFI on its evaluation kit. On the hypothetical 300 mAh, 3.7 V cell below, that row alone gives about 9 hours of standby, before any radio or sensor. The same table lists lower i.MX 93 states, DSM at 7.6 mW and BBSM at 0.1 mW. Whether a product can reach either state with Linux resumable and a usable wake source is an open question to measure on your board.
• Wake sources under Linux. The kernel documentation says the suspend-to-RAM and standby states cannot be implemented without platform support, and that on some platforms low-level components usually prevent in-band hardware interrupts from waking the system. A wake-word or button design has to be checked against the actual platform support.
• Suspend that exits slowly. NXP says its Suspend mode takes longer to exit than Idle but uses far less energy. Deeper saving costs resume time. The text we cite gives no resume figure, so the number is yours to measure.
• Wake latency on an MCU too. The ESP-IDF documentation says wakeup from light sleep takes some time, so not every character sent to the UART can be received. Any first byte, audio sample or button edge during the wake window may be lost unless the design plans for it.
• Flash power-down time. The same documentation says the SPI flash may need more than 300 ms to fully power down. A design that cycles sleep quickly can pay for that.
• Typical values with parts switched off. The ESP32-S3 sleep figures are typical values with Wi-Fi powered down, and PSRAM adds current (140 µA for 8 MB 8-line at 3.3 V). A real product with a radio link, PSRAM and sensors draws more.
• Comparing an evaluation kit with a bare chip. The NXP numbers come from an evaluation kit and the Espressif numbers from a datasheet table. They sit on different rails and measure different things. Read the comparison as an order of magnitude only.
• Boot and footprint claims. The Zephyr introduction page describes a small-footprint kernel for constrained systems and gives one figure, Bluetooth Mesh fitting in devices with at least 16k RAM. It gives no kernel footprint or boot time. Treat any boot-time number you see without a measurement method as unverified.

What should you measure on your own board?

No source we found gives boot time, resume latency or real average current for your product. We have not measured them, and no result appears here. This is a measurement list only. You set the pass line for each item from your product requirements, and you record the basis for that line next to the data.

What should you settle before you choose?

Each question has a yes or no answer. Take the list to your firmware lead, and to any supplier who proposes a platform.

• Do we have a written standby promise, and does a measurement on our own board support it?
• Does any feature need Linux, such as a rich UI, a camera pipeline or a full network stack?
• Could each Linux feature move to a cloud API or be dropped?
• Have we listed every wake source, and has each one been shown to wake the platform from its deepest sleep state?
• Have we measured the time from wake event to first stored audio sample with a logic analyzer?
• Do we know which datasheet figures are typical values, and with which parts switched off?
• Is any power number in our plan from an evaluation kit rather than from our own board?
• If we consider a hybrid design, do we know which processor runs the always-on work and what waking the other one costs?
• Has our firmware lead written down what must be built from scratch on each platform?
• Do we know who maintains the OS and security patches over the product life, and how they are delivered?
• Do we know which datasheet and application-note versions we read, and who re-checks them before launch?

Chip and module selection is part of Gate 0 Feasibility, and measured power, latency and RF numbers come at Gate 1, the works-like prototype. Tell us about your device to start. You can also read how our firmware approach treats platform choice and source ownership.

Sources

All pages accessed October 31, 2026. Datasheet and application-note versions change, so re-read them before launch.

• Espressif, ESP32-S3 datasheet: https://documentation.espressif.com/esp32-s3_datasheet_en.pdf (accessed 2026-10-31)
• NXP, AN13917 (i.MX 93 power consumption and measurement): https://www.NXP.com/docs/en/application-note/AN13917.pdf (accessed 2026-10-31)
• Linux kernel documentation, system suspend code flows: https://docs.kernel.org/admin-guide/pm/suspend-flows.html (accessed 2026-10-31)
• Zephyr Project, introduction: https://docs.zephyrproject.org/latest/introduction/index.html (accessed 2026-10-31)
• Espressif, ESP-IDF sleep modes for ESP32-S3: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/system/sleep_modes.html (accessed 2026-10-31)