RTOS implementations / bindings

[japaric]

Parent issue: #55

Place to discuss RTOS implementations / bindings.

There's some agreement on making some standard RTOS API (traits) and then have the implementation adhere to that.

TODO

Define tasks to tackle

[thejpster]

I think there are two pieces to the RTOS story - the API and the implementation(s). The first implementation might be a FreeRTOS wrapper but I'd love to write a Rust port of it in due course.

The API would involve:

• Static and dynamic queues
• Static and dynamic threads
• Static and dynamic event groups (bitfields you can pend on)
• Static and dynamic mutexes (although in my world we really try and avoid these)
• Static and dynamic timers (these post messages or flag events on expiry)
• High level ISRs (pseudo-ISRs that are scheduled like threads and so have access to the full API)
• Hardware ISR safe subset API (mainly triggering HISRs)

[jcsoo]

In this context, can you go further into what you mean by static and dynamic? Do you mean static creation before starting up tasks vs. creating / destroying these objects within tasks?

Looking at your list, I wonder how far it is possible to get using a SPSC queue supporting zero-sized objects as the main communications primitive.

[thejpster]

In brief, yes. Sometimes you know the resource requirements at compile time - six threads, six queues, one event group, etc. Allocating static space means you don't take up heap/pools. Sometimes you also want to spin up background threads, or bring up a new queue for a test that you later want to delete. It's good to support both models.

I imagine the former would use an RTFM style macro.

[adamgreig]

The CMSIS-RTOS (v1, v2) APIs might be a useful reference too. In theory a wide range of RTOSs implement them, so Rust bindings to that API would allow you to plug in multiple RTOSs under the hood. This includes FreeRTOS: https://github.com/ARM-software/CMSIS-FreeRTOS

In general the CMSIS RTOS APIs provide access to all the common and standard RTOS stuff, but many RTOSs have a few extra things on top that might require additional/special-cased bindings.

Another good and open-source (though GPL only) RTOS for Cortex-M devices is ChibiOS which I'd love to see/write Rust bindings for!

[ryankurte]

Really like the idea of a rust-embedded/rtos-api similar to cmsis-rtos that rtos implementations or bindings can implement. I guess a bit like embedded-hal, if we have a set of primitive traits that RTOS implement it should be pretty easy to build "thread" safe primitives on top of that API.

It seems to be falling out of favour but just to chime in, I think predictability is critical if rust is going to be taken seriously for embedded, and hopefully that could be reflected in these APIs. Static allocation, Mutexes and primitives that work from ISRs, NO runtime exceptions etc. (which are all features of most of the modern/iot rtos's). One of the reasons we struggle to use c++ is that while it's possible to write safe embedded code in c++, it's not obvious / a chore to get it right / remember what's ok and what's not.

[japaric]

There seems to be agreement on the direction of a standardized RTOS API / traits. Could someone make add / suggest work items about that? I expect the work items would also include the task of making a reference implementation by binding some C RTOS.

[jamesmunns]

If we select a target RTOS to bind against (seems like FreeRTOS or cmsis-rtos are the frontrunners), I would be happy to apply the same techniques I used with https://github.com/jamesmunns/nrf52dk-sys.

A word of warning: Most C based project rely HEAVILY on compile time macro settings to change configuration settings, and Cargo/Rust does not really have the same kind of mechanisms to deal with this, as the #[cfg()] flags typically operate in a union style format. I will mention this in #48, since I think it is not specific to RTOS's.

[japaric]

I saw this FreeRTOS bindings on reddit today. I don't know how it maps to what you folks have in mind.

Also, I have turned this issue into an RTOS-only discussion since that's the multitasking model that has been discussed so far.

[jamesmunns]

@japaric This topic is going to be covered in #56 - We may want to close this issue as a duplicate

[memoryruins]

Discovered drone today:
https://github.com/drone-os
https://docs.rs/drone/0.6.0/drone/

[seanybaggins]

Hi. Has there been any progress on this? It has been a while since a post in this issue.

[frank-amy]

is there some graceful ways to comm with threads by rusty, in RTOS such freertos, threadx
I only have some ideas by FFI, based on RTOS C apis, maybe messagequeue
Yes RTOS wrapper layer

[newAM]

It depends on the RTOS of course, but most of the native rust RTOS' have similar mechanisms to ThreadX/FreeRTOS. Maybe take a look at embasssy_sync for some inspiration?

[adityashah1212]

I was actually looking for something like this and would love to work on it. I am not sure what the actual RFC procedure is though. Would love to get some inputs.

Also I think there are more parts to the RTOS ecosystem than just basic tasks, timers and synchronization, but we can definitely start from there.

[adamgreig]

Closing as part of today's issue triage. A number of RTOSs have Rust bindings (see https://arewertosyet.com/), but in the years since this issue was created it's turned out that alternative frameworks such as RTIC and Embassy are also viable for embedded Rust and have become very popular.

In particular, I don't think we need standard RTOS traits now - some RTOSs can implement std (Espressif do this, for instance), which is probably the best set of common interfaces imaginable, and for Embedded-specific things, embedded-hal has become popular and widely used.