How to HOOK a interrupt in an application?

[yesture2005]

Hello, everyone, have a good day.

I have a FPGA-controlled SRAM to access from ARM microcontroller based on
WCE5.0. Every time the SRAM filled, ARM will got a interrupt from FPGA and
notified that there are new data there. I do not want to bother to develop a
driver to only serve the FPGA and the interrupt, so I tried to hook the
interrupt in application directly and mapping SRAM address to user space. I
have done the following:

1) IN the application, Mapping the SRAM by VirtualAlloc() and VirtualCopy(),
so I got a pointer to that SRAM that I can access directly.

2) Made Some changes in BSP, modified OEMInterruptHandler to return a
SYSINTR nnumber for FPGA interrupt, to connect ISQ with SYSINTR.

3) In the application, create an event, and Hook the SYSINTR number with the
event by InitializeInterrupt(), and create a thread who are waiting for the
event.

The above is doing exactly like a driver should do, the difference is I made
it in the application, but drivers are loaded by device.exe.

But the InitializeInterrupt() alwasy failed to hook the SYSINTR. I do not
know why.
My question is:
1) is it possible to hook a interrupt in an application which runs in user
mode? Or do I have to develop a specific driver to serve the interrupt? Is
there any simple way to do that?

2) I am planing to transit from WCE 5.0 to WCE 6.0, and Virtualcopy and
VirtualAlloc no long can be used in User mode in WCE6.0. So what is the best
way to develop the SRAM mapping and interrupt handling issue to be easily
compatible with CE6?

I appreciate your help very much! Thank you in advance!

Yesture

[Paul G. Tobey [eMVP]]

Yes, you *do* want to develop a driver. For now, your application-based
interrupt handling will work, but that won't be the case forever (for that
matter, neither will mapping random areas of physical memory to your
application). Since you say that you're planning to move to CE6, you
absolutely have to build a driver for both of those operations.

Paul T.

"yesture2005" <yestu...@discussions.microsoft.com> wrote in message
news:B2325313-7FD5-4637...@microsoft.com...

[Bruce Eitman [eMVP]]

And besides that, you typed more in that post than you would have needed to
when writing the driver.

But the real question here is why is InterruptInitialize failing? For that
you need to look at the changes that you made to OEMInterruptEnable().

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:umnQBD%23vHH...@TK2MSFTNGP02.phx.gbl...

[Dean Ramsier]

Or there is a problem with the event you're using. I think if you use the
event before the call to InterruptInitialize(), it will fail. Probably
other things can cause that as well.

--
Dean Ramsier - eMVP
BSQUARE Corporation

"Bruce Eitman [eMVP]" <beitman...@applieddata.net.nospam> wrote in
message news:uedKYj%23vHH...@TK2MSFTNGP06.phx.gbl...

[yesture2005]

Thank you Paul, Bruce, Dean

It sounds that we do can hook a interrupt in the application according to
your words, and actually I found an example in ILTiming.c, which seems to do
the interrupt initialize in the application.

Actually I never call or use the event before calling interruptInitialize(),
but it just failed to hook the interrupt. In the OEMInterruptHandler(), I
just added the code to check source Irq and return a SYSINTR I defined as
FIRMWARE+25 in oalintr.h. And also added some code in
SysintrNumToInterruptMask(). I will do more research why the hooking process
failed.

By the way, I defined a class to do what I have said. Is it a possible
reason for the failure?

Bruce means that it is easy to write a driver to handle those code in kernel
mode. If so, I also need to add regsitry in HKLM\drivers\buildin to enable
its loading in the booting process, is it right of my understanding?

Thank you and have a nice weekend!

[Paul G. Tobey [eMVP]]

The use of a class or not isn't relevant, if you constructed the class
correctly. I didn't understand from your message *where* this class exists.
It's in the application? You've taken care to assure that you aren't trying
to get the OS to somehow call a method of the class, other than a static
method, right? Maybe you should forget about being fancy, for now, and
figure out what the problem actually is using the simplest possible code.
Once you have something that works, you can encapsulate it in classes all
you want.

Paul T.

"yesture2005" <yestu...@discussions.microsoft.com> wrote in message

news:CADD321B-232E-40C9...@microsoft.com...

[Steve Maillet (MVP)]

>By the way, I defined a class to do what I have said. Is it a possible
>reason for the failure?

Not likely a problem, but it can cloud the issue when you are working to
unsderstand how it all works. All of our BSPs sue classes to wrap up and
manage the common boiler plate of setting up interrupt handling (along with
other factors including a threading library that can handle any callable
entity including virtual methods on a class as the IST or general thread
function) So, Classes and C++ are not a problem, but they can get in the way
when you are starting out from scratch doing things for the first time.