Next generation RTOS

[utzig]

Will it be open source too? Was it written from scratch?

Fabio Utzig

[Giovanni]

It will be open source, written from scratch except the VTs that have been taken from ChibiOS.

Giovanni

[utzig]

Cool, I'm very excited about any low RAM/ROM OS alternatives!

But suppose it gets very popular, then you start receiving lots of patches. Would not it impact the development of ChibiOS in terms of time you have to spend on both projects? I was thinking why not make more code in ChibiOS #define protected in a way that a user can finely tune the features enabled to best target various processor sizes?

FabIo Utzig

[Tectu]

I was thinking why not make more code in ChibiOS #define protected in a way that a user can finely tune the features enabled to best target various processor sizes?

If someone would ask me to describe the word "pain", I'd say exactly that

No seriously, that sounds like a big mess.


~ Tectu

[utzig]

Yes it is unless you have tools to ease it. Think something like "menuconfig" in Linux kernel, buildroot.

Fabio Utzig

[Giovanni]

I was thinking why not make more code in ChibiOS #define protected in a way that a user can finely tune the features enabled to best target various processor sizes?

ChibiOS already does that, see chconf.h, its minimum ROM size is already round 1KB, it is not like it is large

Nil is internally radically different from ChibiOS, it would not be possible to reduce ChibiOS to... nil. The idea was to follow a radically different approach for the same problem. Very different initial requirements:
ChibiOS - Fastest, all features.
Nil - Smallest, only features commonly required.

Anyway it will be a secondary project and I am not working on it currently. It was a "I want to code something" moment.

Giovanni

[Abhishek]

My suggestion for the next generation of ChibiOS would be ChibiOS++, a C++ implementation of ChibiOS, and not just a wrapper. Especially, I feel that the HAL and device driver implementation should be moved. Being an OOP, it'd probably simplify portability problems across hardware a lot.

e.g. for a LCD. we could define a generic LCDDriver class and then we could inherit the class to define maybe ILI9325LCDDriver, SSD1289LCDDriver, and so on. for an accelerometer we can have a generic Accel class and have LIS302Accel, ADXL000Accel, so on and so forth. similarly peripherals like SPI,I2C, Timers, Dma, SDIO, etc. can also be abstracted for various platforms.

Of course, performance critical code could still be C, but it should overall be a C++ codebase. We could let it support only 32bit MCU like ARM CM3/4 or AVR32.

With 32- bit micros slowly becoming mainstream and within reach of the average embedded developer, and cheap Chinese dev boards (a STM32F103VET6 board with a 2.4in TFT with touch in under $50), it is more relevant than ever.

I had stumbled upon this URL a few days ago. http://andybrown.me.uk/wk/2011/12/28/st ... velopment/ It looks really great and could be an inspiration for a C++ port.

About an RTOS in memory that can load applications and execute them, the Raisonance CircleOS does the same thing. The Raisonance people have woven a complete ecosystem using CircleOS and their Primer boards and organise annual STM32 design contests to promote them. Link: http://stm32circle.com . They have pretty good projects, and I'd love to see something like that using ChibiOS, and contribute to such a project for a ChibiOS exclusive devboard, if it happens.

Best wishes to the next generation RTOS!

Abhishek

[tinito]

A bootloader using ChibiOS has already been discussed/tested, search in this forum. It could be enhanced and offered as a test application.

Do you refer to mabl bootloader? Isn't it a "regular" bootloader, that exploits ChibiOS, but then the execution jumps to the user application that is actually a standalone firmware?
I thought you proposed to have a full (all features ON) chibiOS in the bootloader part of the flash memory, and the user application calls ChibiOS API from that part of the memory, with some linking magic.
If mabl's bootloader is doing this, I didn't realize how

[levrik]

My suggestion for the next generation of ChibiOS would be ChibiOS++, a C++ implementation of ChibiOS, and not just a wrapper. Especially, I feel that the HAL and device driver implementation should be moved. Being an OOP, it'd probably simplify portability problems across hardware a lot.

Totally agree with that. The HAL is already designed in a OOP-way but implemented in C which is definitely efficient. Implementing the drivers in C++ would transfer a considerable degree of work from designer (who has to take care manually about the interfaces, function-tables etc.) to the compiler. The C++ overhead is, if it's done right, almost negligible (see also The Inefficiency of C++ Fact or Fiction?).

Just my 2 cents.

[Giovanni]

I thought you proposed to have a full (all features ON) chibiOS in the bootloader part of the flash memory, and the user application calls ChibiOS API from that part of the memory, with some linking magic.
If mabl's bootloader is doing this, I didn't realize how

What I proposed was a standalone OS where the application is loaded by the OS rather than linked with the OS. It would have to include a bootloader but of course it would not be just that. For example an entry point for OS services would be defined, probably using SVC. Such an OS could even be placed in ROM is some imaginary MCU.

Probably would be a good idea to make threads run in user mode for enhanced safety, access to privileged mode would happen by "asking" the OS to run a privileged function or in callbacks.

Giovanni