Will OEMinterruptHandler be preempted by a higher priority IRQ?

Dear All,
I am using ARM920t and WinCE4.2.
I am doing one installable ISR for my device driver.

My question is that the OEMInterruptHandler can be preempted by a higher
priority external IRQ,such as ethernet,UART,etc.?

WindowCE said it support nested interrupt, but I think ARM cpu have only one
IRQ, so when OEMInterruptHandler is being excuted, nobody can preempt it. Am
I right?
If yes, the installable ISR will reduce the response time of the whole
system, right?

Thank you.

Lee

Steve
Tue May 31 00:26:30 CDT 2005

Wrong, Windows CE does support nested interrupts. However YOUR OAL must
enable interrupts in OEMInterrupthandler and ALL branches of that function
and any Installable ISRs must be written to take into account that they may
be executed with interrupts on. This is not enabled by default because of
the added complexity.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

news
Tue May 31 00:37:17 CDT 2005

Then you mean that by default in OEMInterruptHander(), interrupt has been
disabled by the kernel, so it will not be re-enter?


"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
news:O$z7WFaZFHA.4036@TK2MSFTNGP10.phx.gbl...
> Wrong, Windows CE does support nested interrupts. However YOUR OAL must
> enable interrupts in OEMInterrupthandler and ALL branches of that function
> and any Installable ISRs must be written to take into account that they
may
> be executed with interrupts on. This is not enabled by default because of
> the added complexity.
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
> smaillet at EmbeddedFusion dot com
>
>

Dean
Tue May 31 08:06:46 CDT 2005

Correct

--
Dean Ramsier - eMVP
Vibren Technologies
http://www.vibren.com/Products/schema_bsp.htm


"news.microsoft.com" <li.ning@advantech.com.cn> wrote in message
news:%23ywy9LaZFHA.3272@TK2MSFTNGP14.phx.gbl...
> Then you mean that by default in OEMInterruptHander(), interrupt has been
> disabled by the kernel, so it will not be re-enter?
>
>
> "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
> news:O$z7WFaZFHA.4036@TK2MSFTNGP10.phx.gbl...
> > Wrong, Windows CE does support nested interrupts. However YOUR OAL must
> > enable interrupts in OEMInterrupthandler and ALL branches of that
function
> > and any Installable ISRs must be written to take into account that they
> may
> > be executed with interrupts on. This is not enabled by default because
of
> > the added complexity.
> >
> > --
> > Steve Maillet
> > EmbeddedFusion
> > www.EmbeddedFusion.com
> > smaillet at EmbeddedFusion dot com
> >
> >
>
>

John
Tue May 31 08:15:30 CDT 2005

For completeness, it should be noted that this is ARM specific. On ARM, the
ISR is entered with interrupts disasbled (must explicitly re-enable to allow
nesting as Steve points out), but on MIPS, SHx, and x86, an OEM can
configure the kernel to enter the ISR with some higher priority interrupts
enabled (under OEM control). Of course, caution must still be exercised to
ensure that the ISR code is re-entrant safe.



John Eldridge
Microsoft Corporation
KITL First. Ask questions later!
http://blogs.msdn.com/kitlfirst

Disclaimer: This posting is provided "as is" with no warranties, and
confers no rights.

~~~~~~~~~~~~~~~


"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:eQPXaGeZFHA.1040@TK2MSFTNGP10.phx.gbl...
> Correct
>
> --
> Dean Ramsier - eMVP
> Vibren Technologies
> http://www.vibren.com/Products/schema_bsp.htm
>
>
> "news.microsoft.com" <li.ning@advantech.com.cn> wrote in message
> news:%23ywy9LaZFHA.3272@TK2MSFTNGP14.phx.gbl...
>> Then you mean that by default in OEMInterruptHander(), interrupt has been
>> disabled by the kernel, so it will not be re-enter?
>>
>>
>> "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
>> news:O$z7WFaZFHA.4036@TK2MSFTNGP10.phx.gbl...
>> > Wrong, Windows CE does support nested interrupts. However YOUR OAL must
>> > enable interrupts in OEMInterrupthandler and ALL branches of that
> function
>> > and any Installable ISRs must be written to take into account that they
>> may
>> > be executed with interrupts on. This is not enabled by default because
> of
>> > the added complexity.
>> >
>> > --
>> > Steve Maillet
>> > EmbeddedFusion
>> > www.EmbeddedFusion.com
>> > smaillet at EmbeddedFusion dot com
>> >
>> >
>>
>>
>
>

news
Tue May 31 22:11:41 CDT 2005

Thank you all very much.

Another question about real-time.
After return SYS_INTR to kernel in OEMInterruptHandler, kernel will make a
call SetEvent(SYS_INTR),then what will happen? SetEvent() will wake up
WaitforSingleObject directly? Or it just makes that event singled and after
a system tick(1ms), the scheduler will let WaitforSingleObjet wake up?

Thaks
Lee

"John Eldridge [MSFT]" <johneld@online.microsoft.com> wrote in message
news:uZUqsbeZFHA.1092@tk2msftngp13.phx.gbl...
> For completeness, it should be noted that this is ARM specific. On ARM,
the
> ISR is entered with interrupts disasbled (must explicitly re-enable to
allow
> nesting as Steve points out), but on MIPS, SHx, and x86, an OEM can
> configure the kernel to enter the ISR with some higher priority interrupts
> enabled (under OEM control). Of course, caution must still be exercised to
> ensure that the ISR code is re-entrant safe.
>
>
>
> John Eldridge
> Microsoft Corporation
> KITL First. Ask questions later!
> http://blogs.msdn.com/kitlfirst
>
> Disclaimer: This posting is provided "as is" with no warranties, and
> confers no rights.
>
> ~~~~~~~~~~~~~~~
>
>
> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
> news:eQPXaGeZFHA.1040@TK2MSFTNGP10.phx.gbl...
> > Correct
> >
> > --
> > Dean Ramsier - eMVP
> > Vibren Technologies
> > http://www.vibren.com/Products/schema_bsp.htm
> >
> >
> > "news.microsoft.com" <li.ning@advantech.com.cn> wrote in message
> > news:%23ywy9LaZFHA.3272@TK2MSFTNGP14.phx.gbl...
> >> Then you mean that by default in OEMInterruptHander(), interrupt has
been
> >> disabled by the kernel, so it will not be re-enter?
> >>
> >>
> >> "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in
message
> >> news:O$z7WFaZFHA.4036@TK2MSFTNGP10.phx.gbl...
> >> > Wrong, Windows CE does support nested interrupts. However YOUR OAL
must
> >> > enable interrupts in OEMInterrupthandler and ALL branches of that
> > function
> >> > and any Installable ISRs must be written to take into account that
they
> >> may
> >> > be executed with interrupts on. This is not enabled by default
because
> > of
> >> > the added complexity.
> >> >
> >> > --
> >> > Steve Maillet
> >> > EmbeddedFusion
> >> > www.EmbeddedFusion.com
> >> > smaillet at EmbeddedFusion dot com
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Steve
Tue May 31 22:21:39 CDT 2005

It doesn't actually call SetEvent but the net effect is about the same. The
event is set and the scheduler is invoked to determine what to do next. If
the waiting thread is the highest priority schedulable thread then it runs
that thread otherwise it runs the highest priority thread.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

news
Tue May 31 22:57:08 CDT 2005


So SetEvent() will triger the system scheduler regardless whether there is
a system_tick event or not, right?

"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
news:%23uCuIklZFHA.2756@tk2msftngp13.phx.gbl...
> It doesn't actually call SetEvent but the net effect is about the same.
The
> event is set and the scheduler is invoked to determine what to do next. If
> the waiting thread is the highest priority schedulable thread then it runs
> that thread otherwise it runs the highest priority thread.
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
> smaillet at EmbeddedFusion dot com
>
>

Steve
Tue May 31 23:10:17 CDT 2005

NO, As I said in the case of an interrupt it's not actually calling SetEvent
so Set Event does not necessarily have the same effect. The System schedule
tick by default is 100ms. Which is obviously too long for an interrupt
handler so the kernel will run the scheduler when an interrupt occurs to
determine what should be run next.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

news
Wed Jun 01 03:44:42 CDT 2005

So if one event is not a interrupt event, WaitforSingleObject will be wake
up at least one system tick later after the event was set.
And as to the interrupt event,there is no this kind of limitation.

So except for interrupt events, WaitforSingeObject has a error of at least
one system tick?

Lee
"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
news:uV6VU$lZFHA.2420@TK2MSFTNGP12.phx.gbl...
> NO, As I said in the case of an interrupt it's not actually calling
SetEvent
> so Set Event does not necessarily have the same effect. The System
schedule
> tick by default is 100ms. Which is obviously too long for an interrupt
> handler so the kernel will run the scheduler when an interrupt occurs to
> determine what should be run next.
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
> smaillet at EmbeddedFusion dot com
>
>