Imho Rust will be not much further in embedded world in 2026 than it was in 2016. I managed to get in the role where I have hiring decisions to make. From this perspective I need somebody to be able to work with existing projects in C from the 2006 instead of knowing cool new language. There is no single advantage for a company selling products to change the language used. Transition will only cost money.
Regarding C prototype. I wrote it. 6000 lines of code, works nicely, 4200 lines of code were Xilinx driver calls to move data between the hardware blocks. So changing the language will not really bring any benefit. Maybe even opposite - one must study the register calls and read data sheets to create equivalent functions in other language. The code wasn’t beautiful, was created as “prototype” and was at the end the version shipped to a client.
The embedded rust ecosystem has invanced a pretty insane degree since then. I have an ongoing embedded project and I have had to use C FFI calls a total of zero times in a ~100kloc codebase. There are native rust HAL libraries autogenerated from manufacturer published device specs that are insanely good, and take advantage of rust type system features to offer vastly superior APIs compared to mfgr provided C libs
Regarding C prototype. I wrote it. 6000 lines of code, works nicely, 4200 lines of code were Xilinx driver calls to move data between the hardware blocks. So changing the language will not really bring any benefit. Maybe even opposite - one must study the register calls and read data sheets to create equivalent functions in other language. The code wasn’t beautiful, was created as “prototype” and was at the end the version shipped to a client.