4x4 keypad using 74LS165 chip

probably not a "project" rather than an "is this possible exercise".

i've used the 74HC595 and decided to "try the other side" - i saw a 4x4 keypad with 8 pins (4x4 matrix) and thought, let's rig that up to a '165 - now realising it's not exactly the same as 8 switches.

first some "housekeeping" (or dust-clearing?) if i may - regarding the chip itself and reading datasheets;

Q-0.1
i'd previously got a good reply Shift Registers vs i2c - #11 by Chagrin - General Electronics - Arduino Forum re reading datasheets for current but would appreciate a bit more clarification with the following :
this one is clear;

the MCP23008 allows 
	a total 	125ma current [color=blue][b]source[/b][/color] ("current [u]into [/u]Vdd pin") 
	     or 	150ma [b][color=blue]sink [/color][/b]("current [u]out [/u]of Vss pin")

but with this;

while the SN74HC595 allows 
		70ma ("continuous current [u]through [/u]Vcc			=   [color=blue]SINK  [/color]? 
					               	or GND"). 		   = [color=blue]SOURCE [/color]??

am i correct in understanding that current through Vcc is sinking, and through GND would be sourcing (with respect to the chip itself) ?
or wait... :-/
through Vcc and out the '595 pins = sourcing, while
out the '595 pins and down to GND = sinking... i think that makes more sense...

Q-0.2
i'd been following Nick Gammon's tutorial http://www.gammon.com.au/forum/?id=11979 and i think i can say that if the '595 is sourcing current, driving LEDs, for example; then the '165 is sinking current - reading inputs, ie. switches connecting to 5V.

reading the datasheet of the 74HC165 - i can get;

Continuous current through VCC or GND ±50 mA

clear enough - but more on that later.

while from the 74LS165A which is what i actually have;

ICC   |    VCC = MAX, See Note 4    |    18 (typical) 30 (maximum)   |     mA

For completion sake; NOTE 4. With the outputs open, CLK INH and CLK at 4.5 V, and a clock pulse applied to SH/LD, ICC is measured first with the parallel inputs at 4.5 V, then with the parallel inputs grounded.

am i correct to assume that ICC stands for continous current and is therefore the corresponding spec to be compared with the 74HC165 above - meaning the "LS" is not as robust as the "HC" and one must be more careful in giving it current.

Q-0.3
i'd also seen this tutorial on the Arduino Playground Arduino Playground - ShiftRegSN74HC165N
is the contributor mistaken in calling "CE" clock enable, and so the code might actually be erroneous ?

Nick's code doesn't use the chip enable so i was wondering if this Playground code has "something extra" - unnecessary or different code methodology ?

OKAY, this post is getting long - will post the continuation in the next one....

continuation of above (original) post...

so now we get to the actual "project".

most of the threads or circuits using the 4x4 keypad uses 8 Arduino pins which i thought was rather wasteful but perhaps an essential work-through to understand how it works, there were a few setups using resistor ladders so that one only needs a single analog pin but i thought i'd try and use the SPI bus using a shift register.

i initally imagined i'd connect the 8 pins of the keypad to the 8 inputs of the '165 and then simply read the 2 pins (or '165 register) that read '1' and would then be able to pinpoint which key was pressed.

sketching out the circuit, i realised - where does the current come in ?!
i saw a picture that 'injected' the 5V into the keypad wiring and thought i'd try to work along those lines, i got this;

the first thing that hit me was - one side of the '165 is always going to read "high" !
would that mean i'd have to supply the 5V through 4 different Arduino output pins, which would be "multiplexed(?)" along with the check of each row (to the top half of the '165) ?

that would then defeat the purpose of saving on pins !

now, THE QUESTION;

so i was wondering if there was some other possibility - reading from the above, that the '165 can sink or source current... how does that work ? how do you source current from an input pin ?

i found this resource;

and even more complex, and perhaps something that might be implemented in this "project" ?
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/bf4b2f3568cb0d7086256b8e006ee07c?OpenDocument

ir's taking a while for that source of information to sink in... (sorry !!) :smiley:
so i'd appreciate if anybody could give some "simple language" comments to help me get a grasp of what exactly my obstacle is here.

are those "sink/source" connections specific to what goes on inside the shift register chips or would it be possible to rig some similar layout to achieve 'reading the 4x4 keypad' using a 74LS165 ?

The way a multiplexed keypad works is like this usually:
The 4 rows are driven high from output pins, the 4 columns are on 4 input pins.
One row is driven low - the columns are read one at a time. If a column reads low, the intersecting button is the one that was pressed.
The row is returned high, the next row is turned low, and the process is repeated.

This can be automated by having PCINT for each column pin. Hold all rows low, have pullup resistors on the column inputs (can be the internal resistor). When any button is pressed, a low PCINT is created. Bring all Rows high, and quickly scan the buttons to see which one is closed. The mechanical button press lasts quite a while.

So, having 8 inputs does not really get the job done. You could combine a 74HC595 and 74HC165, use 4 pins on each, with SPI.transfer() to write & read the data very quickly.
Need SCK, MISO, MOSI, and a latch pin. Write the HC595, use 2 pulses - first loads the data into the output shift registers. 2nd loads it a second time, but also latches the state of the column pins into the HC165, which you then read in.

SPI.transfer(rowData); // 1 of 4 low
digitalWrite (ssPin, LOW);
digitalWrite (ssPIN, HIGH); // data moved to outputs of HC595
digitalWrite (ssPIN, LOW); //
digitalWrite (ssPIN, HIGH); // HC165 data latched in
inByte = SPI.transfer(dummyByte); // could be clever, and output the next row data!

CrossRoads:
The way a multiplexed keypad works is like this usually:
The 4 rows are driven high from output pins, the 4 columns are on 4 input pins.
One row is driven low - the columns are read one at a time. If a column reads low, the intersecting button is the one that was pressed.
The row is returned high, the next row is turned low, and the process is repeated.

i realise my fundamental error was that the 4x4 keypad is not a device with 8 output pins (to be read by the '165 chip) but one that has "only" 4 outputs, which are dependent on the other 4 pins which are inputs !

CrossRoads:
...
...
So, having 8 inputs does not really get the job done. You could combine a 74HC595 and 74HC165, use 4 pins on each, with SPI.transfer() to write & read the data very quickly.
Need SCK, MISO, MOSI, and a latch pin. Write the HC595, use 2 pulses - first loads the data into the output shift registers. 2nd loads it a second time, but also latches the state of the column pins into the HC165, which you then read in.

SPI.transfer(rowData); // 1 of 4 low

digitalWrite (ssPin, LOW);
digitalWrite (ssPIN, HIGH); // data moved to outputs of HC595
digitalWrite (ssPIN, LOW); //
digitalWrite (ssPIN, HIGH); // HC165 data latched in
inByte = SPI.transfer(dummyByte); // could be clever, and output the next row data!

i gathered as much that i'd have to go down that route to deal with the "non-input" pins and i suppose since i'm using SPI, only one extra pin would be required instead of the 4 if driven direct from the Arduino.

your code uses the same ssPin for the '595 and the '165 - does that mean one can connect both the '595 Latch pin and the '165 Latch (/PL) pin to the same Arduino pin ?

thanks for the comment about the 'PCINT' will read up on it - am not yet into the world of hardware pins and interrupts so will keep that in "The Queue" for now.

one can connect both the '595 Latch pin and the '165 Latch (/PL) pin to the same Arduino pin ?

Yes. Just need to smart about doing it so the HC595 data is not overwritten wiith something different than intended while latching the HC165 data.

What you need is a combination of shift-in and shift-out. See here:
http://www.codeproject.com/Articles/146430/Keypad-Scanning-Hardware-Firmware

The code provided is not an arduino-sketch though. So if you figure out how to do this on Arduino, let me know.

Peter