74hc595 shift registers, what am I doing wrong?

I getting the feeling you're not hardware guy. The 2n7000 you asked about earlier is an ancient jelly-bean part, and TTL+pullup dates to CD4000 days.

Of course the TTL drives better--it has a totem-pole output. Even worst case it yanks up quickly past 3v. A pull-up makes it kosher.

He linked to an page with a FET used common-gate as a bidirectional i2c level translator, and said he was using that.

It had 10k pullups and perhaps 50-100pF load (up to 50pF just for the 2n7000). That's not going to drive HC "just fine," the rise time will be >500nS. How well that works has already demonstrated, and adding more capacitance kills it altogether.

Cheers, James Arthur

Reply to
dagmargoodboat
Loading thread data ...

as others have said, your problem is likely to do with the clock edges..

my suggestion, low pass filter the clock to remove ringing and crosstalk gl itches, then pass the low pass filtered signal through a schmidt trigger to square it back up that is located next to your register, use a short conn ection from the schmidt to the register less then one inch

Mark

Reply to
makolber

You'd be better off using a NPN level shifter or even a Darlington. Ton is much lower than the FET is.

Jamie

Reply to
Maynard A. Philbrook Jr.

Junk box to the rescue!

I put the scope on it again, paying particular attention to the rising and falling clock edges and there was significant slant on them (wish I would have taken the time to measure it, just for sake of quantifying it).

Grabbed the 74LS04 from the junk box, put it between the pi and the shift registers and the slant is gone and the circuit is stable. Putting the scope probe on the clock pin no longer makes it go wonky, either.

Reply to
smbaker

Very much a hardware guy, but I haven't used LS parts in over 20 years. TTL without the pullup is only around 2.8 volts or so. A pullup is slow which creates problems if it is the driver that gets you across the input threshold. I don't like the idea of pullups to meet voltage levels. I prefer to get there with a driver.

That's the problem with TTL, it *won't* pull hard past 3.0 volts, it just barely gets to 3.0 volts before it quits. At least that is what they spec. It has been too long since I put a scope on an LS output so I don't recall exactly how high a typical LS chip drives. But then it has been more than 20 years since I designed a circuit to work with the part I had my scope probe on rather than designing to the data sheet.

I suppose you could call that a common gate circuit, most people consider it to be a pass transistor: potatoes - potahtoes. Pull the gate up and the drain and source are connected. The problem is there is not enough voltage on the gate for the source to drive more than a volt or so. That part has a 2.1 volt threshold and the gate is at 3.3 volts. Not so good. It will not drive high enough and depends on the pullups to reach the HC input threshold very slowly. Hence the sensitivity to noise.

For all practical purposes this circuit is acting like an open drain output.

The problem is not the capacitance, it is the fact that the circuit isn't driving the HC595 input, the pullup is. Tie the gate to 5 volts and the rPi output should drive the HC595 input ok.

--

Rick
Reply to
rickman

We had a design that used a SPI dac. These work well when on the same board, but someone moved them onto another board, which was a bad idea. Wound up the clock line was picking up glithes from relays. I moved the dac's back to the main board, problem solved. Line drivers may help too, MCU ports tend not to driver very hard.

Cheers

Reply to
Martin Riddle

The LSTTL output is a schottky darlington with a 120r collector resistor. Eyeballing the schematic it looks like roughly 220 ohms to 3.8v at ordinary temps.

formatting link

That rips the load past Vcc/2 pretty quickly, and an external pullup does the rest.

I prefer a driver too, hence the LS04. It's not as good as HCT, but it was something he had.

Yes. That's why I called it an open-drain translator.

A 10k pullup wouldn't be a problem for a 5pF load, but too slow for his ~100pF load. Whether you prefer to blame the R or the C is up to you.

That leaves Vgs=1.7v when Vin=3.3v. The FET wouldn't ever turn fully off. It works properly when the gate is connected to +3.3v, as drawn.

Cheers, James Arthur

Reply to
dagmargoodboat

It has been a long time, but I'm pretty sure the scope says differently than 3.8 volts. More importantly the data sheet says differently and even you only talk about "ordinary temps". I guess old habits of designing to specs dies hard, even for hobby projects.

BTW, the Vcc/2 is also a bad idea. The HC input spec is what, 70 or 80% of Vcc? That would be 3.5 or 4.0 volts so even 3.8 would be rather marginal with little to no noise tolerance even if it did work. Yes, I know you won't find an HC input switching at 4.0 volts, but the point is working outside the spec is not the best idea, especially when it is not hard to work within the spec.

Yes, I agree, a bird in the hand is good enough for he needs.

I'm not sure I agree. 500 ns changes to 25 ns, still *very* slow for logic. Would that work much better? Depends on the noise.

If you define "properly" as an open drain with the rise time and noise issues. As I said previously this circuit normally ties the gate to 5 volts through a diode. Then the behavior is improved. But I think you are right that there is no way to get the proper drive over the full HC input spec. This is just a bad circuit for driving an HC input.

--

Rick
Reply to
rickman

Since I had a 74LS163 sitting next to my scope, I measured it.

With a *10 probe on an output with 0 loads, it rises smartly to

2.8V, slightly less smartly to 3.2V then meanders up to >4V With a *10 probe on an output with 1 load, it rises smartly to 2V, slightly less smartly to 3V then meanders up to
Reply to
Tom Gardner

It really has been a long time but I seem to recall that a TTL input (don't ask me which flavor, I think at some point there was a convention to say "this is a standard load" and all families were referenced to that as 1 load, 0.5 loads, etc.) was on the order of a 100 uA pull up. Or maybe it was a 400 uA pullup. But I'm sure they are pullups, you just don't want to count on them to pull up an open input (at least not with all TTL families).

I just don't feel like googling this. It might be a hard one to find... unless there is a wikipedia page on it. lol

I also remember that a high level TTL output looked like pure crap with many different voltage levels which I can only think were because of what was going on inside the chip.

Your wrote "500 ohm Z0 probe", did you mean 50 ohm? I'm pretty sure that would draw too much current from any TTL device. They are made to pull down hard and up much less hard. Heck, even 500 ohm would be pushing it needing 2 mA per volt.

They make true level converters with separate power supplies on each side of the buffer (bi-directional). The easy fix is to just use HCT devices...

--

Rick
Reply to
rickman

No, I did mean that. It is an HP10020, which is older version of a Keysight (ugh) N2874

formatting link
but with a tip capacitance

Reply to
Tom Gardner

Thanks.

100pF, no d.c. load. Don't forget the 1k pullup to +5v.

Cheers, James Arthur

Reply to
dagmargoodboat

Make sure you are giving proper delays between the changing data line and the clock edge. (Provide proper setup time before the clock.) But, this would likely affect only the first HC595, although the later ones would shift down any corrupt data. So, if you are sending the new data and the clock pulse in the same I/O instruction, try sending the data first, then the clock pulse in a second instruction.

Another possible problem is noise or reflections on the clock signal causing multiple clock pulses to be acted on. These chips are pretty fast, and can easily get a double clock on a reflection that comes 10 ns or so after the first one. You may need a terminator on the far end of the clock line.

Jon

Reply to
Jon Elson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.