Evaluation of the Objectives
The overall objective of the Bern RTOS is to implement a fail-safe system from scratch. The introduction into Rust showed that the programming languages ownership model will already solve many concurrency issues at compile time. Further, can code be generic yet strong typed by using traits and generics with bounds. These characteristics eradicate the bugs typically found in C code that arise from void pointer casting.
The development of a demo application fulfilled its purpose and illustrated the capabilities and limits of Rust on embedded devices. For example, with embedded-hal the advantage is that all platforms share a single HAL interface, but the interface is incomplete and feature support is limited on some microcontrollers. The insights gained from the demo application will find their way into the RTOS design.
From the RTOS survey we can conclude that systems are shifting towards IoT applications, offering optional network stacks and connectivity drivers. Similar to the fail-safety goals of the Bern RTOS, other RTOS with network connectivity also focus on safety and security. The architecture draft for the Bern RTOS was heavily influenced by the structure of Zephyr, which uses many generic interfaces. The book μC/OS-III provides a detailed view on a kernel implementation, from which we have already seen some aspects. The book will certainly affect the scheduler and IPC development in the next project.
At the beginning of the project the plan was to implement a simple scheduler as well. But, there was not enough time because the Rust code introduction took a little longer than expected. For this reason, the scheduler prototype is postponed to the next project.
All in all, we have seen that Rust is a good choice to write a fail-safe RTOS and the insights from existing RTOS helped to formulate a concept.