Of those approaches mentioned, RTIC is the one I find most interesting. It's worth investigating whether you're dealing with RTOS problems or not. It's not actually an RTOS the conventional sense, but a concurrency framework that repurposes the Cortex-M NVIC as a highly efficient hardware accelerated scheduler, with compile time guaranteed deadlock-free operation in Rust.
Seems good. Basically follows what we learned in academia. That said, the scheduler part is a bit weird. I guess I understand why a scheduler could be uninitialized, but I don't understand all the wishy washiness around the scheduler pointer. There's a global schedule. It exists, no doubt about it. Feels a lot easier to say that the now function just always returns its current time and the default time is part of the data section that gets 0-ized, and the scheduler should have its own delay function that if not initialized throws the error or whatever unwrap does. I'm not a rust person but as a C person this seems inefficient considering the system, where the system is one that always has a scheduler instance
Awesome read. Inspiring to attempt this and use it as a platform for learning more about scheduling etc. thanks to the author.