Go Down

Topic: 74HC164 just use 3 pin as 74HC595? (Read 1 time) previous topic - next topic


In my Project, I need a lot of 74HV164 for inputs but I notice that it need one additional pin for each 74HC164 Logic equiment; so, if I need for example 64 74HC164 for input, then I need 35 pins to read 512 inputs, correct? But I can two pieces of 74HC595 to send data to with four pieces of 1:4x16 for switch which 74HC164 the program will need to read. Is that this solution good idea?

I have read a lot about 74HC595 Logic, I see that I need 200 pieces of that. Is that able to run with arduino MEGA2560?

54 pins.
6 pins for input as I described above.
48 pins left
12 pins for 200 pieces, 16 in parallell each 3 pins.
36 pins left for other equiments.


Jan 13, 2016, 05:44 pm Last Edit: Jan 13, 2016, 05:45 pm by DuaneDegn
I'm not familiar with the '164 chip but I've used lots of '165 and '595 chips in projects. The '165 can be daisy chained just like the '595. Adding an additional '165 doesn't require the use of an additional I/O pin.


Hi, what are these 512 inputs? Switches?

There may be a much better way to read these inputs using far fewer components.



I will be building an home cockpit flight simulator.

Now I have a new question about the '165 and '595. How many instructions cycles does it take to read multiple each '165 and write multiple each '595? I want to knowing how long time it takes in nanoseconds.


Jan 13, 2016, 10:10 pm Last Edit: Jan 13, 2016, 10:13 pm by LarryD
You can determine the time by reading micros before and after.
No technical PMs.
If you are asked a question, please respond with an answer.
If you are asked for more information, please supply it.
If you need clarification, ask for help.


Jan 13, 2016, 11:03 pm Last Edit: Jan 13, 2016, 11:18 pm by DuaneDegn
Based on some logic analyzer traces I have from a past project, it looks like the Arduino UNO's SPI clock runs at 4MHz (250 nanoseconds clock period). There will be bit (or a lot) of overhead as you move data around so your data rates won't be the full 4Mbps but you should be able to read switches and light LEDs plenty fast.

I think I was clocking bits out at about 10MHz to drive '595 shift registers fast enough to use the chips to control the brightness of LEDs with PWM. The Arduino isn't as fast as the microcontroller I was using in the video but 4MHz is still plenty fast.

The '595 chips should be able to set a lot of LEDs on or off very quickly. You should be able to read the '165 chips as fast as you can write to the '595 chips.

Just don't try to drive the chips with digitalWrite. Use the Arduino's hardware SPI port.

I'm not positive, but you should be able to read from the '165 chips at the same time you're writing to the '595 chips.

As suggested by Paul, there are likely better ways of dealing with lots of LEDs and switches. The LEDs I controlled using '595 shift registers were multiplexed so four '595 chips could control 192 LEDs.

You can also multiplex the inputs. I've used a combination of '595 and '165 chips to read keypad input. You could wire your buttons in a way which would allow them to be read in a similar manner to keypads.


I want to knowing how long time it takes in nanoseconds.
The hardware SPI port will run at up to 8MHz on a 16MHz Uno. So that's one byte every 1,000ns. 64 bytes would take 64,000ns. But the overheads of dealing with that data in your sketch would be many times more than that, i suspect.


The hardware SPI port will run at up to 8MHz on a 16MHz Uno.
Are you sure about this? My logic analyzer traces showed a 4MHz SPI clock but I'm not positive I was using my 16MHz Uno (but I thought I was). I might have used an 8MHz Pro Mini.

I suppose it's also possible the code I was using didn't use the SPI port at full speed.


See SetClockDivider(). 4Mhz is the default on most Arduino.

But its an accademic question. For some reason the OP is expecting an answer in nanoseconds and is going to be dissapointed.


I want to knowing how long time it takes in nanoseconds.
Wrong unit.  You mean microseconds.


SPI will certainly run at 8 MHz, I did a project where I clocked out 45 bytes to 45 shift registers, with some coding tricks the data can be shifted out in 17 clock cycles per byte.
The 45 bytes was taking 47.8uS.
I was using a '1284, with 14000+ bytes of SRAM holding the pattern I was shifting out at 20 KHz rate (1 frame of 45 bytes every 50uS).
Code: [Select]

// capture data
digitalWrite (latchPin, LOW);
digitalWrite (latchPin, HIGH); // data on shift in register captured
dataInArray[0] = SPI.transfer(dataOutArray[0]);  // read in captured data while sending data to shift out register
dataInArray[1] = SPI.transfer(dataOutArray[1]);
dataInArray[198] = SPI.transfer(dataOutArray[198]);
dataInArray[199] = SPI.transfer(dataOutArray[199]);
digitalWrite (latchPin, LOW);
digitalWrite (latchPin, HIGH); // data on shift out register transferred from input stage to output stage

You may have to tweak the control lines a little, maybe use two, but this is the basic idea.
I would also use direct port manipulation vs digitalWrite to save more time.
Do not put the SPI.transfers in a loop, that slows it down big time.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.


To Paul___B: Yes, I am wrong With nanoseconds, I mean microseconds.

To CrossRoads:
You have measured it. Now I have an idea how long it takes.
Where do you found '1284 With more than 14 kB of SRAM? I thought it just has 8 kB?
You said: I would also use direct port manipulation vs digitalWrite to save more time.
Do not put the SPI.transfers in a loop, that slows it down big time.
Yes, I have read about digitalWrite that it uses more time than direct port manipulation.
Do you mean do not put SPI.transfers in such as while or for loop?

Or I can use a mix of those such as

dataInArray[0] = SPI.transfer(dataOutArray[0];
...repeat 3 times....

for ( ... = 4; 4 < 7;  i++ ) {}

...[8] = ....[8];
... repeat 3 times...

for ( = 12; 12 < 15; i++ ) {}

and so in...

Go Up