Re: [PATCH 0/2] blue part 6: IIO abi rework

[Jonathan Cameron <jic23@cam.ac.uk>]

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