EmbeddedRelated.com
Forums

Irregular second countdown on LCD

Started by Fiona Soon January 18, 2005
Hello All,
 
I am doing a project that involves the LCD as a count down clock. The clock would display the second and minute digit as control by a PIC16F84 PIC. The minute count down is working out fine with regards to the second decrement. But, the second decrement was decreasing in a very random number such as 00, 59, 57, 54,.......until 0 and so on. Before this, i have checked the second output in MPLAB and the second count down is just regular, ie,.00,59,58,57,56,.....for very loop that the pic runs. Can someone tell me why?
Thanks!
 
 
Fiona




I'm curious if this is a class project?

You've given no details about your design so it's impossible to
diagnose. Interrupts? Is the time advancing at the proper rate (i.e.
is it the display or the timer)? I suggest you break your application
up into its component pieces and check each one in turn. The answer
should present itself quickly.

--- In , Fiona Soon <fionasoon2001@y...> wrote:
> Hello All,
>
> I am doing a project that involves the LCD as a count down clock.
The clock would display the second and minute digit as control by a
PIC16F84 PIC. The minute count down is working out fine with regards
to the second decrement. But, the second decrement was decreasing in a
very random number such as 00, 59, 57, 54,.......until 0 and so on.
Before this, i have checked the second output in MPLAB and the second
count down is just regular, ie,.00,59,58,57,56,.....for very loop that
the pic runs. Can someone tell me why?
> Thanks! > Fiona >
> ---------------------------------
>





Hello Phil,
 
I am actually designing a count down timer for a Continuos Passive Motion Machine for knee post surgery patient to exercise their leg muscle. The patient will put their leg on a base that is drive up and down by a DC motor.
That timer is used to count down the exercise time. If we set 20 minutes. It will count down and stop the machine at 0 minute. The second digit is not a critical issue here. It was just a trial to understand how a second digit work.
 
I did not use any interrupts and the motor control is done by another PIC16f877. PIC16F84 was use for the clock. I have written a timing subroutine for 1second and decrement a counter after the 1 second delay. After that delay, it will output the counter value to the LCD.
 
I am not good in explaining. I hope you understand.
 
 
Thank you, phil.

Phil <p...@yahoo.com> wrote:

I'm curious if this is a class project? 

You've given no details about your design so it's impossible to
diagnose.  Interrupts?  Is the time advancing at the proper rate (i.e.
is it the display or the timer)?  I suggest you break your application
up into its component pieces and check each one in turn.  The answer
should present itself quickly.

--- In p...@yahoogroups.com, Fiona Soon <fionasoon2001@y...> wrote:
> Hello All,

> I am doing a project that involves the LCD as a count down clock.
The clock would display the second and minute digit as control by a
PIC16F84 PIC. The minute count down is working out fine with regards
to the second decrement. But, the second decrement was decreasing in a
very random number such as 00, 59, 57, 54,.......until 0 and so on.
Before this, i have checked the second output in MPLAB and the second
count down is just regular, ie,.00,59,58,57,56,.....for very loop that
the pic runs. Can someone tell me why?
> Thanks!


> Fiona>            
> ---------------------------------


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions




first off, anything you do other than count (like update the LCD) will
cause your count to be wrong. I'd use interrupts to do the counting
and a loop to do the LCD update. Much simpler.

are you getting a watchdog timeout? that might prevent the update but
allow you to increment your counter.

--- In , Fiona Soon <fionasoon2001@y...> wrote:
> Hello Phil,
>
> I am actually designing a count down timer for a Continuos Passive
Motion Machine for knee post surgery patient to exercise their leg
muscle. The patient will put their leg on a base that is drive up and
down by a DC motor.
> That timer is used to count down the exercise time. If we set 20
minutes. It will count down and stop the machine at 0 minute. The
second digit is not a critical issue here. It was just a trial to
understand how a second digit work.
>
> I did not use any interrupts and the motor control is done by
another PIC16f877. PIC16F84 was use for the clock. I have written a
timing subroutine for 1second and decrement a counter after the 1
second delay. After that delay, it will output the counter value to
the LCD.
>
> I am not good in explaining. I hope you understand. > Thank you, phil.
>
> Phil <phil1960us@y...> wrote:
>
> I'm curious if this is a class project?
>
> You've given no details about your design so it's impossible to
> diagnose. Interrupts? Is the time advancing at the proper rate (i.e.
> is it the display or the timer)? I suggest you break your application
> up into its component pieces and check each one in turn. The answer
> should present itself quickly.
>
> --- In , Fiona Soon <fionasoon2001@y...> wrote:
> > Hello All,
> >
> > I am doing a project that involves the LCD as a count down clock.
> The clock would display the second and minute digit as control by a
> PIC16F84 PIC. The minute count down is working out fine with regards
> to the second decrement. But, the second decrement was decreasing in a
> very random number such as 00, 59, 57, 54,.......until 0 and so on.
> Before this, i have checked the second output in MPLAB and the second
> count down is just regular, ie,.00,59,58,57,56,.....for very loop that
> the pic runs. Can someone tell me why?
> > Thanks!
> >
> >
> > Fiona
> >
> >
> >
> > ---------------------------------
> >
> to unsubscribe, go to http://www.yahoogroups.com and follow the
instructions
> ---------------------------------
> Yahoo! Groups Links
>
> To >
> ---------------------------------
>





I guess you are doing this:
[wait 1 second]-[update the LCD]-[wait 1 second]-[update the LCD]-....

As you can see, the [update the LCD] routine takes some time, which
can be calculated multipling the number of PIC instruction used. So,
if you count 2 seconds, you will have 2 and a few milliseconds passed
in reality. Try to compute the time eaten by [update the LCD] section,
and count the milliseconds instead of seconds. If, just as an example,
[update the LCD] section takes about 95 milliseconds, then count just
905 milliseconds. --- In , Fiona Soon <fionasoon2001@y...> wrote:
> Hello All,
>
> I am doing a project that involves the LCD as a count down clock.
The clock would display the second and minute digit as control by a
PIC16F84 PIC. The minute count down is working out fine with regards
to the second decrement. But, the second decrement was decreasing in a
very random number such as 00, 59, 57, 54,.......until 0 and so on.
Before this, i have checked the second output in MPLAB and the second
count down is just regular, ie,.00,59,58,57,56,.....for very loop that
the pic runs. Can someone tell me why?
> Thanks! > Fiona >
> ---------------------------------
>






--- In , "ydexter" <ydexter@y...> wrote:
>
> I guess you are doing this:
> [wait 1 second]-[update the LCD]-[wait 1 second]-[update the LCD]-....
>
> As you can see, the [update the LCD] routine takes some time, which
> can be calculated multipling the number of PIC instruction used. So,
> if you count 2 seconds, you will have 2 and a few milliseconds passed
> in reality. Try to compute the time eaten by [update the LCD] section,
> and count the milliseconds instead of seconds. If, just as an example,
> [update the LCD] section takes about 95 milliseconds, then count just
> 905 milliseconds.
>

This can be made to work but is very tricky to get exactly right. Any
changes to the code require refiguring the exact clock count and you
have to compute all the code paths. Being off by 0.1% is 86 seconds
a day - pretty bad.

A much better solution is to set up a timer to generate interrupts
every, say, 10 mS. Actually, any period will work, within limits. In
the interrupt routine, increment a counter and when it gets to 1
second (100 interrupts in this case), increment the seconds counter as
well as bump minutes and hours when appropriate. There are techniques
for ensuring no lost time if the interrupt handler is late. In the
main loop, you compare the current second value with the one you wrote
into the LCD. When they are different, save the new seconds count and
update the LCD. very simple and very accurate.

Phil




> This can be made to work but is very tricky to get exactly right. Any
> changes to the code require refiguring the exact clock count and you
> have to compute all the code paths. Being off by 0.1% is 86 seconds
> a day - pretty bad.
>
> A much better solution is to set up a timer to generate interrupts
> every, say, 10 mS. Actually, any period will work, within limits. In
> the interrupt routine, increment a counter and when it gets to 1
> second (100 interrupts in this case), increment the seconds counter as
> well as bump minutes and hours when appropriate. There are techniques
> for ensuring no lost time if the interrupt handler is late. In the
> main loop, you compare the current second value with the one you wrote
> into the LCD. When they are different, save the new seconds count and
> update the LCD. very simple and very accurate.

My Jal language has a library function for this: the interval delay. You
just set it up for a certain period, and then call await_next_interval
at the top of your loop.

Wouter van Ooijen

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




--- In , "Wouter van Ooijen" <wouter@v...>
wrote:
> > This can be made to work but is very tricky to get exactly
right. Any
> > changes to the code require refiguring the exact clock count and
you
> > have to compute all the code paths. Being off by 0.1% is 86
seconds
> > a day - pretty bad.
> >
> > A much better solution is to set up a timer to generate
interrupts
> > every, say, 10 mS. Actually, any period will work, within
limits. In
> > the interrupt routine, increment a counter and when it gets to 1
> > second (100 interrupts in this case), increment the seconds
counter as
> > well as bump minutes and hours when appropriate. There are
techniques
> > for ensuring no lost time if the interrupt handler is late. In
the
> > main loop, you compare the current second value with the one you
wrote
> > into the LCD. When they are different, save the new seconds
count and
> > update the LCD. very simple and very accurate.
>
> My Jal language has a library function for this: the interval
delay. You
> just set it up for a certain period, and then call
await_next_interval
> at the top of your loop.
>
> Wouter van Ooijen


And definitely interval is a very clever library indeed. I really
don't know why I like more a quite similar way with the methode
presented above, even as an old Jal user (shame me!) :). Maybe just
because interval reminds me about the high level languages which
don't let you to modify a compiler defined (hidden) instruction
(like some PIC basic compilers).

Vasile