74HC589 (parallel in, serial out) shift register - Latch Clock & Shift/Load

[wb0gaz]

I could use help determining if I can use 74HC589 (block diagram attached as PNG) as an input expander controlled by a 3-wire microprocessor interface (clock, shift, and enable, where the microcontroller uses enable to tell the 74HC589 that it is reading whatever was present on the inputs as a serial data stream.)

My difficulty arises from the separate Latch Clock (leading high-going edge captures whatever's on the inputs to a 8 D flip-flops) and shift (high) load (low) which presents 8 RS flip-flops facing the serial output pin.) Can I use a single line from the microcontroller which when it goes from low to high captures what's on the 8 inputs, and remains high while shifting *those* 8 bits out to the microcontroller? I keep thinking there's a timing problem as when the latch clock goes high, at that instant the Shift/Load would also be going high, so it wouldn't have time to capture what's just then being stored into the input D flip flops.

I'm not sure if the part was intended to be used this way, but then the data sheet (onsemi, URL below) has early in the text "The HC589A directly interfaces with the SPI serial data port on CMOS MPUs and MCUs."

I do not have I2C available, and don't have an extra microcontroller pin to separate drive latch clock and shift/load.

Thanks for any observations!

https://www.onsemi.com/pdf/datasheet/mc74hc589a-d.pdf

[Ian.M]

See page 7 of your linked datasheet.   
You presumably want a SPI-like interface, so  /SS goes low then your MCU clocks SCLK and shift in data on MISO, and finally, after SCLK goes back to its idle state, /SS goes back high.

Therefore '589 Serial Shift/nParallel Load  needs to be driven by inverted /SS, and '589 Latch Clock needs to go high *BEFORE* Serial Shift/nParallel Load goes high.  You *could* simply drive '589 Latch Clock from /SS and accept that the data returned will be sampled at the end of the previous SPI transfer, working around the delay if you have to by toggling /SS before setting it low to start the SPI transfer.   Alternatively you could delay  '589 Serial Shift/nParallel Load by about 300ns (to cover the propagation delays) and drive '589 Latch Clock from inverted /SS.

[Picuino]

You can do it with 3 wires:
74HC589 Output  <--> uC Input
74HC589 Latch clock <--> uC Output
74HC589 Shift clock  <--> uC Outuput
74HC589 Output enable  <--> Vdd

74HC589 Serial Shift/Parallel load   need other uC ouput. Perhaps you can connect to 74HC589 Shift clock pin, but you should test it on a protoboard first.

Regards.

[David Hess]

My difficulty arises from the separate Latch Clock (leading high-going edge captures whatever's on the inputs to a 8 D flip-flops) and shift (high) load (low) which presents 8 RS flip-flops facing the serial output pin.) Can I use a single line from the microcontroller which when it goes from low to high captures what's on the 8 inputs, and remains high while shifting *those* 8 bits out to the microcontroller? I keep thinking there's a timing problem as when the latch clock goes high, at that instant the Shift/Load would also be going high, so it wouldn't have time to capture what's just then being stored into the input D flip flops.

It also looks to me like there is a race condition between the latch and load inputs.  Is there some reason you cannot use the 74HC165 instead?

The load input of the 74HC165 can be combined with the load output of the 74HC595 to do simultaneous parallel input and output from a SPI port.

[wb0gaz]

Thank you! That was quick!

I think from these helpful comments this device won't be a good solution. In particular, I didn't read closely enough the datasheet, and the 3-state output is enable-low, not enable-high (I had needed 3-state output to be active only when clocking data from the device to the microcontroller with SHIFT/LOAD high). The other complication (Latch Clock vs SHIFT/LOAD) would cause lagged data (not a problem as the application would be polling the device frequently enough that latency won't be a problem), however, it also was concerned about a race condition (David H comment) when driving Latch Clock and Shift/Load with the same signal.) Creating a time lag sounds like an interesting possibility, but the 3-state output control line is actually the show-stopper.

Unfortunately, the 74HC165 lacks a 3-state output which is needed as the microcontroller pin accepting serial data from the device is shared with another application that will be making use of that pin when the shift register isn't be read.

Thanks very much for the helpful comments!

[Ian.M]

What's the problem?  You can easily fix up any control signals that need inversion with a 74LVC1G04.

[wb0gaz]

Ian M. -

Good idea!

This is a prototype and adding a part (inverter) wouldn't be a problem.

That would correct the logic state for the 3-state output.

If I invert the signal going into Latch Clock, that clocking will "happen" on the opposite edge of the combined control signal, which still introduces a next-read latency but again isn't a problem.

This fixes another problem I hadn't mentioned, because the 3-state output needs to get morphed into an open drain output (as it's going into an open drain signal path).

I'll just use a 74HC05 which would take care of the two inversions needed and the open drain requirement (so 4 of the 6 gates get used, and 3 pull-up resistors are needed. This isn't a high speed application so open drain with pull-up is sufficient to get a logic '1' given the T=RC rise time involved.

Thanks for the idea!

:-) :-)

[Ian.M]

To fix the Tristate output to open drain compatibility, I'd simply use a Schottky diode.   If you *NEED* two inversions, I'd use a 74LVC2G04 but as you only have a single select signal, you should only need a single inverter e.g. 74LVC1G04 unless your SPI mode is incompatible with the '589's shift clock to data out latency.

Of course if you are prototyping, use whatever inverter you've got handy, then order the optimum parts when you layout the final PCB.

[wb0gaz]

That (schottky diode) was my plan at first (I didn't mention it because it looked like a trivial solution that would work), however, the inverter is needed anyway. If this becomes something that's production, the microcontroller pin constraint would get addressed and that would either simplify the expansion method (vs. HC589) or do away with it altogether.

Thanks again, much appreciate your time!

Dave

[David Hess]

however, it also was concerned about a race condition (David H comment) when driving Latch Clock and Shift/Load with the same signal.) Creating a time lag sounds like an interesting possibility, but the 3-state output control line is actually the show-stopper.

The old TI datasheet actually mentions it:

NOTE 2: The RCK t toSRLOAo'setup time ensures the data saved by RCK t will also be loaded into,the counter.

The setup time is 40 nanosecond on the original TTL part, but annoyingly the HC datasheets do not list the minimum setup time.  In either case, it could be generated with a short RC delay between RCL and -SLOAD

Unfortunately, the 74HC165 lacks a 3-state output which is needed as the microcontroller pin accepting serial data from the device is shared with another application that will be making use of that pin when the shift register isn't be read.

The serial outputs are usually not 3-state because it is assumed that the registers will be daisy-chained together rather than operated in parallel.  If you did need the serial outputs to be in parallel, and activated with -CS or whatever, then a separate 3-state or open collector driver would be added, or maybe preferably a multiplexer used.

I did a search through The Book and did not find anything more suitable to what you are trying to do, other than the 74HC165 which is still my preferred part in combination with the 74HC595.  There may be something more modern, or possibly a 4000 series CMOS part?

[wb0gaz]

Thanks for the additional detail. An RC delay sounds workable, however, it brings back some memories of 74123 one-shots in the 1970s, and as I still have to solve the open drain/off the bus problem (I hadn't included that in the original posting, so guilty of scope-creep here), it appears I'll need some extra glue anyway.

I'm reusing SDA on an I2C bus (when it's not otherwise busy) as the path into the microcontroller, so the shift register also needs to be off the bus when not selected (I'm not actually emulating I2C; I just bit-bang when reading the shift register, and do "real" I2C when I need to do that). That's what pulled me towards the 589 + "something" in the first place, and the 74HC/HCT05 seems to be the only common (current production) logic gate with open drain output (and being just an inverter, I can't get the logic "and" that would be needed to support the 165.

Thanks for the interesting ideas, much helpful!

[langwadt]

Thanks for the additional detail. An RC delay sounds workable, however, it brings back some memories of 74123 one-shots in the 1970s, and as I still have to solve the open drain/off the bus problem (I hadn't included that in the original posting, so guilty of scope-creep here), it appears I'll need some extra glue anyway.

I'm reusing SDA on an I2C bus (when it's not otherwise busy) as the path into the microcontroller, so the shift register also needs to be off the bus when not selected (I'm not actually emulating I2C; I just bit-bang when reading the shift register, and do "real" I2C when I need to do that). That's what pulled me towards the 589 + "something" in the first place, and the 74HC/HCT05 seems to be the only common (current production) logic gate with open drain output (and being just an inverter, I can't get the logic "and" that would be needed to support the 165.

Thanks for the interesting ideas, much helpful!

you would get you enable and open-collector with a single npn/n-ch mosfet

base/gate is your enable, emitter/source your signal, and collector/drain your output

[David Hess]

Thanks for the additional detail. An RC delay sounds workable, however, it brings back some memories of 74123 one-shots in the 1970s, and as I still have to solve the open drain/off the bus problem (I hadn't included that in the original posting, so guilty of scope-creep here), it appears I'll need some extra glue anyway.

It is not really good technique to use an RC delay, but it works out well enough at low impedances and low delay times.

I'm reusing SDA on an I2C bus (when it's not otherwise busy) as the path into the microcontroller, so the shift register also needs to be off the bus when not selected (I'm not actually emulating I2C; I just bit-bang when reading the shift register, and do "real" I2C when I need to do that). That's what pulled me towards the 589 + "something" in the first place, and the 74HC/HCT05 seems to be the only common (current production) logic gate with open drain output (and being just an inverter, I can't get the logic "and" that would be needed to support the 165.

That makes sense.  My solution has been to implement 4-wire SPI with the 4th wire being the load and update which drives both the 165s and 595s.  But if you do not have that many port bits available, then other arrangements have to be made.

In some applications it is actually better to replace the 595 with a 164 which lacks the output register because then updates become visible to the user.  You can see this on 80s oscilloscopes from Tektronix like the 2247A and 2400 series where the display lamps blink from the update when a control is operated.  It give s them a sort of "life".

you would get you enable and open-collector with a single npn/n-ch mosfet

base/gate is your enable, emitter/source your signal, and collector/drain your output

That is much better than using a schottky diode.

[Ian.M]

Unless there's an address conflict, why not simply throw a PCF8574(A) 8 bit I2C I/O expander on the I2C bus?