[RFC] Future of HAL and platforms

[Giovanni]

Hi,

I wish to share some thoughts about the future of the HAL subsystem within the ChibiOS project.

It is quite obvious that personally I don't have the bandwidth to support all the MCU familes that would deserve attention, the STM32 takes most of my time already, in the next months I will have to handle SPC5xx devices too and there are important evolutions of the kernel waiting as discussed in another thread.

I am thinking to change how the HAL will be handled in future, the portable HAL will be still part of ChibiOS just like now and maintained to be really "portable", not designed with a specific MCU in mind.

The various platforms would be handled by "platform maintainers", persons who have stakes in a platform and are willing to maintain and enhance them with little to no supervision. Each platform would have its own maintainer(s), a dedicated forum, section on the wiki, a specific bug tracker category, demos, test code and release cycles. The platforms would be released as "plugins" over the base ChibiOS code and specifying the supported ChibiOS version(s).

Existing platforms without maintainers will go in "frozen" mode and not updated, basically just like now...

The license for the low level drivers probably will have to change too, I am thinking to go with BSD for that part. Copyright would be fully retained by the maintainers and the code would not be offered commercially, just "made available" at no cost and without any warranty thanks to the BSD license.

Giovanni

[Xamusk]

This actually looks quite fine. Specially the plugin system. This would actually enable more HAL stuff, like drivers for external peripherals.

Maybe this could even have some sort of dependency tree and package management integrated into ChibiStudio. This would allow, for example, selecting an accelerometer and automatically pulling the SPI, I2C or ADC drivers, according to the specific device. Have you looked at CooCox CoIDE? It actually already has something like it, though it only targets Cortex devices (due to the easy CMSIS HAL integration).

[Tectu]

Once again, it's very important that everything is still usable without any IDE at all. Making an RTOS only usable with it's own IDE dosen't sound right to me. Of course a plugin which helps configuring anything isn't a bad thing.


~ Tectu

[Xamusk]

That's why Giovanni says his IDE generates makefiles usable without an IDE.

[saraben]

Giovanni,
After playing with a more generic and portable HAL for the MSP430 over the last few days, I don't know how you keep up with STM32s even without anything else.

Just some thought from my experience.
The hal provides services to the operating system or upper level code, which is fairly straightforward. The hal is also in need of services from the upper level code which is not always so easy to pin down. The current hal uses at least debugging and stream services. The interface point for these services needs to be clearly defined.

In fact there are two interfaces, as the HAL code is to be OC portable, and platforms maintained separately.
OC > HAL
HAL > Platform

I am assuming, Giovanni, that you will still maintain the first.

Another related issue is the status of the PORTS code for ChibiOS. If the HAL is separeated it needs to be clear what is in PORTS and what in HAL.

One example of why this is important is the current code has system tick IRQ routines as follows.
os/ports/GCC/ARMCMx/...
os/ports/GCC/PPC/SPC563Mxx/...
os/hal/platforms/Posix/...
os/hal/platforms/SPC560BCxx
os/hal/platforms/SPC560Pxx
os/hal/platforms/Win32
boards/ for AVRs
boards/ for MSP430s
boards/ for LPCs
boards/ for SAM7s
boards/ for STM8s

I would think that the separation of the OS, HAL and platform code will cause quite a bit of upheval in the short term but in the long run will result in easier to maintain and port products, although there will be some penalties as some shortcuts will not be available.
I guess the most important is that the work can be spread around easier.

Regards
saraben

[Giovanni]

Hi,

You are right about the system tick, it is a bit random on the various architectures. My idea is to create a specific SysTick driver in the HAL that calls the kernel scheduler function.

About separating the HAL, I agree that it would be beneficial in the long term, tight now I am having an hard time maintaining the monolithic code base.

Things like queues management probably will become part of the portable HAL code, stream services are a bit more complicated because both the HAL and the Kernel require those, I am oriented in keeping the base streams in the Kernel because it is convenient for the test suite and things like chprintf().

Giovanni

[mabl]

Giovanni,

I'm too busy with exams these last weeks, but one comment:
With all your talk of splitting up ChibiOS and using Modules in this new eclipse interface - how are you going to structure the repository? I guess you will not plan on maintaining different copies of the code - this would be a maintenance nightmare. I'd strongly recommend you have a look at "git submodule" and keep each module in its own repo. This will also be the simplest solution for contributed stuff. I think this is also how mbed is doing it for example.

[saraben]

Giovanni,
Some results of investigating a portable HAL with a more generic msp430 implementation as test case.
Implementing a SysTick driver was fairly trivial. The HAL level code is virtually empty, it is all in the platform level code. I haven't considered tick less though.
Pal interface and the like are similarly straightforward.

I then came to serial, as for any serious development and testing a serial interface is normally essential.
So as you suggested I had a go at making queues a part of the HAL.
As a first effort I produced a simple version which has drawbacks from a lack of 2 attributes.

1. Delays: Implementation of Delays, Wait etc. are very operating system dependant. They need implementing in either the queue code, serial driver, or user thread code. Generally the lower down the more efficient.
2. Callbacks: Callbacks are required for low level driver actions associated with queues.

Without callbacks it is impossible to separate the queue driver from the platform driver and no queue delays requires upper lever changes.

So in the attached I have implemented delays and callbacks for a HAL queue driver similar to the ChibiOS queues, and added an operating system dependant "interface" implementation (e.g. chInterface.h, ch_functions.c, ch_functions.h). The queue is implemented in queue2.c and queue2.h. Note that "min" has been used for a prefix for the new queue parts to distinguish from present code. Also note that I need to review the Classes for the APIs as some of them are different in the new queue implementation.

The files are still a bit rough but do you think this approach sufficiently flexible and practical or is there a more elegant approach?
In reality there is probably no reason there cannot be a choice of HAL queue drivers once we defined the interface requirements.

I have tested it using ChibiOS and it appears to basically work. I am about to test it with Nil but should have a look at your recent updates first.
Regards
saraben

[Giovanni]

Hi,

Good work, I am seriously considering start working on a full "portable HAL" sooner rather than later, I like the idea.

Giovanni

[Tectu]

Portable HAL sounds like a lot of painful work...


~ Tectu