I’m working on (and have made some progress toward) adding CMSIS v1 as an OS target for libstd. Now that WASM32 has landed, I’m pretty encouraged about the possibility of using it (alongside Redux, as I’ve been doing) as a template. I’d like to get some feedback about whether I should pursue this with the intention of gaining adoption (maintaining it out-of-tree has proven annoying if not difficult), as well as how best to overcome some obstacles I’ve identified.
The first problem I’ve identified is that of actually linking OS support in. There are a few different kernels (RTX, FreeRTOS, Chibi/OS, and more) that have, at some point, supported a CMSIS RTOS-compliant mode, and using bindgen has proven successful at letting me use an RTOS in a no_std mode. The issue is that I don’t know how to add, e.g. my Chibi/OS bindings, to libstd’s Cargo dependencies. I suppose this question is generalizable to the entire libstd facade discussion.
The second problem I have is actually building the thing. Right now, my best attempts are using Xargo. The build tools since I last looked (1.21) were… intimidating. I’m also hitting very weird compilation errors that are out of scope for this post. Suffice to say I’ve got a bunch of code written that compiles in isolation, but I haven’t solved the build story.
The last issue I can see is that the CMSIS RTOS specification is a moving target. Happily, embedded development is a very conservative arena, so there might not be much resistance to sticking with an old revision. Version 1 is well baked and well supported.
The approach I’ve taken to date has been very close to that of WASM’s - return an Err when something is unimplemented, and await conditional compilation errors only on “kept” code. I’m looking forward to seeing how wasm32 solves libc dependency issues (perhaps out of a narrow libstd-only scope, but necessary to build).