RIOT
RIOT copied to clipboard
drivers: htu21d relative humidity and temperature sensor driver
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 whiledrivers/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
anddrivers/htu21d/include/htu21d_params.h
which just redefine symbols with prefixhtu21d_
, 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=...
@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
, andsht21
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.
@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.
I'm in the middle of a moving, so I won't be able to test this soon.
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.
PR is waiting for review.
Needs rebase
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.
Please rebase. There are also some pending review comments.
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.
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.
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.
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.