nRF52 RotaryIO: raise error when more than 4 encoders are used

[jpconstantineau]

I have a small macropad that has 5 rotary encoders. It appears that CircuitPython has a hardcoded limit of 4 rotary encoders to be setup on the nRF52840. (I use a BlueMicro840).

I created a test program to track the position of all 5 encoders. In the first iteration of the program, I initialize 5 encoders in sequence 1,2,3,4,5 and the 5th one doesn't respond.
In the second iteration, I moved the initializer for encoder 5 up to be between 3 and 4 (1,2,3,5,4). In this sequence, it's the 4th one that didn't respond.

It would be nice to be able to configure the maximum number of rotary encoders to be initialized. I understand that 4 is a reasonable limit for most users but with keyboards and more users looking at HID, I suspect that this will be a parameter that might need to be exposed.

Could it be added into boot.py and not at CP compile time (i.e. hardcoded)?

macropad in question: miniMacro5

[microdev1]

CircuitPython doesn't have a limit for the number of rotary encoders.
nRF52840 has a limit of 8 GPIOTE channels, each rotary encoder uses 2 channels and thus a max of 4 encoders can be used.
Leaving this issue open as an error should be raised when we run out of available channels.

[jpconstantineau]

That makes sense and explains why performance is much better than in the arduino (Adafruit_nRF52_Arduino) software encoders.
Is there any other functionality that would consume channels as well? i.e. Does the consumption of GPIOTE channels impact other functionality? Take for example alarm.pin? Does that use the GPIOTE or pin SENSE mechanism?

Would there be any chance to add the hardware Quadrature decoder (QDEC) on the nrf52 for the first encoder and switch over to GPIOTE to enable 5 encoders and minimize GPIOTE channel consumption if other functionality depends on it? I understand if this isn't something that's going to be done but if GPIOTE is required for lots more functionality, this might free up 2 channels for most people.

[dhalbert]

We've had a lot of discussion of rotaryio in #3875. I found an interesting algorithm, mentioned in that issue, that uses only one interrupt, which would save interrupt channels. We didn't use the QDEC peripheral for the reason you imply, which is that it only supported one encoder.

[jepler]

I think I spoke dismissively about the above-linked algorithm once, but I took the time to actually test it and I think it may be a correct algorithm for quadrature decoding. I believed that any algorithm triggered only by edges from one of A or B had to be wrong, because this particular realization of an A-triggered quadrature decoder is wrong.

There are several differences between the proposed algorithm and mine, including that it is triggered by BOTH edges of A, the way the B state is tracked, and the way that the count direction is computed from A & B together.

My test program generates 10,000 random quadrature sequences and verifies that the algorithm I trust agrees with the proposed algorithm, except that the proposed algorithm counts twice as fast and is sometimes ±1 count from the trusted algorithm. However, the test shows that the difference remains at most ±1 and does not accumulate, at least for the randomly tested sequences.

https://gist.github.com/jepler/8b932d700efd824e6e02bc4b46727ab4

[jpconstantineau]

Counting twice as fast may be an issue, especially with encoders that have mechanical detents (clicks). In such case, we would have double-counts per detent. We would need some kind of divider.

@jepler is your new algorithm the same as the one implemented in the arduino nrf52 stack? This is the one I was referring to in my comment above that didn't perform as well as what's currently implemented.

[jepler]

The algorithm I tried implementing was the one @dhalbert linked to, http://www.technoblogy.com/show?1YHJ

[jpconstantineau]

After some thought, I would err of the side of a better algorithm as opposed to more encoders. End-users always complain when behavior isn't as expected and appears buggy. Number of encoders being limited by hardware features is easier to "explain away".
I would be completely fine if an exception/error be raised when the number of GPIOTE runs out.