PIC to 74HC164 Another question for the experts

[ian]

I have this circuit that is giving me problems, before I spend hours
trying to find the problem anyone care to hazard a guess or point
me in the right direction?

I'm sending data to two 74HC164 serial in, parallel out shift registers
over a 10 foot cable from a PIC microcontroller.
It's a 4 wire cable with +5V, Gnd, clock, and data.
The data input of the second 74HC164 is driven by the last register
of the first HC164, creating a 16 output shift register.
The shift register outputs are driving LEDs when positive, through a
10K resistor so the load isn't bad.
To avoid static or surge problems on the cable I've put 10K resistors
at the PIC outputs before the cable, and at the other end of the cable
before the 74HC164 inputs.

My problem?
The second 74HC164 is picking up false clock pulses. Both 74HC164's
are on the same clock input after the "protection" 10K resistor, so it
must be something flakey happening.
I know the 10K resistors aren't the best protection but it's a short
cable and I didn't expect a problem. Do I really need to put
transciever chips on such a short cable?
I know the second 74HC164 is getting extra clock pulses because my
transmitted LED pattern keeps getting ahead of itself. Randomly,
but fairly consistently. Could this be cause by "ring"? If so, how do I
get rid of the problem?

[MrAl]

Hi there,

Did you try a short cable, like say 4 or 5 inches just to see if
it would work with a shorter cable?

If you try a short cable and it goes away then yes it's a transmission
problem but if it doesnt go away then it's not.
Could be as simple as bypass caps on the receiver end across
the chip supplies.

I've done the same thing with TTL but yeah that's lower impedance.

You could also try lower resistors like 1k because the PIC
can drive 2x 1k resistors in parallel. That could reduce the ringing
on the line if that's what the problem is. It will also reduce
things like 60Hz hum on the line and RF on the line.
A small series resistor on the PIC end sometimes helps too, say
100 to 1000 ohms (higher values without the 1k resistor on the
receive end). That reduces ringing.

[jollyrgr]

My problem?
The second 74HC164 is picking up false clock pulses. Both 74HC164's
are on the same clock input after the "protection" 10K resistor, so it
must be something flakey happening.

This sounds like it might be due to power supply glitches. Do you have a bypass capacitor across the power supply pins of the chip? Something like a 0.1uF cap with as short a leads as possible right to Vcc and ground; as close to the chips' pins as possible. You want one cap at each chip. Filtering power for logic chips only at the power supply can bite you.

A bypass capacitor needs to be a small value so it can charge/discharge very fast. My guess is the switching on one chip is causing noise to be seen at the other. Possibly this is the source of your false clock signals.

Bypass capacitors are so important in TTL circuits that there are even IC sockets with capacitors hardwired between pins 7 and 14. See this example:

http://www.cascadesurplus.com/catalog/p ... ts_id/1090

[philba]

bypass caps make sense. I would reduce the series resistors to 1K and put a moderately high resistor (100K or more between signal and gnd at the 164's. Also, try twisted pairs on the cable - signal and gnd on each pair. I'd use cat 5 or 6.

[haklesup]

there is a good possibility you are getting crosstalk between your clock and data lines. As frequency of the clock goes up, this will get worse. A single ended (not differential) signal is good on a cable generally below 1mHz and soemtimes far below.

By putting the 10k in series with the cable, you increases the RC time constant (most conductors have a parisitic capacitance) causing the swuare wave to round off possibly enough to loose data.

Bypassing is always good design practice for most circuits. Reducing the series resistor shold help. If it is crosstalk, separating the conductors in the cable will eliminate it. If you must have a cable and fast data rate, consider RS232 interface at 12V (larger noise margin) or a differential signal). In a ribbon cable, adding additional conductors of ground between data and clock helps. In a round cable, twisted pairs (wrt ground) will help.

[ian]

I lowered the clock frequency and that didn't help. I did try a bypass
cap but I used a 100uF electrolytic. I'm going to put a scope on it
and see if there's something obvious.

[MrAl]

Hi again,

Bypass required is usually 0.1uf or something like that, a ceramic
cap close to the two supply pins of the chip. Electrolytic caps have
higher ESR and that's not good enough, although if it's not really
a bypass problem neither will help.

The series resistor idea is to cause the inductance of the line
to have less effect on the waveshape at the rec end of the line.
This resistor cant be too high however, or the rec end wont have
enough current to drive the inputs high or low or else it will round
the wave corners too much to allow the rec chip to pick up the
signal as it should, and could even cause multiple clocks to the
rec chip. 10k is probably too high for a series resistor, i assumed
you were using that in parallel. 1k is probably the highest value
that should be used and 10 ohms the lowest, with 100 ohms my
first choice. BTW i drive lines about 18 inches long all the time with
quick tests on chip to chip communications and dont have any problem
using a 1k series resistor or no resistor at all when other conditions
permit. Recently i also used a three conductor cable about 4 or 5 feet
long on the PC's serial port, but that had a 1k series resistor too. The
three cond's were power, signal, and ground. The transmitter had a
bypass cap 0.1uf, and the rec was the computer port with no added
modification.


Another idea is a schmitt trigger gate on the rec end, but i'd try
to get it to work without that first. Unfortunately i dont remember
if i used one or not with my TTL experiment years back.

[dyarker]

Agree, 1K maximum series resistors in data and clock lines. With 20K total, the surprise isn't that the second 74HC164 is over counting, but that the first works correctly.

74HC ICs are CMOS, so the input impedance is very high. At the frequencies of rise and fall times of the signals (not the data rate, the rise and fall harmonics) ten feet of cable is a good receive antenna when not loaded.

So, if it still has problems after applying Mr. Al's suggestions, then at the 74HC164 end ONLY connect 10K resistors from data and clock lines to common after the 100 to 1K series resistors. This is not needed at PIC end because PIC outputs are already low impedance.

Cheers,

[haklesup]

might try 50k pullup (or pulldown) resistor on the HC164 inputs. this will help keep them from toggling on noise. you will need a real signal to toggle the line with a load at the input end. You could probably go quite a bit lower in R for this and still get the same result.

What is IOL and IOH of the PIC chip. 74HC this is reletavely large but other chips won't have as much output current. Buffering the PIC with a 74HC or 74ACT inverter would boost the current.

[dyarker]

No need to buffer PIC. It can source or sink 20mA.

[jm]

What no one seems to have mentioned that a 10 foot wire between logic pins of ordinary chips is well outside their intended use. The designers expected a connection on the same circuit board - even a ribbon cable between boards can sometimes be problematic.

The problem is either on your clock line or the power line or both.

While most of the suggestions and observations are sound, nevertheless they still amount to "putting lipstick on the pig"

If they work fine, if not here are a few fancier solutions.

1) Use your 4 lines for an I2C interface and use an I2C io chip. They are cheap enough. Of course if your specific PIC does not have I2C built in this is probably too much trouble.

2) Use tranceiver buffers. These are high powered logic gates on sender with noise resistant Schmidt input on receiver. This allows you to use 220 Ohm pullups which often 'smother' line transients.

3) How much time are you allowing for data settling before pulsing the clock? Longer may be better especially in combination with (2)

4)Stretch the clock pulse on the RECEIVING side with a 555 timer. This is basically a debouncing circuit. A 100 microsecond one-shot would certainly outlast any bouncing on the clock line. This limits the maximum data rate, but blinking LED's are not too demanding of speed.

5)If you cannot suppress power transients with filter capacitors (as others have sensibly suggested) then consider a seperate power regulator chip on the IO board. In other words, send your raw DC power and regulate to 5V locally. You still need the filter capacitors.

[Robert Reed]

"What no one seems to have mentioned that a 10 foot wire between logic pins of ordinary chips is well outside their intended use. The designers expected a connection on the same circuit board - even a ribbon cable between boards can sometimes be problematic. "

Which brings up another important point - What is your clock rate?

[MrAl]

Hi again,

While we are talking about other possible problems, i should mention
that the relative placement of the clock pulses is also very important
and which edge of the clock is used to clock the data into the receiver
chip.

Assuming the clock is a 50 percent duty cycle and the leading edge
of the data is synchronized with the leading edge of the data,
the receiver should clock the data in on the falling edge of the clock,
and the data should remain constant for the entire (or most of) the
clock period. This gives the data a full 1/2 clock period to settle
at the rec end before it is clocked into the rec chip.
It could be that the receiver is simply acting on the wrong edge
of the clock pulse. Assuming the same as above, if the data is
clocked in on the rising edge of the clock pulse it probably wont
work very well.

Code: Select all

         ______        ______
....____|      |______|      |______ CLOCK

         _____________
....____|             |_____________  DATA (binary 10)

               ^             ^
               ^             ^
               ^             ^
               |             |
              REC           REC

The data is clocked into the rec chip on the falling edge
of the clock (shown at the points in time labeled REC).

Note that there is usually a minimum 'setup' time for the data to be present
before the clock occurs, and here it has a full 1/2 clock period.
You'll also have to compare the bandwidth of the rec chip to the
output of the PIC to make sure the PIC isnt clocking too fast for
the rec chip.

[ian]

The problem is not "crosstalk", nor "data setup time", nor "clock rate".

This problem is getting interesting, in that, even the simplest circuits
that SHOULD work, may not for some strange reason. I guess this is
why following rules of good design is importatnt.

To eliminate the crosstalk issue I held the clock in one state while
pulsing the data at high speed. The LED pattern initially shifted out
before pulsing the data at high speed did not change. Barring transient
crosstalk, it does not seem to be cross talk.

I also slowed the clock rate and I seem to get identical results whether
I use a very fast clock rate or a very slow clock rate. During the slow
clock rate there were 4mS pauses between data setup time, clock
rise times and clock fall times. No perceptable change in the
"randomness" of extre clock pulses on the second 74HC164 only.

I did put a .1uF (I think mylar) cap across the 74HC164.

I tried a 100k pullup (and pulldown) resistor on the clock input of the
two 74HC164s.

I scoped the +5, Gnd, and clock input of the 74HC164. +5 and Gnd
looked solid. The clock input also looked solid with absolutely no
"ring". The clock input had steep rise and fall edges. The falling
edge of the clock was somewhat "rounded" but it is a rising edge
clock so I don't think there's an effect there.

I really don't know what's causing the extra clock pulses. Maybe with
the 20K resistance there's just not enough "drive" to the input.

I did change the clock input configuration. I put a 2n3904 transistor
between the 10K resistor and clock input. I'm pulling the clock input
up with a 10K resistor and pulsing it low with the transistor.
With that configuration it is much better but there's still the odd extra
clock pulse, again, on the second 74HC164 only. I then reduced the
10K pullup to a 3K pullup and it is now perfect even with high clock rates.

Even though I seem to have found a solution I'd still like to know
what caused this problem in the first place. It's odd the clock signal
looked so solid on the scope and yet, there were extra, phantom,
clock pulses.

[MrAl]

Hello again,

I dont think you got the whole meaning of what effect the data
setup time can have on a circuit that is clocked. If you look at
the waveform i drew (in text) in my last post you'll see that the
clock and data have a unique relationship. Part of that means
that for the data and clock as shown the chip must clock in the
data on the *falling* edge of the clock only, and not on the rising
edge. If the chip were to clock in the data on the rising edge
the data actually taken in by the chip could be somewhat random.
It's also interesting that if you had this condition and you delayed
the clock by a small amount the condition would get better where
the data would be more likely to get to the chip.
Since you are saying that only the second chip has the problem
that could indicate that the first chip delay is causing a delay in
the data so that the clock edge appears too soon.

If i were you i would look at this again, and perhaps try inverting
the clock line just to see what happens.
To further see what i was talking about, look at my last post again
and mentally invert the clock while maintaining that the chip clocks
the data in on the falling edge and mentally imagine what could go
wrong when it's done that way instead of the way it's actually drawn.

What else would help would be if you could provide the waveforms
of a typical clock line and data line like i did in my previous post.
This would tell us right away what is wrong with the clock and
data, if anything. Even if you have to draw it by hand in Paint
or something and post it here, i think this would help a lot because
without seeing the actual waveforms we can only guess and it's going
to take longer to figure out that way.

Just in the rare case that one chip is bad, did you try swaping the
chips to see if anything changed?