Re: [Paparazzi-devel] Real Time Paparazzi with ChibiOS/RT

[Felix Ruess]

Hi Michal and Cal,

Here is the first version of Real Time Paparazzi, based on ChibiOS/RT(http://www.chibios.org) and extending work of @enacuavlab. It is certainly not a complete work, rather the first step how to adapt Paparazzi to a RT OS. The system is developed and tested on Lia 1.1 (STM32F1, http://paparazzi.enac.fr/wiki/Lisa/M_v2.0) board, so it can be easily used in existing autopilots.

Great that you are putting effort into this! I'm really looking forward to having a proper preemptive scheduler ;-)

 

The system architecture is shown below. To change as little code as possible, Paparazzi interfaces with ChibiOS via new main_chibios.c file (main thread, invoking other threads according to the system settings) and via arch/chibios files. Those are basically middleware, translating between high-level architecture independent paparazzi functions (such as uart_transmit) and ChibiOS HAL API (such as sdWrite).

I think that keeping the Paparazzi HAL (i2c, spi, etc. in mcu_periph) is a good way to go, so we can have the same peripheral drivers regardless of whether one is running "bare metal" paparazzi or with chibios. And features like the I2C and SPI transaction queues are not available in the chibios HAL if I'm not mistaken.

Which approach will end up to be the better one, writing a translation/glue layer between Papaprazzi and ChibiOS HAL or only using the ChibiOS scheduler (with maybe some select drivers like SDIO) and re-using our current arch drivers is probably impossible to answer until it has been tried...

To get the full potential of RT system, the monolithic Paparazzi application had to be split into more individual threads. Threads are effectively replacing periodic function and events. That is probably the biggest change.

The "tasks" we currently have in main.c (using the virtual sys_time timers) were intended to be converted to real tasks/threads for an RTOS.

I don't know enough about ChibiOS yet to say whether it actually makes sense to create separate threads for e.g. telemetry tx and rx.

The rewards are control over task timing and priorities,

yes!! 

and hardware independence for Paparazzi.

 

Hm.. not that much more than what we have now...

Beware that the ChibiOS HAL does not support e.g. I2C, Uart, ADC for our LPC based boards... (And of course it won't help for systems like the ARDrone which essentially run on a full Linux).

But (at least for me) the HAL is not the reason for choosing an RTOS.

The ChibiOS drivers are also expected to be more efficient, since DMA is natively used where applicable (USART, SPI).

 

How do you come to expect that?

We are also using DMA and I strongly doubt that e.g. the I2C or SPI will get more efficient than what we have now...

The code is available here: https://github.com/paparazzi/paparazzi/pull/554

 

As written in the pull request, please always base new development like this on the master branch and add chibios as a submodule (e.g. like here)

• GCC ARM Embedded toolchain was used for compilation https://launchpad.net/gcc-arm-embedded

This is the recommended toolchain since v5.0 anyway ;-)

The paprazzi-arm-multilib package is only needed to build 4.x and prior versions...

Btw, I (re)built the ubuntu precise package of the gcc-arm-embedded toolchain with python support for gdb:

https://launchpad.net/~flixr/+archive/gcc-arm-embedded

Regarding mutexes for accessing global structs like gps, imu, etc: we should work towards completely removing the need for these as means of passing data between threads.

ABI is meant to do this via a simple publish/subscribe mechanism using callback functions for minimal overhead. See also pull request 525: Baro event handling using ABI

The idea was also to keep the same API there, but change the implementation of ABI to e.g. use queues when using an RTOS like ChibiOS.

Cheers, Felix