Re: interrupt- stream driver- wince 6

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi gol,

When a driver calls InterruptInitialize, the kernel will then call
OEMInterruptEnable which will call OALIntrEnableIrqs.

An interrupt service routine (ISR) is code that handles interrupt requests
(IRQs) on your target device. The ISR is the core of the OAL and is
responsible for locating an interrupt source, masking it, and returning a
unique identifier to the Windows Embedded CE kernel to indicate which driver
needs to be used to handle the event. So what you need to do is IRQ->SYSINTR
mappings, enabling and disabling interrupts, and so on. (We generally create
ISR in OAL)

When the ISR returns to the kernel, the kernel examines the returned
interrupt identifier and sets the associated event. The interrupt service
handler of the kernel schedules execution of the IST that the driver or OAL
created. (We generally create IST in the driver)
If you've received interrupt correctly, your OAL might be finished before.
Then you can just focus on IST in the driver.


--
I hope it is useful ^_^

Best Regards,

Blake Chang



"gol" <gol@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E8409706-5AEA-40B1-AC58-69592CA26E97@xxxxxxxxxxxxxxxx
Thank you very much, Dean

Then let me ask you, do I have to write an ISR?
or this is already being done for me by the OAL.

I mean that if I call InterruptInitialize, given that I've provided
InterruptInitialize with all the information it needs, including the
correct
event and correct SYSINTR, would that be enough?

As far as I understand, if I called InterruptInitialize correctly, then
whenever there is an interrupt, the OAL takes care of the ISR, and I take
care of the IST. Is that true?
Please correct me if I'm wrong
Thank you very much

"Dean Ramsier" wrote:

Not true. The ISR is not called from InterruptInitialize,
InterruptInitialize just sets up the mapping between the SYSINTR number
and
the event that is signaled by the kernel. InterruptInitialize is called
just one time.

The ISR runs every time the interrupt occurs, and it must return the
correct
SYSTINR number to the kernel. The kernel then signals the IST, which
does
the remainder of the processing.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"gol" <gol@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A97CDDDF-9C99-4F52-8D30-51B1A668C112@xxxxxxxxxxxxxxxx
Thank you very much Blake,
you helped me a lot.

There is just one thing that I'm not sure about. When you talk about
ISR,
don't you actually mean IST? because, as far as I understand, ISR
should
be
small and fast and called from InterruptInitialize.

I thought that the call to InterruptInitialize takes care of calling
the
ISR, and that all of the register checkings and other such things are
made
in
the IST.
please correct me if I'm wrong.
Thank you very much

"Blake" wrote:

Hi gol,

That's right. That's a shareed interrupt.
Because you should mask the interrupt after receiving a interrupt, you
can
receive "only" one interrupt once.
You can handle what you want in an ISR, so you can also check their
register
statuses to identify which one triggered the interrup.
It's required to enable the masked interrupt after you finished to
handle
interrupt event in ISR. Then the device can keep on waitting for the
interrupt trigger.
That's all of the processes when you want to handle the interrupt.
Maybe
you
can try to implement what I said to solve your problem.

--
I hope it is useful ^_^

Best Regards,

Blake Chang


"gol" <gol@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E12801A8-D2FD-43ED-B8E0-3BD4246D0F96@xxxxxxxxxxxxxxxx
Hi Blake,
By saying four events I mean that there are four register flags that
each
one of them generates an interrupt.
But I think that you've just helped me to understand something very
important.
You're basically saying that they all generate "the same" interrupt.
That
this is a shared interrupt - one line for multiple events. Am I
right?

And according to this I just need to wait for that interrupt, and
then
check
the registers. Is that what you're saying?
Thank you very much

"Blake" wrote:

Hi gol,

What's the meaning of four events???
Do you mean that there are four interrupt pins will trigger the
interrupt???
Some platforms, such as PXA series, can only share one IRQ for all
of
I/O
devices.
So there are a lot of source can trigger interrupt in a board, and
it
makes
use of variations in GPIOs or registers to identify which device
really
trigger.
You can do this way to identify in ISR or IST.
I don't know if this is what you mean.

--
I hope it is useful ^_^

Best Regards,

Blake Chang


"gol" <gol@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FD2AAC33-AE95-4A70-85C2-579BCE7B63D3@xxxxxxxxxxxxxxxx
Thanks Blake,
Yes, it's a hardware interrupt. I think I don't fully understand
what
you
meant. When I call WaitForSingleObject with a specific event,
then
only
that
specific event will get me out of the waiting state. (I think I
should
also
register that event with the isr in InterruptInitialize).

But I have four such events. And I want one general ( if
something
like
that
exists ), and yes, after receiving interrupt on that general
event I
may
use
your suggestion of checking registers.

so, my questions are: 1.Is this really the way to do it? 2.Is
there
such a
general event that I can use? 3.Am I missing something out here?

Thank you very much

"Blake" wrote:

Hi gol,

What kind of the interrupt source??? Is it hardware, such as
GPIO,
or
something???
If the hardware triggers the interrupt, you might check some
variations
of
registers to identify which event signaled.

--
I hope it is useful ^_^

Best Regards,

Blake Chang


"gol" <gol@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:179DB4F7-FE01-4E32-804F-13B7A26AD850@xxxxxxxxxxxxxxxx
Hi,
I have a question about handling interrupt in a stream driver.
I
have
about
4 events that each one of them generates an interrupt. All of
the
events
are
actually integral parts of the XXX_Read function.
I want to, somehow, make 4 calls to WaitForSingleObject (one
call
for
each
of the events), inside the Read function.

Is it possible to have only one call to WaitForSingleObject
with
an
event
that is somehow general to all of the events, and then, when
the
event
is
signaled , check what specific event really triggered the
interrupt?

Please, if someone can explain how to deal with that
situation.
Thanks















.

Relevant Pages

  • Re: [PATCH 18-rc3] Fix typos in /Documentation : Q-R
    ... The driver will receive them again on the ... The kernel is entered with r3 pointing to an area of memory that is ... Bits are then right shifted into the GP_SAMPLE register at the specified ... you get an interrupt when a full DWORD is recieved. ...
    (Linux-Kernel)
  • Re: Assembling Visual Studio generated listing files
    ... card issues an interrupt each time it has a new position for any one ... An ISR is constrained to act in < 10us, and for most modern machines, 12.5us is a very ... Without MASM and in pure C or C++ and without any Windows API/MFC, ... This is a device driver. ...
    (microsoft.public.vc.mfc)
  • Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
    ... >> in second kernel due to devices not being shutdown during crash and these ... Devices A and B are sharing the same irq line. ... Driver for device A is ... Device B raises an interrupt. ...
    (Linux-Kernel)
  • Re: minimizing interrupt latency to user application in Wince 6.0
    ... As soon as the IST is signaled by the ISR, ... my device simply delivers external event rather then signaling ... So can I somehow bypass driver's IST and wait directly on interrupt hEvent ... Looks like as if kernel is handling this ...
    (microsoft.public.windowsce.embedded)
  • [PATCH 18-rc3] Fix typos in /Documentation : Q-R
    ... The driver will receive them again on the ... The kernel is entered with r3 pointing to an area of memory that is ... Bits are then right shifted into the GP_SAMPLE register at the specified ... you get an interrupt when a full DWORD is recieved. ...
    (Linux-Kernel)