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. -- 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
