IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Hennerich, Michael]

/**
 * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format of a scan =
el
 * @name: the scan el name (may be more general and cover a set of scan ele=
ments
 * @_sign: either s or u for signed or unsigned
 * @_bits: number of actual bits occuplied by the value
 * @_storagebits: number of bits _bits is padded to when read out of buffer
 **/
#define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits, _storagebits) \
        IIO_CONST_ATTR(_name##_type, #_sign#_bits"/"#_storagebits);

There are cases where bits < storagebits and the result is not alligned to =
the LSB.
Lets say we have an 10-bit ADC.
The output is stored in a 16-bit word, with four leading zeros, then the 10=
-bit datum, followed by 2 don't care bits.

So it would be good to provide an additional shift value?
Or how shall we handle these cases?

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Jonathan Cameron]

On 10/05/10 12:24, Hennerich, Michael wrote:
> /**
>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format of a scan el
>  * @name: the scan el name (may be more general and cover a set of scan elements
>  * @_sign: either s or u for signed or unsigned
>  * @_bits: number of actual bits occuplied by the value
>  * @_storagebits: number of bits _bits is padded to when read out of buffer
>  **/
> #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits, _storagebits) \
>         IIO_CONST_ATTR(_name##_type, #_sign#_bits"/"#_storagebits);
> 
> There are cases where bits < storagebits and the result is not alligned to the LSB.
> Lets say we have an 10-bit ADC.
> The output is stored in a 16-bit word, with four leading zeros, then the 10-bit datum, followed by 2 don't care bits.
> 
> So it would be good to provide an additional shift value?
> Or how shall we handle these cases?
This was discussed in the original debate and we simply proposed leaving it until
we had a user.  So the question is how to describe the shift.

So taking your example, how about:

u10/16>>2

Where the shift is optional.

Other suggestions welcome given I made that up with 2 seconds thought.
> 
> Greetings,
> Michael
> 
> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036
> Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
> 
> 
> 

RE: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Hennerich, Michael]

Jonathan Cameron wrote on 2010-10-05:
> On 10/05/10 12:24, Hennerich, Michael wrote:
>> /**
>>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format of a
>>  scan el * @name: the scan el name (may be more general and cover a set
>>  of scan elements * @_sign: either s or u for signed or unsigned *
>>  @_bits: number of actual bits occuplied by the value * @_storagebits:
>>  number of bits _bits is padded to when read out of
>> buffer  **/ #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits,
>> _storagebits) \
>>         IIO_CONST_ATTR(_name##_type, #_sign#_bits"/"#_storagebits);
>> There are cases where bits < storagebits and the result is not alligned
>> to the LSB. Lets say we have an 10-bit ADC. The output is stored in a
>> 16-bit word, with four leading zeros, then the 10-bit datum, followed
>> by 2 don't care bits.
>>
>> So it would be good to provide an additional shift value?
>> Or how shall we handle these cases?
> This was discussed in the original debate and we simply proposed
> leaving it until we had a user.  So the question is how to describe
> the shift.
>
> So taking your example, how about:
>
> u10/16>>2
>
> Where the shift is optional.
>
> Other suggestions welcome given I made that up with 2 seconds thought.

I think this is sufficient. I can only think about right shifts being usefu=
l.
This notation would consistently allow both, that's why I like it.

A bit off topic - some common defines for signed/unsigned types might also =
be useful.

#define IIO_SCAN_EL_TYPE_SIGNED         's'
#define IIO_SCAN_EL_TYPE_UNSIGNED       'u'

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Jonathan Cameron]

On 10/05/10 12:52, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2010-10-05:
>> On 10/05/10 12:24, Hennerich, Michael wrote:
>>> /**
>>>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format of a
>>>  scan el * @name: the scan el name (may be more general and cover a set
>>>  of scan elements * @_sign: either s or u for signed or unsigned *
>>>  @_bits: number of actual bits occuplied by the value * @_storagebits:
>>>  number of bits _bits is padded to when read out of
>>> buffer  **/ #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits,
>>> _storagebits) \
>>>         IIO_CONST_ATTR(_name##_type, #_sign#_bits"/"#_storagebits);
>>> There are cases where bits < storagebits and the result is not alligned
>>> to the LSB. Lets say we have an 10-bit ADC. The output is stored in a
>>> 16-bit word, with four leading zeros, then the 10-bit datum, followed
>>> by 2 don't care bits.
>>>
>>> So it would be good to provide an additional shift value?
>>> Or how shall we handle these cases?
>> This was discussed in the original debate and we simply proposed
>> leaving it until we had a user.  So the question is how to describe
>> the shift.
>>
>> So taking your example, how about:
>>
>> u10/16>>2
>>
>> Where the shift is optional.
>>
>> Other suggestions welcome given I made that up with 2 seconds thought.
> 
> I think this is sufficient. I can only think about right shifts being useful.
> This notation would consistently allow both, that's why I like it.
It would be decidedly odd for right shift to make sense.
> 
> A bit off topic - some common defines for signed/unsigned types might also be useful.
> 
> #define IIO_SCAN_EL_TYPE_SIGNED         's'
> #define IIO_SCAN_EL_TYPE_UNSIGNED       'u'
Fine with me.
> 
> Greetings,
> Michael
> 
> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
> 
> 
> 

RE: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Hennerich, Michael]

Jonathan Cameron wrote on 2010-10-05:
> On 10/05/10 12:52, Hennerich, Michael wrote:
>> Jonathan Cameron wrote on 2010-10-05:
>>> On 10/05/10 12:24, Hennerich, Michael wrote:
>>>> /**
>>>>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format
>>>> of a  scan el * @name: the scan el name (may be more general and
>>>> cover a set  of scan elements * @_sign: either s or u for signed
>>>> or unsigned *
>>>>  @_bits: number of actual bits occuplied by the value *
>>>>  @_storagebits: number of bits _bits is padded to when read out of
>>>>  buffer  **/
>>>> #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits,
>>>> _storagebits) \
>>>>         IIO_CONST_ATTR(_name##_type,
>>>> #_sign#_bits"/"#_storagebits); There are cases where bits <
>>>> storagebits and the result is not alligned to the LSB. Lets say we
>>>> have an 10-bit ADC. The output is stored in a 16-bit word, with
>>>> four leading zeros, then the 10-bit datum, followed by 2 don't care bi=
ts.
>>>>
>>>> So it would be good to provide an additional shift value?
>>>> Or how shall we handle these cases?
>>> This was discussed in the original debate and we simply proposed
>>> leaving it until we had a user.  So the question is how to describe
>>> the shift.
>>>
>>> So taking your example, how about:
>>>
>>> u10/16>>2
>>>
>>> Where the shift is optional.
>>>
>>> Other suggestions welcome given I made that up with 2 seconds
> thought.
>>
>> I think this is sufficient. I can only think about right shifts being
>> useful. This notation would consistently allow both, that's why I like
>> it. It would be decidedly odd for right shift to make sense.
>>
>> A bit off topic - some common defines for signed/unsigned types might
>> also be useful.
>>
>> #define IIO_SCAN_EL_TYPE_SIGNED         's' #define
>> IIO_SCAN_EL_TYPE_UNSIGNED       'u' Fine with me.

Shall we add the shift option to the existing macro?
Or shall we create a new one? How would you name it?

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?

[Jonathan Cameron]

On 10/05/10 13:06, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2010-10-05:
>> On 10/05/10 12:52, Hennerich, Michael wrote:
>>> Jonathan Cameron wrote on 2010-10-05:
>>>> On 10/05/10 12:24, Hennerich, Michael wrote:
>>>>> /**
>>>>>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format
>>>>> of a  scan el * @name: the scan el name (may be more general and
>>>>> cover a set  of scan elements * @_sign: either s or u for signed
>>>>> or unsigned *
>>>>>  @_bits: number of actual bits occuplied by the value *
>>>>>  @_storagebits: number of bits _bits is padded to when read out of
>>>>>  buffer  **/
>>>>> #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits,
>>>>> _storagebits) \
>>>>>         IIO_CONST_ATTR(_name##_type,
>>>>> #_sign#_bits"/"#_storagebits); There are cases where bits <
>>>>> storagebits and the result is not alligned to the LSB. Lets say we
>>>>> have an 10-bit ADC. The output is stored in a 16-bit word, with
>>>>> four leading zeros, then the 10-bit datum, followed by 2 don't care bits.
>>>>>
>>>>> So it would be good to provide an additional shift value?
>>>>> Or how shall we handle these cases?
>>>> This was discussed in the original debate and we simply proposed
>>>> leaving it until we had a user.  So the question is how to describe
>>>> the shift.
>>>>
>>>> So taking your example, how about:
>>>>
>>>> u10/16>>2
>>>>
>>>> Where the shift is optional.
>>>>
>>>> Other suggestions welcome given I made that up with 2 seconds
>> thought.
>>>
>>> I think this is sufficient. I can only think about right shifts being
>>> useful. This notation would consistently allow both, that's why I like
>>> it. It would be decidedly odd for right shift to make sense.
>>>
>>> A bit off topic - some common defines for signed/unsigned types might
>>> also be useful.
>>>
>>> #define IIO_SCAN_EL_TYPE_SIGNED         's' #define
>>> IIO_SCAN_EL_TYPE_UNSIGNED       'u' Fine with me.
> 
> Shall we add the shift option to the existing macro?
> Or shall we create a new one? How would you name it?
Create a new one (as this is optional and as of yet, not that common)
IIO_CONST_ATTR_SCAN_EL_TYPE_WITH_SHIFT should do the job.


> 
> Greetings,
> Michael
> 
> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
> 
> 
>