# RTOS for Cortex M4 with 802.15.4/6LoWPAN stack

I'm evaluating operating systems to use in an Internet of Things Project and I don't know what's the best way to proceed.

I'm using a TM4C123GH6PM MCU with 32k RAM and a CC2520 802.15.4 transceiver, it would be great if the system already provided drivers for those.

The system will run one (interactive) task that draws a dotmatrix screen and reacts to user input. It will store configuration and application data on spi flash. There will be a mesh of multiple modules (based on 802.15.4) to sync data between the modules, extract sensor data from the modules and forward them to a gateway (rpl comes to mind) and also distribute OtA firmware updates in a gossip-like fashion. All while running a rather memory hungry application as well.

So far I've looked into these systems:

RIOT:

pros

• good hardware abstraction
• small footprint
• very active and helpful community
• full 802.15.4/6LoWPAN stack

cons

• unstable, still undergoing fundamental changes
• still contains race conditions/crashes
• no filesystem support
• few network protocols

pros

• mature system, used in commercial products
• full 802.15.4/6LoWPAN stack with many useful protocols
• file system support
• cc2520 support

cons

• development has become stale
• 'grown' codebase, lots of bit rot
• bad quality tiva c port
• little support for modern platforms
• non-preemptive scheduling might cause problems with the application

pros

• easy to use, reliable scheduler
• mature project, used in many products
• lots of ports

cons

• no file system
• no hardware abstraction for drivers/no hardware drivers
• no network stack
• somewhat high use of dynamic memory

pros

• very feature rich, almost feels like Linux, yet still small
• file system support
• good hardware abstraction
• Tiva C port, many other ports

cons

• somewhat complex
• no support for 802.15.4/6LoWPAN, just 'classic' netstack

My conclusion would be to take the good parts of Contiki (the netstack, file system) and port them to FreeRTOS. But I'm not entirely comfortable with a fork like that. I'd probably be adding errors and wouldn't be able to backport upstream fixes, also I still have to invent my own hardware abstraction to be able to switch the MCU in the future. So I'd end up with my own OS for something that seems like a problem that many other people should have too - hasn't someone done that before? (I mean I did find something, but the idea of running the entire contiki-os as a FreeRTOS task makes me uncomfortable)

Is there something I'm missing? Maybe the pain would be worth it and I should try to get Contiki to a functional state on my hardware instead? Or is there another system I've missed that would solve my problems?

Also I'm not sure whether I need 6lowPan at all, but when that means being able to build onto existing protocols/being compatible with other systems (e.g. Linux), I'd be willing to take the additional overhead.

• running the entire contiki-os as a FreeRTOS task makes me uncomfortable That's just.. wow! I would have never thought of that.. – m.Alin Feb 5 '15 at 19:07

If you are not married to that specific processor (or are savvy enough to copy/paste the code out anyway), I frequently use Freescale MCUs with CodeWarrior and Processor Expert. PEX includes a number of components including FreeRTOS, MQX, FAT, etc. Additional components can be downloaded and, in the end, it is just a GUI-based code-generator so, as suggested, you could copy/paste the resulting C code into your project.

Edit:

-MQX includes IP stack

-FNET

Large pre-compiled package of many useful components: http://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/

You're missing mbed OS:

pros

• directly supported (promoted) by the core designer - ARM Ltd.

cons

• its first stable release is expected (planned) only in Nov'15 :-]

If this is for commercial use, I highly suggest you look at the non-free options, support is everything, if it's a personal project then i can understand.

Yes, there is cost involved, but with some RTOS developers, it not that big at all, they really make there money on custom development and licenses can be free until you make a sale. Below is a link to an article that compares some paid competitors:

I'm a project manager, and we switched from using ST offered drivers to Unison. IIRC, the licensing was surprisingly small, and we got a "full-trial" until we were convinced, but consistent direct support was what pushed us over the edge, and what really help up speed up our development. I think they already have support for various TI wireless chips, not sure about CC2520.

The guy that does most of the selling is really personal-able and doesn't list pricing for two reason, i'm told 1) because they want to hear what you need, they really want return customers, and word of mouth references, and 2) competition.

FYI, Unison's website is really bad.