[TALK] The RTOS of future

[Giovanni]

Hello

ChibiOS/RT 3.0 is almost done and I think it is as good as an RTOS of that kind can be, it is fast, it has all the common features and some its own original ones, the codebase is well tested and survived the years.

I wish to start discussing the requirements of the RTOS for future MCU generations which may or may not differ from the requirements that are at base of RT and NIL.

Lets see what is probably ahead in terms of HW and market:

1) MCUs are going to be multicore, there are already examples of this and probably multiple cores will become mainstream in few years.
2) MCUs already include memory protection features.
3) RAM will be less a limitation.
4) Focus will be more and more on focus.
5) Raw CPU performance will make less important the performance of the RTOS itself.

Considering that RT and NIL will be able to cover nicely the low end and the middle area. I want to discuss some features I am considering for this hypothetical future RTOS.

Isolation

The RTOS will no more be linked with the application but could become a separate entity accessed through a common entry point (SVC syscall vector). The RTOS data structures would be accessible only in privileged mode and protected.

Processes

Threads would run by default in non privileged mode and be divided in pools, each pool would be isolated from the others (basically introducing the concept of processes). Such an approach has, of course, an impact on performance because everything will have to go through the syscall, even thing currently handled by lightweight macros.

Bootloader

Being the OS a separate entity, should it be also the system bootloader? how far this should go? to the point of being able to load processes like a fully standalone OS? (but in flash, not RAM)

Cores Handling

Threads would be able to run in any of the available cores. There are two options for this:
1) Dynamic thread scheduling, threads are run by the available cores.
2) Static assignment of threads to cores.
Probably #2 is easier to implement and has a more predictable behavior. It also fixes the scenario when some HW resources are only accessible by some cores and not others.
Cores handling has a cost in terms of performance, so a "single core mode" should be considered with optimized code paths.

IRQs balancing

Probably the OS should have mechanism to assign interrupts to one of the available cores in order to optimize the load OR reduce the jitter on specific cores.

Just few ideas I wanted to share.

Giovanni

[jpa]

More and more of the RTOS applications are considered non-critical. As a natural consequence, the firmware is not as strictly developed and is often of poor quality, yielding many hard-to-debug failures on the field.

Therefore logging and error reporting will become very important. Many people already build custom logging and crash dump features to their systems, but these aren't usually very comprehensive and usually more of a kludge. I've myself called back to fatfs filesystem from HardFault handler, something which is definitely not a very reliable approach. By integrating these to the operating system, it would be possible to log more things (such as thread states), while making good-quality debugging aids available to the poor-quality application code that needs it the most.

In a way this ties in with the bootloaders - reliable on-the-field software update is another very common requirement that is challenging to implement. So some kind of hypervisor or bootloader might be needed, which can handle the firmware download and error reporting tasks that have to be available even when everything else fails.