Linux board or microcontroller for a new product

A prototype runs on a Raspberry Pi or similar Linux board and everything works. Then someone asks what it takes to build five hundred of them, and the answer is less obvious than it looked on the bench. Part of the problem is cost and supply. Most of it is that a Linux board and a microcontroller are different kinds of product to own.

This note is the set of checks we would run before choosing. None of them depends on a particular price list, because prices move and the checks do not.

Start with what the product must do when nobody is watching

The prototype question is “can it do the job?” The product question is “what happens at 3 a.m. in a closet, after someone pulls the plug?”

Write down five behaviors before you pick silicon:

1. How it starts. Seconds of boot are fine for a media box. They are not fine for a sensor that must be sampling when power returns.
2. How it stops. Does the user ever cut power without warning? Battery swaps, breakers and loose plugs all count.
3. How it is updated. Over the network, from a USB stick, or never.
4. How long it must be supported. Two years, or fifteen.
5. What it must never do. A heater that stays on, a valve that stays open.

If the answers lean toward instant start, hard power loss, long life and safe defaults, a microcontroller usually fits. If they lean toward a rich UI, a full network stack, a camera pipeline or existing Linux software you do not want to rewrite, a Linux module earns its place.

What a Linux module actually asks of the rest of the design

A compute module is not a bigger microcontroller. It is a small computer that needs a carrier board, and the carrier is where the product work lives.

The Raspberry Pi documentation for the Compute Module says a custom carrier must supply the module’s rails, at minimum 3.3 V and 1.8 V, and describes the eMMC and the boot-mode jumper used to flash it over USB. That is a reasonable picture of the work: power sequencing, a flashing path for the line, high-speed routing, and a mechanical connector the product has to live with.

Three consequences follow.

Storage is a reliability decision. The module boots a general-purpose operating system from flash, and a general-purpose filesystem does not enjoy being interrupted mid-write. The usual mitigations are a read-only root filesystem, a separate small data partition, and a clean shutdown path triggered by a power-loss detector with enough hold-up energy to finish. Each one is work you own. We covered the same failure from the other side in logging to an SD card without corrupting it on power loss, and the cause is the same.

Power is bigger than the datasheet headline. The module’s own reference carrier takes USB-C power at 5 V and up to 5 A, per the same documentation. A product with a small supply or a battery has to budget for that, and for the rails behind it, not for an idle figure.

Software maintenance never ends. A Linux image has a kernel, libraries and a network stack, all of which accumulate security fixes. If you ship it, you own an update pipeline for as long as the product lives. That is a real cost in time and risk even when the hardware is cheap.

What a microcontroller asks of you instead

A microcontroller moves the burden from the operating system to your firmware, and the burden is smaller but sharper.

You choose the peripherals, so you pick a part that has what you need on-chip. You usually do not get a display pipeline, a file system, a TLS stack and a full network stack for free; you add libraries or an RTOS, as discussed in choosing between bare metal and an RTOS.

What you gain is predictability. Power-up is fast. Power loss during normal operation is easy to design for because there is no filesystem hidden under your code unless you add one. Low-power modes are documented at the register level. For example, the ESP-IDF sleep-mode documentation lists which wake sources the ESP32-S3 supports in deep sleep and which memories stay powered, and it makes the trade between wake time and retained state explicit.

Updates are also better defined. The ESP-IDF OTA documentation describes application rollback, signature checking of update images, and an anti-rollback option that rejects older security versions. Other vendors’ MCUs offer similar mechanisms, and the design question is the same as in firmware updates with recovery and rollback. Check the specific chip’s documentation rather than assuming it.

Supply and longevity, without the headlines

Memory pricing has pushed around the board market this year. Raspberry Pi’s own price-rise announcement attributes the increase to the cost of LPDDR4 memory and says it affects models with 2 GB or more, while 1 GB models and older boards were not changed. It also describes the situation as temporary. Read that as a lesson in structure rather than a forecast: a Linux module carries external DRAM, and DRAM is a commodity whose price you do not control. A microcontroller with on-chip SRAM and flash has no such exposure, though it has its own allocation risks.

Longevity is the better question than price. The Compute Module 5 product page states it will remain in production until at least January 2036, which is a long commitment by the standards of this market. A commitment covers that module, not every board around it, so check the date for each part you plan to use. The same page lists several memory and storage variants, and those are separate decisions with separate availability.

For any option, do the checks from checking a chip’s longevity commitment before you design it in. Whatever you select, a one-page record of the supported variants, the alternates and the last date you can still buy will save an emergency redesign later.

A quick way to decide

If the product needs	Lean toward
Rich UI, camera, large existing Linux software	Linux module
Instant start, hard power cuts, battery life measured in months	Microcontroller
Network connectivity with simple payloads	Microcontroller with a radio
Many years of unattended field life	Whichever you can keep patched and in supply
Fastest path to a one-off demo	Linux board, then decide again

Two cases are common. The first is the product that needs a screen and a network and nothing else heavy. A modern MCU with a display interface can do it, and the savings in boot time, power and update surface are real. The second is the product that must run a vision model or a large third-party application. There the Linux module is the honest answer, and the work moves to the carrier, the storage design and the update pipeline.

Mixed designs also work. A small microcontroller can own power, safety outputs and real-time control, while a module handles the interface. The cost is a second firmware and a defined protocol between them, so only do it when the split is clean.

How we approach it

We start from the five behaviors above, shortlist two architectures, and check each against power, storage, update path, and supply before any layout begins. If you have a working prototype, send the schematic or a parts list, a description of how the product is powered and used, and how many units and how many years you expect. We will tell you which side of the line it falls on and why.

Sources: Raspberry Pi price announcement, Compute Module 5 product page, Compute Module documentation, ESP-IDF OTA, ESP-IDF sleep modes.