I discovered this (on Linkedin): “Introducing the FreeRTOS Symmetric Multiprocessing (SMP) Github Branch” [1].
I have not found any explanation on Github about the architecture of SMP on the xCORE and what it might imply. Here is a list of some points which I would however not know the relevance of:
Now, is one SMP processor unit:
Several XMOS processors and external bus to shared memory?
Several xCORE tiles which have shared memory with.. (on the xCORE architecture on-chip tiles are connected via the xConnect switch which may also be used when communicating with off-chip tiles on other XMOS processors. The xConnect also does hw routing of packet switched data, in several topologies). But SMP at this level?
Several xCORE cores which already have shared memory with those on the same tile?
The architecture and xC already does this per tile = SMP (cores). I think this change is in the FreeRTOS kernel only.
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.
Thank you markseel! I didn't see your comment before today! Sorry!
I appreciate your thoughts, and will bring them along when I some time in the future port my hobby project Beep-BRRR from xC into XTC. I have certainly loved the XC2.0 with interface and three types of tasks (full state, combinable and distributable), and would miss them all in XTC I assume. I have a friend who has tried XTC and he thinks it quite well done. But markseel, I am not certain in your comment when xC/xTIMEcomposer stops and XTC begins. I assume that freeRTOS would mostly be for the ML stuff?
