shift registers instead of matrix (was: Need help with I2C GPIO port expander)

[sinusoid]

EDIT:
The solution to my issue was to use a muxer/demuxer shift registers. See the reply here:
https://geekhack.org/index.php?topic=79155.msg2030286#msg2030286

I2C is most likely too slow. See post below:
https://geekhack.org/index.php?topic=48326.msg1202864#msg1202864

Below is the original post:



_______________________________________________________________



I would like to use a GPIO i2c port expander chip to connect each individual key of a keyboard to an input in ATMega (Arduino Mega for prototyping needs).

Issues I have:
- WHAT CHIP?! I have no idea how to decide! Which GPIO port expanders should I use for a keyboard? Is there anything I should look out for?
- What to prepare for? What issues can I run into?
- Can you recommend a tutorial? Are there any existing builds/build logs that utilize a port expander chip instead of a matrix? (I only see people using them to control LEDs)

I would like to get the necessary chips before the weekend, so I can hack away at it for two days, and I'm afraid I won't be able to find all the necessary information and get the chips before that time. I feel I'm getting stuck in decisionland.

I'd like to hit the ground running with this on Saturday, but I'm still digging through information, and things don't look very optimistic

Please advise!

[evangs]

checkout out this forum post https://www.raspberrypi.org/forums/viewtopic.php?f=48&t=57238

I'm curious to see how this works for you.  I suspect this isn't done much because of performance issues, but I don't have definitive data on that.  would be a fun experiment regardless.

[sinusoid]

Thanks! Reading through, this is nice.

What do you mean by performance exactly? Anecdotal data is fine, I'll be testing against it if given.

The suggested expansion board in that thread uses MCP23017. I see a trend here, most chips for these solutions coming from Microchip Technologies. I saw some stuff being done on MCP23008 elsewhere, and others.

But really, which one to get? Is there a difference? What to look for in these chips?

[evangs]

by performance I mean processing speed, how quickly the keys can be scanned.  I wish I had more information on what chips you need, but my EE knowledge is lacking. I'd get a couple of the MCP23017 and play around with them, if you have issues, then you can use those issues to guide you to a different part.

[senso]

i2c might be a bit on the slow side.
You go old school and use 74HC595 for the outputs and 74HC165 for the inputs.
They are easy to use, no config registers, just SPI blasting at up to 8Mhz with the Arduino/Atmega, plenty fast.

[MOZ]

What do you mean by

... connect each individual key of a keyboard to an input in ATMega

[sinusoid]

@senso: This is the solution I actually needed, thanks a lot! I see they can be daisy chained too. Skimmed this briefly due to a dayjob, don't understand it well at the moment, will dig into it tomorrow to get to the core. Thank you again!

One question: is N key rollover possible with these? (y/n suffices, or keyword I should search for if counterintuitive)

What do you mean by

... connect each individual key of a keyboard to an input in ATMega

Uh oh... I wrote that, didn't I... 
It should be "how do I increase a physical number of inputs of an ATMega, so I can physically connect each of the switches to those inputs". Using a muxer/demuxer is the answer, it seems.

What I wrote before is an ugly leftover from the thought process that led me here. 
It referred to a hypothetical situation in which the amount of outputs from all available switches equaled the amount of inputs available on the ATMega. In that situation, I would simply wire every switch to every pin and handle it on the ATMega side, fast and ugly. Then I hypothesized about a situation when the amount of outputs is bigger than the amount of inputs, and how do I wire it up then.
And this sentence popped up as a derivative of this process, and my lack of knowledge and understanding

Using I2C in this situation is a wrong choice, but the only one I knew (aside from soldering different resistors to each switch and grabbing the resulting voltages on analog pins, but that's fugly as hell and has its own issues).

I should have posed the question differently.


EDIT:
I'll be back to the subject of I2C when I'll be wiring up LEDs.

[MOZ]

Okay. Just out of curiosity, why do you want to have each key as a separate input to your MCU? What's the issue with a matrix and row/column scanning?

[sinusoid]

@MOZ, I'm wiring the datahand, optimizing for density, and with current gnd wireup I don't think I'd be able to get a matrix done. This will change later, as I'll be switching to PCB mounts.

But for the time being I need something fast and dirty that works, is modular, has Nkr, can be torn up and rebuilt quickly, and doesn't require much programming overhead to change stuff.

(with this the only 'programming overhead' will be to update keymaps by changing an array, and if I solve the program well, this should be true for all hypothetical switches that are not yet implemented, in whole input range. Adding more inputs is not a problem, too).



Edit:
Read your modular keyboard thread, saw Old DataHands diss I2C for keyboard use with some writeup on the first page: https://geekhack.org/index.php?topic=48326.msg1202864#msg1202864
I should lurkmoar :/