From: Vasileios Amoiridis <vassilisamir@gmail.com>
Remove the ambient temperature from being a macro and implement it as
an attribute. This way, it is possible to dynamically configure the
ambient temperature of the environment to improve the accuracy of the
measurements.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
---
drivers/iio/chemical/bme680.h | 1 -
drivers/iio/chemical/bme680_core.c | 35 +++++++++++++++++++++++++++++-
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h
index e9e3e08fa366..95d39c154d59 100644
--- a/drivers/iio/chemical/bme680.h
+++ b/drivers/iio/chemical/bme680.h
@@ -45,7 +45,6 @@
#define BME680_REG_RES_HEAT_0 0x5A
#define BME680_REG_GAS_WAIT_0 0x64
#define BME680_ADC_GAS_RES GENMASK(15, 6)
-#define BME680_AMB_TEMP 25
#define BME680_REG_CTRL_GAS_1 0x71
#define BME680_RUN_GAS_MASK BIT(4)
diff --git a/drivers/iio/chemical/bme680_core.c b/drivers/iio/chemical/bme680_core.c
index 5fd5740bb7fe..0979c8f0afcf 100644
--- a/drivers/iio/chemical/bme680_core.c
+++ b/drivers/iio/chemical/bme680_core.c
@@ -120,6 +120,7 @@ struct bme680_data {
u16 heater_temp;
struct regulator_bulk_data supplies[BME680_NUM_SUPPLIES];
+ int ambient_temp;
union {
u8 buf[3];
@@ -483,7 +484,7 @@ static u8 bme680_calc_heater_res(struct bme680_data *data, u16 temp)
if (temp > 400) /* Cap temperature */
temp = 400;
- var1 = (((s32)BME680_AMB_TEMP * calib->par_gh3) / 1000) * 256;
+ var1 = (((s32)data->ambient_temp * calib->par_gh3) / 1000) * 256;
var2 = (calib->par_gh1 + 784) * (((((calib->par_gh2 + 154009) *
temp * 5) / 100)
+ 3276800) / 10);
@@ -878,6 +879,37 @@ static int bme680_write_raw(struct iio_dev *indio_dev,
return ret;
}
+static ssize_t ambient_temp_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct bme680_data *data = iio_priv(indio_dev);
+ int vals[2];
+
+ vals[0] = data->ambient_temp;
+ vals[1] = 1;
+
+ return iio_format_value(buf, IIO_VAL_INT, 1, vals);
+}
+
+static ssize_t ambient_temp_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct bme680_data *data = iio_priv(indio_dev);
+ int ret, val_int, val_fract;
+
+ ret = iio_str_to_fixpoint(buf, 1, &val_int, &val_fract);
+ if (ret)
+ return ret;
+
+ data->ambient_temp = val_int;
+ return len;
+}
+
+static IIO_DEVICE_ATTR_RW(ambient_temp, 0);
+
static const char bme680_oversampling_ratio_show[] = "1 2 4 8 16";
static IIO_CONST_ATTR(oversampling_ratio_available,
@@ -885,6 +917,7 @@ static IIO_CONST_ATTR(oversampling_ratio_available,
static struct attribute *bme680_attributes[] = {
&iio_const_attr_oversampling_ratio_available.dev_attr.attr,
+ &iio_dev_attr_ambient_temp.dev_attr.attr,
NULL,
};
--
2.43.0On Thu, 10 Oct 2024 23:00:26 +0200 vamoirid <vassilisamir@gmail.com> wrote: > From: Vasileios Amoiridis <vassilisamir@gmail.com> > > Remove the ambient temperature from being a macro and implement it as > an attribute. This way, it is possible to dynamically configure the > ambient temperature of the environment to improve the accuracy of the > measurements. > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> New ABI? Would need docs. However, I 'think' we have a few cases where we handle this via the slightly odd interface of out_temp_processed / _raw with a label saying it's ambient temperature. The tenuous argument is that we have heaters that actually control the temperature and the affect of either heating the thing or just happening to know the external temperature ends up being the same. Hence use an output channel for this control. Jonathan
On Sat, Oct 12, 2024 at 01:01:24PM +0100, Jonathan Cameron wrote: > On Thu, 10 Oct 2024 23:00:26 +0200 > vamoirid <vassilisamir@gmail.com> wrote: > > > From: Vasileios Amoiridis <vassilisamir@gmail.com> > > > > Remove the ambient temperature from being a macro and implement it as > > an attribute. This way, it is possible to dynamically configure the > > ambient temperature of the environment to improve the accuracy of the > > measurements. > > > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> > New ABI? Would need docs. > > However, I 'think' we have a few cases where we handle this via the slightly > odd interface of out_temp_processed / _raw with a label saying it's > ambient temperature. > > The tenuous argument is that we have heaters that actually control the > temperature and the affect of either heating the thing or just happening > to know the external temperature ends up being the same. Hence use > an output channel for this control. > > Jonathan Hi Jonathan, Thanks for taking the time to review this. I saw your previous messages, and I am not responding to all of them so as to not flood you with ACK messages. For this one though I have to ask. The last commit of this series is adding support for an output current channel that controls the current that is being inserted into an internal plate that is heated up in order to have more precise acquisition of humidity and gas measurement. Does it makes sense to add an ambient temp output channel as well? Cheers, Vasilis
On Mon, 14 Oct 2024 22:14:23 +0200 Vasileios Amoiridis <vassilisamir@gmail.com> wrote: > On Sat, Oct 12, 2024 at 01:01:24PM +0100, Jonathan Cameron wrote: > > On Thu, 10 Oct 2024 23:00:26 +0200 > > vamoirid <vassilisamir@gmail.com> wrote: > > > > > From: Vasileios Amoiridis <vassilisamir@gmail.com> > > > > > > Remove the ambient temperature from being a macro and implement it as > > > an attribute. This way, it is possible to dynamically configure the > > > ambient temperature of the environment to improve the accuracy of the > > > measurements. > > > > > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> > > New ABI? Would need docs. > > > > However, I 'think' we have a few cases where we handle this via the slightly > > odd interface of out_temp_processed / _raw with a label saying it's > > ambient temperature. > > > > The tenuous argument is that we have heaters that actually control the > > temperature and the affect of either heating the thing or just happening > > to know the external temperature ends up being the same. Hence use > > an output channel for this control. > > > > Jonathan > > Hi Jonathan, > > Thanks for taking the time to review this. I saw your previous messages, > and I am not responding to all of them so as to not flood you with ACK > messages. > > For this one though I have to ask. The last commit of this series is > adding support for an output current channel that controls the current > that is being inserted into an internal plate that is heated up in order > to have more precise acquisition of humidity and gas measurement. Does > it makes sense to add an ambient temp output channel as well? If we need to know that temperature to calculate the meaning of the pressure channels then I think it does. I am a little confused though as this device measures the temperature. Why isn't that the right value to use? Is that because the heater is confusing things? > > Cheers, > Vasilis >
On Sat, Oct 19, 2024 at 02:59:25PM +0100, Jonathan Cameron wrote:
> On Mon, 14 Oct 2024 22:14:23 +0200
> Vasileios Amoiridis <vassilisamir@gmail.com> wrote:
>
> > On Sat, Oct 12, 2024 at 01:01:24PM +0100, Jonathan Cameron wrote:
> > > On Thu, 10 Oct 2024 23:00:26 +0200
> > > vamoirid <vassilisamir@gmail.com> wrote:
> > >
> > > > From: Vasileios Amoiridis <vassilisamir@gmail.com>
> > > >
> > > > Remove the ambient temperature from being a macro and implement it as
> > > > an attribute. This way, it is possible to dynamically configure the
> > > > ambient temperature of the environment to improve the accuracy of the
> > > > measurements.
> > > >
> > > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
> > > New ABI? Would need docs.
> > >
> > > However, I 'think' we have a few cases where we handle this via the slightly
> > > odd interface of out_temp_processed / _raw with a label saying it's
> > > ambient temperature.
> > >
> > > The tenuous argument is that we have heaters that actually control the
> > > temperature and the affect of either heating the thing or just happening
> > > to know the external temperature ends up being the same. Hence use
> > > an output channel for this control.
> > >
> > > Jonathan
> >
> > Hi Jonathan,
> >
> > Thanks for taking the time to review this. I saw your previous messages,
> > and I am not responding to all of them so as to not flood you with ACK
> > messages.
> >
> > For this one though I have to ask. The last commit of this series is
> > adding support for an output current channel that controls the current
> > that is being inserted into an internal plate that is heated up in order
> > to have more precise acquisition of humidity and gas measurement. Does
> > it makes sense to add an ambient temp output channel as well?
>
> If we need to know that temperature to calculate the meaning of the pressure
> channels then I think it does.
>
> I am a little confused though as this device measures the temperature.
> Why isn't that the right value to use? Is that because the heater
> is confusing things?
>
>
Hi Jonathan,
Thank you very much for your message! So, I digged a bit more into the
device datasheet and I found out that the ambient temperature can
actually be taken directly from the measured temperature (p.22 of [1]),
I can use this one. This means, that the ambient temp can be fully
dropped since the temperature of the sensor is the information we need.
Is it ok to drop it fully since it is an ABI change? If not how should I
approach this?
Another thing that I had missed because of the way the code was written
is that actually we can (and should) use output channel for setting the
temperature of the internal heater plate. This sensor essentially has an
internal heater plate that allows it to measure the VOC. Currently if
you check the driver [2], the value of the requested temperature of the
heater is set only once in the probe function and stays all the time
like this. This doesn't allow for much flexibility. But it is something
that I will do in another series and not this one, since this one is
already quite heavy.
Cheers,
Vasilis
PS: I don't understand why Bosch designed the sensor in this way. Since
the value of the ambient temp can be either hardcoded or the actual
value of the temperature sensor, they could have had all this logic in
hardware. They could actually even implement the compensation functions
in hardware and just return RAW values to us. It's kind of the same
situation with the BME280 and BMP{1,2,3,5}80 drivers that we have.
[1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf
[2]: https://elixir.bootlin.com/linux/v6.11.4/source/drivers/iio/chemical/bme680_core.c#L989
> >
> > Cheers,
> > Vasilis
> >
>
On Sat, Oct 19, 2024 at 07:51:32PM +0200, Vasileios Amoiridis wrote:
> On Sat, Oct 19, 2024 at 02:59:25PM +0100, Jonathan Cameron wrote:
> > On Mon, 14 Oct 2024 22:14:23 +0200
> > Vasileios Amoiridis <vassilisamir@gmail.com> wrote:
> >
> > > On Sat, Oct 12, 2024 at 01:01:24PM +0100, Jonathan Cameron wrote:
> > > > On Thu, 10 Oct 2024 23:00:26 +0200
> > > > vamoirid <vassilisamir@gmail.com> wrote:
> > > >
> > > > > From: Vasileios Amoiridis <vassilisamir@gmail.com>
> > > > >
> > > > > Remove the ambient temperature from being a macro and implement it as
> > > > > an attribute. This way, it is possible to dynamically configure the
> > > > > ambient temperature of the environment to improve the accuracy of the
> > > > > measurements.
> > > > >
> > > > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
> > > > New ABI? Would need docs.
> > > >
> > > > However, I 'think' we have a few cases where we handle this via the slightly
> > > > odd interface of out_temp_processed / _raw with a label saying it's
> > > > ambient temperature.
> > > >
> > > > The tenuous argument is that we have heaters that actually control the
> > > > temperature and the affect of either heating the thing or just happening
> > > > to know the external temperature ends up being the same. Hence use
> > > > an output channel for this control.
> > > >
> > > > Jonathan
> > >
> > > Hi Jonathan,
> > >
> > > Thanks for taking the time to review this. I saw your previous messages,
> > > and I am not responding to all of them so as to not flood you with ACK
> > > messages.
> > >
> > > For this one though I have to ask. The last commit of this series is
> > > adding support for an output current channel that controls the current
> > > that is being inserted into an internal plate that is heated up in order
> > > to have more precise acquisition of humidity and gas measurement. Does
> > > it makes sense to add an ambient temp output channel as well?
> >
> > If we need to know that temperature to calculate the meaning of the pressure
> > channels then I think it does.
> >
> > I am a little confused though as this device measures the temperature.
> > Why isn't that the right value to use? Is that because the heater
> > is confusing things?
> >
> >
>
> Hi Jonathan,
>
> Thank you very much for your message! So, I digged a bit more into the
> device datasheet and I found out that the ambient temperature can
> actually be taken directly from the measured temperature (p.22 of [1]),
> I can use this one. This means, that the ambient temp can be fully
> dropped since the temperature of the sensor is the information we need.
> Is it ok to drop it fully since it is an ABI change? If not how should I
> approach this?
>
Actually in the end, no ABI change because the temperature will be
taken from the internal measurement so nothing that has to do with
userspace so there is no ABI change here, my mistake!
Vasilis
> Another thing that I had missed because of the way the code was written
> is that actually we can (and should) use output channel for setting the
> temperature of the internal heater plate. This sensor essentially has an
> internal heater plate that allows it to measure the VOC. Currently if
> you check the driver [2], the value of the requested temperature of the
> heater is set only once in the probe function and stays all the time
> like this. This doesn't allow for much flexibility. But it is something
> that I will do in another series and not this one, since this one is
> already quite heavy.
>
> Cheers,
> Vasilis
>
> PS: I don't understand why Bosch designed the sensor in this way. Since
> the value of the ambient temp can be either hardcoded or the actual
> value of the temperature sensor, they could have had all this logic in
> hardware. They could actually even implement the compensation functions
> in hardware and just return RAW values to us. It's kind of the same
> situation with the BME280 and BMP{1,2,3,5}80 drivers that we have.
>
> [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf
> [2]: https://elixir.bootlin.com/linux/v6.11.4/source/drivers/iio/chemical/bme680_core.c#L989
> > >
> > > Cheers,
> > > Vasilis
> > >
> >
On Thu, Oct 10, 2024 at 11:00:26PM +0200, vamoirid wrote:
> From: Vasileios Amoiridis <vassilisamir@gmail.com>
>
> Remove the ambient temperature from being a macro and implement it as
> an attribute. This way, it is possible to dynamically configure the
> ambient temperature of the environment to improve the accuracy of the
> measurements.
...
> - var1 = (((s32)BME680_AMB_TEMP * calib->par_gh3) / 1000) * 256;
> + var1 = (((s32)data->ambient_temp * calib->par_gh3) / 1000) * 256;
MILLI? KILO?
...
> static struct attribute *bme680_attributes[] = {
> &iio_const_attr_oversampling_ratio_available.dev_attr.attr,
> + &iio_dev_attr_ambient_temp.dev_attr.attr,
> NULL,
Side note: Perhaps a patch or an additional change in the existing one to drop
the trailing comma here.
> };
--
With Best Regards,
Andy Shevchenko
On Fri, Oct 11, 2024 at 01:12:21PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 10, 2024 at 11:00:26PM +0200, vamoirid wrote:
> > From: Vasileios Amoiridis <vassilisamir@gmail.com>
> >
> > Remove the ambient temperature from being a macro and implement it as
> > an attribute. This way, it is possible to dynamically configure the
> > ambient temperature of the environment to improve the accuracy of the
> > measurements.
>
> ...
>
> > - var1 = (((s32)BME680_AMB_TEMP * calib->par_gh3) / 1000) * 256;
> > + var1 = (((s32)data->ambient_temp * calib->par_gh3) / 1000) * 256;
>
> MILLI? KILO?
>
I could do it yes.
> ...
>
> > static struct attribute *bme680_attributes[] = {
> > &iio_const_attr_oversampling_ratio_available.dev_attr.attr,
> > + &iio_dev_attr_ambient_temp.dev_attr.attr,
> > NULL,
>
> Side note: Perhaps a patch or an additional change in the existing one to drop
> the trailing comma here.
>
I could add an additional change if you think it is worth the churn.
> > };
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Cheers,
Vasilis
© 2016 - 2024 Red Hat, Inc.