This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Priority between different DSRs?
- From: Bart Veer <bartv at ecoscentric dot com>
- To: abg at dimat dot es
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Mon, 21 Mar 2005 13:22:18 +0000 (GMT)
- Subject: Re: [ECOS] Priority between different DSRs?
- References: <01C52E08.EB5A8000.abg@dimat.es>
>>>>> "Alex" == Alex Bueno Guarner <abg@dimat.es> writes:
Alex> I have a program which consists of two interupts
Alex> sources. One of them needs to be processed VERY fast, and
Alex> the other doesn't. The fact is that I can't process the fast
Alex> one directly in the ISR, because I have to capture the
Alex> current time, and if I did it in the ISR, the kernel time
Alex> value might be incorrect. (If there's some way to do it in
Alex> the ISR, please tell).
Alex> So the fact is that I have to process both in the
Alex> DSRs. Is there any way to give priority to the DSRs? Also, I
Alex> know that the DSRs are processed after ISRs and before
Alex> returning to the threads, but, in which order? If I am
Alex> processing a DSR and and interrupt occurs, the new DSR is
Alex> processed finishing the first one? As I've seen, it seems
Alex> that the DSR of the new interrupt is executing BEFORE the
Alex> first one finishes. Thus, i tseems that a DSR not only can
Alex> be interrupted by a ISR, but also the DSR associated with
Alex> it. Am I wrong?
Alex> I've looked for more information about it, but I
Alex> haven't found anything about in which order the DSRs
Alex> execute.
It should be fairly obvious from the source code, see
src/intr/intr.cxx in the kernel package.
A DSR can only be interrupted by an ISR. It will run to completion
before another DSR gets run. Kernel objects like the scheduler queue
may be in an inconsistent state while a DSR is running, so allowing
one DSR to interrupt another would make the whole concept of DSRs
meaningless.
With the default configuration settings DSRs run in last-in-first-out
order, see Cyg_Interrupt::post_dsr().
There is no way of giving priorities to DSRs.
An ISR may indeed see an inconsistent kernel time value. The tick
count is usually a 64-bit value, so updating it may not be an atomic
operation.
One solution might be to maintain your own counter alongside the
kernel one. This would be updated by your own alarm function, hooked
to the system clock so it would get called for every clock tick. The
alarm function could briefly disable interrupts around the update of
its counter, thus ensuring that the ISR will always see a consistent
value.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss