Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem

[Andrew Lunn <andrew@lunn.ch>]

> The DSR mechanism has nothing to do with processor specific interrupt
> handling but more with the eCos kernel internal stuff, correct?
> In that case what is the exact role of the DSR in eCos? When to
> implement one or not in a device driver?

ISR can run any time interrupts are enabled. There is very little you
can actually do in ISR context, just read/write bits in the hardware,
generally you just disable the interrupt source. The ISR handler
cannot do anything with the eCos scheduler.

DSR will only run when the eCos scheduler is in a consistent state,
i.e.  the scheduler is not locked. DSR are allowed to do none blocking
calls, eg signal a semaphore to wake up a thread etc.

> I'm asking this because I thought that the DSR needed to be executed
> after returning from the interrupt (reti or what ever), which is not
> the case, in order to allow other interrupts
> at this point. I thought that when combining ISR and DSR in one
> interrupt handling of the processor, this would take too long and
> deteriorate real-time behaviour?

Your ISR and DSR handlers should not do any activities which take a
long time, since while ISR & DSR are running, threads are not
running. If you do need to do a lot of work it is much better to have
a thread doing it, so the scheduler can pre-empty it for a higher
priority thread. The TCP/IP stack follows this model. The Ethernet
device drivers have a thread doing the actual copy of the packet from
the hardware to the stack and the stack is run in a thread.

    Andrew