I'm at a loss as to why XMOS spent time and money on porting FreeRTOS to a platform that has RTOS primitives that are natively and efficiently supported from the ground up. Was this effort by folks who haven't spent time in industry applying XMOS specific hardware concurrency to real products? Was it a marketing ploy? The XC 1.0 language (not 2.0 with all of that interface stuff that feels like an academic experiment, like a playground for language ideas) elegantly (and minimally thank goodness) adds multi-threaded event handling and task messaging/synchronization to the 'C' language with just a few new keywords. Tasks can easily be defined by the PAR statement and while the task creation is static (which in my experience in embedded systems is how things typically play out anyway) you can use the XMOS 'C' library for more flexibility. The SELECT statement is pure genius ... and super simple. Using switch/case semantics you can handle an event from any of three hardware resources - timers, message reception, and port activity. Try doing that with a software RTOS - not easy (RTOS flags ... yuk, ISR's setting semaphores/mutexes ... yawn). The SELECT/CASE can use the 'default' label to support non-blocking behavior, and each case can specify an event transition guard (!). XC channels are fast and efficient and if synchronized message passing (vs asynchronous messaging using FIFO's/queues) is your thing then you can do that with hardware level efficiency and speed (low latency) without adding a bunch of support libraries and source code. Sure RTOS's offer a myriad of multi-threading, messaging, and synchronizing mechanism but it's pretty much a grab-bag of stuff that often results in mixed-model messy concurrent realizations. Keep it simple and get-er-done ... employ synchronous messaging using XC channels, use SELECT to handle events in multiple domains (timer, ports, messages), use hardware/software locks when needed, and skip this RTOS-on-XMOS non-sense which adds overhead and just more code to compile and load into RAM. There are hardware level locks (like a single count semaphore or simple mutex) so whether you use locks or dedicated tasks you can create thread-safe event-driven FIFO's and queues. Oh, and try writing your apps in using XC 1.0 instead of 2.0 ... then other developers won't have to learn a new language (XC2.0) just to understand and contribute to your code. Yes you can do it all with what's already there in the xCore HW and with XC 1.0 and you can do it without overhead or large deviation from the 'C' language standard.