[RFC] Future options

[Giovanni]

Hi,

I am going to pause the work on Nil until I have cleared some doubts. I think it is a very good RTOS, I really like its simplicity and elegance (which are the same thing in my mind), it does not overlap ChibiOS at all so the effort has been worthy the about 24 hours spent on it, now the fun part is over

In order to test Nil I had to put together a test application, my first idea was to use the ST library for initialization but as soon I tryed to use that thing I quickly changed my mind. It is pointless to make an ultra-compact RTOS if you have to use a bloated library for everything else. I ended up creating an ad-hoc initialization code.

My conclusion is that Nil would require an HAL that would have to be as space efficient as the kernel, in this moment creating such an HAL is not an high priority even if it would be "easily" derived from ChibiOS. A subset of drivers with a subset of features without the more exotic stuff.

I am considering several options going forward:
1) Make Nil a ChibiOS subset but compatible at API level, it is already compatible but names are different: "nil" instead of "ch" as functions prefix. Except for names the API behaves in the exact same way, the base concepts (iclass, sclass etc) are the same.
2) Create this mini-HAL. Or alternatively point 3.
3) Try to create an unified HAL usable by both ChibiOS and Nil. The problem is that ChibiOS demos and test suite depends on the HAL, it could not be separated easily.
4) Create a simple test suite like a single application, at least in order to benchmark it against ChibiOS, it could end up being faster than fastest (for very small threads number).

Giovanni

[Abhishek]

I'd suggest pt. 4 first, so that we can get a good idea of Nil's performance, and its break even point with ChibiOS. Then we could think of a Mini-HAL idea or a compatible HAL between Chibi and Nil.

Although I think a mini HAL is better, but if the HAL is made universal, then low power applications could benefit from the small kernel size and the asynchronous API available for certain peripherals (use of DMA and interrupts) that is being used by the current HAL.

[Giovanni]

Outputting the test results would require a serial driver at least, so some kind of HAL. Also, being threads statically declared (see the main.c of the demo) it will be not so simple to quantify the system performance for a variable number of threads, it would require multiple compile/run/report cycles.

Giovanni

[Giovanni]

After some processing I decided that Nil should have its own HAL.

This new HAL would be extremely simplified, it could be designed this way:
- Simplified configuration.
- All function would be synchronous and thread safe.
- Simplified drivers by removing callbacks and events. Callbacks replaced by thread wake-up in some drivers, for example the GPT would wake-up a thread instead of invoking a callback.
- Because of the above point there would be no need for the developer to worry about the driver state, just call functions when you need to do something.
- No crazy stuff like DMA sharing etc.
- Only a subset of the ChibiOS drivers with a subset of functionality.

All the above would make the use much simpler and reduce the footprint.

Candidates for the above effort would be AVR, MSP430, STM32F0, LPC1xxx.

Just a plan, no commitment yet without knowing if there is actually a need for this. Probably the best way is to create the support for one of the platforms and see the response.

Giovanni

[pito]

The need needs to be created .. I think such little rtos will be wellcomed by people who want to change their mindset towards an "os" (..coming from the superloop universe). As the big chibios is concerned - the barrier to enter is high for many, I think.. p.

[Xamusk]

I think a great way to introduce a simple RTOS to a superloop-like, synchronous application, into a platform with existing HAL and need for small footprint would be the Arduino.

The Arduino has a (mostly synchronous) HAL and only 32KB of flash. Also, it has great visibility, and Nil might take advantage of the high visibility with its community.

The only problem I see is integrating the "behind the scenes" stuff. Maybe Nil could just replace that part and use the HAL libraries?

[Giovanni]

The need needs to be created .. I think such little rtos will be wellcomed by people who want to change their mindset towards an "os" (..coming from the superloop universe). As the big chibios is concerned - the barrier to enter is high for many, I think.. p.

The problem for "superloop" people is not about which RTOS they learn first, it is about learning a different way to solve problems.

I think a great way to introduce a simple RTOS to a superloop-like, synchronous application, into a platform with existing HAL and need for small footprint would be the Arduino.

The Arduino has a (mostly synchronous) HAL and only 32KB of flash. Also, it has great visibility, and Nil might take advantage of the high visibility with its community.

The only problem I see is integrating the "behind the scenes" stuff. Maybe Nil could just replace that part and use the HAL libraries?

Using the Arduino as first platform could be a good idea but I am under the impression that the Arduino existing code is not written to be RTOS-friendly, that would make for a poor HAL.

Giovanni