Choose an OS/HAL about flipperzero-firmware HOT 16 CLOSED

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.

from flipperzero-firmware.

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

from flipperzero-firmware.

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

from flipperzero-firmware.

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.

from flipperzero-firmware.

Have you considered going with Zephyr or Contiki?

from flipperzero-firmware.

Have you considered going with Zephyr or Contiki?

Please, indicate pros and cons of these options

from flipperzero-firmware.

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).

from flipperzero-firmware.

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.

from flipperzero-firmware.

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?

from flipperzero-firmware.

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.

from flipperzero-firmware.

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.

from flipperzero-firmware.

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

from flipperzero-firmware.

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

from flipperzero-firmware.

• 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)

from flipperzero-firmware.

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.

from flipperzero-firmware.

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.

from flipperzero-firmware.