zephyr/drivers/sensor/bme280
Paul Sokolovsky b7623a85b0 sensors: Redefine SENSOR_CHAN_HUMIDITY in percents, not milli-percents.
Based on the discussion in #5693, the reason why humidity was defined
in milli-percent was likely following Linux which defines it as such
in its sensor subsystem:
http://elixir.free-electrons.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-iio#L263

However, Linux defines temperature in milli-degrees either, but
Zephyr uses degrees (similarly for most other quantities). Typical
sensor resolution/precision for humidity is also on the order of 1%.

One of the existing drivers, th02.c, already returned values in
percents, and few apps showed it without conversion and/or units,
leading to confusing output to user like "54500".

So, switching units to percents, and update all the drivers and
sample apps.

For few drivers, there was also optimized conversion arithmetics
to avoid u64_t operations. (There're probably more places to
optimize it, and temperature conversion could use such optimization
too, but that's left for another patch.)

Fixes: #5693

Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2018-02-05 14:10:39 +01:00
..
CMakeLists.txt Introduce cmake-based rewrite of KBuild 2017-11-08 20:00:22 -05:00
Kconfig drivers: sensor: clean up Kconfig files 2017-09-21 15:47:58 -04:00
bme280.c sensors: Redefine SENSOR_CHAN_HUMIDITY in percents, not milli-percents. 2018-02-05 14:10:39 +01:00
bme280.h drivers: convert to using newly introduced integer sized types 2017-04-21 10:06:48 -05:00