[RFC] Ideas for ChibiOS/RT 3.0

[Giovanni]

OK, dropping support for small devices in ChibiOS/RT could become an option after creating this same support in NilRTOS. I am thinking to rename it to ChibiOS/NIL and make its API converge as much as possible, I am also thinking to make it entirely free, it also has educational potential because its simplicity.

The problem is that I couldn't support two distinct HALs, this is why I was thinking to an universal HAL usable with ChibiOS/RT and ChibiOS/NIL. This could become a non-problem if ChibiOS/NIL API becomes close enough to ChibiOS/RT.

Giovanni

[barthess]

Real time counter handling moved in the Kernel from the HAL.

Good idea, but I am not sure it can be easily "standardized" and abstracted. For example, in my current project
I need tons of data packages timestamped with uS since Unix epoch. The mS resolution
is good enough so I use virtual timer and int64 counter. It increases every tick and corrected
every PPS pulse from GPS receiver. If I would need uS resolution than I have no way except
using dedicated HW timer, probably without any abstraction layers to gain reasonable perfomance.

Also I vote to C++ migration. Macros based abstraction interfaces looks too "obscured".

[mabl]

Good idea, but I am not sure it can be easily "standardized" and abstracted. For example, in my current project
I need tons of data packages timestamped with uS since Unix epoch. The mS resolution
is good enough so I use virtual timer and int64 counter. It increases every tick and corrected
every PPS pulse from GPS receiver.

While I understand the need - isn't that a bit over-engineered? Let's say you have a good standard crystal with 30ppm accuracy. If you count by us, after one second the time will be off by over 30000us=30ms, wouldn't it? Or am I just horribly too tired to see my logical error?

[Freddie Chopin]

1ppm = 1/10000 %, but for this case it's just easier to calculate with 1 point per milion, so for 30ppm resonator after 1s the result can (but doesn't have to) be off by 30us. I can't imagine how you got to a number that says a precise clock crystal resonator has an error of 3%...

4\/3!!

[mabl]

Indeed, I was too tired. I was counting in nanoseconds... sorry for the noise.

[barthess]

mabl
I do not know how precise my crystal but 1mS error accumulates every 10-15 seconds.

[DeusExMachina]

In my humble opinion it is a good idea to take more efforts on ARM devices. I think that these powerful MCUs need more freedom and speed for communication. So, the ethernet part (lwip) and services (http server, tftp, smtp) is a good point of development.

[arsdmthe]

eheh 3.0 is very cool
missing only few thing to be as i want for tablets
posix layer should not go in the kernel i think
what about a linux driver adaptator ???

[rubenswerk]

[*]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.
[*]Multicore support.
[*]Standalone ChibiOS with bootloader. The HAL would be handled as a separate project.
[*]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.[/list]

I like those ideas, especially focusing on 32 bit platforms (I use the AVR quite often, but I avoid using an OS for these projects).

About the multicore support:
I think that for hobby projects, multicore platforms will be quite unusual in the next years. In my job (infotainment) we started to use multicores, and it was hard work for the OS colleagues to only configure a third party OS. I guess it's a lot of work for Giovanni, but not that much users within next 5 years.

[levrik]

Hi,
I found TLSF a very interesting Project. Perhaps this allocator could be added as a further option besides Memory-pools and heap-allocator.