Searching \ for '[EE] 74HC595 continued...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=74hc595+continued
Search entire site for: '74HC595 continued...'.

Exact match. Not showing close matches.
PICList Thread
'[EE] 74HC595 continued...'
2005\03\01@192646 by brusque

face
flavicon
face
Hello,

    I'm glad to report that I'm using 6 cascaded 74HC595 to light 48
LEDs, with 8 bit software PWM individual brightness control. I'm
connecting the LEDs on the '595 outputs with 100R resistor and I'm
getting, aprox, 9.5mA on the Green and Blue LEDs, 20mA on the Red LEDs.
No '595 blown untill now. :)

    Now, other problem <grin>. Let's say I turn on LEDs 1, 4, 7 and so
on. They turn on correctly, but I got ocasional blinks on the other LEDs
(2, 3, 5, 6 and so on).

    It's very weird. I'm scratching my head, looking at my scope,
modifying my source code... no conclusions. The LEDs on the first and
second '595 are ok, on the third it's happening, on the fourth it's
worse, on the fifth it's even worse, on the sixt it's like sh*t.

    Someone can give any clues? Please, if you need more informations
just ask.

    Thanks,

    Brusque
--
---------------------------------------------------------------------
Edson Brusque                     C.I.Tronics Lighting Designers Ltda
Research and Development                  Joinville  -  SC  -  Brazil
http://www.ryan.com.br/netiqueta.htm             http://www.citronics.com.br
---------------------------------------------------------------------

2005\03\01@193954 by Dave VanHorn

flavicon
face
At 07:26 PM 3/1/2005, spam_OUTbrusqueTakeThisOuTspamHOTPOP.COM wrote:
>Hello,
>
>     I'm glad to report that I'm using 6 cascaded 74HC595 to light 48
> LEDs, with 8 bit software PWM individual brightness control. I'm
> connecting the LEDs on the '595 outputs with 100R resistor and I'm
> getting, aprox, 9.5mA on the Green and Blue LEDs, 20mA on the Red LEDs.
> No '595 blown untill now. :)
>
>     Now, other problem <grin>. Let's say I turn on LEDs 1, 4, 7 and so
> on. They turn on correctly, but I got ocasional blinks on the other LEDs
> (2, 3, 5, 6 and so on).
>
>     It's very weird. I'm scratching my head, looking at my scope,
> modifying my source code... no conclusions. The LEDs on the first and
> second '595 are ok, on the third it's happening, on the fourth it's
> worse, on the fifth it's even worse, on the sixt it's like sh*t.
>
>     Someone can give any clues? Please, if you need more informations
> just ask.

What's the wiring like.
Sounds like ringinginginginging on your signals.
That, or time skew.

Try running it slower, and putting a 100 ohm resistor in series at the micro.


2005\03\01@193955 by Dave VanHorn

flavicon
face
At 07:26 PM 3/1/2005, .....brusqueKILLspamspam@spam@HOTPOP.COM wrote:
>Hello,
>
>     I'm glad to report that I'm using 6 cascaded 74HC595 to light 48
> LEDs, with 8 bit software PWM individual brightness control. I'm
> connecting the LEDs on the '595 outputs with 100R resistor and I'm
> getting, aprox, 9.5mA on the Green and Blue LEDs, 20mA on the Red LEDs.
> No '595 blown untill now. :)
>
>     Now, other problem <grin>. Let's say I turn on LEDs 1, 4, 7 and so
> on. They turn on correctly, but I got ocasional blinks on the other LEDs
> (2, 3, 5, 6 and so on).
>
>     It's very weird. I'm scratching my head, looking at my scope,
> modifying my source code... no conclusions. The LEDs on the first and
> second '595 are ok, on the third it's happening, on the fourth it's
> worse, on the fifth it's even worse, on the sixt it's like sh*t.
>
>     Someone can give any clues? Please, if you need more informations
> just ask.

What's the wiring like.
Sounds like ringinginginginging on your signals.
That, or time skew.

Try running it slower, and putting a 100 ohm resistor in series at the micro.


2005\03\01@195321 by Andre Abelian

picon face
Brusque,

Check input side of 74HC595 look for a glitch if there is any glitch
then check your code if input side is fine then take a can of
freezer and cool it down it might be that 74HC595 chip is over loaded
let me know your result then we will continue from there.
Setup break points in your software if it looked fine then definitely
there is a glitch problem.  

Andre Abelian




{Original Message removed}

2005\03\01@213825 by Marcel Duchamp

picon face
Brusque,

It sounds like maybe you have propagation time problems with your data
lines.

If your chips have all their clock lines tied together, this is what
happens.  The last chip in line (nr 6) gets its clock at the same time
as the first chip.  But it doesn't get any data on its data input until
the data has flowed through all the previous 5 chips.  At slow clock
rates, this is not a problem.  At high clock rates, you begin to have a
race condition.  Eventually, the clocks come and go before the data gets
there.

What is the clock rate you are using to clock the '595 chips?

Check the data sheet for the *exact* parts you are using. See what the
propagation times are at the operating voltage, etc.

To test this idea, simply lower your clock rate.  If the problem goes
away, think of it this way. You have just built a fine propagation delay
tester!  :)

Good luck!
MD



brusquespamKILLspamHOTPOP.COM wrote:
{Quote hidden}

2005\03\01@214401 by res0qrqr

picon face
There was a very comprehensive thread here perhaps four or
five years back on this topic.  I think (?) the general
conclusion was that the 74xx595 lacks a gate internally
which would be needed to prevent a race condition when
the chips are daisy-chained as you are doing.  At the
time, it was pointed out that more modern alternatives
such as the TPIC6595 family do have the proper internal
architecture to allow trouble-free series operation.

My brief search for this thread has come up empty :-(
Maybe someone else remembers more about it and can post
the link.

Brian Aase

{Quote hidden}

2005\03\01@214612 by Dave VanHorn

flavicon
face
At 09:40 PM 3/1/2005, Marcel Duchamp wrote:
>Brusque,
>
>It sounds like maybe you have propagation time problems with your data lines.
>
>If your chips have all their clock lines tied together, this is what
>happens.  The last chip in line (nr 6) gets its clock at the same time as
>the first chip.  But it doesn't get any data on its data input until the
>data has flowed through all the previous 5 chips.  At slow clock rates,
>this is not a problem.  At high clock rates, you begin to have a race
>condition.  Eventually, the clocks come and go before the data gets there.

This isn't really a race condition, just clock skew.
A race would be where the gates could oscillate for short periods.

But in general I think you're right, it's a timing problem where clock and
data are getting further and further out of sync, or maybe a ringing on the
clock line at the end, that doesn't show up closer to the driving end.

Hanging a good two channel scope on the end should resolve that question.

This is one where a logic analyzer would be of rather dubious help.


2005\03\02@012053 by Stephen R Phillips

picon face

--- .....brusqueKILLspamspam.....hotpop.com wrote:

{Quote hidden}

You should remember that the 595 series has 2 clocks. You need to be
sure that the latch clock isn't getting any glitching. That's what you
should be checking with your scope. It sounds to me you are getting a
glitch while you are shifting bits into the shift register.  This is
likely loading your bit pattern on each of the next LED's.  Even if it
happens just after you start shifting new data in. It's still a
problem.  So I would check to see if the output latch is being toggled.
Check all the latch connections. Then if you don't see anything wrong
with those check to be sure you aren't creating the glitch in software.

=====
Stephen R. Phillips was here
Please be advised what was said may be absolutely wrong, and hereby this disclaimer follows.  I reserve the right to be wrong and admit it in front of the entire world.


       
               
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

2005\03\02@014941 by Wouter van Ooijen

face picon face
>      It's very weird. I'm scratching my head, looking at my scope,
> modifying my source code... no conclusions. The LEDs on the first and
> second '595 are ok, on the third it's happening, on the fourth it's
> worse, on the fifth it's even worse, on the sixt it's like sh*t.
>
>      Someone can give any clues? Please, if you need more
> informations
> just ask.

Clock skew? If the N-1 chip has changed its D-out before the clock edge
arrives at the N chip you will have problems. IMHO the only real
solution is to use a chip with a delayed output. (IIRC HC4094?)

To diagnose: try feeding the clock from the opposite end of the chain.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\02@015514 by Wouter van Ooijen

face picon face
>  Check all the latch connections. Then if you don't see anything wrong
> with those check to be sure you aren't creating the glitch in
> software.

I don't think a software-generated glitch would cause a result that
changes with the position of the SR.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\03\02@043542 by Dan Smith

face picon face
On Tue, 01 Mar 2005 21:26:37 -0300, EraseMEbrusquespam_OUTspamTakeThisOuThotpop.com
<brusquespamspam_OUThotpop.com> wrote:
> I'm glad to report that I'm using 6 cascaded 74HC595 to light 48
> LEDs, with 8 bit software PWM individual brightness control. I'm
> connecting the LEDs on the '595 outputs with 100R resistor and I'm
> getting, aprox, 9.5mA on the Green and Blue LEDs, 20mA on the Red LEDs.
> No '595 blown untill now. :)
>
>      Now, other problem <grin>. Let's say I turn on LEDs 1, 4, 7 and so
> on. They turn on correctly, but I got ocasional blinks on the other LEDs
> (2, 3, 5, 6 and so on).

Hi,

I have one product that has 21 x 74HC595 cascaded to drive leds.
There are 3 x 595s on the main processor board, then up to 3 led
boards with 6 x 595s per led board can be added.  I use a 74HCT04 on
each board to buffer the clock and strobe signals and have no drive
problems.  Could be worth a try anyway.

If anyone is interested, it's a 48 zone fire alarm panel -
http://www.terofire.com/multi_1648.html

Dan

2005\03\02@114650 by Robert Rolf

picon face
This sounds an awful lot like 'ground bounce'.
Since each 595 is farther away AND the LEDs are
drawing significant current the ground lifts up a bit,
to the point with the input threshold is crossed.
Think of all traces as RESISTORS and where the current
is going and where voltage drops will be produced based
on the PHYSICAL layout, not the schematic.

Do you have adequate supply bypassing on the chips
AT the chips?

What happens when you disconnect the closer LEDs?

Robert

Andre Abelian wrote:

{Quote hidden}

> {Original Message removed}

2005\03\02@170203 by brusque

face
flavicon
face
Hello Stephen,

> You should remember that the 595 series has 2 clocks. You need to be
> sure that the latch clock isn't getting any glitching. That's what you
> should be checking with your scope. It sounds to me you are getting a
> glitch while you are shifting bits into the shift register.  This is
> likely loading your bit pattern on each of the next LED's.  Even if it
> happens just after you start shifting new data in. It's still a
> problem.  So I would check to see if the output latch is being toggled.

    that's it! I've found the latch line to be very noisier.

    The problem was on the power supply. It's a LM2576 based switching
regulator that receives 24VDC and lowers it to 5V. This was solved with
a higher inductance indutor.

    Also, in my tests I've found it can be good to have a 100pF ceramic
cap across latch and GND pins on the last HC595. I'm thinking about
putting one 100pF cap on clock line too.

    Thank you very much and thank to everybody that replied me.

    Best regards,

    Brusque
--
---------------------------------------------------------------------
Edson Brusque                     C.I.Tronics Lighting Designers Ltda
Research and Development                  Joinville  -  SC  -  Brazil
http://www.ryan.com.br/netiqueta.htm             http://www.citronics.com.br
---------------------------------------------------------------------

2005\03\02@171503 by Dave VanHorn

flavicon
face

>
>     The problem was on the power supply. It's a LM2576 based switching
> regulator that receives 24VDC and lowers it to 5V. This was solved with a
> higher inductance indutor.

If VCC is noisy, all bets are off.
But, you should take care of that in the power supply, and in the system
decoupling caps.

>     Also, in my tests I've found it can be good to have a 100pF ceramic
> cap across latch and GND pins on the last HC595.

While you can get away with not having a bypass for every logic chip, ANY
chip that does a lot of I/O pin loading, or fast switching, needs one.

>I'm thinking about putting one 100pF cap on clock line too.

I wouldn't.  This just makes your micro draw more current during the
transitions.
I'd feed that line with a 100 ohm resistor, and terminate with 100 ohms in
series with a 0.1uF cap.
Then scope it on both ends of the track, and adjust the resistors as needed.


2005\03\02@201309 by brusque

face
flavicon
face
Hello Dave,

>>     Also, in my tests I've found it can be good to have a 100pF
>> ceramic cap across latch and GND pins on the last HC595.
> While you can get away with not having a bypass for every logic chip,
> ANY chip that does a lot of I/O pin loading, or fast switching, needs one.

    oh, maybe I haven't made myself clear. I have a 100nF cap between
VCC and GND pins on each HC595. The 100pF cap I'm refering is an
additional cap between LATCH and GND pins on the last HC595.

    I really want to reduce ripple and any other noise on the VCC line.
The ~400uH inductor instead of the 100uH I was using really helped but I
still would like to reduce it even further. Let's see what can I do
tomorrow.

>> I'm thinking about putting one 100pF cap on clock line too.
> I wouldn't.  This just makes your micro draw more current during the
> transitions.

    Yes, that's right. I've tried it and this messed up everything <grin>.

> I'd feed that line with a 100 ohm resistor, and terminate with 100 ohms
> in series with a 0.1uF cap.
> Then scope it on both ends of the track, and adjust the resistors as
> needed.

    Yes again. I've been thinking about termination but haven't
implemented it yet. Right now, I have a 2m cable between the controller
board (with the PIC18F252) and the LEDs board (with the HC595s). Cable
is a 10 (26AWG) conductor without any twisting. Cable wiring is:

       1 - GND
       2 - GND
       3 - GND
       4 - 24VDC
       5 - 24VDC
       6 - Clock
       7 - Data
       8 - Latch
       9 - Enable

    Cable resistance is about 3ohms (including conector resistance).
This is your ordinary RS232 cables with DB9 male/female connectors. DB9
male on the control board, DB9 female on the LEDs board. I don't know
the characteristic cable impedance but don't think it's a big problem on
this situation.

    Your idea of 100ohms resistor on the controller board and
100ohms+100nF on the end of the line seens interesting. How would it
work? What should I look for when doing those tests?

    Thanks,

    Brusque

--
---------------------------------------------------------------------
Edson Brusque                     C.I.Tronics Lighting Designers Ltda
Research and Development                  Joinville  -  SC  -  Brazil
http://www.ryan.com.br/netiqueta.htm             http://www.citronics.com.br
---------------------------------------------------------------------

2005\03\02@204348 by Dave VanHorn

flavicon
face
At 08:13 PM 3/2/2005, @spam@brusqueKILLspamspamHotPOP.com wrote:
>Hello Dave,
>
>>>     Also, in my tests I've found it can be good to have a 100pF ceramic
>>> cap across latch and GND pins on the last HC595.
>>While you can get away with not having a bypass for every logic chip, ANY
>>chip that does a lot of I/O pin loading, or fast switching, needs one.
>
>     oh, maybe I haven't made myself clear. I have a 100nF cap between
>VCC and GND pins on each HC595. The 100pF cap I'm refering is an
>additional cap between LATCH and GND pins on the last HC595.

You don't want caps on signals that move fast, they don't help like you'd
think they would.


>>I'd feed that line with a 100 ohm resistor, and terminate with 100 ohms
>>in series with a 0.1uF cap.
>>Then scope it on both ends of the track, and adjust the resistors as needed.
>
>     Yes again. I've been thinking about termination but haven't
>implemented it yet. Right now, I have a 2m cable between the controller
>board (with the PIC18F252) and the LEDs board (with the HC595s).

EEk!

What variable current is being dumped into "ground"?
The LED return current, if at all possible, should come back by a separate
return wire, and logic should have it's own ground wire. As the current in
"ground" changes, your logic levels are changing according to the product
of current over resistance in the cable, and dI/dT during the transitions.

Termination may help, but "significant variable current" + "long wire" =
trouble.
Not separating logic and power returns is more or less a squaring term on
that equation.

>  I don't know
>the characteristic cable impedance but don't think it's a big problem on
>this situation.

I'd be surprised if it was significantly different from 100 ohms-ish.

>     Your idea of 100ohms resistor on the controller board and
>100ohms+100nF on the end of the line seens interesting. How would it
>work? What should I look for when doing those tests?

The series R/C provides a termination impedance, without pulling the signal
line to VCC or ground.
You could do termination other ways, but this one is simple.

Look at the edges, on the far end of the cable.
If you see significant ringing, then you don't have enough impedance
between the source and the cable.
The end termination should match the source.

But, grounding your scope to the far end of the cable will affect the
signals, and the measurement.
Ideally a differential probe, with ground taken from the head end, and
measuring the difference between signal and "ground" at the other end of
the cable.


2005\03\03@052419 by Wouter van Ooijen

face picon face
>      I really want to reduce ripple and any other noise on
> the VCC line.
> The ~400uH inductor instead of the 100uH I was using really
> helped but I
> still would like to reduce it even further. Let's see what can I do
> tomorrow.

Why the switcher? The 595's will require very little current, so why not
a linear regulator? Maybe a number of linears, or even one per 595 +
loads.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\03@113359 by Dwayne Reid

flavicon
face
At 03:24 AM 3/3/2005, Wouter van Ooijen wrote:

>Why the switcher? The 595's will require very little current, so why not
>a linear regulator? Maybe a number of linears, or even one per 595 +
>loads.

Umm . . . The hc595's are driving LEDs - a large number of LEDs.  Its those
LEDs that take all the current . . .

dwayne

--
Dwayne Reid   <KILLspamdwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\03\03@132509 by Wouter van Ooijen

face picon face
> Umm . . . The hc595's are driving LEDs - a large number of
> LEDs.  Its those
> LEDs that take all the current . . .

7805's are cheap. If overall power consumption is not an issue (compared
to a humminbird it is insignificant anyway) you could juist distribute
semi-regulated 9V and sprinkle some 7805's where they are needed. Note:
that will solve most V+ problems, but of course not ground
current-related problems (but no indication that you have those).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\03@141613 by Dwayne Reid

flavicon
face
At 11:25 AM 3/3/2005, Wouter van Ooijen wrote:
> > Umm . . . The hc595's are driving LEDs - a large number of
> > LEDs.  Its those
> > LEDs that take all the current . . .
>
>7805's are cheap. If overall power consumption is not an issue (compared
>to a humminbird it is insignificant anyway) you could juist distribute
>semi-regulated 9V and sprinkle some 7805's where they are needed. Note:
>that will solve most V+ problems, but of course not ground
>current-related problems (but no indication that you have those).

Ah - I see now.  He listed his cable pinout which showed only a 24V
rail.  I'm guessing you didn't see that.

Anyway, based on a 24V rail and lots of LEDs, I think that a switcher is
the way to go.

FWIW, one of my display cards contains 40 LEDs with a supply rail of about
16V unregulated.  The card contains a NS simple switcher (2576?) set at
4V.  That let me use 10 pin 100R bussed SIP resistor networks and still
keep the LED current where I wanted it.

I had two choices when doing that card: run the LEDs from 5V and purchase
non-standard (for us) SIP networks or adjust the LED voltage to use one the
SIP values we already had.  Pretty simple choice, given that we use the
-ADJ version of the switchers in so many other products.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\03\03@154813 by brusque

face
flavicon
face
Hello Wouter and Dwayne,

>> 7805's are cheap. If overall power consumption is not an issue (compared

    power consumption IS an issue in this project.

> I had two choices when doing that card: run the LEDs from 5V and
> purchase non-standard (for us) SIP networks or adjust the LED voltage to
> use one the SIP values we already had.  Pretty simple choice, given that
> we use the -ADJ version of the switchers in so many other products.

    Yes, very *cool* devices the LM2576-X are. :)

    Best regards,

    Brusque
--
---------------------------------------------------------------------
Edson Brusque                     C.I.Tronics Lighting Designers Ltda
Research and Development                  Joinville  -  SC  -  Brazil
http://www.ryan.com.br/netiqueta.htm             http://www.citronics.com.br
---------------------------------------------------------------------

2005\03\10@063034 by Ian Chapman

flavicon
picon face
res0qrqr@verizon.net wrote:
>There was a very comprehensive thread here perhaps four or five years
>back on this topic.

I remember that thread.  I haven't found a link to it, though.

>I think (?) the general conclusion was that the 74xx595 lacks a gate
>internally which would be needed to prevent a race condition when the
>chips are daisy-chained as you are doing.

The potential problem is that the Q7' (expand) output from the internal
shift register in the 74xx595 changes state on the same (rising) edge of
the clock as the serial data input.  This may cause timing problems with
chains of devices depending on how the clock is distributed.

The comparable device in the CMOS family (the 4094) enables this problem
to be avoided.  It has a second expand output (QS2) which is delayed by
half a clock cycle through an extra flip-flop clocked on the opposite
(falling) edge of the serial clock.  Unfortunately, the 4094 isn't pin-
compatible with the '595 and doesn't have an asynchronous clear input
for the shift register which may be needed in some applications.

I would hope that some of the newer '595-like devices with high-current
output stages have learnt from this issue.
--
Ian Chapman
Chapmip Technology, UK

2005\03\10@084623 by Bob Axtell

face picon face
I guess age is showing, but I am puzzled as to why ANY race condition
can exist
in the Q7 unregistered output stage.

It IS true that propagation delays will sum up and eventually cause the
serial clock
speed to  require being slowed down, that does not consiitute a "race".
On the 595,
nothing changes on the output until another, unique clock (REG CLK) is
toggled.

I've been using several consecutive stages of HC and LV595s without the
slightest
problem for many years, but as more stages are added, the serial
(transfer) clock
has to be slowed, that's all I have to do.

Flames expected.

--Bob

Ian Chapman wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
TakeThisOuTattachEraseMEspamspam_OUTengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\03\10@100105 by Wouter van Ooijen

face picon face
> I guess age is showing, but I am puzzled as to why ANY race condition
> can exist in the Q7 unregistered output stage.

The Q7 changes state on the edge of the input clock. If the Q7 is fed to
a subsequent 595 and that chip receives a slightly delayed clock edge it
might clock in the new data value, instead of the old one.

The delay need not be an actual time delay, it could also be a slow edge
combined with different trigger points for the two chips.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\10@101914 by Ian Chapman

flavicon
picon face
Wouter van Ooijen <RemoveMEwouterspamTakeThisOuTvoti.nl> wrote:
>The Q7 changes state on the edge of the input clock. If the Q7 is fed to
>a subsequent 595 and that chip receives a slightly delayed clock edge it
>might clock in the new data value, instead of the old one.

I seem to recall that, the last time this was discussed, someone made
the clever suggestion that the serial clock is distributed to the chain
of '595s in *reverse* order (i.e. starting with the one at the end of
the chain and working backwards).  The difference in propagation time
then works in favour of each '595 clocking in the old data value.

I'm not sure who to credit for that idea, though.
--
Ian Chapman
Chapmip Technology, UK

2005\03\10@110652 by Wouter van Ooijen

face picon face
> I seem to recall that, the last time this was discussed, someone made
> the clever suggestion that the serial clock is distributed to
> the chain
> of '595s in *reverse* order (i.e. starting with the one at the end of
> the chain and working backwards).  The difference in propagation time
> then works in favour of each '595 clocking in the old data value.
>
> I'm not sure who to credit for that idea, though.

And I am not sure it would be enough. But surely better than feeding
from the source. Better: use a 4094, or invert the clock for the
odd-numbered 595's.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\10@111120 by Bob Ammerman

picon face
Or even wire the clocks in reverse order with a buffer to add a few
nano-seconds delay from one to the next.

Of course, all of this is distasteful and should be solved in a less ad-hoc
manner if possible.

Bob Ammerman
RAm Systems


{Original Message removed}

2005\03\10@124736 by Bob Axtell
face picon face
I knew it, is WAS my age....Now, the NEXT one has stumped me for 3 days, a
record in my world....

Wouter van Ooijen wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
attachEraseMEspam.....engineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...