On 07/27/11 15:41, Michael Hennerich wrote: > On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >> On 07/26/11 11:52, Michael Hennerich wrote: >>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>> Michael pointed out the issues that not having an explicit direction >>>>>> for channels was causing and the inconsistency of the inX and outX >>>>>> channel naming we got from hmwon. >>>>>> >>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>> >>>>>> Interesting question is whether we reset the base units to be volts >>>>>> whilst we are at it? (for voltage channels obviously!) >>>>> What do you mean exactly volts versus milli volts? >>>> Make the in_voltage_scale correspond to conversion to volts instead of >>>> millivolts as now (I think). Err. Looking at it that isn't actually documented... >>>> oops. I wonder which drivers actually do that and which don't. >>> The ones I wrote provide the scale for millivolts. >>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got >>> the scale accurate enough for the precession 24-bit converters. >>> If we move to the SI base unit volt, we lose this accuracy again. >> Yup, that's the principal counter argument to the change. > If we decide to leave the milli scale for volts... > Do we also want to stay with milli degrees Celsius, etc.? If we do it for one, probably best to do it for them all.. > > One other thing we should also address is the byte-ordering/endianess of > the scan elements stored in the ring buffers. > > Right now the scan_element type details signs, bits, storage bits and shifts. > However it lacks to tell the endianess within the storage bits. Good point. I'd completely forgotten about that. > > How about le:s16/32>>0 or be:s16/32>>0 for example? Yup, that works for me. In cases where it doesn't matter they driver can pick one at random. 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
