This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: IRQs and Scheduler Lock
- From: Jonathan Larmour <jlarmour at redhat dot com>
- To: Sam Sortais <sams at myself dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Fri, 04 Jan 2002 02:19:22 +0000
- Subject: Re: [ECOS] IRQs and Scheduler Lock
- References: <20020103223954.81979.qmail@iname.com>
Sam Sortais wrote:
>
> I did a small test to catch keyboard interrupts
> from PC, in order to test ISR and DSR mechanism, and measure latency.
> It worked fine, then I added code which locked the scheduler for 5 Sec to see what happen. When I press a key during this interval, no ISR was called... only when scheduler_unlock() is called, then ISR is called followed immediately by DSR.
> My understanding was that the ISR/DSR system was done so that IRQs can be processed even if scheduler is locked and DSRs get called when scheduler is unlocked.
Your understanding is correct. You should easily be able to see for
yourself if interrupts have been disabled in the CPU flags register, or
masked in the PIC to find out what's gone wrong. Certainly this normally
works.
> I found another problem related to keyboard when using gets().
> I read in previous messages, support for keyboard works by doing polling, but I do not explain why when gets() is called by one thread, all other threads stop running...
I don't think it should be all threads. But it probably will be all threads
of lower priority - the fact it polls means it is in a busy loop, so lower
priority threads can't run. A proper interrupt driven driver needs to be
written for that.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine