Interesting, probably it could be also integrated in the current version as-is. The licenses look compatible so there should not be problems in that regard.
Thanks for all the ideas, keep them flowing.
Giovanni
[RFC] Ideas for ChibiOS/RT 3.0
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
Hi, few bits from me.
Moving HAL to C++ maybe not the best idea, though it's better than plain macros. The question is how you are going to use C++ in the drivers. If it's only to maintain a good structured design then you can do that in C as well. If you are talking about C++11(which is much better than the predecessors with lambdas, auto, etc.) then you should be confident that the target compiler supports all the features you want to use.
Anyway I completely agree that the HAL should be redesigned. Even if this means more overhead for some systems.
What is also important is to get rid of the GLOBAL driver instances. This is what I'm trying to do in MIPS32 port. I understand that some architectures support only once piece of particular HW but now it's not possible to use new SoC which has, say, one more SPI channel, without modifying the LLD.
Regarding the MMU -> not really sure this is smth one wants to see in RTOS. It's highly non-deterministic thing. In some cases when the CPU has only MMU but not MPU there's still a possibility to make a static mapping at boot time and forget. So my opinion is that MMU/MPU configuration should be defined by the board code in a static manner and should not be changed in time.
It was mentioned earlier that it would be great to have DMA driver in 3.0.
Currently I'm working(well, just started) on generic DMA driver and LLD for PIC32, so it might hit ChibiOs before 3.0.
Moving HAL to C++ maybe not the best idea, though it's better than plain macros. The question is how you are going to use C++ in the drivers. If it's only to maintain a good structured design then you can do that in C as well. If you are talking about C++11(which is much better than the predecessors with lambdas, auto, etc.) then you should be confident that the target compiler supports all the features you want to use.
Anyway I completely agree that the HAL should be redesigned. Even if this means more overhead for some systems.
What is also important is to get rid of the GLOBAL driver instances. This is what I'm trying to do in MIPS32 port. I understand that some architectures support only once piece of particular HW but now it's not possible to use new SoC which has, say, one more SPI channel, without modifying the LLD.
Regarding the MMU -> not really sure this is smth one wants to see in RTOS. It's highly non-deterministic thing. In some cases when the CPU has only MMU but not MPU there's still a possibility to make a static mapping at boot time and forget. So my opinion is that MMU/MPU configuration should be defined by the board code in a static manner and should not be changed in time.
It was mentioned earlier that it would be great to have DMA driver in 3.0.
Currently I'm working(well, just started) on generic DMA driver and LLD for PIC32, so it might hit ChibiOs before 3.0.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
Probably going C++ is premature.
Removing fixed instances is an interesting idea but I foresee two possible problems:
1) Non uniform memory layouts for peripherals. See AVR and similar, not necessarily the peripherals have a common layout, the headers are not even defined as structures.
2) System details like clock enabling/disabling, ISR numbers, DMA numbers would have to be encoded in the configuration structure, this would increase the burden on users.
The advantage would be that the driver would be much simpler, without all those switches and conditional paths.
The MMU is not an option but memory protection units could be interesting because inherent safety. MPUs should not introduce unpredictability. On CPUs like PPCs the MMU can be used very effectively as an MPU.
Giovanni
Removing fixed instances is an interesting idea but I foresee two possible problems:
1) Non uniform memory layouts for peripherals. See AVR and similar, not necessarily the peripherals have a common layout, the headers are not even defined as structures.
2) System details like clock enabling/disabling, ISR numbers, DMA numbers would have to be encoded in the configuration structure, this would increase the burden on users.
The advantage would be that the driver would be much simpler, without all those switches and conditional paths.
The MMU is not an option but memory protection units could be interesting because inherent safety. MPUs should not introduce unpredictability. On CPUs like PPCs the MMU can be used very effectively as an MPU.
Giovanni
Re: [RFC] Ideas for ChibiOS/RT 3.0
Giovanni, I completely understand that for some SoCs it's not straightforward to access HW with MMIO, though it's still possible. Otherwise there's no sense at all to declare driver's instance.
To identify the device you can use integral and do a switch in the driver to access the correct registers(a worst case). Or you can access the registers via the pointers and initialize them during object initialization:
And in this case lldInit should be called by the user, not by the hal itself. Now lldInit is initializes particular instance of the driver, not the whole thing. If for some reason it still required to call driver global init, the function may pass NULL as the driver instance.
This lld architecture eliminates hundreds of "#if defined(STM32_USE_UART1)' and friends.
I understand that it means higher overhead to access the registers but I believe this leads to a clear and maintainable architecture.
-- Dmytro
To identify the device you can use integral and do a switch in the driver to access the correct registers(a worst case). Or you can access the registers via the pointers and initialize them during object initialization:
Code: Select all
lldInit(...) {
switch (d->id) {
case 0:
d->cnf = &CNF0;
d->regx = ®X;
break;
.....
}
lldStart(...) {
*(d->cnf) |= 1<<HW_ENABLE;
}
}
And in this case lldInit should be called by the user, not by the hal itself. Now lldInit is initializes particular instance of the driver, not the whole thing. If for some reason it still required to call driver global init, the function may pass NULL as the driver instance.
This lld architecture eliminates hundreds of "#if defined(STM32_USE_UART1)' and friends.
I understand that it means higher overhead to access the registers but I believe this leads to a clear and maintainable architecture.
-- Dmytro
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
I think that eliminating all the switches and accessing the registers that way would make the code size explode, just look at how much code is excluded by disabling a peripheral using a switch in mcuconf.h.
All the code for all peripherals would always be present, the ISRs would always be "taken", a tradeoff I am not ready to do.
Giovanni
All the code for all peripherals would always be present, the ISRs would always be "taken", a tradeoff I am not ready to do.
Giovanni
Re: [RFC] Ideas for ChibiOS/RT 3.0
Maybe I turned this discussion into a wrong way mentioning the details. The problem I saw(IMHO) in the drivers that they are calling routines(or macros) from the upper layer. Like a call xxObjectInit from xxx_lld_init(which itself is called by xxxStart). This is smth wrong for me as this breaks the hierarchy. The user should call xxxObjectInit, not the LLD. And they do so (likely) because they _are_ the owners of the objects. At least they think so ... =). Again, IMHO, the low lever driver should not know anything about the high level object(how to init it, etc.). Also I saw(and I also did that because I had no choice) is that LLD define the structure of the high level object. Some HAL drivers do this in a different way(like serial driver): the HAL driver defines the object and the LLD can define private fields with a macro.Giovanni wrote:I think that eliminating all the switches and accessing the registers that way would make the code size explode, just look at how much code is excluded by disabling a peripheral using a switch in mcuconf.h.
All the code for all peripherals would always be present, the ISRs would always be "taken", a tradeoff I am not ready to do.
Giovanni
This can be indeed worked out with C++ and inheritance, but in this case the driver will have to allocate memory for the object(which is not the best solution for ChibiOs I guess) OR continue with global driver instances ...
Well, it's interesting to spend some time to think about the architecture that can feet the needs of the system and also be a good piece of SW design. With BIG systems you usually thing about the design first, then about the efficiency ...
Re: [RFC] Ideas for ChibiOS/RT 3.0
Just came to my mind that it'd be cool to have some configuration and build system.
Kconfig has fancy menuconfig but I believe it's very tied to *nix host. Maybe SCONS(or alternatives) would be a good option.
Anyhow we have to get rid of mcuconf.h, halconfig.h, etc.
Good to have a system where you can select options with a GUI but automatic configuration generation is the must for the project like chibios where you have numerous configuration.
It's very tough to update *config.h each time you add or remove an option. Ok, you can do that with sed or whatever but it very error-prone, no dependency-tracking, etc.
Kconfig has fancy menuconfig but I believe it's very tied to *nix host. Maybe SCONS(or alternatives) would be a good option.
Anyhow we have to get rid of mcuconf.h, halconfig.h, etc.
Good to have a system where you can select options with a GUI but automatic configuration generation is the must for the project like chibios where you have numerous configuration.
It's very tough to update *config.h each time you add or remove an option. Ok, you can do that with sed or whatever but it very error-prone, no dependency-tracking, etc.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [RFC] Ideas for ChibiOS/RT 3.0
Hi,
Have you tried SPC5Studio? it includes a graphic configuration tool and you don't need to mess with configuration files anymore. STM32F4/SPC5xx are supported right now.
Giovanni
Have you tried SPC5Studio? it includes a graphic configuration tool and you don't need to mess with configuration files anymore. STM32F4/SPC5xx are supported right now.
Giovanni
Re: [RFC] Ideas for ChibiOS/RT 3.0
Hi Giovanni, no I haven't. But I guess that is STM-specific.Giovanni wrote:Hi,
Have you tried SPC5Studio? it includes a graphic configuration tool and you don't need to mess with configuration files anymore. STM32F4/SPC5xx are supported right now.
Giovanni
I was talking about very generic system.
Re: [RFC] Ideas for ChibiOS/RT 3.0
- Standalone ChibiOS with bootloader. The HAL would be handled as a separate project.
This may currently be possible by adapting the BlackMagic Probe (main page,GitHub Repo) code.
Or perhaps strip away the relevant code from BMP to implement the ARM Debug Access Port (DAP), which is either a Serial Wire JTAG Debug Port (SWJ-DP) and the Serial Wire Debug Port (SW-DP).
Cortex M3 Debug - CoreSight - TRM
CoreSight DAP Lite
- Memory protection (MPU/MMU) support
Besides, the Linaro project seems to have the MMU-enabled stuff well covered.
- Data-flow abstraction interface
Cheers.
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 15 guests