[RFC] Ideas for ChibiOS/RT 3.0

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
User avatar
Giovanni
Site Admin
Posts: 13133
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 770 times
Been thanked: 653 times
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Giovanni » Thu Jan 31, 2013 1:46 pm

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

Dmytro
Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Dmytro » Mon Feb 25, 2013 12:21 am

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.

User avatar
Giovanni
Site Admin
Posts: 13133
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 770 times
Been thanked: 653 times
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Giovanni » Mon Feb 25, 2013 9:34 am

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

Dmytro
Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Dmytro » Mon Feb 25, 2013 1:19 pm

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:

Code: Select all

lldInit(...) {
 switch (d->id) {
   case 0:
      d->cnf = &CNF0;
      d->regx = &REGX;
      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

User avatar
Giovanni
Site Admin
Posts: 13133
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 770 times
Been thanked: 653 times
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Giovanni » Mon Feb 25, 2013 2:47 pm

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

Dmytro
Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Dmytro » Mon Feb 25, 2013 10:28 pm

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
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.
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 ...

Dmytro
Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Dmytro » Thu Mar 14, 2013 12:29 am

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.

User avatar
Giovanni
Site Admin
Posts: 13133
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 770 times
Been thanked: 653 times
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Giovanni » Thu Mar 14, 2013 8:35 am

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

Dmytro
Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Dmytro » Thu Mar 14, 2013 8:55 am

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
Hi Giovanni, no I haven't. But I guess that is STM-specific.
I was talking about very generic system.

inca
Posts: 37
Joined: Mon Apr 22, 2013 12:08 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby inca » Tue Apr 23, 2013 1:24 am

  • Standalone ChibiOS with bootloader. The HAL would be handled as a separate project.
I would like to see interactive development over the programming/debugging interface. For instance, over USB CDC serial interface, one might use the ChibiOS command line shell to deploy binary programs or scripted peripheral functionality while the kernel could be configured to manage traces, core dumps, and debugging.

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
I would avoid the MMU, if possible. I am a fan of the Burroughs B5000 architecture, which I heard did quite well without the MMU. It is a data-driven architecture and influence a bunch of classic designs, such as the 68k.

Besides, the Linaro project seems to have the MMU-enabled stuff well covered.

  • Data-flow abstraction interface
With the end goal of a gui IDE, such as LabVIEW, around a data-flow language, such as VHDL. The data flows over wires, just like in the hardware. The ability to grasp this model and mode of development empowers users to create what they need by defining what they want in terms which inherently exist: the physical design of the board, the peripherals, the wired interconnects, and so on.

Cheers.


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 4 guests