5 ms·

I think the RTOS side is being addressed pretty well for rust, which libraries do you feel are missing now?

• flykespice 4y ago
• deepspace 4y ago
  Last time I looked, RTIC was the most complete RTOS implementation, but it lacked some functionality related to timeout actions in the network stack that I needed (and was provided by FreeRTOS). Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
  • bfrog 4y ago
    Tock is probably closer to a true RTOS in the sense that tasks have stacks. Maybe also hubris. RTIC, embassy, and probably a few others do ISR preemptive task scheduling and synchronization. This is super cool and probably enough for most people. Until you need time slicing probably. Threads have pros and cons like anything else, the biggest cons tend to be… Stack sizing is hard. Stack swapping kills caches. Stack overflows can be very infrequent and hard to debug. Thread priority doesnt always do what you think. Even with threads not every RTOS does time slicing. So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.
• elcritch 4y ago
  Nah, the RTOS side in Rust is still in its infancy. Hubris is pretty cool but really only supports two families of chips (and requires an MPU iirc). Rust's ecosystem still struggles with no_std, so the majority of crates won't work. Worse (for me) is that using Rust with arrays (not heap allocated vec's) is still a pain.
  • steveklabnik 4y ago
    (Hubris does require an MPU, you're recalling correctly :) )