next topic »

[on:]

I am interested in interfacing my Arduino to both:

• a 74HC595 shift register (via SPI), to control some LEDs
• and an SD-card (also via SPI)

Since they share the same SPI port, based on my understanding, I would need to Chip-select (CS) when speaking with one versus the other.

With the SD-card, this is simple because it has a CS pin.
But the 74HC595, according to the datasheet, doesn't have one (although it has an Output-Enable pin).

I want to ensure two things:

• that writing to the SD card won't randomly turn on and off various LEDs because of interfering SPI communication
• and likewise, that controlling desired LEDs via the shift-register won't cause weird activity on the SD-card because of interfering SPI (but I think I'm safe in this 2nd case, because the SD-card has chip-select).
  

What might be a way to accomplish this?

(PS: I could bit-bang the 74HC595 but that would cost me extra pins that I could use for other things! Hence I'm using SPI.)

[Reply #1 on:]

You should be able to do it with the ST pin (12) which is "storage register clock input". Absent a rising pulse on that it won't shift any data into the output latches.

http://www.gammon.com.au/forum/?id=11518

[Reply #2 on:]

Use the output strobe pin.

Or a hc164.

[Reply #3 on:]

OK, so how about something like the below then?

Part 1: Hardware-side



Part 2: Software-side

• With the SEL_SdCard pin held LOW (active), I can write to the SdCard, then once done, pull the SEL_SdCard pin HIGH.
• Then, with the SEL_74HC595 pin held LOW, I can write to the 74HC595 registers, then bring SEL_74HC595 pin HIGH. The chosen LEDs now turn ON or OFF as was instructed (/written to the registers), and are maintained that way (until the shift-register is communicated with again).
• And then continue by starting again with the SdCard when necessary, then the 74HC595, and so on.

[Reply #4 on:]

Yes, that was what I had in mind. Plus ground and power of course.

[Reply #5 on:]

@Nick:
Noted; thank you.
And I'll probably add a pull-up on the LATCH, something that your webpage notes.

[Reply #6 on:]

@Nick:
I have a question:

On your webpage, for the Latch pin on the 74HC595, you state:
"The 10K pull-down resistor on the SS (Slave Select) is designed to keep the registers from clocking in bits while the main processor is booting, and the SS line might be "floating" and in an indeterminate state."

Is there a reason why you chose to pull down (i.e., to GND) specifically, and not a pull UP?

[Reply #7 on:]

Pin 12 (which I label SS) is the ST_CP pin on the chip (storage register clock input). The wiring diagrams show it is normally low and active on the rising edge. Thus I wanted it to start low and then be brought high when data was present, eg.

Code:

  digitalWrite (LATCH, LOW);
  SPI.transfer (c);
  digitalWrite (LATCH, HIGH);

The SPI.begin() probably defeats that a bit because it brings SS high. However hopefully by that stage there are no clock pulses so it shouldn't do too much harm.

[Reply #8 on:]

Data is strobed out on the rising edge of latch. So for it to have been correctly implemented, you need to pull it up to avoid spurious strobing.

Also strobing should not be part of your spi routines as it needs to be done by user program for cases where multiple bytes are to be transmitted in one frame.

[Reply #9 on:]

Data is strobed out on the rising edge of latch. So for it to have been correctly implemented, you need to pull it up to avoid spurious strobing.

This may be correct. It then starts off high, and then is pulled down and back up.

Also strobing should not be part of your spi routines as it needs to be done by user program for cases where multiple bytes are to be transmitted in one frame.

This was the user program.

[Reply #10 on:]

Pin 12 (which I label SS) is the ST_CP pin on the chip (storage register clock input). The wiring diagrams show it is normally low and active on the rising edge. Thus I wanted it to start low and then be brought high when data was present, eg.

Noted. Thanks for the clarification.