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.