This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]