rotary-encoder.txt 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108
  1. rotary-encoder - a generic driver for GPIO connected devices
  2. Daniel Mack <daniel@caiaq.de>, Feb 2009
  3. 0. Function
  4. -----------
  5. Rotary encoders are devices which are connected to the CPU or other
  6. peripherals with two wires. The outputs are phase-shifted by 90 degrees
  7. and by triggering on falling and rising edges, the turn direction can
  8. be determined.
  9. The phase diagram of these two outputs look like this:
  10. _____ _____ _____
  11. | | | | | |
  12. Channel A ____| |_____| |_____| |____
  13. : : : : : : : : : : : :
  14. __ _____ _____ _____
  15. | | | | | | |
  16. Channel B |_____| |_____| |_____| |__
  17. : : : : : : : : : : : :
  18. Event a b c d a b c d a b c d
  19. |<-------->|
  20. one step
  21. For more information, please see
  22. http://en.wikipedia.org/wiki/Rotary_encoder
  23. 1. Events / state machine
  24. -------------------------
  25. a) Rising edge on channel A, channel B in low state
  26. This state is used to recognize a clockwise turn
  27. b) Rising edge on channel B, channel A in high state
  28. When entering this state, the encoder is put into 'armed' state,
  29. meaning that there it has seen half the way of a one-step transition.
  30. c) Falling edge on channel A, channel B in high state
  31. This state is used to recognize a counter-clockwise turn
  32. d) Falling edge on channel B, channel A in low state
  33. Parking position. If the encoder enters this state, a full transition
  34. should have happend, unless it flipped back on half the way. The
  35. 'armed' state tells us about that.
  36. 2. Platform requirements
  37. ------------------------
  38. As there is no hardware dependent call in this driver, the platform it is
  39. used with must support gpiolib. Another requirement is that IRQs must be
  40. able to fire on both edges.
  41. 3. Board integration
  42. --------------------
  43. To use this driver in your system, register a platform_device with the
  44. name 'rotary-encoder' and associate the IRQs and some specific platform
  45. data with it.
  46. struct rotary_encoder_platform_data is declared in
  47. include/linux/rotary-encoder.h and needs to be filled with the number of
  48. steps the encoder has and can carry information about externally inverted
  49. signals (because of an inverting buffer or other reasons). The encoder
  50. can be set up to deliver input information as either an absolute or relative
  51. axes. For relative axes the input event returns +/-1 for each step. For
  52. absolute axes the position of the encoder can either roll over between zero
  53. and the number of steps or will clamp at the maximum and zero depending on
  54. the configuration.
  55. Because GPIO to IRQ mapping is platform specific, this information must
  56. be given in seperately to the driver. See the example below.
  57. ---------<snip>---------
  58. /* board support file example */
  59. #include <linux/input.h>
  60. #include <linux/rotary_encoder.h>
  61. #define GPIO_ROTARY_A 1
  62. #define GPIO_ROTARY_B 2
  63. static struct rotary_encoder_platform_data my_rotary_encoder_info = {
  64. .steps = 24,
  65. .axis = ABS_X,
  66. .relative_axis = false,
  67. .rollover = false,
  68. .gpio_a = GPIO_ROTARY_A,
  69. .gpio_b = GPIO_ROTARY_B,
  70. .inverted_a = 0,
  71. .inverted_b = 0,
  72. };
  73. static struct platform_device rotary_encoder_device = {
  74. .name = "rotary-encoder",
  75. .id = 0,
  76. .dev = {
  77. .platform_data = &my_rotary_encoder_info,
  78. }
  79. };