I concur, and add my 2 cents on why "Use FreeRTOS and ship the product" actually works in the real world (i.e. paid job), from the perspective of a part-time fi

I concur, and add my 2 cents on why "Use FreeRTOS and ship the product" actually works in the real world (i.e. paid job), from the perspective of a part-time firmware engineer. Obviously none of this applies if you are just having fun building your side project. 1. Unless your product is mass-produced, as long as your $work has >= 2 projects, having them share a over-spec'd MCU family (i.e. way more pins, MHz, SRAM, ... than you could imagine yourself needing), or even a single part, is very desirable. The BOM is much simpler, and given the current chip shortage situation, you don't have to track incompatible chip families. All the infra work, internal codebases, know-how, even quirks and their workarounds can be shared in-house. 2. The vendor most likely has some BSP (board support package) written in C with examples in C as well, and it most likely will support / assume / integrate with FreeRTOS. Neither of these will be optimized to the bones --- usually the situation is quite on the contrary, with O(n) loops liberally littered around. However, since you picked a overkill MCU, it will more likely than not gladly chug along, given you don't abuse them. When you FFI / shim / start from scratch with registers, usually the happy path does work after some hacking, but when it doesn't work, do you have confidence it's a HW issue, or is it rather your added indirection? With Embedded Rust's prevalent macro-heavy approach, this can be a real time sink. 3. Firmware engineering really works closer to hardware than you'd think. To avoid a catch-22 situation in the co-design, already knowing a lot about what embedded platform breaks the loop and effectively decouples HW and SW, reducing your time-to-market.