How a Firmware Abstraction Layer for Multi-Radio Products can De-risk your Roadmap
Perfectly good projects are going off the rails and missing their ship dates, because of worldwide chip shortages, as the worldโs FABs focus on pumping out AI chips.
As of mid-2026, 32-bit industrial MCUs and power management ICs are running lead times as long as 52 weeks, driven by AI infrastructure eating into the mature foundry capacity that IoT parts depend on. Automotive-grade MCUs are still sitting at 26 to 40 week lead times through Q2 2026. Thatโs down from the 52+ week peaks of the prior shortage cycle, but still long enough to force a mid-program part change on most connected products.
That number is the actual argument for a Firmware Abstraction Layer (FAL). Not portability as a design virtue. A parts shortage that arrives mid-program and forces a chip swap on a schedule you donโt control.
When that swap happens, the cost depends entirely on how the firmware was written. If power management calls, event loop timers, and socket buffers are wired straight into the original vendorโs SDK, a driver swap turns into a rewrite. Thatโs especially true when application code up the stack had no business knowing which chip was underneath it. If none of that is wired in, itโs just a new driver behind an interface that hasnโt changed.
The Industry is Moving, But Not Fast Enough To Save You
Silicon vendors know this pain point exists, and 2026 has brought real movement. Silicon Labs launched Simplicity SDK for Zephyr at CES 2026, a QA-tested Zephyr distribution built for its wireless chips. The SDK is MCU-agnostic and lets developers mix MCU vendors inside one project, which is a genuine step toward portability rather than a new flavor of lock-in.
Nordic moved in a similar direction with the nRF93M1, announced at MWC 2026, which ships with built-in coexistence control for Wi-Fi and cellular radios sharing one module.
Both of these solve coexistence within a single vendorโs silicon. Coexistence across vendors is a different problem, and itโs still an open problem at the RTOS layer. Zephyrโs Bluetooth stack currently binds to a single controller, so a product canโt natively run Bluetooth radios from two different vendors at once. A proposal to fix that has been open since July 2025, still not shipped.
So vendors are getting better at owning coexistence on their own chips. Managing radios across vendors is still on the OEM to solve, and thatโs exactly what a FAL is for.
Step 1. Identify Every Radio and Every Place They Can Collide
List every radio in the product, whether thatโs BLE, Wi-Fi, cellular, or UWB. For each one, write down the vendor, the SDK version, and the frequency band it operates in.
Then map where they can interfere with each other. A Wi-Fi transmission can wipe out an incoming BLE advertising packet on the same band. A cellular modem waking up for a paging window can starve a UWB ranging session of power budget. These collisions come from physics, not software architecture, and a single vendorโs SDK has no idea another radio even exists on the board.
This inventory is the spec for everything that follows. Skip it and youโll end up designing an abstraction layer for radios that donโt actually fight each other, while missing the pair that does.
Step 2. Design the Power State Machine Before Writing Driver Code
Vendor SDKs manage power per radio. BLE connection intervals, cellular eDRX timers, and Wi-Fi power-save modes each get handled separately, by their own SDK, with no visibility into what the other radios are doing at the same moment.
Replace that with one system-level state machine that every radio driver reports into. Two states cover most products, System_Sleep() and System_Active(). Before switching states, the FAL checks every active radio and picks the lowest power level that all of them can safely handle.
Work out the timing rules on paper first. Decide which radioโs constraints are allowed to hold up a sleep transition and which arenโt. If you get this wrong, youโll spend the second half of the project chasing power bugs that only show up once two radios are active together.
Step 3. Build One Error Taxonomy Across Every Vendor Stack
A cellular modem times out silently over several seconds. A BLE driver drops the connection instantly with a stack-specific status code that means nothing outside that SDK. If you leave this alone, the application layer will fill up with chip-specific if/else branches for every vendor youโve ever integrated.
Translate every vendor error into a small set of system-level states instead, things like LINK_TEMPORARY_LOSS or HARDWARE_UNRESPONSIVE. The application layer reacts to these states and never has to know what a specific vendorโs error code means.
This step tends to have the biggest payoff for the smallest amount of code, which is also why teams skip it first under deadline pressure. It doesnโt block a demo. It blocks the fifth product revision, when nobody on the team remembers which vendorโs error code meant what.
Step 4. Put One Component in Charge of Arbitration
Antenna sharing, board-level power rails, shared bus access. When two radios need the same physical resource at the same moment, something has to decide who goes first, and that decision canโt be left to whichever driver happened to initialize last.
Build a single arbitration component that owns every shared resource on the board, and routes every radio driverโs requests through it. Donโt let a driver talk to a shared antenna switch or a shared power rail directly, even when the vendor SDK makes that shortcut tempting.
Most of your real RF debugging time during bring-up ends up here anyway. A clean arbitration boundary keeps those bugs in one file instead of scattered across three different vendor codebases.
Step 5. Wall Off OTA Updates and Certification Scope
Radio firmware updates need their own execution pipe, separate from application code. A failed radio firmware update shouldnโt be able to take down the rest of the product. And when only a wireless component changes, keeping the update isolated means regulatory recertification stays scoped to the radio abstraction module instead of pulling your whole application layer back into scope.
The cost difference here is real. A pre-certified wireless module cuts FCC certification cost by 60 to 80 percent and roughly halves the timeline compared with a custom RF design. Keep the split clean and a wireless-only change stays a wireless-only filing. Mix it with application code, and the whole product can get pulled back into certification scope.
If your OTA pipeline currently pushes application code and radio firmware through the same mechanism, split them now, while itโs a small job, rather than during a hardware revision, when it isnโt a small job anymore.
Where This is Playing Out Right Now
Thereโs a live example of this on the Zephyr project. A team building on an NXP 88W8987 Wi-Fi combo module wants to add Bluetooth, and the open issue confirms thereโs no upstream Bluetooth HCI driver for that chip, even though the Wi-Fi side already works.
The thread lays out three options. Add a second Bluetooth chip from a different vendor. Work from an unofficial vendor driver outside the mainline Zephyr tree. Or redesign the hardware around a different combo chip entirely, which the thread notes isnโt always possible once BOM, supply chain, and certification decisions are already locked in.
Every one of those options costs something, and the reason the team is stuck choosing between them is that nobody drew the FAL boundary early enough. A team that already has a power state machine, an error taxonomy, and an arbitration layer in place can absorb a second radio vendor as a driver-level change. A team without one ends up making this decision in a GitHub comment thread, mid-project, instead of in a design review months earlier. Our previous post goes more into this โ Architecting Multi-Radio Embedded Devices with BLE, Wi-Fi, LTE, and UWB.
Decide Ownership Subsystem by Subsystem
You donโt need to own every layer for every product. What matters is deciding, for each of the four systems above, whether you build it yourself or lean on the vendor SDK.
If youโre shipping on a single vendorโs chip for a short product life, with no planned cost-down or radio swap, take the vendorโs SDK as it comes, coexistence tools included. The speed advantage is real, and thereโs no multi-vendor problem to solve.
If youโre running radios from more than one silicon supplier, this applies to you. It also applies if youโre building a product line meant to last three to seven years through component shortages and cost-downs. Build the power state machine, error taxonomy, arbitration layer, and OTA isolation yourself. Leave everything else on the vendor SDK.
Most teams donโt need to build a FAL from scratch. They need these boundaries drawn correctly before the second radio vendor shows up as a surprise instead of a plan.
Final Word
Multi-radio products get harder to maintain when the boundaries between vendor firmware and system firmware are unclear. Defining those boundaries early gives your team more options when hardware, suppliers, or product requirements change.
embedUR brings 20 years of experience building wireless stacks, controller firmware, and cross-vendor abstractions for connected products. If youโre planning a multi-radio product or preparing for a hardware refresh, our engineering team can help you define the right firmware boundaries.
Schedule a Firmware Architecture Review with our experts and protect your product roadmap against silicon delays, unexpected chip swaps, and costly recertification cycles.