Re: bme680 gas sensor channel attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 12 Feb 2019 08:53:46 -0800
David Frey <dpfrey@xxxxxxxxx> wrote:

> Hi,

Hi David,

Always fun to expand ABI :)
> 
> I would like to enhance the gas sensor support in the bme680 driver, but
> I'm not sure how to fit the enhancement into IIO.
> 
> The bme680 has the following registers:
> idac_heat_0 to 9 at 0x50..0x59 - initial current applied to heater
> res_heat_0 to 9 at 0x5A..0x63 - target temperature of heater
> gas_wait_0 to 9 at 0x64..0x6D - heater on duration
> 
> The ctrl_gas_1 register has an nb_conv<3:0> field which selects which of
> the settings (0 to 9) to use for the gas sensor.
> 
> Currently, the driver just hard codes some values into res_heat_0 and
> gas_wait_0.  idac_heat_0 is not written, but the datasheet says this is
> optional.  I think it would be good if the user could configure these
> parameters.  At a minimum it would be nice to expose one set of the
> three values, but if I'm going to expose one, it seems like I might as
> well expose all 10 and also allow the user to select which setting group
> is active.
> 
> The current version of the driver has this for the gas channel definition:
> {
> 	.type = IIO_RESISTANCE,
> 	.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> },
> 
> Other channels of the device (such as temperature) support an
> oversampling ratio, and are defined like this:
> 
> {
> 	.type = IIO_TEMP,
> 	.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
> 			      BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),
> },
> 
> I checked enum iio_chan_info_enum and there is no IIO_CHAN_INFO_
> definition which seems applicable to "initial current", "target
> temperature" or "heater duration".  How can I add these configuration
> parameters in an idiomatic way?
I'll be honest, these are pretty device specific, and unlikely to
be of interest to any in kernel users.  As such use the
extended attribute infrastructure to define some custom attributes
for them.  First step though is probably to document the ABI so
we can discuss how it first into the wider ABI (should still be
consistent as we can make it).

We have previously dealt with heaters via explicit output channels
(they are common in humidity sensors) but that probably only gives you
a base to work from given they still won't have the right attributes.

Jonathan

> 
> Thanks,
> David




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux