[ECOS] Priority between different DSRs?

Bart Veer bartv@ecoscentric.com
Mon Mar 21 16:33:00 GMT 2005


>>>>> "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



More information about the Ecos-discuss mailing list