Bern RTOS: RTOS Analysis and Rust Introduction

Flexibility & Scalability

In the end an RTOS is just a tool. It is supposed to simplify embedded systems development, by moving some responsibilities (e.g. time management, synchronization) from the developer to the RTOS. But when developing an RTOS we cannot anticipate all the applications the user will want to use the system. Thus, the system should be flexible enough to be used for some unforeseen use cases. Nevertheless, the RTOS flexibility will be restricted in some ways in exchange for safety by introducing a resource privilege system.

Flexibility is for example needed in memory management. Most systems will probably get by with static memory management. But for some application dynamic memory management is beneficial or necessary. For these applications the Bern RTOS should provide deterministic pool of memory blocks.

The Bern RTOS should be scalable, so it can run on many architectures regardless of power and memory constraints. This is mainly achieved by abstracting the architecture and avoiding artificial limits (e.g. max number of tasks) in the kernel design. Some applications emphasize one part of an RTOS more than others, i.e. power management is important on wireless sensor node while a motor controller needs timeliness.