search

flipperdevices / flipperzero-firmware

Flipper Zero firmware source code
https://flipperzero.one
GNU General Public License v3.0
12.12k stars 2.65k forks source link

Choose an OS/HAL #17

Closed glitchcore closed 3 years ago

glitchcore commented 4 years ago

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 commented 4 years ago

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

glitchcore commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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:

reendael commented 4 years ago

Have you considered going with Zephyr or Contiki?

glitchcore commented 4 years ago

Have you considered going with Zephyr or Contiki?

Please, indicate pros and cons of these options

hp197 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

These use cases lead us to the following requirements:

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Some additional arguments for Tock OS:

pavel-demin commented 4 years ago

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:

I also see some cons:

glitchcore commented 3 years ago
  • 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 xCreateStatic alternative)
pavel-demin commented 3 years ago

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 commented 3 years ago

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.