RTOS with a Dictionary is standard in any system I build.
Most people will think FreeRTOS or a similar thread shifter then we say “RTOS” on embedded, but the hard reality is that most embedded systems are “barebone” and run some version of a round robin scheduler. Myself I do the same – I install FreeRTOS if I need to, but I still run a Linear Scheduler on top of FreeRTOS, Linux or Windows because they scale better than needing a stack for every thread.
Another major issue is that a linear scheduler can switch tasks with ca 10us in between, while any task shifter struggle with the same since they are depending in interrupts. You are welcome to try interrupts 10,000 times a sec (100us) and see what happens. You will be using a lot of CPU power on that interrupt alone – depending on MCU.
But, what about the OS part of any RTOS? An OS is more that just multi-tasking – it is your eco-system with library functions you can safely access in any module and expect to exist on any system you use.
- Clock – RTC and ETC is a must
- Signals and Timers
- Message Queues
- Standard API functions/framework.
Myself I also include a mechanism called a Dictionary that is an index over variables and tables that I use as API between modules. In a well designed system my dictionary will be the only module that can access all parts of a system and it consist of a generic part that is extended with an index table containing pointers to variables and tables I want to access.
One of the standard functions are Persistent Memory that is handled by the Dictionary.
Another critical function is entity integrity then dealing with protocols like CAN and Modbus. These protocols are capable of sending you a single parameter in a message, meaning that your system can start operating on incomplete data unless you have a mechanism ensuring integrity over a set of variables. The most used technique is a low cost CRC.
But mentioning CAN, Modbus and other protocols they all access the same variables making it very convenient to build these protocols on top of a dictionary.
Or to make it simple – a well designed dictionary will simplify your system dramatically and reduce the total usage of flash/ram if you have a complex system.
CLI and Configuration is another feature. Will all API variables accessible through a central dictionary it becomes ease to implement a CLI with set/get functions, and since CLI is USB/TCP or serial ports they can be scripted as well.
The last trick I often use is the HMI that mirror the dictionary on a PC that again is linked 1:1 with components or entities on the screen. This allows me to focus on gadgets and with a few lines of code I have fancy UI that can visualize or edit variables/tables on multiple embedded devices.
FreeRTOS or any thread shifter can be added with a few lines of code if I need them, most often I don’t.
As for modules I have a strict requirement that any module – collection of embedded C++ code – can be dropped into any project with only 2-3 lines of code since they use a standard API and OS definition that I can duplicate on any system embedded, Linux or Windows.
Added functionality like Redundancy or distributed systems is basically added dictionary functionality.
One advice is to use #ifdef to exclude/include entire modules. GCC is very good at excluding code that is not used, but this is the only time I recommend #ifdef and a custom config.h that manage this.