Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTOS implementations / bindings #45

Open
japaric opened this issue Feb 21, 2018 · 10 comments

Comments

Projects
None yet
7 participants
@japaric
Copy link
Member

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Feb 27, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 27, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Feb 28, 2018

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.

@hannobraun hannobraun changed the title Multitasking models RTOS implementations / bindings Mar 5, 2018

@japaric japaric removed their assignment Mar 16, 2018

@jamesmunns

This comment has been minimized.

Copy link
Member

commented Apr 3, 2018

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

@memoryruins

This comment has been minimized.

Copy link

commented May 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.