Extended ShiftRegisterKeys to support multiple data pins with shared clock and latch

[kolkmvd]

Added support for multiple data pins which share the same latch and clock, e.g.

k = keypad.ShiftRegisterKeys(
    latch=board.GP2,
    clock=board.GP3,
    data=[ board.GP10, board.GP0 ],
    key_count=[ 32, 16 ],
    value_when_pressed=False,
)

Backwards compatible, data can also be a single pin instead of a list. The key_count numbers are consecutive, e.g. in the example the first key of GP0 will have number 32.

[dhalbert]

I will review this, but I have a hw question: why use parallel shift registers instead of chaining them as a single long shift register? Is it to reduce latency?

[kolkmvd]

I will review this, but I have a hw question: why use parallel shift registers instead of chaining them as a single long shift register? Is it to reduce latency?

No in this case there are 4 independent and optionally connected button controllers. Each button controller has 32 switches (4x HC165 chained) and has a free independent physical location. All max 4 controllers are individually connected to the same control board with a 2meter wire (with 5 strands). So save 3x latch+clock pins on the microcontroller, but also to have equal priority for all controllers, the board has parallel data pins. Also when you would daisy chain these controllers it makes it more complex to figure out which ones are connected and it would require a latch+clock return wire.

I did not think of latency, guess the shifting is quite fast.

[dhalbert]

Makes sense, thanks. For things like keyboards, some people claim latency issues, but we are often skeptical. Yes, shift registers are fast.

[dhalbert]

Looks good, and you have tested (I did not set this up to test.)

One q re API

[dhalbert]

For the user code, would it be more useful to return a tuple in the case of multiple shift registers? Instead of doing a gc_alloc, you could create a tuple, and you can index into that, and return it for .key_count. (I was thinking about a new .key_counts, but the input arg is still key_count, so it would not be consistent.)

[jepler]

How important is it to have a different key count per shift register? Is this needed for a real in-the-wild design, or is it more a hypothetical?

Another alternative would be to have a single argument giving the maximum count of keys. "shift register 0" would be 0..(n-1), "shift register 1" would be n..(2*n-1) and so on. Unused positions would need to be hard-wired to the non-pressed state (not an undefined state or the pressed state), and some key numbers would be unused if the real number of keys per shift register is "ragged" (e.g., 3, 5, 3, 6, or whatever).

[kolkmvd]

The current use case i have is ragged, but I could live in my case with a single key_count and ignore unused keys (which would i my case be signalled as pressed and end up in the event queue). I believe the key_count() function is also used to allocate the currently_pressed / previously_pressed stuff for the toplevel keypad code, so a tuple might not work.

[jepler]

If this is needed to support already existing hardware then I'm not opposed to incorporating a feature that supports ragged shift registers.

[dhalbert]

Thanks for the discussion. I'll merge!

[kolkmvd]

Thanks for merging!