rotaryio, reset pin

[gbit-is]

The rotaryio lib is quite good as it is but I have a suggestion for an addition to it: The ability to have a reset pin that sets the counter to 0. When using the rotaryio library to track relitive positions it can be usefull to be able to reset the counter when another pin is triggered.

In my case I have a large geared circle (the rotating dome of a full size R2D2) connected to a rotary encoder that tracks the relitive position of the head, to "home" it I use a hall effect sensor that can give the rotary encoder a fixed position to know where zero is.

the code looks something like (not an optimal solution, very much a WIP):

encoder = rotaryio.IncrementalEncoder(board.GP0, board.GP1)
hall_effect = digitalio.DigitalInOut(board.GP2)
hall_effect.digitalio.Direction.INPUT
hall_effect.digitalio.Pull.DOWN

while True:
    
    if not hall_effect.value:
        encoder.position = 0
    print(encoder.position)
    

What I envision is the ability to have this implemented into the rotaryio library itself instead of outside of it by defining a reset_pin and the ability to toggle wether or not that ability is active

encoder = rotaryio.IncrementalEncoder(board.GP0, board.GP1, divisor=2,reset_pin=board.GP2)
encoder.reset_pin_enabled = True
encoder.reset_pin_enabled = False

[jepler]

This is also called the "index" signal by folks coming from a CNC background. (which is my background)

This should be feasible to add to the "softencoder" implementations, which are based on a microcontroller-level pin change interrupt followed by software decoding of the quadrature data into position based on a state table look-up. The "softencoder" is used by all our ports that implement IncrementalEncoder except espressif.

The limitation of the "softencoder" approach is twofold:

• a software interrupt must occur & be completed for every transition on the a/b (and, with this change, x) pins. otherwise, transitions can be lost.
• if bounce occurs between the firing of the pin change interrupt & latching the port values from the interrupt code, transitions can be lost.

This is "pretty much fine" when it comes to using a rotary encoder as a human interface knob, which is the use case we consider for CircuitPython. Before you put a load of time into using it in a robotics context I encourage you to check whether it's adequate to your needs in terms of not losing position.

(the rp2040 implementation is a bit different, because each change is captured in an 8-deep fifo, so the interrupt needs are reduced and there's not the "pin change to port sample" gap. I feel it's probably the best of the lot)

espressif-family microcontrollers have a peripheral called "pcnt" that is actually quite ill-suited to being used as a quadrature encoder. It doesn't have an explicit quadrature counting mode, but a pair of up/down counters are created on the same pair of pins and in a clever way it correctly counts each quadrature edge. I honestly do not understand how it works. I don't think it supports an index pin; However, it would be OK to just have the specification of a reset/index pin cause a "not supported" exception if it's not possible with the peripheral.

[dhalbert]

Here's an RP2040 PIO implementation that does not use interrupts. It requires emptying the fifo to read the latest value.