This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Re: In trouble of timer operations
- From: "Paul D. DeRocco" <pderocco at ix dot netcom dot com>
- To: "ariga masahiro" <ariga at link-lab dot co dot jp>, "eCos Discuss" <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 30 May 2008 00:48:49 -0700
- Subject: RE: [ECOS] Re: In trouble of timer operations
> From: ariga masahiro
>
> OK,I re_state what I want.I like to hold delay as close as multiple of
> 10ms.
It might be helpful if we had an idea of what you actually need this delay
for. Let's say you need the software to turn on some hardware device at one
point in time, then turn it off some known amount of time later. If 10ms
granularity is sufficient, and it's acceptable to have both the turn-on and
turn-off occur on ticks of the existing system clock, then you could do a
one-tick delay to synchronize your thread to the clock, turn the device on,
delay some additional ticks, and then turn it off.
cyg_thread_delay(1);
control_something(TRUE);
cyg_thread_delay(n);
control_something(FALSE);
You'd get a pretty accurate n-tick delay between the two calls to
control_something(). But that assumes that no other thread of the same or
higher priority is running.
But if that's all you need, it's easier just to use an alarm object attached
to the system clock, and do whatever you need to do in the alarm handler. It
will run in DSR context, so can't do certain things like file I/O, but it
won't be pre-empted by anything else other than other ISRs and DSRs. A
thread could still control things either by setting static variables that
the alarm handler reads, or by explicitly enabling and disabling the alarm
as needed.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss