The application may want to know the configured mode without inspecting
Kconfig macros; this is important for proper management of BASELINE
which is mode-dependent.
It also may need to know the version of the hardware and firmware, as
the behavior of application firmware 2.0 is significantly better than
version 1.1.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
This mode is documented as producing a raw result every 250 ms that the
application must convert to eCO2 and eTVOC readings. In practice
application firmware 2.0 appears to convert the readings as with all
other rates.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Expose the entire content of the ALG_RESULT_DATA block to the
application, primarily so the status and error flags can be seen. With
those available the application has the ability to detect that a stale
result has been provided so sensor_fetch_sample() can return -EAGAIN in
this case instead of -EIO, and it doesn't need to block which is
annoying.
This should also make the sensor usable on older Nordic Thingy:52
devices with outdated CCS811 application firmware that doesn't properly
implement the DATA_READY bit.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Accurate estimate of gas presence requires temperature and humidity
data. Add API to update these values.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Proper use of the CCS811 requires maintenance of the BASELINE
register value measured in clean air at various points in the sensor
life cycle. The sensor driver abstraction has no facility to support
this, so add an application header with functions to fetch and update
the register value.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
