A connected node can run its radio and its application on one wireless MCU, or it can keep a separate radio beside a host processor of its own. The choice trades a smaller and cheaper board against flexibility and a lighter exposure to any single vendor's lifecycle, and it is a decision to make on purpose rather than inherit from whichever reference design happened to land on the bench first.

Many of the radio subpillars meet this question from their own side, since a BLE SoC, an integrated cellular part, or a LoRa-plus-MCU all fold the radio into the processor. Seen from the host's side, the same decision reads differently: it is about whether the application gets its own MCU, chosen for its peripherals, its power, and its supply, with the radio kept as a part that can be swapped without redrawing everything around it. That framing is the one this subpillar takes, because it is the one that decides how a long-lived product ages.

Integrate or keep them separate

Integration is the obvious win on paper. One wireless MCU removes a second chip, the interface between the two, and a whole power domain, which shrinks the board, drops the bill of materials, and lets the application and the radio share one set of sleep states and one toolchain. For a small, high volume product built around a known radio, that is usually the right call, and many of the integrated parts in the other subpillars exist precisely because this path wins so often that it has become the default. Stated plainly, the question is when a wireless MCU genuinely replaces a separate radio and host and when the seam between them earns its keep, and a long-lived design settles that before it commits to a part.

The cost of integration is not on the bench, it is in the years that follow, and it is the part a first design tends to miss. A wireless MCU ties the application to one vendor's part and to that part's lifecycle, so the radio, the processor, and the software become a single dependency rather than three that can move on their own. If that part reaches end of life, or its supply tightens, or its next generation shifts the pinout, the whole design moves with it, firmware and board together, because there is no seam to cut along. A separate radio and host keep that seam open: the application lives on a standard MCU with second sources and a long life of its own, the radio is a part that can be changed for a pin-compatible alternative or a different vendor's module without touching the application, and a problem on one side can be solved without dragging the other into it. The separate path also lets a team reuse an MCU it already knows and has already qualified, carrying its drivers and its certifications forward and adding only the radio as new work. It costs the extra chip, the board space, the interface to manage, and a little more standby current across two domains, so it is not free, but what it buys is the room to absorb a supply shock or a feature change on one side without redesigning the product. The way to decide is to weigh how long the product must stay in production, and how exposed its chosen radio is, against how much the integration saves, since a part that saves a dollar and a square centimeter today can cost a full redesign in three years if its lifecycle turns the wrong way at the wrong time. The math is not only the part price, since integration also folds in the cost of the second chip's layout and the firmware for the link between two domains, all of which the wireless MCU avoids; against that sits the redesign-and-recertify bill that a separate radio lets a team pay piecewise and on its own schedule rather than all at once when a vendor forces the move. Neither column is a single number, and the right answer differs for a throwaway gadget and a meter that has to run for fifteen years.

Integration still wins for the short-lived or the cost-driven product, where the years of exposure never arrive and the saving is real now. The separate path earns its keep on the long-lived design, the one that has to ship for a decade and cannot afford to be held hostage to a single wireless SoC's roadmap and the certifications welded to it.

When the radio stays separate

Then the host MCU becomes a decision of its own, chosen for the node rather than handed down by the radio.

The host MCUs for a separate radio

At the smallest end, a node that does little more than read a sensor and feed a radio wants the least MCU that does the job. The LPC812M101JDH20FP suits a small connected sensor node, a low pin count Cortex-M0+ part that is cheap and tiny and carries just enough flash and peripherals to sample a sensor, talk to a radio over SPI or I2C, and sleep, which is the whole of what a simple endpoint asks of its host. It is the answer when the application is light and the cost and the board area are the numbers under pressure, and it keeps the host from being the thing that makes a small node bigger than it needs to be. Its limits are real, since a heavier application or a second interface outgrows a part this small fast, but for an endpoint that only senses and reports it is exactly enough and no more.

The mainstream choice for a connected node is a low power part with room to grow into a real application. The STM32L431 is a low power connected MCU with a capable Cortex-M4 core, a useful spread of peripherals, and the low run and sleep currents a battery node needs, which makes it a comfortable host for a radio and a genuine workload without paying for the highest tier. It sits in the wide middle where the bulk of separate-radio designs land, backed by an ecosystem and a tool flow a lot of teams already work inside, which shortens the path from a familiar MCU to a connected one.

Where battery life is the whole game, the newer ultra low power parts push the standby figures down hard. The STM32U585 serves as an ultra low power edge node host, pairing a low sleep current with the compute for an edge workload and the security blocks a connected product now expects, which fits a node that has to do real work between long sleeps and still last years on a cell. It costs more than the mainstream part and returns it where the energy budget is tight and the application is not trivial, such as a sensor that runs a little signal processing before it decides whether to wake the radio at all. That headroom is what lets a node grow a little intelligence without leaving the low power tier, which is increasingly where edge designs want to sit as more of the decision moves onto the node itself.

A different tradition answers the same low power goal with memory that holds its contents without power. The MSP430FR2433 does ultra low power sensing with FRAM, using ferroelectric memory that writes fast and at low energy and retains with no backup, which suits a logging node that wakes, records a reading, and sleeps without spending the energy and time a flash write would cost. It has been a long-standing pick for metering and sensing where every microjoule per sample counts and the log must survive a power loss intact.

Between these sits the general purpose workhorse. The ATSAMD21G18 is a general purpose 32 bit node host, a Cortex-M0+ with a flexible set of configurable serial peripherals that pairs cleanly with almost any radio and carries a broad base of community support and example code, which makes it a safe default for a connected design that wants a capable 32 bit host without committing to one vendor's larger ecosystem. It is the part a design reaches for when it wants room and familiarity more than the lowest possible current, and it rarely surprises anyone late. Its serial peripherals can be mapped flexibly across pins, which eases a layout that has to route a sensor on one side and a radio on the other around a small board.

Watching the supply on a wireless SoC

The lifecycle risk that pushes a design toward a separate radio deserves its own attention, because a wireless SoC carries more of it than a plain MCU does. Radio parts turn over faster, tie to certifications that have to be redone when they change, and come from a market where a vendor can drop a line or a whole product family with about a year's notice, which lands hardest on a product built tightly around a single integrated part with nowhere else to put the design.

When a wireless SoC reaches end of life, the design built closely around it has nowhere easy to go. The pinout, the radio stack, the certifications, and the firmware were all sized to that one part, so a replacement is rarely a drop-in, and the work to move can rival the original design while arriving at the worst time, after the product is shipping and the team has moved on to the next thing. This is the failure mode the separate-radio path is built to avoid, and it is the reason a product meant to live for years weighs the integration saving against it so carefully rather than taking the cheaper board on sight. The cost is not only engineering hours, since a gap with no part to ship is lost revenue and a customer who moves to someone else, which is why a team burned once treats a sole-sourced radio as a risk to price in from the start rather than a detail to handle later.

The skill that softens this is reading the signs early, since spotting an end of life on a wireless SoC before it lands turns a forced redesign into a planned one. Lengthening lead times, a vendor steering new projects toward a successor part, a quiet move to not-recommended-for-new-design status, and distributor stock that thins without restocking all run ahead of a formal notice, and a team that watches them can design in a second source or bank enough inventory to bridge the gap before the part becomes unobtainable rather than after the line has already stopped.

The defense is the one good sourcing applies everywhere: keep a second source where the architecture allows it, prefer parts and modules that carry a stated longevity commitment, and keep the radio behind an interface that a different part could sit behind later. A wireless MCU can still be the right choice, and often is, but a long-lived design makes that choice with its eyes open to the day the part it leans on is no longer sold, and it leaves itself a path to take when that day comes. None of this argues against integration as such; it argues for making the call with the lifecycle in view, so the cheaper board today is not quietly buying a forced redesign a few years out.