RIOT-OS and multiple executables?

Question

I am brand new to embedded programming and am wondering if RIOT-OS has the capabilities that my small project requires.

I have 3 executables, fizz, buzz and foo. They all do separate - but very important - things. My understanding with real-time OSes is that you typically:

1. Take your app’s source code and somehow merge/splice it with the RTOSes source code; then
2. You cross-compile this conglomerated source code (again your app + RTOS source) into a binary that is compatible with the ultimate platform/architecture you will run it on; then
3. You flash the binary to the chip using something like UART or SPI, etc.

First, if this understanding is incorrect, can someone please help correct/clarify things for me?

Assuming I'm more or less on target, then I’m wondering if RIOT-OS supports the concept of "multiple executables" running when the chip/OS starts up? In other words, is it possible for RIOT-OS to be cross-compiled with, and then at runtime execute, all 3 executables (fizz, buzz and foo)?

Answer 1

Read the RIOT-OS introduction and the RIOT: One OS to rule them all in the IoT report.

It looks like you'll make a single application (linked with RIOT runtime); this can be your mixture of the three executables, each running it its own threads.

Having an OS supporting several executables seem to require some file system (or something to separate the executables) and some notion of process, which apparently RIOT-OS does not have.

If you have full access to the C source code of your executables (i.e. your three programs), mixing them is in principle easily possible: you just ensure that every program has unique names. You could for example write some script to get the names in each public function (e.g. aa, ab, foo in program fizz) and generate a header fizznames.h with #define aa fizz__aa, #define ab fizz__ab etc... to be included in every translation unit of fizz, etc... This header could be generated with nm feeding some simple awk script (or perhaps by your MELT customizing extension to GCC....); then you write a gluing application which would start each fizz, buzz, foo main function in its own thread. Alternatively, you could play ld tricks (e.g. ld -r) with your own GNU ld script (perhaps using the visibility function attribute) to mix your three programs in a single executable (and you'll still need your own starting function).

You still have to care about communication and synchronization (between fizz, buzz, foo)