The forum was quiet this week, so as promised we published an honest RISC-V vs ARM comparison for product planners - covering where ARM still wins, where RISC-V wins on cost and freedom, a realistic hybrid K1-gateway + WCH-MCU architecture, and a practical 2026 decision framework.
Welcome to the Week 41 edition of the Open RISC-V Weekly Tech Digest. The community forum stayed quiet again this week, so as promised in last week's preview, we are publishing an honest, engineering-first comparison of RISC-V and ARM for product planners deciding what to build on in 2026. No ideology, no vendor talking points - just the trade-offs that actually show up in a bill of materials, a build farm, and a shipment.
For most new embedded products in 2026, the decision is no longer "RISC-V or ARM" as a single choice. It is a per-subsystem decision: pick ARM where mature software ecosystems save months, pick RISC-V where cost, control, and roadmap independence win. The interesting work is knowing which of the two applies to each block of your product.
Here is how the trade-offs break down across the dimensions that matter.| Dimension | ARM (Cortex-M/A) | RISC-V (2026) |
|---|---|---|
| Entry cost | Royalties per unit + license fees | Zero royalties, ISA is open |
| Ecosystem maturity | Decades of HALs, RTOS ports, middleware | Good and improving; gaps remain in niche stacks |
| Compiler/toolchain | Arm GCC/Clang, extremely battle-tested | RISC-V GCC/Clang production-quality |
| Supply chain | Multi-vendor but licensed IP | Multi-vendor with true architectural freedom |
| Customization | Fixed ISA unless you license and modify | Extensions (custom instructions) are first-class |
| Long-term availability | Vendor-dependent EOL policies | ISA is permanent; multiple vendors can re-spin parts |
Be honest about the strengths. If your product needs an Android-grade application processor, a certified safety island (ASIL-D), or a deep DSP stack with vendor-optimized libraries, ARM remains the lower-risk path. The software inertia is real: a team that already ships Cortex-M4 firmware with FreeRTOS, a USB stack, and a BLE middleware stack will be productive on a new ARM part in days.
The lesson is not "avoid ARM." The lesson is: do not pay ARM premiums for blocks where RISC-V is now simply good enough.The pattern we see working across the community: a RISC-V Linux gateway plus WCH bare-metal MCUs, each doing what it is best at. Here is the classic split, with the MCU side in bare C:
// CH32V208: BLE provisioning + health reporting to the K1 gateway #include "ch32v20x.h" #include "debug.h" int main(void) { SystemInit(); Delay_Init(); // 1. BLE 5.3 advertises; phone app provisions WiFi credentials // 2. MCU sends sensor/health telemetry over UART to K1 // 3. K1 (OpenWrt 23.05) aggregates, applies nftables policies, // and forwards to the cloud while(1) { Ble_Task(); Telemetry_Report(); Delay_Ms(1000); } }And on the Linux side, the K1 gateway is just standard OpenWrt - the ISA underneath is invisible to your application layer:
# On SpacemiT K1, stock OpenWrt 23.05 workflow opkg update opkg install kmod-nftables tcpdump nft add table inet filter # Everything you know about OpenWrt applies unchangedThat is the quiet win of RISC-V Linux parts: the software stack is the same one ARM gateways run, so migration cost is mostly hardware bring-up, not retraining.
A comparison is only honest with the risks on the table:
A practical checklist we recommend:
Got a topic you want covered? Post it on the Open RISC-V forum - the best threads become the next digest.