RFC input: rotary_encoder: use more than two gpios as input
Get series with b4
b4 am 1470515.ydY47qFlGL@pcimrVersions newest first
- v1 RFC Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input
Quoted 30 lines · On Saturday 05 December 2015 20:50:18 Daniel Mack wrote:
Quoted 21 lines · Rojhalat Ibrahim
Quoted 8 lines · On Wednesday 02 December 2015 19:59:20 Uwe Kleine-K?nig wrote:
I have a real rotary encoder with 4 input lines and so 16 distinguishable positions. It would be described as:
compatible = "rotary-encoder"; gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>; rotary-encoder,steps = <16>; rotary-encoder,steps-per-period = <16>;Quoted 6 lines
with the binding implemented in my patches.
The wikipedia article about rotary encoders[1] uses a device with 3 input lines to explain gray encoding. So I didn't consider "my" device as exotic up to now.
So you have an absolute encoder. From the state of the four input lines you can determine the absolute position value. There is no need to count steps. At least that's the original purpose of your device.
Quoted 7 lines
Of course it might be conceivable to use that kind of absolute encoder in an incremental way and count the steps throughout multiple revolutions. But why would you do that? The resolution of 16 steps per revolution is not very good (incremental encoders often have hundreds or thousands of steps per revolution). And the whole point of an absolute encoder is that you are able to determine the current position at any time just by looking at the inputs without having to count steps.
Quoted 7 lines
Yes, you're right, that's actually a very different kind of device which should be supported with a different mode or something, so that the output of the driver reflects the absolute state of the encoder. This even simplifies things in the driver: The entire state logic would be bypassed in this mode, and the current state of the GPIO lines would be used directly to get the absolute value. Makes sense?
Definitely makes sense to me.
Thanks.
Rojhalat
Quoted 8 lines
Thanks,
Daniel_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel