[RFC] Ideas for ChibiOS/RT 3.0

[Giovanni]

Hi,

I wish to share a list of ideas regarding the next big evolution: ChibiOS3.0.

Currently I have a list of possible evolutions:

• Tickless kernel, remove the system tick and reduce the power consumption, the CPU will be able to stay deep sleeping for longer intervals. The problem is a more difficult portability because timer requirements.
• High Resolution Timer, the intervals handled by the kernel would not be milliseconds but a much higher resolution, this could become possible in a tickless kernel.
• Real time counter handling moved in the Kernel from the HAL.
• CPU usage performed using the real time counter.
• Multicore support.
• HAL no more strictly coupled with the kernel and usable also standalone or with other RTOSes implementing the RTOS abstraction layer.
• Standalone ChibiOS with bootloader. The HAL would be handled as a separate project.
• Memory protection (MPU/MMU) support.
• Statistics module in the kernel.
• Make 3.0 32bits only and optimize for it. NilRTOS could be targeted to the 8/16 bits space and be able to use the new HAL.

Other points that should be added or considered?

Giovanni

[mabl]

I love those ideas - especially tickles timer and higher precision. MPU support will also help a lot!

I'm wondering though: Could this be achieved out of the current code base without many changes to the user api?

[Giovanni]

The API would be largely compatible but some changes could be required, especially for MPU support. For example the Thread structure should be removed by the thread working area because the stack thread is meant to be private while the Thread structure can be accessed from other threads and ISR context.

[jcbarlow]

• Tickless kernel, remove the system tick and reduce the power consumption, the CPU will be able to stay deep sleeping for longer intervals. The problem is a more difficult portability because timer requirements.
• High Resolution Timer, the intervals handled by the kernel would not be milliseconds but a much higher resolution, this could become possible in a tickless kernel.
• Real time counter handling moved in the Kernel from the HAL.
• Make 3.0 32bits only and optimize for it. NilRTOS could be targeted to the 8/16 bits space and be able to use the new HAL.

I would see the above (all together) as a positive step.

I have for some time considered your goal of providing portability across such a wide range of CPUs rather unrealistic. Portability is good if not too much is sacrificed to achieve it but, for example, failing to utilize the full feature set of the CM4 series so as to maintain compatibility with AVR8s is just not a tradeoff I'm willing to make.

Similarly, I think trying to make your code base portable across several compilers (some of which are just downright broken) is a poor use of your time. Even the Linux kernel guys don't try to do that. I would like to see you standardize on gcc and move to a subset of C++. That would facilitate portability (among 32 bit CPUs) without having to depend on so much hard to read preprocessor magic.

[handaza]

what is tickless kernel? can RTOS work without tick interrupt ?

Make 3.0 32bits only and optimize for it. NilRTOS could be targeted to the 8/16 bits space and be able to use the new HAL

I am afraid this could be a step that lead to drop 8/16 bits support, and what is NilRTOS ?

also can I suggest to make DMA driver in chibios 3.0.

[Tectu]

@handaz: NilRTOS is a kind of derivat of ChibiOS/RT which Giovanni made a few months ago. It's a usual ChibiOS/RT stripped down to a ver basic bare none level. It comes with a very very low memory footprint and dosen't need much RAM as well.
Take a look at the sub projects forum section.

Am I missing something about the DMA? At least the STM32F1 and F4 come with DMA support?

@Giovanni: Personally I don't really like the idea of splitting the HAL appart from ChibiOS that much. One of the things I like ChibiOS so much is because it commes with everything running out of the box!

Also, do you gain so much by dropping 8/16-bit support and move it to NilRTOS?


~ Tectu

[Giovanni]

The current driver already use DMA where applicable

The HAL would not be split apart, the idea is to modify it to be able to work with both ChibiOS, NilRTOS and this new generation kernel. It would work out of box with any of those.

Also, do you gain so much by dropping 8/16-bit support and move it to NilRTOS?

A smaller resources usage for those platforms, I don't think an AVR application would ever use all the ChibiOS features. It is way overkill.

I don't think the current ChibiOS is unoptimized in any way because its portability, limiting it to 32bits would not help, limiting it to GCC and ARM could allow some extra optimizations but I don't think it would be a good idea.

After making the HAL adaptable (now ChibiOS/HAL, muck like ChibiOS/GFX) I would be free to support different kernels tailored for specific use cases, think at them as a family of products:

NilRTOS - Minimal footprint, targeted at 8/16 and very low end 32 bits. I could rename it ChibiOS/NIL or something like that. Footprint 0.5KB-2KB.
ChibiOS/RT - Would continue as-is with the new HAL, lets call this one ChibiOS/RT 3.0. It could evolve to include this tickless mode and RT counters.
ChibiOS/xx - Would be a new kernel with protection and/or SMP support targeting the high end only. I could consider for this one supporting a single architecture and have a version for ARM and another for PPC. "xx" is TBD.

Giovanni

[Freddie Chopin]

How about adding a POSIX compatible wrappers/functions, use some drivers via standard open()/close()/read()/write() mechanisms, thus adding an actual "system" to the scheduler? Generally the way NuttX choose - a mini Unix.

4\/3!!

[Giovanni]

A Posix wrapper could be a potential development, the fun thing is that the ChibiOS grandfather was a Unix-like with RT extensions, it ran on M68K in early '90.

I am not a big fan of open/close/read/write/lseek/dup/dup2/etc in embedded systems however, there is a significant overhead in implementing everything as file handlers. Some device drivers fit well in that model (Serial for example) others not so much and would still require a non-Posix API.

Another problem is that some Posix constructs, like signals, make no sense in a RT system, signals would make response time unpredictable because any thread could be interrupted to serve a signal.

Giovanni

[Freddie Chopin]

I am not a big fan of open/close/read/write/lseek/dup/dup2/etc in embedded systems however, there is a significant overhead in implementing everything as file handlers. Some device drivers fit well in that model (Serial for example) others not so much and would still require a non-Posix API.

That's why I suggested that only for some drivers. NuttX does have such API for UART, but SPI or I2C is handled via a dedicated API for each.

Another problem is that some Posix constructs, like signals, make no sense in a RT system, signals would make response time unpredictable because any thread could be interrupted to serve a signal.

I actually consider that quite a nice idea (; The code would be as predictable as the programmer desires, right? (;

4\/3!!