IncrementalEncoder: factor out the quadrature state machine

[jepler]

.. and use the same one in samd, nrf, and raspberrypi.

nrf used a different one which may be the cause of #3875 (but I didn't actually test so I don't know if it's fixed)

If we want to substitute a smaller implementation (like one without a table, as discussed in #4559) now we can do it just once instead of 3+ times.

esp32s2 wasn't touched, as it is using a hardware quadrature decoder module.

[ladyada]

i can test this on samd later cause im going to make a rotary trinkey

[dhalbert]

I tested this on a Feather Sense (nrf) and a QT Py M0. On both I got no position changes: .position was always 0.

I did not test with an RP2040 board.

Reloading both boards with 6.2.0 showed both could work. However, I noticed that the nrf and the atmel-samd implementations run in opposite directions! One goes up, and one goes down, when turned in the same direction. We'll need to pick a direction and note in the release notes that 7.0.0 has reversed one or the other. I presume the nrf post will change because the code is copied from atmel-samd, but we should double-check.

Test program:

import board,rotaryio,time
r = rotaryio.IncrementalEncoder(board.A0, board.A1)
while True:
    print(r.position)
    time.sleep(0.5)

[jepler]

I'll convert this to a draft and do further testing before taking up anybody else's time. I stand by the idea that it's a good idea to unify these, especially when discussing alternate implementations of the quadrature state machine, but clearly the implementation is flawed.

[jepler]

Ah there was an obvious problem, yay. Setting back to ready-for-review!

[dhalbert]

OK, I pushed several changes:

• Changed 4-bit struct fields to whole bytes. The amount of RAM saved is minimal, at the cost of larger code size, which is an issue on some boards.
• Fixed nrf ISR for rotaryio: it was not setting the values properly.
• Made the direction of rotation be the same across the three ports. Used the atmel-samd direction as the default, since there are more boards out there. This necessitated remembering the pin swap on raspberrypi, and it needs to start out "swapped" due to the direction. We will need to document this incompatible change in the release notes.

I am still wondering about the requirement for consecutive pins on the RP2040. Yes, then you can use PIO, but it makes rotaryio code less portable across boards. I lucked out because I was using A0 and A1, which happened to be consecutive on the Feather RP2040, but it was just luck.

Tested on Feather Sense (nrf), QT Py M0, and Feather RP2040.

[dhalbert]

All set now after trading reviews :) . Thanks @jepler for doing the refactoring.