[PATCH 11/14] staging: comedi: multiq3: tidy up multiq3_encoder_insn_read()

[Hartley Sweeten]

On Monday, October 05, 2015 9:12 AM, Ian Abbott wrote:
> On 03/10/15 01:30, H Hartley Sweeten wrote:
>> Encoders are not a "normal" subdevice in comedi. For aesthetics, tidy
>> up this function and add a couple comments to clarify the function.
>>
>> Remove the strange munging of the data. The encoder data is decoded
>> in quadrature and used to increment or decrement a 24-bit counter.
>> Adding 0x800000 to the counter value doesn't make any sense.
>
> I think it's because the counter starts at zero when reset, and moving 
> it backwards would make it go negative, which the comedi user would see 
> as a large jump in the unsigned value.  The offset biases it to the 
> middle of the range so moving it backwards just decreases the value.  Of 
> course if you keep moving it in the same direction for long enough, it 
> will eventually wrap around, but that shouldn't happen if there are 
> physical limits on how far the encoder can move forwards and backwards.

> -		data[n] = (value + 0x800000) & 0xffffff;

Hmmm... So the munging is basically offsetting the reset value (0x000000)
to the middle of the maxdata range. Positive turns of the encode will then
increment the value and negative turns decrement it.

An encoder normally does not have any type of physical limit that would
prevent it from turning.

A 2000 line encoder in quadrature results in 8000 counts per revolution
so approximately 2097 revolutions can be measured without overflowing
the counter.

The munging above would essentially allow the encoder to be rotated
either direction about 1048 times without an overflow. So I guess the
odd munging makes sense.

1 click negative counter value = 0xffffff -> read value 0x7fffff
Reset counter value = 0x000000 -> read value 0x800000
1 click positive counter value = 0x000001 -> read value 0x800001

Maybe a comment just to clarify the odd munging?

Thanks,
Hartley