RISC-V Microcontrollers: An Open Architecture for Embedded Systems

RISC-V has moved from an academic curiosity to a practical option on my bench in less than five years. When I first brought up a CH32V003 on a breadboard, I expected a rough toolchain and missing documentation. What I found instead was a surprisingly mature GCC port, a familiar peripheral set, and an architecture that forces you to think differently about how an MCU is built. Unlike the closed ARM Cortex-M ecosystem where you license a fixed core, RISC-V gives silicon vendors a modular ISA they can tailor, and gives firmware engineers direct access to the control and status registers that define how the core behaves. For embedded systems where cost, supply chain resilience, and long-term maintainability matter, that openness is not just philosophical — it changes how you select parts, write drivers, and port an RTOS.

Why RISC-V Modularity Makes Sense for Microcontroller Silicon

In my experience, the biggest misunderstanding about RISC-V is that it is a single processor. It is not. It is a base integer instruction set plus optional extensions that a vendor can include or omit. The RV32I base gives you 32-bit integer operations with 32 registers. Everything else is an add-on: M for hardware multiply/divide, A for atomics, C for 16-bit compressed instructions that cut code size by 25-30%, and F/D for floating point. When you see RV32IMAC on a datasheet, it means the core implements Integer, Multiply, Atomics, and Compressed.

This modularity explains why two RISC-V microcontrollers can feel so different even at the same clock speed. A low-cost 48 MHz CH32V003 implements RV32EC — a reduced register set (16 registers) with compressed instructions to save area. An ESP32-C3 implements RV32IMC with a full 32 registers and is built for wireless workloads. In contrast to ARM where you choose between a Cortex-M0+, M4, or M33 with fixed feature sets, RISC-V lets WCH, GigaDevice, Bouffalo Lab, and Espressif each tune the core for a cost or power target. You have to read the specific core manual, not just the "RISC-V" label.

For IoT products, this has a direct supply chain benefit. I worked on a sensor node where the original ARM-based MCU went end-of-life during a 2023 shortage. Re-qualifying on another ARM vendor meant re-licensing, different errata, and new toolchain quirks. With RISC-V, we were able to evaluate three pin-compatible alternatives that shared the same GCC toolchain and CMSIS-like abstraction, because the ISA itself is royalty-free. If you are weighing this openness against the maturity of established ecosystems, my Microcontroller Selection: ARM Cortex-M, RISC-V and AVR Decision Criteria breakdown covers how I score current consumption, toolchain support, and vendor longevity side-by-side.

The Privilege Model You Will Actually Use

Most RISC-V microcontrollers implement only Machine mode (M-mode). Unlike application processors that have User and Supervisor modes for Linux, MCUs run everything in M-mode. That simplifies things: you have full access to CSRs and no virtual memory. The trade-off is that you are responsible for all trap handling. There is no SVC exception like on Cortex-M; instead you configure the mtvec register to point to your trap handler and decode mcause yourself. It sounds low-level because it is, but it gives you deterministic control over faults, which I prefer for hard real-time control loops.

Anatomy of RV32IMAC: Extensions That Change Your Firmware Footprint

When I select a RISC-V MCU, I look at extensions first, clock speed second. The extension set determines compiler flags, library choices, and whether you need software emulation.

The M extension is non-negotiable if you do any signal processing or PID control. Without it, a 32x32 multiply becomes a library call that takes dozens of cycles. I learned this the hard way on an early RV32I prototype where a simple sensor filter loop missed its 1 kHz deadline because the compiler emitted __mulsi3 calls. Adding -march=rv32imc immediately cut that loop from 84 cycles to 9.

The C extension is equally important for embedded flash budgets. Compressed instructions are 16-bit encodings for common operations. On a 16 KB flash part like the CH32V003, enabling C saved us nearly 4 KB, which was enough to fit a bootloader and an I2C stack without compression tricks. Always compile with -march matching your hardware — for example, rv32ec for CH32V003 or rv32imac for GD32VF103 — otherwise the linker will either generate illegal instructions or miss size optimizations.

The A extension (atomics) matters if you plan to run an RTOS. FreeRTOS and Zephyr use atomic read-modify-write operations for queue and semaphore handling on multi-core or interrupt-heavy systems. Even on a single-core MCU, LR/SC and AMOSWAP give you lock-free primitives without disabling interrupts globally. If your chosen MCU omits A, the RTOS port will fall back to critical sections, increasing interrupt latency.

# Example: Compiler flags for different RISC-V MCUs
# WCH CH32V003 (RV32EC)
CFLAGS_CH32V = -march=rv32ec -mabi=ilp32e -Os -msmall-data-limit=8

# GigaDevice GD32VF103 (RV32IMAC)
CFLAGS_GD32V = -march=rv32imac -mabi=ilp32 -O2

# Espressif ESP32-C3 (RV32IMC)
CFLAGS_ESP32C3 = -march=rv32imc -mabi=ilp32 -O2 -msave-restore

# Check which extensions your toolchain supports
riscv32-unknown-elf-gcc --target-help | grep -E "march|mabi"

Reading the Datasheet Correctly

Vendors love to market "RISC-V 32-bit" without listing extensions. Always check the "CPU Core" chapter for the exact march string and the "CSR Map" for implemented registers. I have found that low-cost parts often omit the floating-point CSRs (fcsr) and the performance counters (mcycle/minstret) are read-only. If you rely on hardware floating point, verify that the F extension is present and that -mabi=ilp32f is supported; otherwise the compiler will use soft-float and you will see unexpected stack usage.

Toolchains, SDKs and the Debug Experience I Actually Use

The RISC-V GCC toolchain is now the reference I recommend for production. You have two main ABI choices: ilp32 for soft-float and ilp32f/ilp32d for hardware float. The toolchain is upstreamed, so riscv32-unknown-elf-gcc from xPack or the vendor's package builds reliably on Linux, macOS, and Windows. Clang/LLVM also supports RISC-V well, and I use it for static analysis with clang-tidy, but GCC still has better support for link-time optimization and compressed instructions on the smallest parts.

Vendor SDKs vary widely in quality. WCH's EVT SDK is minimal — essentially headers, startup assembly, and a few peripheral drivers. GigaDevice's GD32VF103 SDK is more complete and mirrors STM32's SPL style, which made porting from STM32 HAL Drivers: GPIO, UART, SPI and DMA Configuration straightforward because the GPIO and USART register layouts are intentionally similar. Espressif's ESP-IDF for the ESP32-C3 is the most polished: it abstracts the RISC-V core entirely, so you write FreeRTOS tasks the same way you would on the Xtensa-based ESP32. That consistency is why I often point readers to ESP32 for IoT: WiFi, Bluetooth and Deep Sleep for Battery-Powered Projects when they want to see a mature wireless stack on top of a RISC-V core.

For debugging, OpenOCD with a WCH-LinkE, GD-Link, or ESP-Prog works well. The RISC-V debug spec uses abstract commands over JTAG, so single-stepping and register view feel identical to ARM once configured. In my experience, the common pitfall is forgetting to set the correct adapter speed. A 48 MHz CH32V003 will fail to connect at 6 MHz JTAG if the target is sleeping; drop to 1 kHz until you disable low-power modes in firmware.

// Minimal startup: setting mtvec and enabling global interrupts on RV32
// File: startup_ch32v00x.S

.section .init, "ax", @progbits
.global _start
_start:
    la sp, _eusrstack          // set stack pointer
    la t0, trap_handler
    csrw mtvec, t0              // set trap vector base
    csrsi mstatus, 0x8           // set MIE (Machine Interrupt Enable)
    jal SystemInit
    jal main
    j .

// Simple trap handler - decode mcause
.global trap_handler
trap_handler:
    csrr t0, mcause
    blt t0, x0, handle_interrupt // MSB set = interrupt
    j handle_exception
handle_interrupt:
    // save context, call handler, restore
    mret
handle_exception:
    j . // halt on fault for debug

One practical tip: always provide a default trap handler that blinks an LED or dumps mcause/mepc over UART. On Cortex-M you get a hard fault handler with stacked registers; on RISC-V you have to save them yourself. Without that, a misaligned load will appear as a silent reboot.

Interrupts, CSRs and How They Differ From Cortex-M NVIC

If you come from ARM, the interrupt model is the steepest learning curve. There is no NVIC with 8 priority bits and automatic stacking. RISC-V uses CSRs — Control and Status Registers — and a Platform-Level Interrupt Controller (PLIC) plus a Core-Local Interruptor (CLINT).

The CLINT handles software and timer interrupts (MSIP/MTIP). The PLIC multiplexes external peripheral interrupts (GPIO, UART, SPI) to the core. Each external interrupt has a priority and an enable bit in the PLIC, and the core claims the interrupt by reading plic_claim and completes it by writing plic_complete. This is more manual than NVIC's vector table, but it gives you full control over nesting and preemption.

CSRs are accessed with csrr/csrrw/csrw instructions. The key ones for MCUs are mstatus (global interrupt enable), mie/mip (interrupt enable/pending), mtvec (trap vector), mepc (exception PC), and mcause (trap reason). I keep a cheat sheet in every project because the names are cryptic at first. For detailed CSR behavior, the Zephyr Project Documentation (https://docs.zephyrproject.org/) has excellent context-switch code that shows exactly which CSRs are saved on a thread switch.

#include <stdint.h>

// Example: direct CSR access for critical sections on RV32
static inline void global_irq_disable(void) {
    __asm__ volatile ("csrci mstatus, 8" ::: "memory"); // clear MIE
}

static inline void global_irq_enable(void) {
    __asm__ volatile ("csrsi mstatus, 8" ::: "memory"); // set MIE
}

static inline uint32_t read_mcause(void) {
    uint32_t val;
    __asm__ volatile ("csrr %0, mcause" : "=r"(val));
    return val;
}

// Configure PLIC priority for UART0 (IRQ 12) and enable it
#define PLIC_BASE       0x0C000000UL
#define PLIC_PRIO(irq)  (*(volatile uint32_t*)(PLIC_BASE + 4*(irq)))
#define PLIC_ENABLE     (*(volatile uint32_t*)(PLIC_BASE + 0x2000))
#define PLIC_THRESHOLD  (*(volatile uint32_t*)(PLIC_BASE + 0x200000))

void plic_uart_enable(void) {
    PLIC_PRIO(12) = 1;          // lowest non-zero priority
    PLIC_ENABLE |= (1UL << 12); // enable IRQ 12
    PLIC_THRESHOLD = 0;          // allow all priorities > 0
}

Latency and Determinism in Practice

I've measured interrupt latency on a 108 MHz GD32VF103 at around 12-16 cycles from assertion to the first instruction of the handler when using vectored mtvec mode. That is comparable to Cortex-M4, but you only get that if you use the vectored table (mtvec MODE=1) and keep handlers short. If you use direct mode (MODE=0) where all traps go to one address and you branch in software, add another 10-15 cycles. For time-critical PWM or encoder inputs, I always use vectored mode and place the handler in RAM with the VTOR remap disabled to avoid flash wait states.

Memory Maps, Protection and Low-Power Modes on Production RISC-V MCUs

Memory protection on RISC-V MCUs is handled by the Physical Memory Protection (PMP) unit, not the MPU you know from ARM. PMP has 8-16 entries that define address ranges with R/W/X permissions for M-mode. This is simpler than ARM's MPU but also coarser. I've used PMP to isolate a bootloader at 0x08000000 from application flash and to make a portion of SRAM execute-never, which catches stack overflow exploits during fuzz testing. Unlike Cortex-M where MPU regions can be overlapping with priority, PMP entries have fixed priority by index, so ordering matters.

Low-power modes are vendor-specific and this is where RISC-V openness shows its limits. The core defines wfi (wait for interrupt) but the definition of sleep, deep-sleep, and standby is entirely in the vendor's power controller. On the ESP32-C3, deep sleep with RTC retention draws ~5 µA and wakes via RTC GPIO, very similar to the ESP32 workflow described in mobile battery projects. On the CH32V003, stop mode draws ~20 µA and only certain pins can wake the core. You cannot port sleep code blindly between vendors; you have to rewrite the PWR and RCC logic.

Peripherals are also vendor-defined. Most RISC-V MCUs copy STM32-like register maps for market familiarity: GPIO with CRL/CRH, UART with SR/DR, SPI with CR1/CR2. That helps if you have STM32 experience, but do not assume register compatibility. I once wasted a day because the GD32VF103's USART BRR calculation differs slightly from STM32F103 due to a different APB prescaler interaction. Always use the vendor header, not an STM32 header.

Running FreeRTOS and Zephyr on Low-Cost RISC-V Boards

Both major embedded RTOS options support RISC-V well now. FreeRTOS has an official RISC-V port (see FreeRTOS Documentation at https://www.freertos.org/Documentation/) that handles the M-mode context switch, tick timer via CLINT mtime, and interrupt nesting. Zephyr has even broader support and abstracts the PLIC/CLINT behind its driver model, so your application code is portable across CH32, GD32, and ESP32-C3.

In my experience, Zephyr is the faster path if you need BLE, Wi-Fi, or MQTT out of the box, because its devicetree and Kconfig let you enable a pre-tested IP stack. FreeRTOS is leaner if you want full control and minimal flash. On a 16 KB CH32V003, FreeRTOS with one task and a queue fits in ~6 KB after optimization, while Zephyr's minimal kernel needs ~18 KB and will not fit — so you have to choose based on flash budget.

The key porting task is the tick. RISC-V does not have a SysTick like Cortex-M. Instead you use the CLINT mtime and mtimecmp registers. The tick ISR compares mtime to mtimecmp, wakes the scheduler, and increments mtimecmp by the tick period. If your vendor's SDK does not provide this, you will write it yourself. Both FreeRTOS and Zephyr examples show this in 30-40 lines; copy them rather than inventing your own.

For MQTT and cloud connectivity, the ISA is irrelevant — the TCP/IP stack and TLS library dominate flash and RAM. I have run MQTT over Wi-Fi on the ESP32-C3 with mbedTLS using the same application code I use on an ARM-based gateway. The MQTT Specification (https://mqtt.org/mqtt-specification/) behaviors are identical; what changes is how you provision certificates in the RISC-V flash map and how you handle OTA. Espressif's IDF handles OTA partitions transparently, while on GD32 you will implement your own bootloader with PMP-protected dual-bank updates.

Practical Bring-Up Checklist I Follow

Before I commit a RISC-V MCU to a production design, I run through this sequence: 1) Build a blinky with bare-metal CSR access to prove toolchain and debug probe work. 2) Add a UART trap logger that prints mcause/mepc on any fault. 3) Port FreeRTOS or Zephyr tick and run two tasks that ping-pong a queue for 24 hours to catch interrupt enable bugs. 4) Measure wfi current with a precision shunt and verify wake sources. I've found that skipping step 2 is the most common mistake — without mcause logging, a misaligned access during development looks like a random reset and you will chase it for days.

Frequently Asked Questions