Using multiple 74HC165 and 74HC595 on the same SPI along with other SPI devices? - Page 1
Forum section: electronics / projects

author: kreyszig
author_rank: Regular Contributor
timestamp: February 10, 2023, 01:20:02 pm
content: Hi,I am designing a circuit where I need to read DIP switch positions using 74HC165 devices and where I need to drive LEDs using 74HC595 devices. I would like to connect both types of devices using the same SPI, and keep the SPI available for other SPI devices as well. I don't need anything fancy in terms of buffer functionalities. I only need to read the switches once when the 74HC165s are enabled, and I only need to set the LED state once when I enable the 74HC595s. I don't need the 3-state of the 74HC595s. What I want though is for these buffers to ignore anything going on the SPI lines when their NSS line is held high.My understanding is that I need to add some extra components in order to get a 3-state MISO output (74HC165 device), to share a common MOSI line between a 74HC165 device and possible other SPI devices, and also to share the clock between a 74HC595 device and other devices. I tried using a 74LVC buffer for the 3-state output, and gates for the other functionalities (OR gate for the 74HC165s and AND gate with one inverted input for the 74HC595s). So I came up with the attached schematic.Is there anyone that can tell me if this makes sense and should work, including how I tie the RCLK of the 74HC595s to NSS1 and how their SRCLK line goes through the 74LVC1G97? My understanding is that I don't need any external pull-up/pull-down for this design? I could not find a way to drive the parallel load line of the 74HC165s from the NSS line without adding another device...To me it seems the circuit should allow to drive several 74HC's of both types, in addition to support additional SPI devices, either through the usage of multiple NSS lines or through MISO/MOSI daisy chaining. I could not really find anything equivalent by googling around.... Thanks!

author: ledtester
author_rank: Super Contributor
timestamp: February 10, 2023, 02:43:51 pm
content: In your schematic the output of the 74LVC97 and the NSS1 signal appear to be connected together -- looks like a mistake.The outputs of the 595's won't change until you pulse RCLK. So how about connecting MOSI and SCK directly to the 595's and allocate another GPIO to control the RCLK pins.To send data to the 595's, shift out 16 bits and then pulse RCLK.When talking to other SPI devices just activate the device's CS line, perform the SPI transaction as normal. The 595's will also receive the SPI traffic from MOSI but if you don't pulse RCLK they won't change their outputs.

author: kreyszig
author_rank: Regular Contributor
timestamp: February 10, 2023, 02:52:46 pm
content: Thanks!Quote from: ledtester on February 10, 2023, 02:43:51 pmThe output of the 74LVC97 on pin 4 is connected to SRCLK and not to NSS1?QuoteOn the datasheets I was looking at for the 595's (https://www.ti.com/lit/ds/symlink/sn74hc595.pdf,https://assets.nexperia.com/documents/data-sheet/74HC_HCT595.pdf), it looked like RCLK going high is needed, but a pulse (up/down) was not? This is why it seemed to make sense to me to tie it to NSS so the outputs get updated when NSS goes high at the end of the communication? On the other hand, pulsing of the parallel load for the 165's seemed to be needed.Thanks!

author: ledtester
author_rank: Super Contributor
timestamp: February 10, 2023, 03:20:23 pm
content: Quote from: kreyszig on February 10, 2023, 02:52:46 pmHere is the connection:QuoteQuoteTo talk to a 595:- first make sure RCLK is low- shift out 16 bits of data- bring RCLK high and then low again- shift out more data- bring RCLK high and then low...Data is latched only on a low-to-high transition of RCLK, but in order to do a second low-to-high transition you need to bring RCLK low so that's why you bring it low right after you bring it high.Here's some more info with an animation:https://microcontrollerslab.com/74hc595-shift-register-interfacing-arduino/

author: kreyszig
author_rank: Regular Contributor
timestamp: February 10, 2023, 03:30:22 pm
content: Quote from: ledtester on February 10, 2023, 03:20:23 pmOups sorry you are right, I had not noticed this connection, it was not intended.QuoteBut in my case I want to shift 16 bits of data, then bring RCLK high and then after that I am done with this SPI transmission to the 595's, i.e. I want to bring NSS1 high again. So if I tie RCLK to NSS1, it will bring RCLK down again the next time I bring down NSS1 to update the 595's. Is there any reason why this would not work? Thanks!

author: ledtester
author_rank: Super Contributor
timestamp: February 10, 2023, 03:42:32 pm
content: Simply tie NSS1 to the RCLK pins of the 595's and nothing else.I don't see the need for the 74'97. RCLK/NSS1 will not change when SCK is changing and vice-versa.See the code in the link I mentioned above.

author: kreyszig
author_rank: Regular Contributor
timestamp: February 10, 2023, 03:50:21 pm
content: Quote from: ledtester on February 10, 2023, 03:42:32 pmYes I agree that removing the 74'97 will not affect the state of the storage registers. It only disables shifting between the shift registers. It probably just reduces power consumption and wear...

author: Benta
author_rank: Super Contributor
timestamp: February 10, 2023, 08:18:47 pm
content: You're overcomplicating this, and it's totally unnecessary.SPI is really very, very simple.You can use it in a "star" topology, but then you need a lot of chip-select lines, so we'll forget that here.Or you can use it as originally intended, which is very elegant.In your case, you have aringof five shift registers, each with its ouput connected to the next register's input (or vice versa, each SR's input connected to the previouse SR's output). In short: a ring. All clocked together on one clock.In your case, two 74HC595 and two 74HC165 (or 74HC597) in series, followed by your controller's shift register (number five).The controller has the MISO/MOSI inputs/outputs and controls clocking of the whole ring. Additionally, it needs an output pin to control the input and the output latches. That's all. No need for extra logic etc.The only thing you need to be careful of is the clock polarity/phase. SPI has four modes here. the Master mode needs to match the 74HC devices.I don't remember which is the right one, but it's easy to check.Yes, it's really that simple.

author: kreyszig
author_rank: Regular Contributor
timestamp: February 10, 2023, 10:14:14 pm
content: Quote from: Benta on February 10, 2023, 08:18:47 pmThanks for your feedback. For my application I do not want to read the 165s every time I use the 595s (typically I would read the 165s once at startup then I would drive the 595s very frequently), so this is why I was looking to use a separate chip-select for both. Note that I am using a total of two chip select lines though, so I don't think it necessarily results in using more output pins compared to using separate controls for latches? Also if I want to be able to support additional SPI devices, isn't it less constraining to add a 3-state to the 165s MISO so the star topology is still possible?

author: Benta
author_rank: Super Contributor
timestamp: February 10, 2023, 11:20:19 pm
content: Quote from: kreyszig on February 10, 2023, 10:14:14 pmI get how you're thinking, but a lot of it is still unnecessary. You need to see the simple beauty of the SPI interface.We're talking DIP-switches and LED outputs at this point, right? Both slow, I think.Does it matter if you have to shift 32 bits or just 16 bits? I don't think so.It can all be done in your firmware. An example for initialization (presumes the 'HC595s are first in in the chain for simplicity, but you can rearrange as you like):1: send 2*8 SPI bits containing LED data.2: assert the latch signal. Now the LEDs are (re)set and the DIP switches are read.3: send another 2*8 bits while reading the SPI controller. Now you've read the DIP switches and the LEDs stay the same.Done.You can update the LEDs any time by sending 2*8 bits and asserting the latch signal. Ignore the MISO input.Simple, no?Now, concerning multiple SPI rings, which is your wish. Exactly what is circulating in your SPI ring shift registers can be ignored completely. It's only relevant when you assert the latch signal for the relevant devices.You can have N SPI rings running in parallel, (each with their own latch signal) and the data running through them is garbage, except to one. And that's the one you assert the latch signal to.You may need to use more complex SPI chips, but that's easily solved by adding a chip-select signal to that one.Happy SPI'ing

author: DavidAlfa
author_rank: Super Contributor
timestamp: February 11, 2023, 12:58:59 am
content: You could do it with the 595/165 "in series". The main problem is the data output from the 165, which can't be set to Hi-Z.LEDs: Don't enable any CS. Shift 16 bits out, pulse LOAD_OUT to load the new data into the leds.Switchs: Don't enable any CS. Pulse LOAD_IN to read the switches. Shift 16 bits in.Interfacing the outside world:MOSI: Don't enable CS yet, send 16 data bits (Will be stored in the 595s), enable CS (So the external device expect the data coming next), send the rest of the data (First data starts streaming out of the 595s), then send additional 16 bits (Dummy clocks) to transfer the remaining data stored in the 595s, disable CS.MISO: Enable CS, read 16 bits (Dummy clocks) discarding the data, (Valid data will be available following that), read the desired bytes, disable CS when there're 16 bit remaning (The slave already sent everything, but it's traveling through the 165s), read the last 16 bits.As long as you don't fire any LOAD_* pin, the serial data passing through the registers will be preserved.Alternatively, use a 74HC125 to isolate internal and external MOSI/MISO lines.

author: Benta
author_rank: Super Contributor
timestamp: February 11, 2023, 09:02:46 pm
content: An issue here is, that no one knows what "NSS0" and "NSS1" are. No matter how you look at this, you'll likely need more I/Os than just those two to control an SPI network.So what are they, and do you have more I/Os available?