banner



How To Cascade Shift Registers

Guest

Super Member

  • Full Posts : 80508
  • Advantage points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

Driving cascaded SIPO shift registers (74HC595'south)

Greetings all,

Forgive the length of my first postal service ever in this forum . I am trying to exist
equally thorough as possible to hopefully gain hints from such wizards as
ric, bob_barr, Olin, mfb and the rest of the gang on this forum

Afterward searching archives and googling and I have non been able to find
by and large accepted programming techniques on driving multiple 74xx595
SIPO shift registers which are cascaded together.

I am currently working with an 16f628 PIC and ASM as my language

I have four 74HC595 shift registers cascaded. I would similar to drive
24 common cathode 7 segment LEDs in multiplex fashion past using i '595 to
drive the anodes/segments of the displays, and use the remaining three
'595 shift registers to drive transistors that would control the cathodes
of each individual display

Driving the segments was an easy exercise every bit the pattern for the displays
fits in one byte/register as so:

                    
;SN74xx595 shift annals layout
SCK equ RA3 ;clock pulse output
SER equ RB4 ;serial data output
RCK equ RB5 ;strobe latch output

;segpat has the 7 segment led blueprint to be displayed
;
drive_segment movlw 0x08 ;write one byte
movwf i ;prime number iteration counter
next_segment rlf segpat,f ;shift all bits one identify
bcf PORTB,SER ;default output bit to 0
btfsc STATUS,C ;practice nosotros have a scrap to output?
bsf PORTB,SER ;yes, set output bit ane
bsf PORTA,SCK ;pulse our clock loftier
bcf PORTA,SCK ;pulse our clock low
decfsz i,f ;any more than $.25 to write?
goto next_segment ;yes, write out the adjacent bit
bsf PORTB,RCK ;no, load byte on to the latch
bcf PORTB,RCK ;reset the latch
return ;done writing one byte

My question is what would be a skilful technique on driving the remaining
3 shift registers? I would crave i 24bit register to fit my bit
design on which cathodes I want to bulldoze. Or since I'm using an 8
flake microcontroller I would need three 8bit registers for the
scrap pattern.

I as well considered structuring the code so I have a loop to drive the to a higher place
code 3 more times for the other 3 shift registers. Or in pseudo-code,
consider:

                    
/* drive 3 shift registers for cathode control */
for (i = 0; i <= iii; i++) {
/* each shift register needs 8 bits input */
for (j = 0; j <= 8; j++) {
shift bit out
}
}

/* drive 1 shift register for segments */
for (i = 0; i <= viii; i++) {
shift bit out
}

Perhaps there is a more elegant solution. Any hints or maybe some
asm code or application notes to share anyone?

A little more background on this project. It's a four player game with 6
LEDs per player. 6 * 4 = 24 LEDs

- During the game not all players may be 'live', so I do not want to
bulldoze ALL the cathodes all the time. Worst case, all 4 players are
alive so I must drive each cathode. Best case, only 2 players
are live so I only need to drive 12 cathodes.

- As an aside, I technically simply need 3 '595's to drive all 24 LED's
3 '595s * viii = 24 Would it be easier to assign each player ain HC595
instead, and so making bit patterns for driving the cathodes easier

- Another matter to consider is speed, as I desire to avoid whatever flicker.
If anyone has hints on perhaps a more efficient way doing this please
lemme know. Driving that many LEDs in multiplex style will exist in
interesting claiming for me. [&:]

Thank you!
-Vivi Smile

< Message edited by vv -- Jan. 8, 2005 2:11:40 AM >

Invitee

Super Member

  • Full Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 06:30:51 (permalink)

Just let me become this straight; you have 24 displays, each 7 segments, right?

And then in each cycle you are driving one of the vii segments, on all displays in parallel. That means yous need to shift out the bit pattern of the displays interleaved. Lets say yous have 24 viii-bit registers, R1 ... R24, containing the fleck blueprint for each 7 segment display (I assume this is the near natural fashion for your application).

The register would incorporate east.g. (in binary format)
R1 = x, D1S7, D1S6, D1S5, D1S4, D1S3, D1S2, D1S1
R2 = x, D2S7, D2S6, D2S5, D2S4, D2S3, D2S2, D2S1
...
so "D2S5" ways Brandish 2 Segment five, and "x" = not used.

Y'all would demand to shift out
D1S1, D2S1, D3S1, D4S1, D5S1, D6S1, D7S1, ..., D24S1
in the first cycle, and in the next cycle
D1S2, D2S2, D3S2, D4S2, D5S2, D6S2, D7S2, ..., D24S2

To practise this efficiently you could use indirect addressing. If R1 - R24 are stored in consecutive registers, you could do something similar this

                    movlw	D'7'			; There are 7 segments
movwf SEGMENT_COUNTER

movlw B'00000001' ; This is the initial bit mask for the segment selection
movwf SEGMENT_SELECT

next_segment
; Outer loop : drive all 7 segments of each brandish
movlw D'24' ; There are 24 displays
movwf DISP_COUNTER

movlw R1 ; Initiate FSR (pointer)
movwf FSR
next_display
; Inner loop : shift out current segment for each display
bcf PORTB,SER ; Default output bit to 0

movf SEGMENT_SELECT, w ; Move segment flake mask to W
andwf INDF, w ; AND with current display chip pattern
btfss Condition, Z ; If zero, and then skip setting SER = 1
bsf PORTB, SER ; SER = 1

bsf PORTA,SCK ; Pulse our clock high
bcf PORTA,SCK ; Pulse our clock low

incf FSR, f ; Increase FSR to admission next display register
decfsz DISP_COUNTER, f
goto next_display

bcf STATUS, C
rrf SEGMENT_SELECT, f ; Shift right to access next segment

bsf PORTB,RCK ; Load bytes on to the latch
bcf PORTB,RCK

; Here you must change segment to be driven
;
;

decfsz SEGMENT_COUNTER, f
goto next_segment

Note that the part where I wrote "Here you must change segment..." is where I call up y'all should clock a decade counter, instead of a '595, since yous will ever only go along one segment active at a time (the bit blueprint of a 595 would always exist seven '0'south and one '1').

Also note that past using this method at that place volition be no need of intermediate storage of the interleaved bit pattern. Instead the interleaving is washed at the same time equally the output is generated.

Hope this helps y'all in some mode.
Cheers

NOTE: I edited the code because I had forgotten to initialize some registers...

< Message edited by Jakob [SWE] -- January. 8, 2005 6:39:02 AM >

Olin Lathrop

Super Member

  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 06:58:58 (permalink)

I'chiliad not clear what you lot're request. Does this code work or not? If and then, what's the trouble with calling information technology 3 times?

                      
;SN74xx595 shift annals layout
SCK equ RA3 ;clock pulse output
SER equ RB4 ;serial information output
RCK equ RB5 ;strobe latch output

Defining symbols for port $.25 is a practiced idea, but y'all've simply washed it half way. You are still relying on knowing later which port a chip is in. A better fashion to do this is to ascertain a string substitution macro for the port and the flake:

                    
#define sck porta, 3
.
.
bsf sck
                      
;segpat has the seven segment led design to exist displayed
;
drive_segment movlw 0x08 ;write one byte
movwf i ;prime iteration counter
next_segment rlf segpat,f ;shift all bits ane place
bcf PORTB,SER ;default output bit to 0
btfsc Condition,C ;practice nosotros have a bit to output?
bsf PORTB,SER ;yes, ready output bit one
bsf PORTA,SCK ;pulse our clock loftier
bcf PORTA,SCK ;pulse our clock low
decfsz i,f ;any more than $.25 to write?
goto next_segment ;yes, write out the adjacent bit
bsf PORTB,RCK ;no, load byte on to the latch
bcf PORTB,RCK ;reset the latch
render ;done writing 1 byte

Another potential trouble is that y'all are ignoring the banking company setting. For this code to work, the depository financial institution needs to be gear up to 0, and the variable "I" had improve be in that bank.

Guest

Super Member

  • Total Posts : 80508
  • Advantage points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595'southward) 2005/01/08 07:16:24 (permalink)

I read your posts + Olin's reply a few times, and realized that y'all probably have gotten some things wrong in your postal service.

Yous say you use i register to select segment, and 3 others to select displays. Now, in your posted asm code yous assume that you have a bit pattern for a brandish and want to shift that out. And so y'all say you want to shift out a 24 bit blueprint on which displays to bulldoze. This seems to be logically wrong. The proper style would be to shift out 24 bits, where only one chip is set ('one') and all others are '0', in lodge to select the display for which the segment bit pattern has been shifted out. Get the idea?

Now this is not a very good solutions since the on/off ratio would be only 1/24 (1 display at a time is existence driven). In my code, I causeless that you lot instead select one segment at a time, so shift out the 24 bit pattern of which displays has this segment set. This gives an on/off ratio of seven, much better. Smile

bob_barr

Super Member

  • Total Posts : 5428
  • Advantage points : 0
  • Joined: 2003/eleven/07 12:35:23
  • Location: Morgan Hill, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 07:58:54 (permalink)

Wow, y'all certainly 'did your homework' before making your first post.grin

At first look through your code, I don't see anything that I'd suggest beyond what Olin has already pointed out. It's early on though and I need my first cup of coffee. I'll look through it again and run into if I can add anything to Olin'south comments.

HEY NEWBIES - Now, THIS is how to enquire a question!

While it's always practiced to larn from 1's mistakes, it's much easier to learn from the mistakes of others.
Delight don't PM me with technical questions. I'll be quite happy to help (if I can) on the forums.

bob_barr

Super Fellow member

  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2003/xi/07 12:35:23
  • Location: Morgan Hill, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'south) 2005/01/08 08:07:07 (permalink)

The HC595 is a 'not-rippling' register. Information technology has separate shift and output registers.

While the information is being clocked through it, the output pins practise not change. A strobe (Latch Enable) transfers the data from the shift register to the output annals.

In one case the data has been strobed into the output annals, the output pins will remain the same until new data is strobed in with the next 'Latch Enable'.

While it's e'er skilful to learn from one's mistakes, information technology'south much easier to acquire from the mistakes of others.
Delight don't PM me with technical questions. I'll be quite happy to help (if I tin) on the forums.

K8LH

Super Member

  • Total Posts : 1888
  • Reward points : 0
  • Joined: 2004/03/26 05:12:34
  • Location: Michigan, The states
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 08:21:10 (permalink)

VV, tin I presume yous're doin' somthing similar this? If so, you lot'll be sending 32 $.25 of information for each digit browse. The commencement 24 bits are the digit select (just one 'ane' or '0' flake in the lot, depending on your digit driver polarity) and then the viii segment information bits, earlier issuing the strobe/latch with RCK. This is easy enough to do the way you're going.

The only problem I see is that a 1/24th scan rate is approximately a 4% duty wheel and it'due south been my experience that annihilation less than about ten-12% yields extremely low illumination of the LEDs...

Expert luck with your project... It looks like slap-up fun...

Regards, Mike - K8LH (Westland, MI, USA)

Attached Image(s)

bob_barr

Super Fellow member

  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2003/11/07 12:35:23
  • Location: Morgan Hill, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'due south) 2005/01/08 08:28:47 (permalink)

The just problem I see is that a one/24th scan rate is approximately a 4% duty bicycle and it's been my feel that annihilation less than nigh 10-12% yields extremely low illumination of the LEDs...

Duty cycle doesn't come into play here. The LED drive is latched from i update cycle to the next. See my before post on how the HC595 works.

<added
Forget this post. The display actually is being time-multiplexed.
/added>

< Message edited by bob_barr -- January. 9, 2005 x:55:12 AM >

While it's e'er adept to learn from 1'south mistakes, information technology's much easier to learn from the mistakes of others.
Delight don't PM me with technical questions. I'll exist quite happy to help (if I can) on the forums.

K8LH

Super Member

  • Total Posts : 1888
  • Advantage points : 0
  • Joined: 2004/03/26 05:12:34
  • Location: Michigan, United states of america
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'southward) 2005/01/08 08:39:18 (permalink)

Bob, forgive me, I'm confused (I'm a relative "newbie" too). I sympathise the '595 latches volition go along the segment data and digit select 'alive' while the next serial stream is being clocked in, but, if merely one LED can be displayed (latched) at a time with this circuit doesn't that yield a 1/24th duty bicycle per display when you lot want to light all 24 displays?

Regards, Mike - K8LH

< Message edited past K8LH -- Jan. 8, 2005 11:48:25 AM >

bob_barr

Super Member

  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2003/11/07 12:35:23
  • Location: Morgan Loma, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'due south) 2005/01/08 08:53:20 (permalink)

No forgiveness required.Smile It certainly tin can become confusing.

The key is that the LEDs aren't being turned on individually nor are they existence scanned across digit-by-digit.

With the proper data pattern latched into the 595 output registers, the LEDs can have all of the segments turned on at the same time. Those segments volition all remain on until the next brandish update cycle.

While information technology's always good to acquire from one's mistakes, it'south much easier to learn from the mistakes of others.
Please don't PM me with technical questions. I'll exist quite happy to help (if I can) on the forums.

Guest

Super Fellow member

  • Total Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Condition: online

RE: Driving cascaded SIPO shift registers (74HC595'south) 2005/01/08 11:01:20 (permalink)

How-do-you-do Olin,

Thank you for your reply.


I'm non clear what you're asking. Does this code piece of work or not? If and so, what'due south the problem with calling it 3 times?

My question is, how do people typically handle this hardware situation,
e.g. driving multiple 8bit IC's cascaded. In my instance I essentially have
1 large 32bit annals.

What algorithms or data structures would you use to drive a 32 bit shift
register using an 8 flake microcontroller? K8LH posts below has a diagram
depicting _exactly_ the setup I had in mind if that helps visualize.

I have included the code to drive _one_ 8 bit shift register
successfully. Information technology works ok in my breadboard. To test information technology out I used 2
7 segment LED and two discrete transistors (for controlling brandish
cathodes) driven from 2 other pins on the PIC. Now I want to tackle
driving multiple displays and control the transistors through shift
registers

Another thing to proceed in mind is I do non necessarily need to bulldoze all
the cathodes sequentially. If I may quote myself:


- During the game not all players may exist 'alive', so I exercise not want to
drive ALL the cathodes all the time. Worst case, all four players are
live then I must bulldoze each cathode. Best case, only ii players
are live then I only need to drive 12 cathodes.

- As an aside, I technically only need 3 '595'due south to bulldoze all 24 LED's
iii '595s * 8 = 24 Would it exist easier to assign each histrion ain HC595
instead, so making flake patterns for driving the cathodes easier

I promise this makes more sense. Here is some more code and logic to
illustrate what I have then far. A couple of things I should explain
nigh information technology.

This code is executed via an ISR since I'1000 controlling all the
displays in multiplexed mode and getting all the displays lit
and bright is high priority since I'thou driving so many of them.

The lawmaking
-loops through all the players
-Information technology tests to see if they are live or expressionless
-If they are alive illuminate their display.
-If they are expressionless, skip them and go on to the side by side player.

I utilize the census variable to keep rail of who is live and who is dead
1 bit per per actor, with a maximum of 4 players (the chip is set if
the player is alive and cleared if the histrion is dead)

I update the census annals in the principal loop of the code killing
players off as needed.

The subroutine I am trying to write is the the 'output_health' shown
below. It should have admission the the iteration counter 'histrion' used in
show_health to make up one's mind which display should be lit. (I assume histrion 1
gets displays 1-6, player ii gets displays 7-12, player 3 gets displays
13-xviii and actor 4 gets displays 18-24) And information technology would have admission to the
wellness points to be displayed (stored in due west before output_health is chosen)

And I suppose it would use the routine I wrote in my original post to
display a vii segment bit pattern

                    
NPLAYER equ 0x04 ;maximum number players supported

cblock 0x20 ;begining of VRAM
player ;current player
health:NPLAYER ;role player wellness points
census ;players live/dead status
endc

show_health movlw NPLAYER ;how many players?
movwf player ;prime iteration counter
movlw wellness ;load health assortment
movwf FSR ;fetch start wellness counter
next_health movf INDF,westward ;number to exist displayed in output_health
rlf census,f ;check the players mortality
btfsc census,iv ;is the actor alive?
call output_health ;yes <- THIS IS THE SUBROUTINE IM TRYING TO WRITE
incf FSR,f ;no, fetch adjacent health counter
decfsz actor,f ;any more health counters left?
goto next_health ;yes,
swapf census,f ;no, restore our census
render ;done displaying

output_health call bin2bcd ;convert wellness points to decimal
movf msd,w ;fetch its most pregnant digit
call bcd2seg ;lookup its 7 segment LED pattern

;do something nifty to drive display one here.
;this is what im missing

movf lsd,westward ;fetch its least significant digit
telephone call bcd2seg ;lookup its 7 segment LED pattern

;do something nifty to drive display 2 here.
;this is what im missing
.
.
.
;etc etc
return

I hope I am not making matters more than confusing by introducing more details.
merely it somewhat essential to my design problem/question. If it is somewhat
flawed I won't be offended if you lot tell me grin


Defining symbols for port bits is a good idea, but y'all've only done it
half way. You are notwithstanding relying on knowing later which port a bit is
in. A meliorate way to do this is to define a cord commutation macro
for the port and the bit:

#define sck porta, 3

Agreed. For this mail I chose to not be equally symbolic every bit I normally would
take, and then as to non confuse people. In hindsight perchance it would not
have been so disruptive after all since you lot only happened to detect grin


Some other potential trouble is that yous are ignoring the bank
setting. For this code to work, the bank needs to exist fix to 0, and the
variable "I" had improve be in that bank.

Of course. I omitted much of the housekeeping code such as this and so as
to non backbite from the master problem and interesting parts of the code. wink

-ViVi

< Message edited past vv -- Jan. viii, 2005 11:34:02 AM >

Invitee

Super Fellow member

  • Total Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595'due south) 2005/01/08 11:06:52 (permalink)


Wow, you certainly 'did your homework' before making your starting time mail service.

Howdy Bob,

I accept been lurking here for quite a expert while. I can usually discover answers to my questions by searching the athenaeum or Usenet. Still I am stumped on this item instance [eight|]


At commencement look through your code, I don't come across anything that I'd propose across what Olin has already pointed out. It's early though and I demand my starting time cup of coffee. I'll look through it once again and see if I can add anything to Olin'due south comments.

I have replied to Olin's mail service with more details, perhaps it volition be more useful in describing my problem more accurately.

Thank you for any aid or ideas
-ViVi

Guest

Super Member

  • Total Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 11:sixteen:58 (permalink)

ORIGINAL: K8LH

VV, can I presume you're doin' somthing similar this? If so, y'all'll exist sending 32 bits of data for each digit scan. The first 24 $.25 are the digit select (only 1 '1' or '0' bit in the lot, depending on your digit driver polarity) and and then the eight segment information bits, before issuing the strobe/latch with RCK. This is easy enough to do the way you're going.

Hello K8LH,

This is precisely what I had in mind. Although I was thinking perhaps using a TPIC6B595 (a Power Logic viii-flake Shift Register) for driving the segments and the remaining iii vanilla 74HC595s would bulldoze ULN2803 for decision-making the cathodes in example anyone was interested. Its all an idea and not sure how well information technology will work simply I volition test information technology out soon.

-ViVi

bob_barr

Super Member

  • Total Posts : 5428
  • Advantage points : 0
  • Joined: 2003/11/07 12:35:23
  • Location: Morgan Hill, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'due south) 2005/01/08 11:37:17 (permalink)

This is precisely what I had in heed. Although I was thinking perchance using a TPIC6B595 (a Power Logic 8-flake Shift Register) for driving the segments and the remaining 3 vanilla 74HC595s would drive ULN2803 for controlling the cathodes in case anyone was interested. Its all an thought and not certain how well it volition piece of work but I will test it out before long.

You might want to double-check the Iol and Ioh specs on the vanilla HC595. IIRC, it's a adequately 'beefy' fleck and may be able to meet your needs without the ULN device. Since there's no multiplexing of the segment drives, you lot may exist surprised at how little current it takes to get practiced brightness.

While information technology's e'er good to larn from one's mistakes, information technology's much easier to learn from the mistakes of others.
Please don't PM me with technical questions. I'll exist quite happy to help (if I can) on the forums.

stewart

Super Member

  • Total Posts : 191
  • Reward points : 0
  • Joined: 2004/01/23 00:xi:24
  • Location: Colorado
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'south) 2005/01/08 11:51:32 (permalink)

VV

I may exist over simplifing things, if then, I'm sad for overlooking.

Equally Bob pointed out, the shift registers you are using concur what ever information they final latched. Then based on latched information, why fifty-fifty bother with digit selection? It would seem to me that you simply need to write the brandish equally required (when the data to be displayed is updated).

If the 'rest' of the lawmaking determines that player iii is out, simply articulate all of the bits for the role player 3 data.

Again, since the data is latched, at that place is no need to 'scan' the display.

I would write the lawmaking such that your primary focus is controlling the data to be displayed. The code to write out the changed data doesn't fifty-fifty need to "care" what is in the data, merely shift it out and then strobe the mutual "latch" betoken to display the new data. This could be done either by setting a flag to say "information has changed" or (if information technology were me) would use a backgroung routine that would update the display every 50mS (or whatsoever) regardless of a modify or not. Just this arroyo would work best to copy the working information to a private display information area then shifts and other modifications to the display information would not "stomp" on the working brandish information being maintained by the "rest" of the lawmaking. This way, once the 'UpdateDisplay" lawmaking is written, yous don't have to worry or even consider it within the part of the code that is creating the game or other proccess.

Break your lawmaking up into functional blocks, make each take intendance of "it's ain trivial world" and they hardly need to know (or care) what the other parts are doing.

Have fun

Stewart
When in doubtfulness,
READ, REAd, REad, Read the data book.

Guest

Super Member

  • Total Posts : 80508
  • Advantage points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595'due south) 2005/01/08 12:02:33 (permalink)

My question is, how practise people typically handle this hardware situation,
e.g. driving multiple 8bit IC'due south cascaded. In my case I substantially have
one big 32bit register.

Hm, what about using iv 8-bit registers? It seems like no 1 really understands what your question is... I am getting more and more than confused with all posts. Are y'all asking about how to clock 4 cascaded '595s or are you asking virtually how to drive multiplexed displays?

You take iv '595 ICs cascaded. Whenever you desire to change the status of all '595 ICs, simply shift out 32 bits that corresponds to whatever y'all desire to put on the output latches. And then latch the data. It is that uncomplicated, yes.

Using an 8-bit controller? Employ one GPR for the first 8 bits, then use another GPR for chip 9-16, a 3rd GPR for bit 17-24, and a 4th one for 25-32.

I suggest that you draw a picture of what the displays will look like, different cases and then on. That would make things much easier to empathise.

< Message edited by Jakob [SWE] -- Jan. 8, 2005 12:05:28 PM >

Invitee

Super Fellow member

  • Total Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Condition: online

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 12:fourteen:43 (permalink)

ORIGINAL: bob_barr

No forgiveness required.Smile It certainly can become confusing.

The key is that the LEDs aren't existence turned on individually nor are they being scanned across digit-by-digit.

With the proper information blueprint latched into the 595 output registers, the LEDs tin can have all of the segments turned on at the same time. Those segments volition all remain on until the adjacent display update cycle.

That sounds incorrect to me. Even if the reg's take output latches, y'all'd go a dudy cycle less than 100%. Yep, yous can turn on all segments of all displays at the same time, simply suppose you lot want something else, or more specific different patterns on each brandish.
As I see it, there's no mode yous tin drive 24*7 individual LEDs using 32 private signals without multiplexing, if you want to be able to create all possible patterns of the LEDs. Or am I incorrect?

bob_barr

Super Member

  • Full Posts : 5428
  • Reward points : 0
  • Joined: 2003/11/07 12:35:23
  • Location: Morgan Loma, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595'south) 2005/01/08 12:46:32 (permalink)

I call up yous may be confusing hardware multiplexing (sets of segments being existence driven by different cathodes) with fourth dimension-multiplexing (sets of segments being driven at different times).

In this application, whatever the brandish latches contain will bulldoze the segments until the next fourth dimension the latches are rewritten. Once they take been changed, they will remain in that new land until they're changed all the same again. This is what I mean by '100% duty wheel'. The display is static between updates and doesn't require any periodic updates for all of the sets of segments to remain visible.

In the case of time-multiplexing, sets of segments are lit at different times and the center's 'persistence of vision' makes information technology appear equally if they're lit steadily. If iv sets of segments are being scanned in round-robin fashion, the duty cycle on each set is 25%. If the display isn't periodically refreshed, only 1 of the 4 sets will be visible. If the display doesn't get refreshed quickly plenty, it will appear to flicker.

While it's always expert to learn from i'southward mistakes, it's much easier to learn from the mistakes of others.
Please don't PM me with technical questions. I'll be quite happy to assistance (if I tin) on the forums.

Guest

Super Member

  • Total Posts : 80508
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 xiii:00:28 (permalink)

OK, and so the author was referring to hardware multiplexing in his first post. I immediately assumed time-multiplexing since we're dealing with LED displays hither. But I don't fully sympathise the original question, and so I think I'll quit posting [&:]

bob_barr

Super Member

  • Full Posts : 5428
  • Reward points : 0
  • Joined: 2003/eleven/07 12:35:23
  • Location: Morgan Colina, CA
  • Status: offline

RE: Driving cascaded SIPO shift registers (74HC595's) 2005/01/08 13:12:thirty (permalink)

Simply I don't fully sympathize the original question, so I call back I'll quit posting

There's no reason to quit posting.Smile People make assumptions all the time and some of them simply turn out to have been incorrect. (I think, though, that we may have hashed things out pretty thoroughly on this detail thread.)

While it'due south always good to learn from 1'southward mistakes, it'south much easier to acquire from the mistakes of others.
Please don't PM me with technical questions. I'll be quite happy to aid (if I can) on the forums.

Source: https://www.microchip.com/forums/m69059.aspx

Posted by: smithgoidesseem.blogspot.com

0 Response to "How To Cascade Shift Registers"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel