drivers: htu21d relative humidity and temperature sensor driver

[gschorcht]

Contribution description

This PR adds a driver for the TE Connectivity HTU21D humidity and temperature sensor. The driver could also be used with Sensirion SHT21 and with SI7021.

The sensor only supports single measurements and polling. This driver provides also drivers/saul capabilities.

Please note: Even though the HTU21D driver also works with SI7021 sensor for which drivers/si70xx already exists, there are the following differences:

• drivers/si70xx checks some registers during intialization that do no exist in HTU21D sensor (heater control register and revision registers).
• drivers/si70xx uses clock stretching which blocks the bus and the master during the measurement which can take up to 85 ms. drivers/htu21d does not use clock stretching to avoid this blocking.
• drivers/si70xx does not implement the CRC check while drivers/htu21d implement and use it.

As an alternative, I could provide a PR that

• defines a pseudomodule for HTU21D,
• modifies drivers/si70xx so that it would also work also with HTU21D,
• includes wrapper files drivers/include/htu21d.h and drivers/htu21d/include/htu21d_params.h which just redefine symbols with prefix htu21d_, and
• includes a tests/driver_htu21d as test application.

I have it already realized also in that way and could provide it. The same could be done for SHT21. But please keep in mind that a pseudo/wrapper module would use drivers/si70xx which blocks the bus and the master while waiting for measurement results.

Testing procedure

USEMODULE=htu21d make flash -C tests/saul BOARD=...

[maribu]

@gschorcht: I could review this PR, but I don't have the hardware to test it. Should I still review? @basilfx: Maybe you could get involved as author of the si70xx.

To me the advantage of not using clock stretching to allow using multiple I2C device on the same bus is obvious. Is there any technical argument to not use this approach in the si70xx? If not, I personally would favor a unified driver for all devices that would work in a non-blocking fashion, unless one of the following would result:

• The resulting unified driver would be bigger than two separate drivers
• The resulting driver would perform significantly poorer (e.g. regarding performance, features, ROM size) than each of the two separate driver
• The resulting driver would be harder to maintain than two separate drivers (e.g. code gets way more complex)
• Simultaneous use of si70xx, htu21d, and sht21 devices would not be possible by one unified driver, but it would be by separate drivers.

Note: I did not look yet into either this code or the si70xx drivers. So maybe the above questions are obvious.

[gschorcht]

@maribu Thanks for your offer to review the driver. We should wait some more time for an answer from @basilfx. Once he has answered we can decide whether to redesign the si70xx or to continue with the separate driver.

[basilfx]

I'm in the middle of a moving, so I won't be able to test this soon.

[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]

PR is waiting for review.

[aabadie]

Needs rebase

[maribu]

This PR adds a driver for the TE Connectivity HTU21D humidity and temperature sensor. The driver could also be used with Sensirion SHT21 and with SI7021.

Could this replace the sth2x and the si70xx driver? If so, I really would love to have less code to maintain to provide the same features.

This would also be greatly beneficial in case someone (for whatever reason) connects a bunch of temperature+humidity sensors of the various flavors, as with the single driver only ROM space for one implementation would be needed.

[aabadie]

Please rebase. There are also some pending review comments.

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

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

[mguetschow]

Since this PR has been stale for several years, I'll convert it to a draft.

Please feel free to remove the draft state if anyone wants to pick this up again.