On 12/03/2015 02:01 PM, Rojhalat Ibrahim wrote: > 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>; >> >> 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. > > 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. 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? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
