Time Delay - non accurate
Archiver
Posts: 46,084
--- In basicstamps@yahoogroups.com, "Tim Hart" <tim.hart@h...> wrote:
> Jon gave an excellent example....we can expand on that to get
minutes....you could just nest the loops.
Doesn't the rest of the program effect the accuracy of the timer ?
if you are communicating with another device and need to import or
export data to memory or to an ADC ?
I've run into problems with outputs running too fast so I will use a
simple and non-accurate delay.
setting a variable and just adding 1 to it each time thru the
program. then, when it hits 100 or 1,000 or some number, the number
or times thru the loop times loop speed is the delay.
this is terrible for long delays, but works great for short ones.
I first did this with 2 variables and lighting an LED so it would be
on 50% of the time, ie: 1000 times thru the program and it goes on,
next 1000 times and it goes off. lets you see how the other routines
effect speed.
> Jon gave an excellent example....we can expand on that to get
minutes....you could just nest the loops.
Doesn't the rest of the program effect the accuracy of the timer ?
if you are communicating with another device and need to import or
export data to memory or to an ADC ?
I've run into problems with outputs running too fast so I will use a
simple and non-accurate delay.
setting a variable and just adding 1 to it each time thru the
program. then, when it hits 100 or 1,000 or some number, the number
or times thru the loop times loop speed is the delay.
this is terrible for long delays, but works great for short ones.
I first did this with 2 variables and lighting an LED so it would be
on 50% of the time, ie: 1000 times thru the program and it goes on,
next 1000 times and it goes off. lets you see how the other routines
effect speed.
Comments
parameter value of 65535. The method you suggest works -- I used it and
have done so on a commercial product that is used to time four switch
inputs and take action if a switch exceeds its "closed time" parameter.
The tricky aspect of this kind of programming is that you must ensure
that every path through your program runs the same period. With the
BASIC Stamp this requires hardware analysis to get close (assembly
language programmers can count instruction cycles, we can't). On my
project I used a second Stamp to measure a pulse output from the Stamp
under test, and pads were added to make every path run the same.
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: Dave Mucha [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=DQAU430KMRLTiNMfsER9jtt3tynUKHvbihTMh2iffaZELSqKpmFkWGwHdEgnfKopWKP8COW5Lx457XoF]davemucha@j...[/url
Sent: Friday, August 08, 2003 10:41 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: Time Delay - non accurate
--- In basicstamps@yahoogroups.com, "Tim Hart" <tim.hart@h...> wrote:
> Jon gave an excellent example....we can expand on that to get
minutes....you could just nest the loops.
Doesn't the rest of the program effect the accuracy of the timer ?
if you are communicating with another device and need to import or
export data to memory or to an ADC ?
I've run into problems with outputs running too fast so I will use a
simple and non-accurate delay.
setting a variable and just adding 1 to it each time thru the
program. then, when it hits 100 or 1,000 or some number, the number
or times thru the loop times loop speed is the delay.
this is terrible for long delays, but works great for short ones.
I first did this with 2 variables and lighting an LED so it would be
on 50% of the time, ie: 1000 times thru the program and it goes on,
next 1000 times and it goes off. lets you see how the other routines
effect speed.
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
This message has been scanned by WebShield. Please report SPAM to
abuse@p....
wrote:
> I think the original post on this had to do with the maximum PAUSE
> parameter value of 65535. The method you suggest works -- I used
it and
> have done so on a commercial product that is used to time four
switch
> inputs and take action if a switch exceeds its "closed time"
parameter.
> The tricky aspect of this kind of programming is that you must
ensure
> that every path through your program runs the same period.
<snip>
If a pause slows down other parts of the process, and you can live
with an alkward timer that is not precision or even close to it, this
is a great trick.
I had to convince myself just how fast the micro was. toggle an LED
each time thru the program.
then count 10 times thru - toggle - 10 times-toggle - etc and you
still don't see it blink. and it is nice to have a blinking light
for those projects that seem to hang or to see how much slower a
looong program is.
I have used it in a crude debounce or proven switch on circuit too.
But, you are correct the origional poster was looking for 7 minutes,
heck, I'd hate to try to get 7 seconds accuratly with this.
Dave
> that every path through your program runs the same period. With the
> BASIC Stamp this requires hardware analysis to get close (assembly
> language programmers can count instruction cycles, we can't).
Wow... you just reminded me of my first assembly language project (after the
blinking LED, of course) with my shiny new Parallax "True-Flight" PIC
programmer in 1994... It had to change the frequency of an incoming pulse
train by 10% in real-time on a cycle-by-cycle basis. Each trip through the
loop could only be 30 machine instructions, and it had to check the incoming
signal, increment a 2-byte counter, do the 90% calculation if the input had
toggled, store the result, decrement the 2-byte output counter, and toggle
the output as needed. Every trip through the loop had to be exactly 30
cycles, regardless of what happened. Boy, did I wrestle with the code --
but it really ended up working! That True-Flight programmer was a clever
piece of work; Parallax has been doing cool stuff for a long time. (And I
definitely prefer BASIC when I'm not doing something goofy like this.)
Randy
www.glitchbuster.com
Not only is timing all the loops to match "tricky" it can be VERY
painful and time consuming. Much easier to have an external delay -
like in my Co-Processor...8^)
Using another Stamp as an equivalent oscilloscope for measuring
delays is a great idea for folks without a scope. It might be worth
expanding as a Nuts & Volts article.
Harry
Stamp Robotics to the next level
www.bluebelldesign.com
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...>
wrote:
<snip>
> The tricky aspect of this kind of programming is that you must
ensure
> that every path through your program runs the same period. With
the
> BASIC Stamp this requires hardware analysis to get close (assembly
> language programmers can count instruction cycles, we can't). On
my
> project I used a second Stamp to measure a pulse output from the
Stamp
> under test, and pads were added to make every path run the same.
>
> -- Jon Williams
> -- Applications Engineer, Parallax
> -- Dallas Office
>