Searching \ for 'shift registers' 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=shift+registers
Search entire site for: 'shift registers'.

Truncated match.
PICList Thread
'shift registers'
1998\10\14@101751 by Mike Montgomery

flavicon
picon face
Hi all.
In Myke Predko book programming & customizing the PIC ( which I think is
a great book ), Myke has a listing for 3 wire LCD display using a shift
reg Can any one suggest a part number for this & a circuit diagram
including any parts need for this shift reg.

mike
-----------------------------------------------------------------
Mike Montgomery

Gardown can be downloaded from my home page http://anali.demon.co.uk
-----------------------------------------------------------------

1998\10\15@120205 by org Hager

flavicon
face
On Wed, 14 Oct 1998, Mike Montgomery wrote:

> Myke has a listing for 3 wire LCD display using a shift
> reg Can any one suggest a part number for this & a circuit diagram
> including any parts need for this shift reg.

Well, I think that Myke's diagram says it all, but if you want to see a
similar setup with another shift register (CD4094) and some more in-depth
instructions, take a look at

http://www.iaehv.nl/users/pouweha/lcd_examp.htm

Georg.

1998\10\15@164027 by myke predko

flavicon
face
Since my name's being used in vain, maybe I should put in my two cents:

>On Wed, 14 Oct 1998, Mike Montgomery wrote:
>
>> Myke has a listing for 3 wire LCD display using a shift
>> reg Can any one suggest a part number for this & a circuit diagram
>> including any parts need for this shift reg.
>
>Well, I think that Myke's diagram says it all, but if you want to see a
>similar setup with another shift register (CD4094) and some more in-depth
>instructions, take a look at

In the book (and for most of my designs), I normally use a '374/'574 to
create a shift register.  The '374/'574 consists of a number of edge
triggered "D" flip flops that are normally used in Parallel.

To create a shift register, I connect the "Q" output of one flip flop to
another.

For example, for a 8 bit serial in/parallel out, I use the common clock and the
data connections:

Serial --->  1D  1Q  -+----->  Bit 0 Out
                     |
      +--------------+
      |
      +-->  2D  2Q  -+----->  Bit 1 Out
                     |
      +--------------+
      |
      +-->  3D  3Q  -+----->  Bit 2 Out
                     |
              o
              o
              o

And so on for eight bits.  When you use this method make sure you know which
bit goes first (ie in this case it's the most significant).

The third bit is used for the LCD strobe.  When I'm doing an LCD "quick and
dirty" set up, I'll tie "R/W" high (can't read), run the LCD in 4 bit mode
and use one of the available bits for "R/S".


I've seen this method of writing to LCDs used in a number of applications.
It's fairly easy to implement (especially if you use a '574) and doesn't
take up a bunch of pins.


I also wanted to say that I've been having a ton of problems with my PC (I
was on a business trip last week and I obligingly helped out a marketeer
with a VGA/TV adapter that he had bought and the drivers trashed my windows
.ini files) although there is light at the end of the tunnel (which
hopefully, isn't a train coming my way).  I have about fifty notes from
people that I haven't been able to respond to and I apologise for that .
Over the next few days I promise I will get them taken care of (and put the
latest version of "PICLite" up on my website).

myke

Scott Adams latest, "The Joy of Work" is the Book of the Week.

http://www.myke.com/Book_Room/book1a.htm

Also look at:

http://www.myke.com/My_Books/homcu.htm

for information on "Handbook of Microcontrollers"

1998\10\20@151123 by John Payson

flavicon
face
part 0 1894 bytes
Although the '374 has the advantage that it's available at Radio Shack,
I think the '595 is a much nicer part for many applications.  Its eight
outputs won't change until you hit a "latch enable" signal (which you
may do after shifting in your data).  The one feature the '595 lacks
which would be nice to have would be a QH' output which was delayed by
1/2 clock (to allow the devices to be cascaded without race conditions).

For certain applications, btw, there's another kludge to saving port
pins: use RC delays to slow down certain signals.  For example, while
an LCD display normally requires five signals plus enable (4 data and
1 register select) it's possible to save two pins by wiring small caps
to two of the data wires and connecting them, through resistors, to the
other two data wires.

Assuming the caps are 0.01uF and the resistors are 2.2K, the RC delay
time is about 22uS.  To write a nybble to the display, you need to
output the data for the "capacitor"'ed pins, wait about 50uS, output
the data for the other pins, and very quickly hit and release the
enable signal.  You're relying here on the fact that the pins with the
caps on them are guaranteed to switch within 50uS (almost 2.5 RC time
constants) but not to switch in under 5uS or so (less than 1/4 RC time
constant).

This approach is a bit kludgy, and doesn't really allow for very fast
data rates (since generous safety margins are a must) but can sometimes
be useful to eke out an extra port pin here and there, especially for
functions which are seldom-used.

For example, on one graphical LCD display I used, there's a reset pin.
Since the chip is enabled a very small portion of the time, and since
it's okay if resetting the display takes awhile, I used the RC trick
with the reset and enable pin: holding enable for a LONG time will
reset the display, but normal writing to it won't.

1998\10\28@160532 by John Payson

flavicon
face
The diagram at

http://www.iaehv.nl/users/pouweha/lcd_examp.htm

for driving a Hitachi LCD using 3 port pins (and a shift
register) is pretty clever; one slight simplification and
enhancement would be to use the D wire (which feeds the
shift register) for the RS function rather than the clock.
Since the D input is ignored by the shifter except when it
is clocked, this should allow the elimination of the RC
delay that was used for sharing the clock signal.

Also, while I don't generally like it too much for most
applications, the 74HC164 serial->parallel converter will
work fine here and, for the benefit of U.S. readers, is
available at Radio Shack.  Since the LCD ignores what's
on its data wires when it's not enabled, the propagation
of the data bits through the output bits shouldn't be a
problem.

1998\10\28@175001 by paulb
flavicon
face
John Payson wrote:

> The diagram at
> http://www.iaehv.nl/users/pouweha/lcd_examp.htm

> for driving a Hitachi LCD using 3 port pins (and a shift register) is
> pretty clever; one slight simplification and enhancement would be to
> use the D wire (which feeds the shift register) for the RS function
> rather than the clock.

 Didn't I comment on this earlier?  You don't even need to do that;
just remove the RC delay and feed the clock line direct to the RS.

 The 4094 clock is edge-triggered (as are by definition, all shift
registers), clocking on the positive edge.  You take it low then high
for each data bit presented to the D wire, then finally set it to the
desired RS value.  If that is high, then the clock line is not altered.
If low, then the clock line goes low but this does not have any effect
on the data.

 A further simplification to the wiring can be made by realising that
the latch on the 4094 is OTOH, *level*-triggered, so it can be tied
permanently low.  (Just as well, or there would be a race condition.)
The HD44780 doesn't care about the data (some microsecond) prior to
Enable so as long as the final setting of the Clock/ RS line is an
operation before Enable, all data will be perfectly stable.

 Alternately, if the delay was implemented by a Schmitt gate (HC14),
the circuit would only require two control lines; the serial clock/ RS
and the serial data, delayed to become Enable.  This like the original
proposition is a bit slower, but ... it's an LCD display!

 Alternative; serial data doubles as RS, serial clock delayed and
inverted to form Enable.  Normally held high, it is lowered and raised
for one PIC cycle for every bit to be shifted, but held low to do the
Enable.
--
 Cheers,
       Paul B.


'shift registers'
1998\11\01@100142 by Ian Chapman
flavicon
picon face
On Tuesday 20th October 1998, John Payson wrote:
>I think the '595 is a much nicer part for many applications.  Its eight
>outputs won't change until you hit a "latch enable" signal (which you
>may do after shifting in your data).  The one feature the '595 lacks
>which would be nice to have would be a QH' output which was delayed by
>1/2 clock (to allow the devices to be cascaded without race conditions)

To quote Horowitz and Hill: "It is surprisingly easy to overlook a race
condition".

John's comment gave me a scare when I realised that one of my designs
uses two directly cascaded '595s.  This seems to be a drop-off in the
design of this part as the Philips data sheet for the HC/HCT595 states
that the Q7' (QH') output is intended for cascading - and yet it is
clear from closer examination that a skew of 10ns or more between the
shift clocks of the respective devices could result in marginal timing
and possibly incorrect operation.  As John says, an extra flip-flop
acting on the falling edge of the shift clock would solve this.

Having examined my own design, it looks as if I can get away with this,
as the two '595s in question are driven directly by a PIC output via a
short PCB trace with no additional loading.  The data sheet suggests
that, when operating at +5V, there is a positive margin of 10ns worst
case (still not a lot!) between the propagation delay (from shift clock
to Q7') of the first '595 and the data set-up plus hold time for the
second '595.  However, this margin becomes negative at lower supply
voltages - so I'm glad that my application isn't safety-critical!

Any suggestions on simple fixes to make this more robust?  I don't have
room on the PCB for another IC (i.e. a flip-flop).
--
Ian Chapman
<spam_OUTpicTakeThisOuTspamchapmip.demon.co.uk>

1998\11\01@104831 by Peter L. Peres

picon face
On Sun, 1 Nov 1998, Ian Chapman wrote:

{Quote hidden}

But you surely have room for a RC, if needed, as a PCB mod for 2 SMT parts
(been there ;(. 220 ohms + 47 pF should get you there in this case. And
next time use 4094s which have what you are looking for, and high
efficiency displays that make enough light with 1.6 mA / segment ;)

Peter

1998\11\01@104959 by Radboud Verberne

flavicon
face
{Quote hidden}

Why not the common used 4094?

;***************************************************************************
; Output Signals Needed: (3) CLOCK, DATA & STROBE           Radboud Verberne
; Registers Needed: (2) tempreg & bitcount                            PE1RUH
; The OE pin of 4094 is connected to Vdd
;***************************************************************************
;--------------------------------Hef4094------------------------------------
hef4094                         ; Data to be send Must already be in W!
       movwf tempreg           ; Place it in tempreg
       movlw 0x08              ; Eight Bits in a Byte
       movwf bitcount          ; Move it to Bitcount
SendNextBit
       bcf CLOCK               ; Clock is Low
       bcf DATA                ; Data is initially Low
       rlf tempreg, f          ; Rotate Left trough Carry
       btfsc STATUS, C         ; Is the Carry Bit Set?
       bsf DATA                ; Yes, Send A "1"
       bsf CLOCK               ; Put The Clock High to Clock data
       decfsz bitcount, f      ; Are We Done with 8 bits?
       goto SendNextBit        ; Nope, SendNextBit
       bsf STROBE              ; Yep, Generate A Strobe Puls to latch data
       bcf STROBE              ; the data
       return                  ; Returns To Program Counter
;---------------------------------------------------------------------------

1998\11\01@122858 by Ian Chapman

flavicon
picon face
John Payson mentioned the potential race condition when 74XX595 latched
shift registers are directly cascaded by connecting the serial "cascade"
output of one to the serial input of another.

I wrote:
>>Having examined my own design, it looks as if I can get away with this,
>>as the two '595s in question are driven directly by a PIC output via a
>>short PCB trace with no additional loading.
[snip]
>>Any suggestions on simple fixes to make this more robust?  I don't have
>>room on the PCB for another IC (i.e. a flip-flop).

Radboud Verberne <r.verbernespamKILLspamHSBOS.NL> replied:
>Why not the common used 4094?

Thanks for the suggestion.  I had assumed that the 4094 did not include
the output latch (hence the need for the '595) - until I read the data
sheet!  Unfortunately, I have already committed the PCB layout (and, as
usual, the pinout of the 4000-series device is completely different from
that of the 74-series device).

Peter L. Peres <.....plpKILLspamspam.....ACTCOM.CO.IL> replied:
>But you surely have room for a RC, if needed, as a PCB mod for 2 SMT parts
>(been there ;(. 220 ohms + 47 pF should get you there in this case. And
>next time use 4094s which have what you are looking for, and high
>efficiency displays that make enough light with 1.6 mA / segment ;)

Yes, this should be possible.  I assume you are suggesting an RC network
on the serial input of the second (cascaded) shift register to lengthen
the hold time for the cascaded serial data.
--
Ian Chapman
<EraseMEpicspam_OUTspamTakeThisOuTchapmip.demon.co.uk>

1998\11\01@123930 by Peter L. Peres

picon face
On Sun, 1 Nov 1998, Ian Chapman wrote:

> Peter L. Peres <plpspamspam_OUTACTCOM.CO.IL> replied:
> >But you surely have room for a RC, if needed, as a PCB mod for 2 SMT parts
> >(been there ;(. 220 ohms + 47 pF should get you there in this case. And
> >next time use 4094s which have what you are looking for, and high
> >efficiency displays that make enough light with 1.6 mA / segment ;)
>
> Yes, this should be possible.  I assume you are suggesting an RC network
> on the serial input of the second (cascaded) shift register to lengthen
> the hold time for the cascaded serial data.

Yes. The SMT parts are required if the board is already manufactured. A
trace can be cut and the parts pasted from the back. In my case it was not
my design, I just invented a method to patch a stack of botched boards ;)

Peter

1998\11\01@143721 by Mark Willis

flavicon
face
Ian Chapman wrote:
> <snipped>
> Any suggestions on simple fixes to make this more robust?  I don't have
> room on the PCB for another IC (i.e. a flip-flop).
> --
> Ian Chapman
> <@spam@picKILLspamspamchapmip.demon.co.uk>

 I can't count the engineering mods I've seen/done/designed for people
where ya superglue a flip-flop atop something on the PCB & wire-wrap,
test, then solder.  (Don't want to mention how many where the PCB
prototypes came from the mfg. with one or more IC's backwards/whatever,
same basic fix.  "Oops!"

 Like everyone else on the list, I say "Eeeew."  But it works in a
pinch.  (Harder to do now in the days of SMD!  And it's easier to do SMD
PCB's at home than through-hole's.)

 Sometimes just a couple inverters in series gives a nice reliable
delay, sometimes non-inverting if you just need 1 gate delay...

 (The fun ones were the client who were having me throw wire-wraps
together, one co. kept faxing me mods when 3/4 done - the whole widget
has to fit in a DB-25 shell size case.  Do that enough and you get a
flexible brain - or severe brain damage.  Or both.  Taught ME to rtfm
again & again, eventually he got better <G>  I'm good at spatial stuff
<G>)

 Mark, KILLspammwillisKILLspamspamnwlink.com

1998\11\01@173235 by Ian Chapman

flavicon
picon face
Peter L. Peres <RemoveMEplpTakeThisOuTspamACTCOM.CO.IL> suggested addition of an RC network as a
simple solution to a potential race condition when cascading two 74XX595s:
>The SMT parts are required if the board is already manufactured. A
>trace can be cut and the parts pasted from the back. In my case it was not
>my design, I just invented a method to patch a stack of botched boards ;)

Thanks for this suggestion, which looks very practical as the requisite
track runs in the clear on the top side of the PCB.  I must read the data
sheets more carefully in future!

<Quick rant> I had assumed that, when the '595 data sheet says "The shift
register has ... a serial standard output for cascading", it meant that in
general this could be done without additional external components.  Since
the '595 was designed more recently than the 4094 (at least, my '595 data
sheet is dated Sept 1993 whereas my 4094 one is March 1988) I'm surprised
that it did not draw on the strengths of the latter. </Quick rant>

I'll be using the 4094 in future designs, unless I need an asynchronous
reset capability.  It's cheaper than the '595 and it's also available as
an HCT part (i.e. greater output drive if required).  It also looks as if
the same PIC software can drive both parts interchangeably.
--
Ian Chapman
<spamBeGonepicspamBeGonespamchapmip.demon.co.uk>

1998\11\02@091202 by Chip Weller

flavicon
face
Ian Chapman wrote:


>Peter L. Peres <TakeThisOuTplpEraseMEspamspam_OUTACTCOM.CO.IL> suggested addition of an RC network
as a
>simple solution to a potential race condition when cascading two
74XX595s:
>>The SMT parts are required if the board is already manufactured. A
>>trace can be cut and the parts pasted from the back. In my case it was
not
>>my design, I just invented a method to patch a stack of botched boards
;)
>
>Thanks for this suggestion, which looks very practical as the requisite
>track runs in the clear on the top side of the PCB.  I must read the
data
>sheets more carefully in future!
>
><Quick rant> I had assumed that, when the '595 data sheet says "The
shift
>register has ... a serial standard output for cascading", it meant that
in
>general this could be done without additional external components.
Since
>the '595 was designed more recently than the 4094 (at least, my '595
data
>sheet is dated Sept 1993 whereas my 4094 one is March 1988) I'm
surprised
>that it did not draw on the strengths of the latter. </Quick rant>
>
>I'll be using the 4094 in future designs, unless I need an asynchronous
>reset capability.  It's cheaper than the '595 and it's also available
as
>an HCT part (i.e. greater output drive if required).  It also looks as
if
>the same PIC software can drive both parts interchangeably.
>--
>Ian Chapman


I just don't see any race condition on the '595. I have cascaded two in
series before (but never longer chains), and have not had a problem.
According to my data sheet (Philips, 5V operation (4.5V) -40 to +85C)
the part has a 13nsec setup time and a 3nsec hold time from the positive
clock edge. There is a 40nsec maximum delay until the data appears on
the shift output pin. Chain will reduce the maximum shift rate from
24MHz to 18.8MHz, but I don't see any race condition. Exactly where does
the race condition you are seeing exist?

Also the HCT part has the same output structure as the HC part. I prefer
the HC parts when interfacing to most devices (execpt old 74LSxx parts
which output TTL signals) since they provide a greater noise margin.

Chip

1998\11\02@133009 by Morgan Olsson

picon face
>I just don't see any race condition on the '595. I have cascaded two in
>series before (but never longer chains), and have not had a problem.
>According to my data sheet (Philips, 5V operation (4.5V) -40 to +85C)
>the part has a 13nsec setup time and a 3nsec hold time from the positive
>clock edge. There is a 40nsec maximum delay until the data appears on
>the shift output pin. Chain will reduce the maximum shift rate from
>24MHz to 18.8MHz, but I don't see any race condition. Exactly where does
>the race condition you are seeing exist?

Yes, I don«t think the manufacturers have overlooked the possibility of
chaining them.

I have used HC595 @2,6V supply, 7 chained in series: no problem at all.
Driven from a 60HC05 @ 4MHz, 5V, as fast as possible, using just series
diodes for logic level conversion together with HC595 internal clamping
diodes.

Used them to direct-drive a high-bright LED display.  The voltage is
adjusted so correct current per segment is achieved using only the internal
R of 595 outputs and LEDs.  Nice and stable readout, as opposed to
multiplex on an vibrating machine...  First i just tested the setup, and
then found it worked very well indeed.  :)

>Also the HCT part has the same output structure as the HC part. I prefer
>the HC parts when interfacing to most devices (execpt old 74LSxx parts
>which output TTL signals) since they provide a greater noise margin.

Exactly.

>Chip

/Morgan

       Morgan Olsson                   ph  +46(0)414 70741
       MORGANS REGLERTEKNIK            fax +46(0)414 70331
       H€LLEKS           (in A-Z letters: "HALLEKAS")
       SE-277 35 KIVIK, SWEDEN               RemoveMEmrtspamTakeThisOuTiname.com
___________________________________________________________

1998\11\02@142544 by Dwayne Reid

flavicon
face
>John's comment gave me a scare when I realised that one of my designs
>uses two directly cascaded '595s.  This seems to be a drop-off in the
>design of this part as the Philips data sheet for the HC/HCT595 states
>that the Q7' (QH') output is intended for cascading - and yet it is
>clear from closer examination that a skew of 10ns or more between the
>shift clocks of the respective devices could result in marginal timing
>and possibly incorrect operation.  As John says, an extra flip-flop
>acting on the falling edge of the shift clock would solve this.
>
>Having examined my own design, it looks as if I can get away with this,
>as the two '595s in question are driven directly by a PIC output via a
>short PCB trace with no additional loading.  The data sheet suggests
>that, when operating at +5V, there is a positive margin of 10ns worst
>case (still not a lot!) between the propagation delay (from shift clock
>to Q7') of the first '595 and the data set-up plus hold time for the
>second '595.  However, this margin becomes negative at lower supply
>voltages - so I'm glad that my application isn't safety-critical!

You don't have a problem, and you can't add the flip flop to fix the problem
you don't have because you can't get access to the shift register stages
before the latch!  The '595  is DESIGNED to be cascaded.

You are right - there is little room for timing error.  If you need to feed
the Qs output off-board to another '595, you will probably run into
problems.  The cure is simple - add a RC delay to the clock line feeding the
off-board shift registers.

My standard off-board I/O connections always include series resistors for
'OOPS' protection.  They often also have small capacitors for EMI
protection.  You will see that this has lead to timing problems for cascaded
shift registers!  The cure was as mentioned above - ensure the RC delay on
the clock line is longer than any of the other delays (but shorter than your
clock period!) and the problem does not exist.  Note: my off-board shift
registers operate at very slow data rates (512 bits / sec) for EMI reasons
and I have LOTS of leeway to ensure that setup times are ample.


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

1998\11\02@162852 by Russell McMahon

picon face
AFAIR without going and looking it up (lazy!) the CD4094 has the
extra flip-flop and also a latch so data on outputs does not change
while shifting. I use 2 in series as outputs in one design and 2 x
CD4021 as equivalent inputs.


   Russell McMahon

ge-----
From: Ian Chapman <EraseMEpicspamCHAPMIP.DEMON.CO.UK>

>On Tuesday 20th October 1998, John Payson wrote:
>>I think the '595 is a much nicer part for many applications.  Its
eight
>>outputs won't change until you hit a "latch enable" signal (which
you
>>may do after shifting in your data).  The one feature the '595
lacks
>>which would be nice to have would be a QH' output which was delayed
by
>>1/2 clock (to allow the devices to be cascaded without race
conditions)
>.....
 >John's comment gave me a scare when I realised that one of my
designs
>uses two directly cascaded '595s.  This seems to be a drop-off in
the
>design of this part as the Philips data sheet for the HC/HCT595
states
>that the Q7' (QH') output is intended for cascading - and yet it is
>clear from closer examination that a skew of 10ns or more between
the
>shift clocks of the respective devices could result in marginal
timing
>and possibly incorrect operation.  As John says, an extra flip-flop
>acting on the falling edge of the shift clock would solve this.

1998\11\02@172059 by John Payson

flavicon
face
|AFAIR without going and looking it up (lazy!) the CD4094 has the
|extra flip-flop and also a latch so data on outputs does not change
|while shifting. I use 2 in series as outputs in one design and 2 x
|CD4021 as equivalent inputs.

The 4094 does indeed have the other latch, and may be a better
part to use for future designs.  The 4021, however, does not
appear to have the extra latch and thus may be subject to the
type of problems described.  On the other hand, when all of the
chips in the shifting chain are on the same board and the clock
edges are sharp and the clock traces feed all the shifters sim-
ilarly, there's not likely to be any problem.

The difficulty comes when, e.g., the clock is fed to shifters on
two separate boards and it's slope-limitted to minimize EMI.
No matter how slow the bit rate, the clock edge will trigger both
of the following events:

[1] The data input of the second device will latch the data from the
   first device.

[2] The data output from the first device will stop outputting the
   bit it was outputting (which is what we want the second device
   to latch) and start outputting new data.

Ideally, [2] will happen before [1], but if different Shmidtt trig-
gers have different threshholds, there's no guarantee that that will
be the case.  Adding a latch whose clock polarity is the opposite of
the shift registers' will cause the two events mentioned above to
happen on opposite clock edges; provided the clock edges do not occur
too close together, there will no longer be any race conditions.

I will mention an important caveat here, however: be careful of any
coupling between the data cascade signal going between the shifters
and the clock wire.  I had some trouble recently with that: the clock
would sometimes pick up a little noise from the switching data signal;
since the clock was itself in transition the noise was apparently en-
ough to cause a very brief (20ns or so) glitch on the clock wire which
the shifter quite happily used as an excuse to shift another bit.

When shifters work, they're wonderful.  But sometimes they can be a
pain in the [bleep]...

1998\11\02@172520 by Ian Chapman

flavicon
picon face
Thanks for all the replies to my original query on this thread.  So many
questions - so little time!

John Payson started this off some time ago by scaring me:
>I think the '595 is a much nicer part for many applications.
>The one feature the '595 lacks
>which would be nice to have would be a QH' output which was delayed by
>1/2 clock (to allow the devices to be cascaded without race conditions).

I then wrote:
>Having examined my own design, it looks as if I can get away with this,
>as the two '595s in question are driven directly by a PIC output via a
>short PCB trace with no additional loading.

Chip Weller responded:
>I just don't see any race condition on the '595. I have cascaded two in
>series before (but never longer chains), and have not had a problem.
>According to my data sheet (Philips, 5V operation (4.5V) -40 to +85C)
>the part has a 13nsec setup time and a 3nsec hold time from the positive
>clock edge. There is a 40nsec maximum delay until the data appears on
>the shift output pin. Chain will reduce the maximum shift rate from
>24MHz to 18.8MHz, but I don't see any race condition. Exactly where does
>the race condition you are seeing exist?

I can't speak for John, but I see the potential problem as occurring if
the new data ripples through the first shift register so fast that the
cascade output changes state before the hold time for the serial input
of the next stage has been satisfied.  This could result in the second
'595 shifting in the next-but-one bit rather than the next bit.

My 74HC595 data sheet states the following characteristics at +25C with
a 4.5V supply: propagation delay 19ns typ, 32ns max; hold time 3ns min,
-2ns typ.  This suggests a positive margin of 16-20ns (*) which should
be ample unless there is significant skew between the clock timing of
the two devices (e.g. if the rise time is slowed due to capacitive
loading and the two devices have different input thresholds).  However,
since no *minimum* propagation delay is specified, there seems to be no
guarantee that the cascade data will not appear earlier - although I
would imagine this to be very unlikely.

(*) Please disregard my previous comment about this becoming negative at
different supply voltages - my eye skipped a line on the data sheet!

Dwayne Reid also replied:
>You don't have a problem, and you can't add the flip flop to fix the problem
>you don't have because you can't get access to the shift register stages
>before the latch!  The '595  is DESIGNED to be cascaded.

Like Chip, I have not yet observed a problem - I am just nervous about
the potential for a marginal condition to exist.  I am glad to hear that
this appears to be only a theoretical possibility.

It is possible to add a flip flop to the cascade output, which is the
one stage of the shift register that is available prior to the latch.

Dwayne continued:
>You are right - there is little room for timing error.  If you need to feed
>the Qs output off-board to another '595, you will probably run into
>problems.  The cure is simple - add a RC delay to the clock line feeding the
>off-board shift registers.

Surely this will make the problem worse!  I was anticipating adding an
RC delay to the *data* line between the shift registers, to ensure that
the cascaded data remains stable during and shortly after the rising
edge of the clock.

Morgan Olsson reassured me further:
>I have used HC595 @2,6V supply, 7 chained in series: no problem at all.
>Driven from a 60HC05 @ 4MHz, 5V, as fast as possible, using just series
>diodes for logic level conversion together with HC595 internal clamping
>diodes.

If there were any marginal behaviour to be observed, then I imagine that
you would have found it with this configuration.  Sounds good!

Dennis Plunkett was pleased to hear about the 74HCT4094 alternative:
>HCT part, now that's good!

But Morgan Olsson cautioned:
>BTW, the ones with the T suffic are TTL compatible, and therefor do not
>have symmetric input levels, so they are more suspectible to be disturbed
>by EMI.
>So, stick to HC when possible, and AC if you need and can take that higher
>EMI.

I mentioned the HCT4094 rather than an HC4094 because, according to my
RS catalogue, the former is a Harris Semiconductor part but, as far as I
know, the latter is not being manufactured.  I'm aware of the lower
noise tolerance of HCT inputs but I don't anticipate this being an issue
if the shift registers are an electrically short distance from the PIC.

Whew!  I hope this clarifies my point of view.
--
Ian Chapman
<RemoveMEpicEraseMEspamEraseMEchapmip.demon.co.uk>

1998\11\02@172925 by paulb

flavicon
face
Morgan Olsson wrote:

> Yes, I don«t think the manufacturers have overlooked the possibility
> of chaining them.

 As far as I can see, there is no problem unless you make one in your
layout.  The *only* problem that can arise is slow clock rise time, such
as could happen if the clock was buffered between registers.

 One interesting approach to this is to feed the clock backwards
through the register chain.  If the registers are on separate boards, a
buffer per board (non-inverting) in this direction should be fine.
--
 Cheers,
       Paul B.

1998\11\02@225008 by Dwayne Reid

flavicon
face
I stand corrected!

>It is possible to add a flip flop to the cascade output, which is the
>one stage of the shift register that is available prior to the latch.

Yep - you can.  I was wrong.  For some reason, I was thinking that the '4094
Qs' output was 1/2 bit early rather than late.  This, of course, is
preposterous.


{Quote hidden}

I was so sure of myself that I didn't even go look at the boards where I do
this.  My memory had indeed failed me - I've just looked at 2 different
layouts and indeed, the delay network is on the DATA line.

Sorry for the misinformation.

dwayne


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

1998\11\03@051712 by Morgan Olsson

picon face
At 22:14 1998-11-02 +0000, Ian Chapman wrote:
>Thanks
-snip-

>Morgan Olsson reassured me further:
>>I have used HC595 @2,6V supply, 7 chained in series: no problem at all.
>>Driven from a 60HC05 *1 @ 4MHz, 5V, as fast as possible, using just series
>>diodes *2 for logic level conversion together with HC595 internal clamping
>>diodes.

OOPS; Corrections:
*1) it was of course 68HC05
*2) ment to say series *resistors* !
I must have been tired!  -sorry

To add more info: i had all clocks on 595's connected together, then a 2k2
(i think) to 68HC05 port pin, the same for latch.  The first 595 data input
had 10 kohm from 68HC05 port pin.  This display board connected to
processor board through a 20cm long ribbon cable, where I had a GND or
supply voltage conductor between each signal.  The resistors were of course
located on the display board.

3cm below the display board there was a 3-phase relay that switced a 2hp
motor!
Well if that caused glitches i am not sure, but it was not seen on the
display.
It was a one-unit design for a customer, to be used on a mobile steel sheet
band edge folder.  (He woorks on roofs etc)
Unit designed 5 years ago, never (yet) a malfunction.

But, if the shift registers were used for something that would never be
allowed to fail i would probably added *data* holding RC between the 595«s.

Or, as Paul B. Webster suggest, feed the clock "backwards" and delayed
between the shift registers.  Problem is that if unbuffered the signal rise
time vill not be very good after 7 series connected RC«s...

An alternative to RC delays is to use plain buffers.
Or pairs of inverters in series.
Using a HC04 we can have three delays (double inv) in one package!
Cheaper than 3 R and 3 C, mounting cost included.

An octal buffer with all buffers series connected to generate 8 clocks
consecutively delayed, 9 clocks including original.  Jump the odd ones to
get double skew.

(my display was updated at least 10Hz, i din not mind to get the shifting
extremely safe)
/Morgan

       Morgan Olsson                   ph  +46(0)414 70741
       MORGANS REGLERTEKNIK            fax +46(0)414 70331
       H€LLEKS           (in A-Z letters: "HALLEKAS")
       SE-277 35 KIVIK, SWEDEN               RemoveMEmrtTakeThisOuTspamspaminame.com
___________________________________________________________

1998\11\03@062645 by Peter L. Peres

picon face
On Sun, 1 Nov 1998, Ian Chapman wrote:

> Peter L. Peres <EraseMEplpspamspamspamBeGoneACTCOM.CO.IL> suggested addition of an RC network as a
> simple solution to a potential race condition when cascading two 74XX595s:
> >The SMT parts are required if the board is already manufactured. A
> >trace can be cut and the parts pasted from the back. In my case it was not
> >my design, I just invented a method to patch a stack of botched boards ;)
>
> Thanks for this suggestion, which looks very practical as the requisite
> track runs in the clear on the top side of the PCB.  I must read the data
> sheets more carefully in future!
>
> <Quick rant> I had assumed that, when the '595 data sheet says "The shift
> register has ... a serial standard output for cascading", it meant that in
> general this could be done without additional external components.  Since
> the '595 was designed more recently than the 4094 (at least, my '595 data
> sheet is dated Sept 1993 whereas my 4094 one is March 1988) I'm surprised
> that it did not draw on the strengths of the latter. </Quick rant>

The 4094 is so old, I can't find a data book without it, and I've some
from 1980 or so. The CMOS devices came out just after the 1st TTLs if I'm
not wrong. Or even before. Old & good ;)

> I'll be using the 4094 in future designs, unless I need an asynchronous
> reset capability.  It's cheaper than the '595 and it's also available as
> an HCT part (i.e. greater output drive if required).  It also looks as if
> the same PIC software can drive both parts interchangeably.

Well, if you don't care about non-tristate outputs anyway, use the LS/HCT
273 which is edge triggered and has an async reset. It has almost the same
problems as the 595 but the edge trigger removes most of it (the trigger
is faster than the Tpd) - but check !! this is from memory.

Peter

1998\11\03@125357 by Peter L. Peres

picon face
On Mon, 2 Nov 1998, Dwayne Reid wrote:

> I stand corrected!
>
> >It is possible to add a flip flop to the cascade output, which is the
> >one stage of the shift register that is available prior to the latch.
>
> Yep - you can.  I was wrong.  For some reason, I was thinking that the '4094
> Qs' output was 1/2 bit early rather than late.  This, of course, is
> preposterous.

Look up the 4094 data sheet and internal block diagram. It has way more
than just an extra flipflop: you can use an inverter and/or the fact that
there is a 'one gate' difference between Qs and Qs'.

The 4094 is a cunning little part ;) I wish there was something like a
4021 with an interrupt-on-change open drain output though (wishful
thinking).

Peter

1998\11\03@125409 by Peter L. Peres

picon face
On Mon, 2 Nov 1998, John Payson wrote:

> The difficulty comes when, e.g., the clock is fed to shifters on
> two separate boards and it's slope-limitted to minimize EMI.

Actually the trick with slow CMOS-B D flipflops is, that if the slope on
the clock is reasonably fast it is guaranteed that the next stage will
latch properly. The reason is the output buffer of the previous stage that
adds a natural 'two inverter' delay. This can be in the order of 200nsec -
1usec for CMOS-B series at 5V. So, all you have to do is, give them clock
with a flank better than 200 nsec. This is why I often use a 40106 to
boost the clock signal on an extender board when it was slowed down for
RFI suppression purposes. The PIC and other micro-controllers all have
flanks that are very fast vs. CMOS speed, and never cause problems in this
respect.

Peter

1998\11\03@125423 by Peter L. Peres

picon face
On Mon, 2 Nov 1998, Chip Weller wrote:

> Also the HCT part has the same output structure as the HC part. I prefer
> the HC parts when interfacing to most devices (execpt old 74LSxx parts
> which output TTL signals) since they provide a greater noise margin.

Well, I prefer the slow original CMOS parts unless I have reasons not to.
Not only are they very quiet RFI-wise, but the low response speed makes
glitches and other nasty issues disappear. There is no real reason to use
something fast in a LED/LCD driver that updates once every 20 msec or so,
unless you're trying to make concurrence to some local broadcast station
of course. Also, the low power requirements and the impossibility to make
them draw a lot of current are very very good for 'oopses'. In fact, I've
seen no failed CMOSs in any of the stuff I work with.

Peter

1998\11\06@213208 by paulb

flavicon
face
Morgan Olsson wrote:

> Or, as Paul B. Webster suggest, feed the clock "backwards" and delayed
> between the shift registers.  Problem is that if unbuffered the signal
> rise time vill not be very good after 7 series connected RC«s

 I wasn't proposing that you would need to use RC delays if the clock
is fed in "backwards".  I wouldn't propose RC delays anyyway.  More that
if you are going to be concerned with the delays you already have, that
is how things should be arranged.  Since the major application of these
chained shift registers is distribution of outputs over a wide area,
either on one PCB or many, it's more a matter of arranging things right
than adding extra delays.

> An alternative to RC delays is to use plain buffers.  Or pairs of
> inverters in series.  Using a HC04 we can have three delays (double
> inv) in one package!  Cheaper than 3 R and 3 C, mounting cost
> included.

 And an octal non-inverting buffer will provide 8.  I doubt however
any such thing would be necessary on a single board, rather route the
clock liine in the right order.

 Multiple boards I think should have the 595 and an HC14 on each, with
a double inverter in the clock line in the retrograde direction and
since you now have it already to spare, another double inverter in the
data line.
--
 Cheers,
       Paul B.


'Shift Registers'
1999\05\13@091137 by Mr Kok Lau
flavicon
face
Hi,

I'm building a digital camera, and I need to send some synchronizing
signals to a CCD chip.  And on top of that, the ADC that converts the
output signal from the CCD chip has it's own timing diagram as well.  I
was thinking of using some form of shift registers which I can program.
Hopefully it'll have 6 output lines, and the chip has it's own
microprocessor.  So I can program a sequence in and ask the chip to repeat
that particular sequence for each output line.  Does anybody know of a
chip with this kind of capability?

Or can anybody recomend me some other solution.  I'm thinking of using a
PIC, but that would mean I'll have to learn an extra language.  And at the
present moment, I'm already tied down trying to learn the programming
language for a digital signal processor which would do some signal
processing of the CCD signals.

The ultimate aim of the project is to apply kalman filters onto an input
stream of images and track the movement of an object.

Any help or suggestion would be helpful.

1999\05\13@212335 by Chris Eddy

flavicon
face
What kind of time resolution are you looking for?  microseconds or
milliseconds?

Chris Eddy

Mr Kok Lau wrote:

> Hi,
>
> I'm building a digital camera, and I need to send some synchronizing
> signals to a CCD chip.  And on top of that, the ADC that converts the
> output signal from the CCD chip has it's own timing diagram as well.  I
> was thinking of using some form of shift registers which I can program.

1999\05\13@212740 by Mr Kok Lau

flavicon
face
> What kind of time resolution are you looking for?  microseconds or
> milliseconds?
>
hopefully around microseconds range (apprx 25 - 60 microsecondS for each
register shift)
{Quote hidden}

1999\05\13@214616 by Chris Eddy

flavicon
face
Mr Kok Lau wrote:

> > What kind of time resolution are you looking for?  microseconds or
> > milliseconds?
> >
> hopefully around microseconds range (apprx 25 - 60 microsecondS for each
> register shift)

Hmmm.. Let's see here.  Assume you want to generate this bit pattern, but take
care of a few other simple matters, such as some state machines and the like.
Assume that the pic processor is a mid family part, with interrupts (you would
have to be a genius to pull it off in a 5X, unless the pattern is never
ending).  Using timer0 as an interrupt, and a 20MHz clock, your instruction
rate and clock input are 200nS  If you wait for the 256 roll, you will
interrupt in 51.2uS.  If this is not good enough, you can prestuff the timer
every interrupt and exit the turnpike every 20 or 30 uS.  I would say it looks
do-able.  I would also work hard to make sure that the ISR routine as the
lowest possible max execution time, so that it can fit in the 10-20uS of time
between interrupts, with some safety.  Last word of advice, wth these time
critical applications, specify the fine features of the task very clearly and
completely.  Maybe even draw some timing diagrams.

Then again, although it pains me to say this, you could look at Scenix.
(there.. I said it).

Chris Eddy

1999\05\14@005107 by Tjaart van der Walt

flavicon
face
Chris Eddy wrote:

> Then again, although it pains me to say this, you could look at Scenix.
> (there.. I said it).

Yeah Chris! Way to go!
Here's the link : http://www.scenix.com

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
RemoveMEtjaartKILLspamspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartSTOPspamspamspam_OUTsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\14@160658 by Thomas McGahee

flavicon
face
Mr. Kok,
Sounds like you want six recirculating shift registers that you can pre-load.

OK. Imagine a shift register whose last output is fed BACK into the first
input via a 1K resistor. Connect a PIC I/O line directly to the shift
register's first input. Whenever the PIC I/O line is high, it forces the input
high, regardless of the state of the final output. Whenever the PIC I/O line
is low, it forces the input low, regardless of the state of the final output.
If you re-program the PIC I/O is an INPUT, then the shift register input
will be the current state of the shift register's final output (or whichever
output is being fed back).

For six units, use six individual PIC outputs as shift register data lines.
For this application you would want to use a shift register that always
presents the internal data on its output lines. If your shift register
has LOAD and TRISTATE lines, make both active by hard-wiring to Vss or Vdd
as required. As for the Clock line(s), you can use a single I/O pin for all
shift registers that will be operating at the same clock speed.
Use separate clock lines for any shift registers requiring other clock speeds.

Load all six shift registers at a time, and use the clock lines to shift the
data in. When it has all been shifted in, switch the PIC data output
lines to act as inputs. This will now allow the data to re-circulate
via the 1k resistors.

The PIC now just has to drive the Clock(s) at the proper speed.

The absolute fastest that you can clock direct from the PIC with a
50% duty cycle is based on how long this loop takes:

Loop:     BSF      somereg,somebit
         NOP
         NOP
         BCF      somereg,somebit
         GOTO     loop

6 usec using a 4 Mhz PIC. 4 usec without the recommended NOPs, but
no longer 50% duty cycle. Still useful. But I recommend at least
one NOP between the BSF and BCF instructions.

For mixed-clock speeds, consider a longer section between the
LOOP label and the GOTO loop instruction. You can use full register
writes instead of the BSF/BCF instructions. This allows you to keep
multiple clocks all synchronized. Imagine two bits, A and B being loaded
as shown for 8 sets of loads:
AB
00
01
00
01
10
11
10
11
----- repeat sequence as often as needed

It is clear that B has a frequency that is exactly 4 times that of A.

If you need faster clocking speeds, then use an external clock. It can be
as fast as the shift registers allow (it is not restricted to the PIC
clock speed). Use a PIC I/O pin to control a data multiplexer so that
the Clock can come either from the PIC or from the external source.
In this case the PIC literally has nothing more to do once it has loaded
the shift registers and gated the external clock ON.

You can buffer the OSC2/CLKOUT pin and get a 4 Mhz clock almost for free.

You can reset via MCLR, of course. If you have any unused PIC I/O lines
you can maybe do something else useful with the PIC once it has
gated the external clock on. Like blink an LED!

*** [OT] ***

You can also more easily and cheaply implement this function (minus the
blinking LED) with several parallel-load serial-shift shift registers.
Hard wire the parallel-load data, or use DIP switches to set the pattern.
On power-up, pulse the LOAD line and away you go. Oh yeah, you need a
clock source.

Fr. Tom McGahee

----------
{Quote hidden}


'Shift registers'
2003\01\09@160748 by Colin Constant
picon face
HI,

I'm guessing that lots of folks use 8 bit shift registers to get data into
and out of PICs.  So I was just wondering what are the most popular para
in/ser out and ser in/para out devices.

Do you use any that are daisy chainable?

TIA
Colin



_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\09@162455 by tcs

face picon face
Huh?

That's what they make serial ports on the PIC for!
Why would I want to add a chip?

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\09@163909 by Wagner Lipnharski

flavicon
face
Colin Constant wrote:
> HI,
>
> I'm guessing that lots of folks use 8 bit shift registers to get data
> into and out of PICs.  So I was just wondering what are the most
> popular para in/ser out and ser in/para out devices.
>
> Do you use any that are daisy chainable?
>
> TIA
> Colin


A bunch of them in all logic books.

But obviously the question arise;

If you have a programmable unit in front of you, why not do the shift
register by software? considering you are using an unit without UART.

Wagner.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\10@135410 by Jeethu Rao

flavicon
face
He's asking about shift registers for IO expansion,
Not for communications.

I regularly use 74HC164 for output and 74HC166 for output.
And there are dozens more from all the logic families.

Jeethu Rao

{Original Message removed}

2003\01\10@141114 by Dwayne Reid

flavicon
face
At 01:57 PM 1/9/03 -0700, Colin Constant wrote:
>HI,
>
>I'm guessing that lots of folks use 8 bit shift registers to get data into
>and out of PICs.  So I was just wondering what are the most popular para
>in/ser out and ser in/para out devices.
>
>Do you use any that are daisy chainable?

4021 for inputs, 74hc595 for logic level outputs (also drives LEDs),
TPIC6595 for high current (sinking) outputs.  Note: there are probably
better chips for the input SRs - I've been using 4021 since the early '80s,
before the 74hc5xx family was introduced and just stay with it since it
does the job I need.

All are daisy-chainable.

dwayne

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

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
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.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

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