Choose an OS/HAL

[glitchcore]

At this stage of the project I want to discuss what technology stack (OS/HAL/etc.) we will use for Flipper. Now, changing key components is not so painful, but it can bring benefits in the future.

Current solution: STM CubeMX for generating target code, STM HAL/LL for interact with hardware and FreeRTOS.

+ simply get all necessary files for build
+ complex functions like clock, GPIO functions/alternate, timers etc. can be configured in GUI mode with real time constrains control
+ FreeRTOS is well-known (for me), it has big community
+ FreeRTOS has very rich API for thread control and IPC.

- CubeMX GUI complicates CI and development processes
- FreeRTOS itself has no infrastructure and no "best practices"
- Make as build system forces the developer to poke around in makefiles

ChibiOS

+ OS, HAL and many additional feature in one
+ HydraBus project use it, It is very relevant project for me and I'm going to use a lot of code from this one.

- I have no experience with Chibi.

RIOT OS

+ Cool infrastructure: semihosting, in-box building for linux, application build system

- At first glance it seemed to me that it has a poor API

Rust, embedded-hal, Tock OS

+ More safety in core of Flipper
+ Many community crates for additional features, without being tied to a specific operating system/HAL implementation
+ Nice build system
+ Using Rust in Flipper may be big contribution to the community

- I have some question to embedded-hal API itself
- Perhaps not many people are willing to support Rust

[yiiii777]

Which OS give to us any protection from any bugs in user applications? Which OS is more safe?

[glitchcore]

Which OS give to us any protection from any bugs in user applications

I think there is no such magic OS) But we can do some steps to minimize bugs:

• show best practice and patterns for developing user applications
• restrict some dangerous operations in main API.

Which OS is more safe?

Tock positions itself as "safe os". In general, using Rust will avoid stupid bugs like "using data from collapsed stack" and other shoot-in-leg with (God*)((uint32_t)(void*)ptr + 100)->field

[Disasm]

In general it's possible to use almost any C/C++ RTOS and at the same time have both C/C++ and Rust support for user applications. While C/C++ support is obvious, Rust application can be compiled into a separate binary/library and interact with the OS via FFI and message passing. There is a PoC for Rust+RIOT interaction here: https://christian.amsuess.com/presentations/2019/rust-on-riot/, I also worked with the author on support for RIOT+Rust+FE310 combo.

Since we are (hopefully) allow C/C++ for user applications, which sometimes require direct access to the MCU peripherals, we can't talk seriously about overall safety, only about safety of individual system components. Due to that, I see no reason to use Tock OS apart from the (possible) goal of preventing potential problems in the RTOS itself.

[glitchcore]

About tock Maybe we should use Tock for good integration Rust core + Rust HAL, if we choose Rust as language for HAL/Core.

About RIOT I like it has:

• building system
• some infrastructure like linux support and semihosting.

[reendael]

Have you considered going with Zephyr or Contiki?

[glitchcore]

Have you considered going with Zephyr or Contiki?

Please, indicate pros and cons of these options

[hp197]

Most of my experiences are with FreeRTOS.

I havent used rust yet in a real production environment. The language seem to change syntax too much still. For example, what is made now, might break in 6 months and you can easily end up in a dependency hell with external packages (much like nodejs, where you have to download half the internet to run a simple application).

[glitchcore]

Most of my experiences are with FreeRTOS.

Looks like many people in this project have FreeRTOS experience and it may be decisive factor.

I havent used rust yet in a real production environment. The language seem to change syntax too much still.

No, I use Rust for two commerce project (STM32F103 and NRF52 based). Rust have "stable" version even for baremetal development, and it allow write effective and clean code.

dependency hell with external packages

You can feel free not to use external packages and write your implementation, but also can use external crates for case that somebody already solved. C have no included package manager and you have no choose.

[pavel-demin]

I've just joined this project and I'm not sure the following has been discussed yet. So I apologize in advance for raising issues that have already been addressed elsewhere.

I think the choice of operating system and libraries should be determined by the functionality requirements.

For example, I can think of the following use cases:

• installing applications and data
  • connect Flipper Zero to a USB port of a computer
  • Flipper Zero is recognized as a mass storage device
  • use mass storage device to add and remove applications and data
• running applications
  • find an application using the main menu of Flipper Zero
  • run the application
• updating firmware
  • find a firmware file using the main menu of Flipper Zero
  • start the firmware update
  • installed applications and data must remain intact
• developing applications
  • install the SDK
  • install the application template
  • use system calls for typical operations (read data dialog, write data dialog, handling keyboard events, output text, access radio modules, etc)
  • use the compiler and the linker to create a binary file

These use cases lead us to the following requirements:

• file system
• loadable applications
• shared system call library
• main menu, mass storage emulator, firmware updater could be loadable applications

To avoid the need for dynamic linking, the following simplifications can be introduced:

• applications could be copied from FLASH to a fixed address in SRAM and then run from SRAM
• the shared system call library could have a vector table at a fixed address in FLASH

To me this looks more like CP/M or DOS than one of the RTOS listed above.

It is possible for the shared system call library to use the ST HAL library if there are sufficient resources for all the overhead that comes with the ST HAL library.

It is not clear whether preemptive multitasking is really required. It would be nice to have use case examples showing that preemptive multitasking is required.

What do you think?

[glitchcore]

installing applications and data

Also we want to implement HID bootloader to control upload progress and do not disturb user by mounting/unmounting of storage.

find an application using the main menu of Flipper Zero

don't forget that some application may be start at startup or by some trigger actions (for example, BLE/USB connection). Also applications can start each other: for example, RFID UI can start other "backend" emulation app when you need to emulate something.

installed applications and data must remain intact

I'm afraid we can't take much efforts to support back-compatibility and in some cases updating of main FW will require recompiling applications using new core API

applications could be copied from FLASH to a fixed address in SRAM and then run from SRAM

But in this case you cannot run more than one application at time.

the shared system call library could have a vector table at a fixed address in FLASH

I prefer more flexible way when you can get some functions (struct with function pointer) by name (like "require" or "import" works in many langs). You can use FURI records for this purpose.

To me this looks more like CP/M or DOS

As I know, DOS is not support multitasking.

It is possible for the shared system call library to use the ST HAL library if there are sufficient resources for all the overhead that comes with the ST HAL library.

We already use ST HAL, but for some case we had to rewrite functions (for example, iButton emulation requires fast timer setup and fast GPIO operations).

It is not clear whether preemptive multitasking is really required.

I think we must provide cool API to users where they can write

digitalWrite(..., HIGH);
delay(100500);
digitalWrite(..., LOW);
delay(100500);

and do not worry about another features like LCD backlight control or measuring batt level.

[hp197]

I think we must provide cool API to users where they can write

digitalWrite(..., HIGH);
delay(100500);
digitalWrite(..., LOW);
delay(100500);

and do not worry about another features like LCD backlight control or measuring batt level.

From a user perspective I fully agree on this. Keep it as close to the arduino api as possible.
It is a language a lot of people feel comfortable with and it enlarges code interoperability.

[pavel-demin]

Some additional arguments for Tock OS:

• Tock OS supports dynamically loadable applications:
  https://github.com/tock/tock/blob/master/doc/Compilation.md#compiling-a-process
  https://www.tockos.org/blog/2016/dynamic-loading
• Tock OS supports applications written in C, C++, Rust:
  https://github.com/tock/libtock-c
  https://github.com/tock/libtock-rs

[pavel-demin]

Have you considered going with Zephyr or Contiki?

Please, indicate pros and cons of these options

I am currently testing Zephyr RTOS with STM32WB55.

So far I think Zephyr RTOS has many pros:

• complete SDK and build system
• Zephyr RTOS code is organized similarly to Linux code (kernel, drivers, devicetrees, Kconfig files, configuration menu, etc)
• STM32WB55 is well supported (drivers for all subsystems, low power modes, BLE, USB)
• useful libraries (BLE host, LVGL GUI library, SDHC card support, POSIX threads, etc)
• many examples easy to understand and modify (https://github.com/zephyrproject-rtos/zephyr/tree/master/samples)

I also see some cons:

• BLE host runs on the main CPU
• FLASH and SRAM consumption is high compared to STM32Cube examples
• no drivers for CC1101 and ST25R3916
• no support for loadable applications

[glitchcore]

• no support for loadable applications

1. Is zephyr support MMU feature (like xTaskCreateRestricted in FreeRTOS)?
2. Is zephyr supports to control where its objects allocated, to allocate it on stack? (in FreeRTOS every xCreate* fn have xCreate*Static alternative)

[pavel-demin]

The user mode threads are restricted by default in Zephyr RTOS. Here is a link for more information:
https://docs.zephyrproject.org/latest/reference/usermode/overview.html

If we use the kernel API directly, we have full control over the allocation of objects.

If we use the CMSIS RTOS API provided by Zephyr RTOS, it depends on the type of objects we create. For example, memory for semaphores and mutexes is statically allocated using K_MEM_SLAB_DEFINE.

[glitchcore]

After long discussion and regretfully I came to a conclusion that any change of OS and HAL is destructive for project: most active participants well know FreeRTOS and STM32 HAL and we have no human resources for experiment.

You still can implement any alternative OS for FW and we are ready to consider your suggestions, but I place this task to backlog.