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
[RFC] Ideas for ChibiOS/RT 3.0
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
Giovanni wrote: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".
-
- Posts: 417
- Joined: Tue Dec 21, 2010 10:19 am
- Location: Karlsruhe, Germany
- Been thanked: 1 time
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
barthess wrote: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?
-
- Posts: 36
- Joined: Wed Oct 17, 2012 8:57 am
Re: [RFC] Ideas for ChibiOS/RT 3.0
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!!
4\/3!!
-
- Posts: 417
- Joined: Tue Dec 21, 2010 10:19 am
- Location: Karlsruhe, Germany
- Been thanked: 1 time
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
Indeed, I was too tired. I was counting in nanoseconds... sorry for the noise.
Re: [RFC] Ideas for ChibiOS/RT 3.0
mabl
I do not know how precise my crystal but 1mS error accumulates every 10-15 seconds.
I do not know how precise my crystal but 1mS error accumulates every 10-15 seconds.
- DeusExMachina
- Posts: 223
- Joined: Tue Apr 03, 2012 5:08 am
- Location: South Korea
- Has thanked: 3 times
- Been thanked: 3 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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.
Re: [RFC] Ideas for ChibiOS/RT 3.0
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 ???
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 ???
-
- Posts: 104
- Joined: Wed Feb 22, 2012 11:39 am
- Location: Austria
Re: [RFC] Ideas for ChibiOS/RT 3.0
Giovanni wrote:[*]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.
Re: [RFC] Ideas for ChibiOS/RT 3.0
Hi,
I found TLSF a very interesting Project. Perhaps this allocator could be added as a further option besides Memory-pools and heap-allocator.
I found TLSF a very interesting Project. Perhaps this allocator could be added as a further option besides Memory-pools and heap-allocator.
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 47 guests