next topic »

[on:]

I have ported ChibiOS/RT and FreeRTOS to Teensy 3.0 as libraries.  This allows mixing Teensy software with RTOS functions.

I am now working on ports for Due. It looks like Due will also be able to support these RTOSs as Arduino libraries.

I am also looking at other possible RTOS candidates.  Here are my criteria for candidates.

Active development

Supports Cortex M3/M4

Open Source

Free version available

OS Website has forum with activity

Here is my current list of candidates.  Some of these would not be easy to port to Due.

ChibiOS/RT

FreeRTOS

CooCox CoOS

NuttX RTOS

BeRTOS

eCos

QP

First, are there other good candidates that satisfy the above criteria?

Second, what features would other RTOSs have that are not covered by ChibiOS/RT and FreeRTOS?

Clearly QP is different since it is state-machine based.  In the past I was a fan of state-machines in embedded systems but I am less enthusiastic now.

It's interesting that after making the above list, I found this list https://sites.google.com/site/stm32discovery/stm32-resources-and-links/open-source-real-time-operating-systems-for-the-stm32-and-cortex-m3-mpus.  It has many of the same systems.

[Reply #1 on:]

First of all, thanks for doing this. I don't have a due board, but i often benefit from work like yours.

I've been considering using qp for a project, but as a single threaded async finite state machine. You indicate you are less enthusiastic about state machines. Could you elaborate. It may save me some development time. I am an experienced windows real time software developer, but have very little experience with micro controllers.

Thanks doug

[Reply #2 on:]

The classroom version of using state machines is great.  In practice not so much.

The idea is that you design with something like UML state diagrams.  Once you totally understand the problem, you implement the solution possibly with the help of some tools.  You then live happily ever after.

The problem is that you never understand the real world while you are drawing state charts.  Systems evolve and the real world is messy.

The end result is that the code to implement state machines is not readable so you need or should go back to the design documents to make changes.

This just doesn't work well in the development of large embedded systems.

This article, that is selling a tool for state machines, hits on a lot of the problems but this type of tool doesn't solve them in the real world.

http://www.iar.com/Global/Resources/Viewpoints/What%27s%20your%20state%20of%20mind.pdf

At one point I was a principal in a start-up company that promoted a state machine approach to embedded systems.  After leaving the company I went back to building large embedded systems for big science projects.  I found once again that tools like QP are not nearly as important as fundamental knowledge of the problem to be solved.  Having a PhD in physics trumps use of any tool when you are dealing with a Large Hadron Collider.

[Reply #3 on:]

Thanks for your perspective.

[Reply #4 on:]

Free version available

You might want to pay attention to whether the license permits "free" commercial use, as well as hobbyist/educational use.  It can be quite  a moral quandary to be faced with the possibility of selling a few of your arduino-based gadget, only to need to spend thousands of dollars of licensing fees to stay compliant.

What do you think about Contiki?  I know it's already been ported to mid-sized AVRs (Raven) to implement wireless IPv6 sensor networks; Networking seems to frequently be one of the factors pushing people to real OSes.

[Reply #5 on:]

FreeRTOS can be used in commercial products http://www.freertos.org/a00114.html.  You must pay for the version called OpenRTOS.

There is also a free version of ChibiOS that can be used in commercial products http://www.chibios.org/dokuwiki/doku.php?id=chibios:license.  ChibiOS also has a non-free version.

I have looked at Contiki and at first glance it didn't look easy to port it as an Arduino library.  I haven't ruled it out and will study it more.