LED chase 4017

Thread Starter

kelvinmead

Joined May 15, 2011
30
Hi,

Im on a mission! i want to hit a button, and then a series of leds light up, one after the other (1 on at a time)

And when the last led lights up, it awaits the next button press.

Im using a simple 555 monostable circuit for the trigger, timing (of a secondary circuit) and the providing of a trigger.

From what ive investigated i have aquired some 4017 chips, but they are not performing the way i want (every button press lights the next led)

should i set a second 555 astable circuit to trigger the 4017, and then find a way to stop the 4017 at the end of the sequence, or is there a simpler way?

thanks
kelvin.
 

Yako

Joined Nov 24, 2011
245
Hi,
should i set a second 555 astable circuit to trigger the 4017, and then find a way to stop the 4017 at the end of the sequence?
That is correct. You're on the right thought path.

I would reserve the last Q output on the CD4017 as a flag indicating the end of the sequence. Enable / disable control over the NE555 IC.

You should only require one NE555 IC and an RC time constant here and there.

If you're starting to pull your hair out, then we will tell you how to do it.

Until then -- Keep thinking.
 
Last edited:

thatoneguy

Joined Feb 19, 2009
6,359
This link has everything you need to know about 555's and light chasers, and then a bit more (including a knight rider circuit or two).

Written by member Bill Mardsen here.
 

Thread Starter

kelvinmead

Joined May 15, 2011
30
ahh, ok, ive got it, but backwards! my trigger works fine (555 push button circuit creating +ve output for preset time)

i have the 555 astable with dual trims to fine tune the speed, and the output linked to the 4017.

now to stop the sequence after 1 cycle involves using the reset and enable to ground with a trigger / switch.

my trouble is my 555 outputs +ve and i need it to "trigger" ground.

at the moment, instead of choosing when to trigger the leds, im choosing to stop them...

edit, sorry, just being daft... did have the 4017 chip connected to the +ve, instead ive now connected it to the 555 trigger output and all works perfectly!

:)
 
Last edited:

Yako

Joined Nov 24, 2011
245
I don't see an EEPROM though. Wondering how he planed on making it interface to a PC for the user to be able to program in their own custom messages? Where to store the data and how to translate it? As it stands, there seems to be no PC software for that project.

I really had to think outside of the square when I engineered mine. It's not easy.
 

SgtWookie

Joined Jul 17, 2007
22,230
The PIC has EEPROM which the CPU can write to and store the patterns. They'll be retained after power off. Translating the characters is not a big deal; just a look-up table.
 

Yako

Joined Nov 24, 2011
245
It's not enough.

It is usually < ~200 bytes for most.

Certainly not enough to scroll a sentence of many words in my view.
 

SgtWookie

Joined Jul 17, 2007
22,230
With the PIC16F87x uC's, you can also programmatically write to flash memory.
The 873/874 have 4k flash, the 876/877 have 8k flash. Obviously, a fair portion of that will be used for the program and the look-up tables for the fonts.
 

thatoneguy

Joined Feb 19, 2009
6,359
With the PIC16F87x uC's, you can also programmatically write to flash memory.
The 873/874 have 4k flash, the 876/877 have 8k flash. Obviously, a fair portion of that will be used for the program and the look-up tables for the fonts.
It is a very small price step (50 cents), to go to an PIC18 series, where you have 128k of Flash for program memory/data, and 4k of dual ported SRAM for fast variable access. Compared to the 4k Flash program, 256 bytes of EEPROM, and 368 bytes of single port SRAM of the PIC16 series.

Fonts for scrolling messages are a few hundred bytes for the 7 bit ASCII set, and typically stored in program memory, since there's plenty of it in most cases, especially a sign that is built to only scroll messages. To get the USB computer connection, you'd be using a PIC18 anyway (unless you like bit banging at the slowest speed USB supports), I'm sure even a 1k font data chunk in program flash wouldn't be noticed from the 128k available.

@Bill
That capacitor dimmed KR display you linked above is the best rendition of the original I've seen, since the car used incandescent bulbs at the time. Found a scene from the original show: http://www.youtube.com/watch?feature=player_detailpage&v=NV-mlVVyb8w#t=221s, go to 3:40 in to see the sequence, you can deconstruct it to make it exact, there's only 8, and they are rectangles, not squares!
 
Last edited:

sheldons

Joined Oct 26, 2011
613
the last q op of your 4017 can be tied to the inhibit on the 4017 which would then freeze the count until you reset the 4017(plus with additional parts edge trigger a 555) 0r you could edge trigger a 555 from the carry out pin on the 4017(via additional parts)
 

Yako

Joined Nov 24, 2011
245
With the PIC16F87x uC's, you can also programmatically write to flash memory.
This is true, in fact, you can do that with any flash-based PIC. It is very slow though. One needs to remember that the ideal multiplexing frequency for LEDs is no less than 50Hz, otherwise you begin to see flicker.

Moreover, when sequentially writing data to the EEPROM flash memory it is suggested by Microchip that around 5mS of time be allowed before writing the next byte to preserve reliability.
 

Yako

Joined Nov 24, 2011
245
Fonts for scrolling messages are a few hundred bytes for the 7 bit ASCII set, and typically stored in program memory, since there's plenty of it in most cases, especially a sign that is built to only scroll messages. To get the USB computer connection, you'd be using a PIC18 anyway (unless you like bit banging at the slowest speed USB supports), I'm sure even a 1k font data chunk in program flash wouldn't be noticed from the 128k available.
Some people don't use fonts in the actual MCU or EEPROM, but rather get the PC interface software to convert each character into little more than row data that is seqentially cycled through. The MCU just writes bytes to the rows and cycles through the columns. Works well. To think fonts is to think a bit too high-level like for a project like this.

Take this for example (can scroll messages with thousands of chracters in length):

http://www.picbasic.co.uk/forum/showthread.php?t=6033
 

thatoneguy

Joined Feb 19, 2009
6,359
A well designed "window size" sign or similar scrolling sign shouldn't need to be connected to a computer to run, only to load data.

PIC18 series and many other uCs can write data/update their Flash program memory via the uC software at runtime, self-modifying code is possible. It is a one time slower operation. Loading a large message and the font is "only" a matter of setting up communication protocol to load font, then message, and writing the software interfaces. This is a commercial application, as the costs involved are not viable for a hobbyist, as LEDs alone would cost more than a new sign.

The only time a CPU should stay connected is when dealing with a video quality RGB graphical billboard on a busy street or baseball stadium, where a dedicated task oriented CPU w/Hard Drive storage and high speed wireless network updating is required.

The sign issue is far from "Easy" or "Simple" like the circuit being discussed in this thread. Topic is best left for another thread for somebody to create if they wish.
 
Top