Re: [ECOS] Disabling interrupts when locking the scheduler

[Erik Christiansen <erik@dd.nec.com.au>]

On Fri, Jun 03, 2005 at 10:37:35AM +0100, Nick Garnett wrote:
> Erik Christiansen <erik@dd.nec.com.au> writes:
> > 
> > *1) No timeslicing, CYGSEM_HAL_USE_ROM_MONITOR == 1.
> 
> Why do you want to do this?

The reason is that we have configured eCos to leave interrupt handling
to our pre-existing application, and initialised the interrupt vectors
from our pre-existing BSP. There are then no DSRs.

If interrupts are disabled while in the kernel, then it seems "in
principle" safe for ISRs to directly employ the kernel API, and the lack
of DSRs is no longer a problem. (Please accept my apologies for
attempting such acts with eCos.)

> eCos is carefully designed not to disable interrupts unnecessarily.

Understood from the documentation. (And I'd like to have the time to go
with that, but when porting an existing application, there can sometimes
be strong imperatives to avoid a major rebuild.) We can tolerate a
little interrupt latency.

> It will probably fail catastrophically if interrupts are disabled
> during the scheduler lock periods.
>
> The interrupt disable you have found is only part of the SMP code, and
> is matched by a HAL_RESTORE_INTERRUPTS() at the end of the
> HAL_SMP_SCHEDLOCK_INC() macro. So interrupts are disabled for a very
> short period, inside that macro.

Oh Oh! Yes, only disabling interrupts for the whole kapi function, not
just during locking/unlocking, would give their use in an ISR any chance
of success. (But I don't yet understand why the longer disable period is
such a big risk.)

Thank you for your analysis & warnings. We'll give it a shot, and see
what happens. It's bound to teach me something. :-)

Erik

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss