ChibiOS Free Embedded RTOS

Hello there,
EX code will be unstable for a couple of days. We are implementing multiple interfaces to solve some known issues.


Current Status:

• HTS221 -> Reworked on trunk, Backported to 18.2.x
• L3GD20 -> Reworked on trunk, Backported to 18.2.x
• LIS3DSH -> Reworked on trunk, Backported to 18.2.x
• LIS3MDL -> Reworked on trunk, Backported to 18.2.x
• LIS302DL -> Reworked on trunk, Backported to 18.2.x
• LPS25H -> Reworked on trunk, Backported to 18.2.x
• LSM6DS0 -> Reworked on trunk, Backported to 18.2.x
• LSM303DLHC -> Reworked on trunk, Backported to 18.2.x

The structure in the header files in EX are a little different from the structure in HAL.

One example is that of how the VMT is defined. In HAL you'll find this structure:



In EX, you've implemented this structure:



Can you make them consistent, one way or the other ?

Oh, while I was browsing, I noticed a minor typo in HTS221.h line 168: "Driver pre-thermoile time settings."
I'm guessing that should be "pre-compile" .

And on Line 85, I that thermo_sens looks wierd, maybe a decimal missing? It isn't used anywhere in the code ..
#define HTS221_THERMO_SENS 00015625f .

Thanks for reporting. Going to fix it.

I know they are not used. This because this sensor has certain internal registers which can be used to compute real sensitivity and bias. Defines represent the typical value : are there just to keep code pattern similar between all mems.

Note that ex drivers do not extend BaseSensor anymore so they could be different. An EX driver extends BaseObject and implements one ore more BaseSensor: this because most of them have to offer a multiple interface to sereveral kind of base sensors.

We could add a stub define in BaseSensors classes but it would be pointless: these classes have not specific methods.

LIS3MDL doesn't seem to fit pattern of other drivers. Shouldn't it expose a BaseCompass interface? I'm seeing things done in different ways, it's making it difficult to design other drivers and interfaces to be aligned with the OO-style Chibi has adopted..

There are now two ways to implement a driver:

1) Simply extending an existing class this requires no interfaces.
2) Extending a class and implementing multiple interfaces, used for devices that need to expose multiple aspects.

Are you referring to this?

Giovanni

faisal wrote:LIS3MDL doesn't seem to fit pattern of other drivers. Shouldn't it expose a BaseCompass interface? I'm seeing things done in different ways, it's making it difficult to design other drivers and interfaces to be aligned with the OO-style Chibi has adopted..

My bad, I reworked LIS3DSH not LIS3MDL (it was late last night ).

Check all the drivers which have been re-worked. Their pattern should be consistent between each other.

Reworked and backported to 18.2.x

You shouldn't have backported EX trunk to 18.2.x stable. The 18.2.x stable branch doesn't support the latest changes to the abstract classes (hal_objects..), and are incompatible with trunk. Please revert the changes so that the EX drivers are compatible with 18.2.x stable.

I have backported hal_objects and base peripherals. Update the repository.