scmRTOS for Arduino

Currently in a fairly primitive but functional state:

Requires no changes to the core, so a somewhat different set of tradeoffs vs. DuinOS.

= Mike

How compatible is it with arduino libs? Should people expect to customize existing code or will it largely work as is? Is this best considered for new projects?

In general, the library is very compatible.

The most significant issue you'll have with most libraries is that they're not re-entrant, and so you need to be careful about only calling a given library from a single process. Most libraries are safe when used with interrupt handlers that do port I/O, and from the perspective of a lower-priority process, a higher-priority process looks like an interrupt handler.

In general a simple route to a safe design would be to use the Arduino libraries primarily from one process, and use the other processes for higher-priority or background processing.

The only hardware resource it uses is Output Compare #2 on the timer that Arduino uses for time. I did some googling and couldn't find anyone that was using that vector (Tone can use #1 in some cases). If you were to find yourself with libraries trying to use both #1 and #2 then you could use any other timer that would give you an interrupt at a similar rate.

I intentionally didn't try to wrap any of the Arduino libraries to make them re-entrant. The DuinoOS project is already covering that ground, and it involves substantial modifications to the Arduino core to add the appropriate locking &c. With the scmRTOS library the user may need to be a little more careful, but the environment requires less effort to set up.

= Mike

To your question about existing code vs. new projects, that's likely to depend on what you wanted to add to your existing code.

I covered existing libraries already. Making a library re-entrant doesn't have to be difficult; it could be as simple as adding a mutex that you take on entry to any library function and release on exit. You can wrap libraries from the sketch side, or adapt the library depending on your preferences. There are lots of ways of managing concurrency; I don't want to write a textbook here.

For sketches, the most common reason to want to add an RTOS to an existing sketch is because there's something you want to do pre-emptively, or in the background when the sketch is otherwise idle. In both cases using scmRTOS can be quite simple; pick one of the processes to run your original sketch's loop() function, and assign the others to your background/realtime loops. As long as you yield time (using OS::delay) appropriately, things will "just work".

Obviously if you're starting from scratch, you can design your sketch to take full advantage of the RTOS with mutexes and queues to communicate between processes, but that's not a requirement.

= Mike

Thank you for your follow ups.

From what I've found, the only documentation is in Russian. So I guess sample code and the code itself is the only source of documentation?

I've previously looked at several other RTOS here and got mixed results. Those mixed results were likely because of the horribly buggy compiler provided by my Linux distribution. Now that I have a seemingly valid compiler I was planning on going back and evaluating again. This seems like another one to consider, though admittedly the seemingly total lack of documentation is a big minus. Perhaps I missed something? Is the source code the sole source of documentation?

The other option I've been looking at is either adopting some of the event frameworks or writing my own. A couple of the event frameworks I've looked at seem to have huge negatives in that they require each widget to implement its own loop and therefore encourage each consumer and producer to monopolize the CPU for extended durations; typically to exhaustion. Basically making all of the event framework projects advertised here a complete show stopper. I guess if you have absolutely no real time requirements*, or very limited event production/consumption cycles, some of these event frameworks become palpable; otherwise simply creating your own without these shortcomings is just far too easy. Which basically means, creating your own without massive negatives is far too easy.

Which means for me, either a roll my own event framework or use of one of the existing RTOSes is the very likely route for me.

(*) And its not so much that hard realtime requirements need play a role, its that the event processing is frequently so poorly handled, its that they become sequentially, completely unbounded. Which means, these can easily make even simple user interfaces extremely unresponsive and unacceptable - by design. I suspect many who are running with these solutions simply don't have the experience to understand the potentially substantial negatives they are taking on. But as you point out, RTOSes carry their own sets of potential issues.