On 05/27/2011 12:53 PM, Jonathan Cameron wrote:
On 05/27/11 11:23, Michael Hennerich wrote:
On 05/27/2011 11:44 AM, Jonathan Cameron wrote:
...
Hi Jonathan,
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> ls
device0:buffer0 power
in-in_scale range
in0-in0_raw range_available
in1-in1_raw sampling_frequency
in2-in2_raw sampling_frequency_available
in3_raw subsystem
in4_supply_raw temp0_raw
in4_supply_scale temp_scale
in_scale trigger
name uevent
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale
0.000140
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat range_available
2500 1250 625 312 156 78 39 19
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 312> range
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale
0.000010
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 78> range
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale
0.000000
root:/sys/devices/platform/bfin-spi.0/spi0.18/device0>
with these 24-bit converters and input AMPs we are already exhausted
the number of available digits we have for scale.
Time for a new return type and extra logic in the core.
IIO_VAL_INT_PLUS_NANO
should still fit in a 32 bit long. Perhaps it's better to make a bigger jump - or
this will just bite us again sometime soon.
After nano we will have to start having padding zeros which is going to be a little
strange - or I guess we don't have to keep val as being int...
IIO_VAL_MICRO_PLUS_PICO maybe? The maximum option of IIO_VAL_NANO_PLUS_ATTO seems a little
'odd'.
The more complex question is going to be writing values that are this small. I think we will
have to add another callback into the drivers where they can query what format a value should
be in so the core can provide it. Make this optional so it doesn't effect the majority
of drivers where int + micro does the job.
IIO_VAL_INT_PLUS_NANO should do the job for now.
What shall we do?
Also how would you name AIN1(-) - AIN1(-)?
#define AD7793_CH_AIN1P_AIN1M 0 /* AIN1(+) - AIN1(-) */
#define AD7793_CH_AIN2P_AIN2M 1 /* AIN2(+) - AIN2(-) */
#define AD7793_CH_AIN3P_AIN3M 2 /* AIN3(+) - AIN3(-) */
#define AD7793_CH_AIN1M_AIN1M 3 /* AIN1(-) - AIN1(-) */
in0-in0_zerooffset_raw ?
Hmm.. That is awkward. Given only the channel numbers exist in event codes
it will also possibly cause us issues at some later date.
How about having in0-in0_raw then in0-in0_offset + in0-in0_offset_available.
(actually this would be shared I guess so in-in_offset_available).
A little clunky, but does fit better within the api. Is there a real use case
for buffering where one grabs both offsets in the same scan?
As far as I understand things - We do zero and full scale calibration,
The results read from the other channels should have the offset eliminated.
I agree the offset read from AIN1(-) - AIN1(-) should be the same for all channels.
So in-in_offset sounds good to me - why _available?
Because there are two options possible. One when we are doing signed output
and one for differential but with only positive values possible.
Sorry I can't follow here. These 3 differential channels pairs always
deliver signed values.
Why would a differential channel only deliver positive values?
If the voltage on AINx(+) is lower then the voltage on AINx(-) the
result is negative.
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
