VMT interface between upper and lower level HAL

Discussions and support about ChibiOS/HAL, the MCU Hardware Abstraction Layer.
faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

VMT interface between upper and lower level HAL

Postby faisal » Thu Apr 04, 2019 5:52 pm

I'm currently working on creating a driver for an external SPI to CAN device. I would like to use the hal_can abstraction, but the way HAL is currently designed is that it is directly linked to the hal_<device>_lld functions. I would like to use the HAL to be more than just bound to MCU built-in peripherals, and instead (or optionally extended?) to be able to use a virtual method table interface with the low level driver.

Calling LLD functions thru the VMT incurs extra redirection overhead which wouldn't always be desirable, so perhaps such an interface could be a compile time option?

Good candidates for this type of interface would be ADC, DAC, CAN, MAC, RTC. Those are commonly used external peripherals, which would be really cool if they could use the HAL API.

User avatar
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: VMT interface between upper and lower level HAL

Postby Giovanni » Thu Apr 04, 2019 6:12 pm

Perhaps HAL should go full C++ but I don't know if the world is ready for this :)

Giovanni

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: VMT interface between upper and lower level HAL

Postby faisal » Thu Apr 04, 2019 6:23 pm

Giovanni wrote:Perhaps HAL should go full C++ but I don't know if the world is ready for this :)

Giovanni


Definitely not ready yet :) ...

I'm guessing the VMT should just be part of the driver object. In hal_<device>.c, calls to LLD could be done thru a macro - which either uses the hal_<device>_lld calls directly, or uses the VMT as part of the driver object - based on a #define configuration .. That would make it relatively clean, without having a bazillion #ifdefs everywhere ..

electronic_eel
Posts: 77
Joined: Sat Mar 19, 2016 8:07 pm
Been thanked: 17 times

Re: VMT interface between upper and lower level HAL

Postby electronic_eel » Thu Apr 04, 2019 8:06 pm

faisal wrote:Good candidates for this type of interface would be ADC, DAC, CAN, MAC, RTC. Those are commonly used external peripherals, which would be really cool if they could use the HAL API.

Don't forget GPIO. IO extenders are a very common thing.

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: VMT interface between upper and lower level HAL

Postby faisal » Tue Apr 09, 2019 6:00 pm

So, what do you think - should we make something like a BaseCanLLD (following the style of the other single inheritance Base* 'classes') which hal_can would then use?

User avatar
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: VMT interface between upper and lower level HAL

Postby Giovanni » Wed Apr 10, 2019 7:40 am

It is not so simple, in the current model the relationship between HLD and LLD is bidirectional, the LLD exports interfaces to the HLD and the HLD exports interfaces to the LLD.

A fully OO approach would require the HLD to be a generic base class and the LLD to extend it. It is not something that can be easily implemented in the current HAL, this is why I suggested it should be redesigned using C++ (a very very strict subset of). This is something I would like to experiment with.

Another point, using VMTs is not the most efficient approach, not every method needs to be virtual, most HLD/base methods would just be abstract but not virtual.

Giovanni

User avatar
alex31
Posts: 374
Joined: Fri May 25, 2012 10:23 am
Location: toulouse, france
Has thanked: 38 times
Been thanked: 61 times
Contact:

Re: VMT interface between upper and lower level HAL

Postby alex31 » Wed Apr 10, 2019 10:27 am

Hi,

Giovanni wrote:This is why I suggested it should be redesigned using C++ (a very very strict subset of).
Giovanni


I think this is a good idea, embedded C++ help to write code with more abstraction, more compile time checking, often with zero cost overhead, and sometime with negative overhead (in optimized mode, compiler can often deduce virtual function and avoid the indirection).

The problem will be what goes to the "strict subset of" :-) ?

Perhaps we should write a list of c++ features with pro and cons ?

° template (better type checking, avoid cast, but difficult to write)
° constexpr function (compile time function, permit to calculate data stored in flash, but need a recent compiler)
° subset of STL (like std::array) : permit to pass data and compile time known size in one argument to function
etc ...

It's a difficult decision, I still wrote low level (driver) code in C, to be language agnostic (students often don't learn C++), and applications in C++17, avoiding RTTI, exception, and dynamic memory allocation.

Alexandre

User avatar
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: VMT interface between upper and lower level HAL

Postby Giovanni » Wed Apr 10, 2019 1:21 pm

Well, it would be at least:
- No exceptions.
- No STL.
- No runtime type checks.
- No dynamic anything.

I have no problems with templates, those could be useful for some drivers. Imagine streams of not just bytes. I would also avoid the mental contortions of the latest C++ versions, a very basic usage.

In addition we would have to find a way for the C++ derived LLD classes to use/wrap existing C LLDs, this way both a C HAL and C++ HAL could be maintained.

An experiment could be done using one or two drivers, just to find all the problems with the approach.

Giovanni

electronic_eel
Posts: 77
Joined: Sat Mar 19, 2016 8:07 pm
Been thanked: 17 times

Re: VMT interface between upper and lower level HAL

Postby electronic_eel » Wed Apr 10, 2019 7:01 pm

Giovanni wrote:- No dynamic anything.

Do you want to allow or forbid virtual functions?

Let's say you have a controller with one internal CAN interface, but you need 2 for your application. So you add an external one via SPI. Without virtual functions, you couldn't use something like a generic SendMessage(CanInterface *) function for both interfaces. So I think the usefulness of this concept is severely reduced when you forbid virtual functions.

But on the other hand virtual functions add runtime and memory costs. So they should be enabled in a project only if you really have different types of interfaces implementing one base class. I don't think there is a way in C++ to automatically detect and handle this. Maybe add some #define-options if one class should use virtuals or not?

Giovanni wrote:An experiment could be done using one or two drivers, just to find all the problems with the approach.

Sounds like a good idea to me.

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: VMT interface between upper and lower level HAL

Postby faisal » Wed Apr 10, 2019 7:06 pm

I'm working on a CAN driver for the MCP2515, making it look like a standard hal_can_lld . When I get that working, I'll play with some ideas we're talking about here. Now let's see who gets some code out there first lol :).


Return to “ChibiOS/HAL”

Who is online

Users browsing this forum: No registered users and 16 guests