Main Site Documentation

Multi-button modules


#1

A “Y” gadgeteer socket has 7 data pins. Every time you plug a button module into a Y socket, a kitten dies.

I’ve been kicking around the idea of doing a simple 7 button module. Nothing fancy, no matrices or anything (which is not really worth the effort with only 7 pins, as that would give you only 12 buttons like on the keypad Gus has in the protoyping section). Scanning also takes CPU cycles whereas direct digital IO effectively doesn’t.

I’m also considering the approach of tying up two sockets and using a matrix to get a crazy number of buttons (49) – good for MIDI controllers a la monome . That’s more work, of course, and requires more components on the boards (resistors/diodes etc.depending on approach used).

Anyone interested in a module with 7 pushbuttons on it? Driver-wise, it would be similar to the stock single button module.

Is anyone interested in the larger one that would use two sockets? If so, would you want the buttons all on a PCB (big expensive PCB), or just have headers and diodes on the PCB and you wire the buttons on a panel? (smaller PCB that way). There are also shift register approaches that may work here, or even using a small MCU that does scanning and reports it back via serial (hate to tie those up) or SPI or something.

Just kicking around some ideas here :slight_smile:

Pete


#2

You can do 12. Have you seen the keypad?


#3

I actually mentioned it in the second paragraph:


#4

Ha ha, Peter never miss anything :slight_smile:

Ideally, we would have a multi button module with nice colored caps. Like the one skewworks prototyped. I haven’t found a good and reliable source of these yet.


#5

One point, there is no gurantee of having interrupts on any pins beside pin3.


#6

I just knew something would foil my evil plans. :stuck_out_tongue:

I see that now looking at the socket table in the module builder’s guide.

Maybe go with an off-board scanner over SPI then. It doesn’t seem like the Gadgeteer spec allows for daisy chaining of SPI though, which is too bad, as you could certainly support more than one device as long as you could provide CS. Daisylink is an option, but after having looked at it, the daisylink protocol is more than I care to mess around with right now.

I have a few ideas for different modules I’d like to use at the same time, but they all end up using more SPI than either the Spider or Hydra have. (and looks like the Cerebus can only use one SPI at a time? not sure what the “shared signals” note is)

Pete


#7

No, i2c then use software i2c with socket x. Do not waste socket S for buttons :wink:

Can you see I have thought about this for a while :slight_smile:


#8

I’d do a matrix, and then use the one guaranteed interrupt to signal to the mainboard that data is ready to read from the matrix.

You wouldn’t need to CONTINUOUSLY scan, you’d only need to read the matrix whenever the interrupt port went high (or low).


#9

Developing one at the moment that has max 64 keys and can be plugged into an I, K, S, U, X and Y socket
When the X socket is used only 4 buttons are available, or with software i2c all 64.
All could be interrupt driven to prevent scanning.
Still thinking about adding ps2 and/or USB so that you can plug in a real keyboard and still be able to use the same software.

Still pre-alfa because i not even have a gadgeteer mainboard in my possesion to properly test it :slight_smile:


#10

Why not use a cheap pic16f with 2 port to accomodate 64 Keys and software i2c and interrupt to cpu?

Ps: few monte ago I red about a chip mpr121 that manage touch keypad for 16button