Latched Shift Register 74HC595 - Control via Single MCU I/O pin

[eblc1388]

I looked with fascination of the single I/O pin shift register control by Roman Black, shown in the image below. (Website www.RomanBlack.com, Shift1 system)

I wonder if I can "improve" the circuit a little better so that it will provide 8-bits of user data instead of seven.

Then I noticed another potential problem regarding the latch signal. I remembered I was taught the CMOS clocking rise/fall time has a worst case limit of a microsecond. One can usually "get away" with it with several microseconds without problem. Checking the 74HC595 data sheet, it surely recommends a max transition time of 500nS on clocking inputs.

Referring to the design, the RC time constant on the DAT pin is perfectly OK but with 33K and 2n2 on the latch pin, the rise time is a whopping 160uS. This is over two order of magnitude over the recommended limit.

Even though the circuit works as stated, I would consider it sloppy design and unreliable.

Criticizing other's idea is easy but what would you do instead? I'm working on a solution that would address both the slow rise time problem and the 7-bit problem, and I'm glad to say there is some light at the end of the tunnel. Don't hold your breath though. It could be a few days before I have a chance to actually test it out on a breadboard. Obviously placing a Schmitt trigger gate before the LAT signal is a solution but where is the fun then?

If the above problem has already been solved I'm not aware of the solution. Please share your idea.
 

[Ian.M]

With cheap OTP SOT23-6 MCUs breaking the ten cent barrier, and a wide choice of fully featured 6 or 8 pin MCUs at around the half dollar price point, you have to be really desperate and probably certifiably insane to consider using Shift1 or similar in a real product.     It falls firmly in the category of hacks you do on protoboard to gain a few pins of debugging LEDs, because you were too cheap or couldn't wait for a single wire I/O expander, couldn't be arsed to program an Arduino to take serial data and drive some LEDs with the resulting binary number, and for *whatever* reason couldn't use a logic analyser or DSO with protocol decoding to view your single wire debug output.

I'm sure your solution will be technically interesting, but as a 74LVC2G17 dual Schmidt buffer would only add a single half-dollar SOT23-6 to the BOM, avoiding Schmidt buffers just makes it even more of a 'niche' curiosity.

[eblc1388]

Thank for your comment Ian, and on the the use of 74LVC2G17.

But even if one uses the chip, one still left with the problem of seven useful data bits instead of eight.

This post is purely of technical interest only. No one including myself would use such a scheme when the I/O pins on microcontroller are so easy to come by.

The real quest is to answer the simple question, can one transfer 8 bits to a latched shift register output or not, using a single MCU pin? Think of it as a circuit design question instead of one with any practical usage.

[Ian.M]

The real quest is to answer the simple question, can one transfer 8 bits to a latched shift register output or not, using a single MCU pin? Think of it as a circuit design question instead of one with any practical usage.

Assuming the constraint of no MCUs or custom programmed logic apart from the one with the single available I/O pin:

Of course you can- its just a matter of generating the latch pulse automatically so that it goes high once the line has stopped pulsing low for the data bits.   Add a Schottky diode (cathode to signal in) and another resistor in series across RT above to get asymmetric rise and fall times, and as long as there isn't an excessive time between bits, it will go low sometime during the first few bits and stay low until a time set by RT after the last bit.

However that doesn't address the slow clock and latch transition issue.   Even the dual Schmitt trigger is a bit of a bodge.  To do that right you need to use a dual monostable - one half for data, and the other for the latch pulse.

[eblc1388]

No ICs or special chips/mcu. 

My idea is to do it with seven jelly bean discrete component, made up of four resistors, one capacitor and one diode. 

It works in LTspice, but the acid test is when I actually build it on the breadboard, flashing 8 LEDs one after another.  This time I'm sure lady luck is on my side.

Oh, wait, that only six components. What is the missing one?

I spoke too soon. An idea just pop into my head. Why would you need a resistor if there is one pullup resistor on the port pin inside the MCU? Why would you need a capacitor if there are strait capacitance on the HC595 input pin? OK..OK. Points taken. I will now try to make it work with only five jelly bean component.

[eblc1388]

Ok, I have attached the circuit diagram and LTSpice simulation.

It is near impossible to generate three different events with a single logic high or low. Another state is required to fullfil the task.

Referring to the circuit, consider what happens to NPN Q2 when:
a) MCU pin is HIGH
b) MCU pin is LOW

The answer is simple. When CLK(MCU pin) is high, Q2 is biased on via R2 and MCU port pin. It conducts and LATCH is low. If CLK is LOW, then Q2 has no bias and stop conducting, giving a HIGH on the collector.

Now, what if I ask what happens if the link(A) between the circuit and the MCU pin is severed? Well, Q2 is still biased via R2 and R3, with the remaining charges from R1/C1. I have chosen appropriate values for R2 and R3 such that Q2 remains in conduction under this case. Therefore the collector voltage remains LOW. The voltage at CLK is not zero, but being the voltage drop across R3 plus the Vbe drop of Q2. If this voltage is 1.5V or lower, then it will be considered a LOW under CMOS logic level. C1 will discharge until it reaches this voltage level, simulating a LOW on DAT line.

While we can't physically severed the connection between the circuit and the MCU, we can achieve the same result by placing the MCU pin in high impedance mode, or to put it simply, changes it from output mode into input mode.

If we alter the timing between the states we can manipulate the DAT voltage level too. The four cases are:

1. MCU pin is High (idle state)
2. MCU pin is disconnected for a short interval (shift a high bit)
3. MCU pin is disconnected for long interval (shift a low bit)
4. MCU pin is LOW (generate LATCH signal)

The next image is the proposed software steps required to generate the signal on the MCU pin. I would code this up on an AVR and see how the design responses. Fingers crossed.

[Siwastaja]

This probably violates the data hold time in the data=0 case. In practice, you'll have delay mismatches, so you may end up violating both setup and hold times.

[eblc1388]

This probably violates the data hold time in the data=0 case.

I don't follow your argument. The data hold time after the SRCLK rising edge is zero in the data sheet. Can you be more specific about where the violation occurs?

In practice, you'll have delay mismatches, so you may end up violating both setup and hold times.

As I understand it, the setup time refers to the minimum time where logic level must be stable before the active edge occurs. The data sheet specify a minimum of 25ns. In my design, while the voltage level is changing,  the logic level is stable within this period. I don't see how the violation occurs.

Please share your ideas and please avoid using words like "probably" or "may", because either it violates or it doesn't.

     

[Ian.M]

7 component proof of concept for the method I posted in reply #3.   

It uses two diode, three resistors and two capacitors, and doesn't need the port pin to go tristate.

It needs a lot of work to tune the pulsetrain timings to guarantee valid CMOS logic levels and check with worst case data bytes, which isn't going to happen unless I take the time to create a LTspice data serialiser model to generate the pulsetrain.

[Siwastaja]

Just wanted to point out what pitfalls may or may not exist. Didn't look at the actual hold time, which seems to be zero for this chip!

What I'm talking about with "may"s are circuit delays not present in your simulation. I don't instantly see how this wouldn't work, but would be interested in seeing if this still works when chaining several. You know, with this architecture, you cannot add delays between data/clk with software to satisfy setup time and make sure the data is clocked on the correct side of the clock.

But you can always make C1 bigger and slow down the communication even more... So looks fairly perfect, is this what you wanted to hear?

This looks rather fun and even though I wouldn't trust it for something serious, it could drive a lot of non-critical indicator LEDs for example from the only remaining IO pin.

[Bassman59]

With cheap OTP SOT23-6 MCUs breaking the ten cent barrier, and a wide choice of fully featured 6 or 8 pin MCUs at around the half dollar price point, you have to be really desperate and probably certifiably insane to consider using Shift1 or similar in a real product. 

Hell, for that 50 cents you can get a 16-pin micro, which you can use its UART’s receiver peripheral to get incoming data from the main micro’s transmitter, and break it out to the 8 pins as required. (Remember you need power and an incoming data pin.)

It’s one chip, and a decoupling cap. The rest of this thread is kinda silly.

[eblc1388]

7 component proof of concept for the method I posted in reply #3.

I ran your simulation file and note that the LAT signal still suffer a long rise time of over 20us. I guess this slow rise is inherent to the design and you can't tweak the component values to make it faster. Also the two set of RC time constants would likely affecting each other and tweaking one of them will cause the other to go off limit.

But thanks for taking the time to test out the concept. 
 

[eblc1388]

I don't instantly see how this wouldn't work, but would be interested in seeing if this still works when chaining several. You know, with this architecture, you cannot add delays between data/clk with software to satisfy setup time and make sure the data is clocked on the correct side of the clock.

If by saying "chaining several" you meant cascading several HC595 together, then I see no reason why there will be any problem. The DAT signal is connected to the first hc595(SR) only and the second SR get its DAT signal from the last register output QH' of the first SR. The DAT of the third SR is getting its signal from the second SR in similar fashion. All logic levels, except the DAT input of first one are stable between clocking. As the clocking is common to all cascading SRs, there will not be any additional delay as the direct result of cascading.

In my design, the clock determine the DAT level so DAT is not freely changing. The clocking will always occur on the "right" side. HC595 does not response to the falling edge of clocking.

In addition, the clocking rising edge used is actively driven by the MCU output pin instead of from a signal via a RC combo, therefore it can drive many(20?) HC595 without issues.     

This looks rather fun and even though I wouldn't trust it for something serious, it could drive a lot of non-critical indicator LEDs for example from the only remaining IO pin.

That's the spirit. What would I want to design such a thing? Simply because I can and its a lot of fun.

If you think it is unreliable, why don't you try it out and locate its weak points. Demonstrate it is unreliable. BTW, how can one determine if a certain design is reliable or not? Say if I shift out one million different bytes and read back the bytes via the MCU, if there is no error in one million such trials, can the circuit be call reliable, in a hobby application sense?


 

[David Hess]

Then I noticed another potential problem regarding the latch signal. I remembered I was taught the CMOS clocking rise/fall time has a worst case limit of a microsecond. One can usually "get away" with it with several microseconds without problem. Checking the 74HC595 data sheet, it surely recommends a max transition time of 500nS on clocking inputs.

Referring to the design, the RC time constant on the DAT pin is perfectly OK but with 33K and 2n2 on the latch pin, the rise time is a whopping 160uS. This is over two order of magnitude over the recommended limit.

The maximum transition time of 500 nanoseconds only applies to the clock input.  The data and latch inputs do not have a restriction and can tolerate as slow a transition time as you like because they do not affect internal state; only their level at the time of a positive clock transition matters.

To put it another way, if the clock input was double clocked, that would screw things up by causing a second shift.  If the data or latch inputs were double clocked, nothing would happen.

[eblc1388]

If the data or latch inputs were double clocked, nothing would happen.

Yes, agree.  As the shift clock and the latch clock are both feeding to internal FFs, and datasheet always shows the same positive going edge requirement in the truth table for both, I thought they should be subjected to the same clocking constraints.

I  was biased towards a very slow clock would not work reliably, and results in no latching at all.     

[David Hess]

If the data or latch inputs were double clocked, nothing would happen.

Yes, agree.  As the shift clock and the latch clock are both feeding to internal FFs, and datasheet always shows the same positive going edge requirement in the truth table for both, I thought they should be subjected to the same clocking constraints.

I  was biased towards a very slow clock would not work reliably, and results in no latching at all.

Oh, does the latch input drive D flip-flops or an actual transparent latch?  I guess we know from the datasheet's truth table that it is always a D flip-flop so it might cause a problem as you suggest.  Transmission gate logic is weird.  You could test it to see if it fails at any reasonable transition time although this could vary significantly with manufacturer.

This varies by manufacturer even with the same CMOS part but some include schmitt inputs for clock inputs.  The Diodes Incorporated datasheet specifically says "Schmitt Trigger Action at All Inputs" but has the same input transition specifications as the Texas Instrument part.

[eblc1388]

The Diodes Incorporated datasheet specifically says "Schmitt Trigger Action at All Inputs" but has the same input transition specifications as the Texas Instrument part.

I guess it is an improvement to the previous design.

The Diode Incorporated datasheet also specifically mentions "All registers capture data on rising edge and change output on the falling edge." in the part description which I don't find in datasheet of other manufacturers, which says "content of previous stage appears on the output of the next stage after the positive going edge of the shift clock". Now I'm confused.

Is the Diode Inc part differs to other parts regarding the operation of shifting data? If the shift clock goes high and remains high, does the arrival of the latch pulse moves the "old data" or the most recent shifted data to the output registers?

[eblc1388]

Good news. My little circuit works as expected. I have eight LEDs flashing one by one.

The circuit takes 7 components but I said I can made it works with 5. I did modify the software to include the port pin internal pullup resistor and remove the 68K and 150pF capacitor. In addition, I have increased the 5K6 resistor value to 180K. Yes, it does work with just 5 components but this is would be unreliable as it depends too much stray capacitance. 

For those who are interested, here is a Youtube video I made. Have fun.

[David Hess]

The Diodes Incorporated datasheet specifically says "Schmitt Trigger Action at All Inputs" but has the same input transition specifications as the Texas Instrument part.

I guess it is an improvement to the previous design.

The Diode Incorporated datasheet also specifically mentions "All registers capture data on rising edge and change output on the falling edge." in the part description which I don't find in datasheet of other manufacturers, which says "content of previous stage appears on the output of the next stage after the positive going edge of the shift clock". Now I'm confused.

Is the Diode Inc part differs to other parts regarding the operation of shifting data? If the shift clock goes high and remains high, does the arrival of the latch pulse moves the "old data" or the most recent shifted data to the output registers?

I am pretty sure the Diode Incorporated part is identical to the Texas Instruments part but who really knows?  At least they have the same specifications for their clock and latch inputs.  I have run across the Schmitt trigger input issue on HCMOS parts before; some manufacturers specifically state that they use them for certain inputs and some do not on the same part.

Test them and find out.  Make a test circuit and measure when or if the clock and latch inputs fail when driven by a variable transition time edge.  If they really have Schmitt trigger inputs, then a slow edge should not matter except for noise immunity.

[TerraHertz]

https://en.wikipedia.org/wiki/1-Wire