RISC-V or ARM Cortex: the differences that actually matter on a project
The RISC-V versus ARM debate usually collapses into licensing fees, which is the least interesting angle for a team that has to ship a product. The differences that really cost or save money lie elsewhere: in the modularity of the instruction set, in what conformance actually guarantees, and in toolchain maturity.
What "RISC-V" actually names
ARM Cortex-M4 names a specific core, whose behaviour is specified by ARM and identical across every vendor that integrates it. RISC-V does not name a core: it is an instruction set specification, and anyone may build an implementation of it.
A RISC-V core is described by a string of extensions. RV32IMAC means: 32-bit, base integer set, multiply and divide, atomics, compressed instructions. Add F and D for single and double precision floating point, V for vector, B for bit manipulation.
The consequence is direct and often discovered late: two RISC-V microcontrollers may not run the same binary. Code compiled for RV32IMAFC will not run on an RV32IMC core, which has no FPU. On ARM, forward compatibility within a profile is far more constraining for the vendor, therefore far more comfortable for you.
Standardised profiles such as RVA23 exist precisely to reduce that fragmentation, but they are recent and mostly aimed at application-class compute.
Interrupt handling, a concrete example
Take interrupt handling, which every embedded project touches.
On Cortex-M, the NVIC is standardised and part of the core. The vector table, priorities, automatic register stacking, interrupt return: all identical from one vendor to the next. An interrupt handler written as an ordinary C function works, because the core stacks the context itself.
On RISC-V, the base mechanism defines only a single vector and a few control registers. The interrupt controller, PLIC or CLIC, is external to the core and varies by implementation. Context stacking is your responsibility, or the compiler's through a specific attribute.
This is neither better nor worse, it is more open and less uniform. In practice it means low-level code is less portable between two RISC-V silicon parts than between two Cortex-M parts.
Toolchain maturity, the real gap
| Item | ARM Cortex-M | RISC-V |
|---|---|---|
| Compiler | GCC and LLVM mature for 15 years | GCC and LLVM solid, newer extensions less proven |
| Debugger | CMSIS-DAP, universal probes | OpenOCD, vendor-dependent support |
| Tracing | ITM, ETM standardised | depends on the implementation |
| RTOS | all of them, with proven ports | Zephyr and FreeRTOS well ported, others uneven |
| Optimised libraries | CMSIS-DSP, CMSIS-NN | younger equivalents |
| Certified static analysis | broad offering | limited offering |
The most expensive day-to-day gap is not the compiler, it is tracing and debugging. On a Cortex-M, a standard probe plus ETM gives you a non-intrusive execution trace. On many RISC-V parts you work with whatever the vendor implemented.
Where RISC-V has a decisive advantage
Extending the instruction set. You can add your own instructions for a specific computation, and the specification reserves encoding space for exactly that. On a proprietary cryptographic algorithm or signal processing filter, a five to twenty times speedup is achievable. That is impossible on ARM.
No single-vendor dependency. For a long-lived product, or a market with sovereignty constraints, being able to change implementation without rewriting application software has real strategic value.
Cost at very high volume, where per-unit royalties become significant. Below a few hundred thousand units that argument weighs nothing against engineering cost.
Where ARM keeps the advantage
The component ecosystem. The number of available ARM microcontrollers, with their peripherals, libraries and documentation, is in a different league.
Built-in security. TrustZone-M, with its hardware memory attribution and standardised transition model, has no equally widespread RISC-V equivalent yet. RISC-V security extensions exist but adoption is uneven.
Hiring. Finding an engineer who knows Cortex-M is easy. The RISC-V pool is narrower, which costs ramp-up time.
Certification. For a product under a functional safety standard, having a core and toolchain already qualified changes the cost of the file dramatically.
How to decide
Choose ARM Cortex if the product must ship soon, if the team is already trained, if you need TrustZone or a safety certification, or if volume does not justify an architecture investment.
Choose RISC-V if you have a specific computation that would benefit from dedicated instructions, if independence from a vendor is a real constraint, if volume is very high, or if you are integrating the core into your own silicon.
And in both cases, ask the question that actually decides: which toolchain and which support will you have in seven years. For a product under an obligation to ship security patches for at least five years, that criterion outweighs the rest.
References
- RISC-V International, Specifications, base set and extensions
- RISC-V International, RVA23 profile, reducing fragmentation
- RISC-V, Platform-Level Interrupt Controller, and CLIC
- Arm, Cortex-M NVIC, integrated interrupt model
Going further
These differences become tangible once you have written an interrupt handler on both architectures and compared what the core does for you. That is what our RISC-V architecture course and our ARM Cortex architecture courses cover.