|
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
|
Irregular second countdown on LCD
Started by ●January 18, 2005
Reply by ●January 18, 20052005-01-18
|
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 > > --------------------------------- > |
|
|
Reply by ●January 18, 20052005-01-18
|
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:
|
Reply by ●January 18, 20052005-01-18
|
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 > > --------------------------------- > |
Reply by ●January 20, 20052005-01-20
|
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 > > --------------------------------- > |
|
|
Reply by ●January 20, 20052005-01-20
|
--- 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 |
|
|
Reply by ●January 20, 20052005-01-20
|
> 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 |
|
|
Reply by ●January 21, 20052005-01-21
|
--- 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 |
