On 2/26/23 19:30, Jonathan Cameron wrote:
On Sat, 18 Feb 2023 20:08:10 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
Thanks a lot Jonathan,
You have been super helpful :) Thanks!
On 2/18/23 19:20, Jonathan Cameron wrote:
Hmm. There is another approach that I'd not thought of in this case because
in my head integration time is more continuous than it is for this part and
that is to fiddle the _raw values (we do this for oversampling or SAR ADCs
where things tend to be powers of 2). The trick is to shift the raw value
always so that the 'scale' due to (in this case) integration time remains
constant. That separates the two controls completely.
Holy cow! That's a neat trick which I didn't think of!
Basically, we could do >> 1 for the data when time is 100 mS, >> 2 when
200 mS and >> 3 when 400 mS. We would want to use 19-bit channel values
then.
However, I'm not sure that makes sense here where the thing we typically
want to change when scaling due to saturation is integration time.
That's a bit problematic, yes. We could "fool" the user by doing the
saturation check in driver, and then just returning the max value of all
19-bits set if the saturation is detected. This, however, would yield
raw values that are slightly off. OTOH, with max sift of 3 bits that's
only 7 'raw ticks' - which I hope is acceptable. I hope the user will
then be switching to shorter integration time and start getting correct
readings.
It's slightly sad to say "good bye" to the gain-time-scale helpers but I
guess you just helped me to solve this with a _really_ simple way. We
can keep those helpers in "back pocket" for the day when we need them ;)
I will see what comes out of this idea - thanks for the help again!
Jonathan
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
