RISC-V vs ARM in embedded — what are the key differences?
The most fundamental difference is the business model. ARM is a proprietary ISA — chip vendors pay licensing fees and royalties to ARM Holdings for the right to implement Cortex-M cores. RISC-V is an open-standard ISA maintained by RISC-V International — anyone can implement it without fees. This has led to a wave of RISC-V microcontrollers (ESP32-C3/C6, GD32VF103, BL602/BL616, Kendryte K210) from vendors seeking to avoid ARM licensing costs or gain design flexibility. For engineers, this means RISC-V parts are often cheaper at the same performance tier, and startups or academic projects can design custom RISC-V cores without legal barriers.
From a technical architecture standpoint, several differences matter for embedded firmware. RISC-V uses the PLIC (Platform-Level Interrupt Controller) instead of ARM's NVIC — the PLIC supports priority-based preemption but has a different programming model (claim/complete semantics vs. automatic hardware stacking). RISC-V has no equivalent to ARM's automatic context save on exception entry — the firmware or compiler must save/restore registers in ISR prologues/epilogues, which adds a few cycles of interrupt latency compared to Cortex-M's hardware stacking. RISC-V's modular ISA extensions (M for multiply, A for atomics, F/D for float, C for compressed instructions, V for vector) mean that two "RISC-V" chips may have very different instruction sets, whereas "Cortex-M4F" guarantees a specific feature set everywhere.
The ecosystem maturity gap is the most practical difference today. ARM Cortex-M has 15+ years of tooling: mature compilers (GCC, Clang, IAR, Keil), debuggers (J-Link, ST-Link, OpenOCD), RTOS ports (FreeRTOS, Zephyr, ThreadX), and middleware (lwIP, mbedTLS, USB stacks) that have been battle-tested in billions of deployed devices. RISC-V tooling is catching up rapidly — GCC and LLVM support is solid, OpenOCD works with RISC-V debug (via the RISC-V Debug Spec), and FreeRTOS/Zephyr have official RISC-V ports — but vendor-specific HALs, peripheral libraries, and IDE integrations are less mature. For a production project today, ARM is the safer choice for time-to-market; for a new product with a 2-3 year development horizon, RISC-V is increasingly viable and avoids vendor lock-in to ARM's licensing terms.
Source: MCU Cores & Clocking Q&A
