Every few weeks a founder or a CTO asks me some version of the same question: “Should we build this on RISC-V?” And every few weeks I give an answer that sounds evasive until I explain it: which RISC-V?
That is not me dodging. RISC-V is not one decision. It is three quite different markets sitting at three different maturity levels, and if you lump them together you will either dismiss something that is already in your product or bet a regulated launch on an ecosystem that is not ready to carry it.
So here is the way I actually walk teams through it. I have tried to keep the ideology out and the trade-offs in. Where I am giving you an opinion rather than a fact, I will say so.
Why “is RISC-V ready?” is the wrong question
When people say “RISC-V” they usually mean one of three things:
- A coprocessor buried inside a bigger chip that you never program directly.
- The main microcontroller your firmware team lives on for the life of the product.
- A certified or application-class core in a medical, automotive, industrial-safety, or Linux-based product.
Each of these has a different answer in 2026. Let me take them one at a time.
Market 1: Deeply embedded cores
Here is the part that surprises people. If you have shipped a wireless product in the last three or four years, there is a very good chance RISC-V is already in it.
The radio coprocessor in your Wi-Fi SoC. The power-management controller inside your application processor. The sensor hub. The little state machine that sequences the boot before your “real” CPU wakes up. Silicon vendors have been quietly swapping licensed Arm Cortex-M0/M3 cores and hand-rolled proprietary logic for in-house RISC-V cores in these roles for years now, and the reasoning is hard to argue with: no per-core licence, no royalty, freedom to add whatever custom instructions the block needs, and the customer never has to touch the toolchain.
Espressif put RISC-V in the main application core of the ESP32-C series back in 2020. Nordic’s nRF54H20 carries RISC-V “VPR” coprocessors alongside its Cortex-M33 cores, inside a part that is marketed, quite reasonably, as an Arm product. When you see market-share charts showing RISC-V “growing fast,” a large chunk of that growth is this segment.
My verdict: done. If your only exposure to RISC-V is “the vendor used one inside the chip,” there is no decision to make and no risk to manage. You will never see the ISA, and the vendor owns the toolchain problem, not you.
Market 2: RISC-V as your main MCU
This is the decision teams actually face: picking a RISC-V microcontroller as the primary application processor, where your engineers write the firmware, run the debugger, and live with the toolchain through mass production and years of field updates.
The 2026 picture here is materially better than it was two years ago. It is also still short of the Cortex-M baseline in ways that show up on real schedules. Both halves of that sentence matter.
What works now
The compiler question is settled. GCC and LLVM both treat RISC-V as a first-class upstream target, and code generation for ordinary control code is competitive with Arm. This stopped being a legitimate objection around 2024.
The RTOS question is settled. Zephyr and FreeRTOS both ship mature RISC-V ports. If your firmware sits on either, the ISA underneath is close to invisible to most of your application code.
Profiles are taming fragmentation. The ratification of the RVA23 and RVB23 profiles gave everyone a shared baseline to target. Walking the halls at Embedded World this year, the vendor pitch had clearly shifted from “we have a RISC-V part” to “we have a profile-compliant part with a support commitment.” That shift matters more than any single chip launch.
Functional-safety tooling is arriving. Qualified-compiler programmes (HighTec’s work with SiFive cores is the well-known example) signal that the automotive and industrial safety path is being built. Nobody funds a qualified toolchain for a market they expect to stay small.
What still costs you
The debugger experience is the gap engineers feel first. OpenOCD plus GDB works. probe-rs is improving quickly. Commercial tools do exist for RISC-V — IAR and SEGGER both support it, and J-Link probes have handled RISC-V for years. What you do not yet get is the thing you get on Arm: flash breakpoints, trace, and RTOS-aware debugging that behaves identically across every vendor’s silicon on day one. Coverage is uneven part to part, and you find out which parts are the awkward ones by trying.
On a recent evaluation we had two candidate RISC-V MCUs from different vendors. One debugged as smoothly as any Cortex-M we have used. The other cost us the better part of a week getting reliable breakpoints inside interrupt handlers. Same ISA, very different week.
Vendor extensions bring the fragmentation straight back. The ISA’s greatest strength; anyone can add custom instructions is its ecosystem’s biggest hidden tax. A part with vendor-specific DSP or AI extensions delivers its headline benchmark numbers only through that vendor’s toolchain fork. The moment your hot loop depends on those extensions, your “open ISA” portability story is over. You have recreated vendor lock-in with extra steps, and you should price the part as proprietary silicon that happens to use a RISC-V baseline.
The long tail is thinner. Middleware, protocol stacks, reference designs, forum answers, and this one bites hardest – engineers you can hire who have already shipped on the specific part. All of it exists. All of it is a fraction of the Cortex-M pool. Every problem your team hits has fewer prior solutions, and that compounds over a multi-year programme.
My verdict: winnable, with conditions
If you have a greenfield product, a team comfortable in open tooling, and a part that hits your cost or capability target on base-profile instructions alone, RISC-V is now a defensible mainstream choice, and the BOM saving at volume can be real.
If you have a brownfield port, a team whose debugging muscle memory is built on IAR or Keil, or a performance target that only the vendor extensions can reach, the hidden costs still exceed the visible savings in 2026. That is not a criticism of the ISA. It is a statement about where the segment is this year.
Market 3: Safety-critical and application-class
This is where the marketing runs furthest ahead of reality: RISC-V as the certified core in a medical device, the lockstep core in an automotive domain controller, or the application processor under your Linux product.
The building blocks are appearing. RVA23-compliant application silicon is shipping. Qualified compilers exist. The first safety-certified cores have been announced. All true.
But here is the thing I most want teams to internalise: certification is an ecosystem property, not a core property. A safety programme needs the certified core, plus the qualified compiler, plus the certified RTOS, plus a tooling evidence chain, plus – and this is the piece that takes a decade to build, assessors and notified bodies who have seen enough RISC-V evidence packs that yours is routine rather than a precedent.
Arm’s Cortex-M and Cortex-R lines have well over a decade of ISO 26262 and IEC 61508 history behind them. RISC-V has announcements and a handful of first deployments. For a regulated product starting today with a 2028 launch, choosing RISC-V for the safety core means volunteering to be early. Some well-resourced teams should volunteer, and we will happily help them. Most should not.
My verdict: watch, don’t bet – unless being early is the deliberate strategy and you have the budget and the schedule slack to fund it.
The four-question test we use at Better Devices
Strip away the ideology and silicon selection is the same discipline it has always been. When we run discovery on a new embedded programme, these are the four questions that decide the ISA conversation:
1. Will you ever need the vendor’s custom extensions to hit your performance target? If yes, price in single-vendor lock-in regardless of how open the ISA is.
2. Can your team live in an open toolchain for the product’s lifetime? If your debugging workflow is built on IAR or Keil, budget six to twelve months of friction and be honest about who absorbs it.
3. Is there a real second source for the part, or a profile-compatible equivalent at your performance point? The open ISA only delivers supply-chain leverage if a credible alternative actually exists. “In principle anyone could make one” is not a second source.
4. Does the part need certification, and is your launch inside three years? If yes to both, the Cortex ecosystem’s precedent is currently worth more than the licence saving.
Two or more answers pointing the wrong way means the sensible choice in 2026 is still Cortex-M. Not because RISC-V failed, but because the segment you are buying in has not matured yet.
How this plays out by scenario
| Your situation | Where I would lean in 2026 |
|---|---|
| Vendor uses RISC-V inside the SoC; you never touch it | Irrelevant to your decision — proceed |
| Greenfield IoT product, Zephyr/FreeRTOS, open tooling, base-profile part | RISC-V is a fair contender; evaluate on price and support |
| Brownfield port from an existing Cortex-M codebase | Cortex-M, unless the BOM delta is very large |
| Performance target needs vendor DSP/AI extensions | Treat as proprietary silicon; judge the vendor, not the ISA |
| Certified product launching before 2029 | Cortex-M/R, unless early adoption is a funded strategy |
| Linux-class application processor | Watch RVA23 silicon closely; pilot, don’t commit |
The trajectory only goes one way
I want to end on the honest long view, because it is easy to read the above as sceptical. It is not.
The deeply embedded segment is won. The mainstream MCU segment is being won, part by part and profile by profile. The safety segment will take the rest of the decade. Teams that re-run this assessment every twelve to eighteen months will catch the crossover for their segment. Teams that decided once, in either direction, will be wrong soon.
If you would like a second pair of eyes on a silicon decision against your actual workload, your actual team, and your actual certification path rather than industry sentiment – talk to one of our embedded architects. Silicon selection is a one-way door; the ISA, toolchain, and ecosystem you commit to at proof-of-concept is the one you live with through mass production. We would rather you walk through it with the trade-offs in front of you.
Frequently asked questions
Is RISC-V ready for production embedded systems in 2026?
It depends on which segment you mean. For deeply embedded roles – coprocessors and management cores inside larger SoCs, RISC-V is already dominant and invisible. For mainstream MCU applications, it is a defensible choice for greenfield products on teams comfortable with open tooling. For safety-critical and certified applications, the ecosystem precedent remains years behind Arm.
What are the biggest remaining gaps in the RISC-V embedded ecosystem?
Uneven debugger and trace support across vendors’ silicon, fragmentation through vendor-specific instruction extensions, and a thinner long tail of middleware, reference designs, and engineers with shipped-product experience compared with Cortex-M.
Do vendor extensions undermine RISC-V’s open-ISA advantage?
Largely, yes. Custom extensions deliver real performance, but they bind your firmware to one vendor’s toolchain fork and recreate the lock-in the open ISA was meant to remove. If your performance target requires them, evaluate the part as proprietary silicon that happens to use a RISC-V baseline.
Should a safety-critical product choose RISC-V today?
Only where being an early adopter is a deliberate, funded strategy. Certified cores and qualified compilers are appearing, but certification precedent, assessors and notified bodies who have already seen RISC-V evidence chains – takes years to accumulate. For most regulated products launching within three years, Arm’s precedent outweighs RISC-V’s licence savings.
Can I mix RISC-V and Arm in one product?
You probably already do, whether you chose to or not: many “Arm” SoCs carry RISC-V coprocessors. Deliberately mixing them at the board level is also common and works fine, provided each core’s toolchain and debug path is owned by someone on the team.
How often should teams re-evaluate the RISC-V decision?
Every twelve to eighteen months. The ecosystem is maturing quickly and segment by segment. A verdict reached in 2024 is already stale; a verdict reached today will be stale by 2028.