drivers: Existing sensor drivers that are working for a couple of sensors

[gschorcht]

Description

How do we deal with sensors for which there is no specific sensor driver but that are working with an existing sensor driver? Examples:

• MPU9250 is working with MPU9150 driver
• SHT21 is working with HTU21D driver
• LSM9DS1 magnetometer part is working with LIS3MDL driver since LSM9DS1 = LSM6DS0 + LIS3MDL
• LSM9DS0 gyro and accelerometer parts are working with L3GD20H driver since LSM9DS0 = LSM303 + L3GD20H

For a user, it is not obvious from the driver names for these examples that they also work for the other sensors.

From my point of view, possible approaches would be:

• Document for which sensors the driver is also working. Not easy to figure out for the user since doxygen includes only symbols in the search index.
• Implement a complete new driver. Makes probably no sense due to code duplication.
• Rename the driver, e.g., mpu9150 renamed to mpu9x59. This might produce compatibility issues for applications that already used the driver.
• Realize a wrapper around the existing driver.

The realization of a wrapper seems to be a feasible approach. Such a wrapper would only consist of

• a driver include file drivers/include/<driver>.h
• a driver parameters file drivers/<driver>/include/<driver>_params.h

The driver include file drivers/include/<driver>.h would include the wrapped driver header file and rename symbols that are visible for the application, for example drivers/include/mpu9250.h

#include "mpu9150.h"

#define MPU9250_DEFAULT_SAMPLE_RATE     MPU9150_DEFAULT_SAMPLE_RATE
...
#define mpu9250_t           mpu9150_t
#define mpu9250_params_t    mpu9150_params_t
...

The driver parameters file drivers/<driver>/include/<driver>_params.h would include the wrapped driver paremeters file and rename symbol names that are visible for the application, for example

#include "mpu9150_params.h"

#define mpu9250_params   mpu9150_params

Then the application could use the wrapper as a driver.

#include "mpu9250.h"
#include "mpu9250_params.h"
...
mpu9250_init(&dev, &mpu9250_params);
...

In that way also sensors could be supported that are combinations of other sensors like LSM9DS1.

[olegart]

Wrapper is the best option.

• Document for which sensors the driver is also working. Not easy to figure out for the user since doxygen includes only symbols in the search index.

No, people are looking for the drivers that support their chip, not for the chips supported by the driver, so at first glance they decide chip is not supported at all if there's no driver with a similar name.

• Implement a complete new driver. Makes probably no sense due to code duplication.

Yes.

• Rename the driver, e.g., mpu9150 renamed to mpu9x59. This might produce compatibility issues for applications that already used the driver.

Will become a mess someday, something like "mpxx5050" that should mean both "MPX5050" and "MPXV5050". Also, impossible with ST sensors (I think their engineers are strictly forbidden to communicate with each other, there's no other reasonable explanation for their chips' naming and specs differences).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[gschorcht]

@aabadie @haukepetersen @smlng They have also developed many drivers. Before I close this issue, I would like to know what you think is the best approach to use an existing driver for other sensors.

[aabadie]

After reading the description, I like the wrapper option.

There's also an old PR from @gebart that introduced a generic sensor module, see #9075. It might also be interesting.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.