User workflow
The Devicetree and architecture of Zephyr restricts its user to a specific workflow, where the RTOS handles hardware and services. The advantage of an RTOS that handles the hardware is that it can ensure resource access is safe, either at runtime by applying permissions or to some extent with Rusts ownership at compile time. The problem here is that the learning curve to adopt such a system is steep and most people will probably only use a system that already has widespread hardware support.
Implementing and maintaining drivers for every hardware requires a large community or MCU manufacturer support. The Rust community already has a hardware abstraction project in place, the embedded-hal. The HAL already supports numerous MCUs, especially support for STM32 devices is well advanced. Some companies might still want to implement their own HAL based on memory mapped registers. For the Bern RTOS we need to find a solution that allows the usage of the embedded-hal or a custom HAL.
The idea for the user workflow is that the Bern RTOS can be adopted to an existing workflow to some extent. In particular should it be possible for a user to reuse existing code (e.g. a custom HAL or embedded-hal based device drivers) when switching from bare-metal to the Bern RTOS.
To manage and configure projects in Zephyr custom tools are provided. At some point the Bern RTOS might reach a level of complexity where such tools are necessary as well, e.g. to create projects, to configure the RTOS or to validate permissions. The goal is again to keep the workflow a user is already familiar with by extending Cargo.