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: How are DSRs scheduled?


> Are these DSRs run on a first-come first-served basis, i.e. the order in
> which they were posted?

I actually think they are in reverse order. There was a long
discussion about this a while ago.

> Do they run as a sort of super high priority thread (all DSRs having the
> same high priority)?

DSR can be deferred if the scheduler is not in a state which allows
the DSRs to run. eg if the thread which was interrupted had the
schedular locked, the DSR won't be run until the scheduler is
unlocked. 

> There can be interrupts generated form a number of sources, if the rx
> queue is half-full, full, or if the line has become idle.

Are these different interrupt lines to the processor? Or one interrupt
line and then you need to read a control register in the serial device
to determine what caused the interrupt? I think you mean the first.

> All of these
> interrupts are have the same priority.

Doh! That answers my question.

> Unless there is something which I have overlooked, what I am observing
> appears to be that when the half-full DSR is in the middle of doing a
> block transfer then idle interrupt fires and posts its DSR which runs
> straight away and it then tries to do a block transfer before the
> original half-full DSR has been given a chance to finish. This then
> fires an assert in serial.c.

DSRs should not preempt each other. So the first DSR should run to
completion before the second one starts. It could be just that they
are called in the reverse order you expected.

> One final point, if I was to instead do all of this in a single DSR
> routine which somehow deterimines the context, or ISR source from which
> is was called, then would prevent this problem?

Yep. That in fact is the more normal structure. Generally the hardware
only has one interrupt, you then read a register to find out why it
interrupted. Also, generally, in the ISR you just disable the
interrupt source. In the DSR you determine the cause of the interrupt,
by reading a status register and handle it. At the end of the DSR you
then re-enable interrupts for that device. With your multiple
interrupts device this is a bit harder. However, you could register
the same DSR function for all interrupts, and in the DSR function
handle all possible sources of interrupts, being careful to do them in
the right order. ie full, half-full, idle. 

    Andrew

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