Propeller: A test application - Digital Clock

littletransistor

As I've seen in other websites about building a digital clock (yeah, that's too simple for all of you guys, but this is the most common applications during learning microcontrollers), mostly revolves around single-core AVRs and/or PICs.

In any of the 8-bit single core microcontrollers in the market, the method is casual - if 7-segments are used, multiplex, and while the rest of them are done by inserting a 32.768kHz crystal inside, divide, divide, divide into 1Hz pulses, and then count these up, then to the BCD and finally convert to 7-segment through Look-up tables.

Yes - multiplexing and counting 1-secs will involve interrupts. And that's not beginner-friendly and these routines must not be starved. Cranking up the PLL multiplier works, or replace with a crystal with higher MHz value.

Wait, how about the buttons to set time and stuff? Must it be debounced or scanned? Just insert another interrupt routine inside? Gonna cook up tightly-timed routines again, which translates to more work. Whattabout the "blink" in the "hours" and the "minutes" sections during time-setting that is usually present in those digital clocks we all buy in the store?

A digital-clock chip like MM5314N could have all the stuff inside, and unfortunately, these are not manufactured anymore (if I'm not mistaken).

Could we stuff multiplexing, button scanning, some novelties present in the digital clock like blink digits, counting 1Hz pulses and decomposing the counters into readable BCD form, all into the Parallax Propeller? And of course, a few cogs will be taken to split the workload.

tonyp12

No proplem for the prop to run the function of a clock, even one cog could handle it all.

LED uses alot of power though, so battery operation is not an option.
So we don't have to run the prop in power saving mode either= higher accuracy.

I would use waitcnt to wait 1/256 seconds to time a state machine.

Every state cycle I would multiplex the 6 digit 7seg led, so the leds get a 16% duty cycle.

every state cycle I would run a debounce check on the buttons, if press =10 cycles in row = on.

every 128 cycles, blink (xor) the second dots if any.

Every 256 cycle add 1 to second counter.
If seconds counter = 60, miniutes =+1, seconds=0

littletransistor

tonyp12 wrote: »

No proplem for the prop to run the function of a clock, even one cog could handle it all.

LED uses alot of power though, so battery operation is not an option.
So we don't have to run the prop in power saving mode either= higher accuracy.

I would use waitcnt to wait 1/256 seconds to time a state machine.

Every state cycle I would multiplex the 6 digit 7seg led, so the leds get a 16% duty cycle.

every state cycle I would run a debounce check on the buttons, if press =10 cycles in row = on.

every 128 cycles, blink (xor) the second dots if any.

Every 256 cycle add 1 to second counter.
If seconds counter = 60, miniutes =+1, seconds=0

Thanks for the opinion. Well, the digital clock I mentioned is not for battery operation - it's emulating the digital clock chip during the 70s and the 80s, but with a different kind of twist (like adding RTC and stuff).

Could it be possible if I use one cog for multiplexing, and another one for button debouncing and another one more for general timekeeping?

Heater.

Better to use just one COG for all the basic clock things as described above.

Then you have all those spare COGs free for more interesting features.

Say getting correct time updates from a five dollar GPS unit. Or playing tunes form SD card for alarms and such. Or get the thing to display temperature.

I'm considering throwing something together like that myself as I have had tubes of seven segment LED digits hanging around for years. My clock will also have to double up as a frequency counter.

Mike Green

Yes, typically you'd use one cog for multiplexing the display. It would also do the decoding of the segments as it's multiplexing so the rest of the program would just deal with digits and some single bits for decimal points or colons.

You'd use one cog for timekeeping. It would keep the one second clock and update the memory locations used by the display cog.

A third cog would handle any buttons, debounce them, and interpret the meaning of the buttons (handle setting the time or changing modes, etc.)

If you want an alarm, a fourth cog could handle that including the generation of sound.

Dividing up the tasks like this makes for a more straightforward program than a state machine

littletransistor

Mike Green wrote: »

Yes, typically you'd use one cog for multiplexing the display. It would also do the decoding of the segments as it's multiplexing so the rest of the program would just deal with digits and some single bits for decimal points or colons.

You'd use one cog for timekeeping. It would keep the one second clock and update the memory locations used by the display cog.

A third cog would handle any buttons, debounce them, and interpret the meaning of the buttons (handle setting the time or changing modes, etc.)

If you want an alarm, a fourth cog could handle that including the generation of sound.

Dividing up the tasks like this makes for a more straightforward program than a state machine

Yes - I agree. The state-machines are effective, however, I'm still in a struggle and learning how to master them. Right now, I only know how to do a simple state machine using the "case" in C/C++ and a counter which is inside. But that's for the PIC microcontrollers + timer interrupts inside.

However, the digital clock I'm showing is actually to the begineer microcontroller hobbyists and engineering students (example, Mechanical and Chemical) without much background knowledge of microprocessors. The clock might not be useful in their projects, but it is just a loose demonstration of parallel processing.

tonyp12

Using a few cogs just to show off the parallel power of the prop is good.

But State machines are easy to do, just remember to never use long loops or wait.
(not real code below)

Loop:
Waitcnt 1/256second. ; next delay will be added here too so code time below is non relevant.

statecounter=statecounter+1        ; free running master counter

7seg lookup-table for led(n)
set pins gnd or vdd etc.
n=n+1, if n=6 when n=0             ; if whe having 6 digits

test statecounter, #%1111111 wz ; only happens every 128 cycles.
if_wz XOR pin20                 ; second dot(s): on 1/2 second off 1/2second.

test statecounter, #%11111111 wz ; only happens every 256 cycles.
if_wz add SecLow, #1
    cmp SecLow, #10 wz
if_nz jmp #donetime:
    clr SecLow
    add SecHigh, #1
    cmp SecHigh, #6 wz
if_nz jmp #donetime:
    clr SecHigh
    add MinLow, #1
    cmp MinLow, #10 wz
if_nz jmp #donetime:
    ....   
    ....

donetime:
jmp #Loop:

P.S I would treat each led digit as inpendent and not count to 0-59 (or 1-12)
but SecLow= 0-9, SecHigh= 0-5, makes the LED multiplex rutine smoother.