On 05/27/2011 01:16 PM, Jonathan Cameron wrote:
On 05/27/11 11:55, Michael Hennerich wrote:
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.
So what is AIN1(-) - AIN1(-) ?
I thought that was unipolar differential.
No - In this mode the AIN1(â) input is internally shorted to itself.
This can be used as a test method to evaluate the noise performance of the
parts with no external noise sources. In this mode, the AIN1(â) input should
be connected to an external voltage
within the allowable common-mode range for the part.
As you see this is only for test and evaluation purposes...
--
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
