system interrupt handler programming on a PC under windows

system interrupt handler programming on a PC under windows

[Adrien Plisson]

hello everyone !

i wonder if anyone can explain me (or give me a pointer to an explanation) how 
i can set up an interrupt handler under windows to interact with a PCI board 
plugged into my computer.

in my company we are using a PCI I/O board which is only programmable through 
the use of a library available only for C, VB and Pascal. i would like to 
interract with this board from Ada, but writing a thin binding over the library 
does not lead to anything useful. so i would like to create a really thick 
binding by interacting directly with the board.

this board is very well documented: i have all the interresting values address 
expressed in term of BASE address + offset and all seems ok for me to read or 
write them (or they wouldn't have documented this).

but i need to set up an interrupt handler to get notified of events. i started 
using Ada.Interrupts but discovered that the I/O board interrupt is reserved so 
i can't register my own interrupt handler.

so, how can I override the default handler ? is it safe to do it ? what about 
shared interrupts ? in short, i want to know everything you can tell me about 
system interrupt handling from Ada...

thanks in advance.

-- 
rien

Re: system interrupt handler programming on a PC under windows

[Steve]

IMHO it is very likely you would be better off interfacing to the vendors
library using the C interface.

Ada has very nice capabilites for interfacing with C (see Interfaces.C).

In my experience interfacing with hardware only starts with following the
documentation.  It is followed by identifying what features of the hardware
don't work properly and creating work-arounds.

Several years ago I started to write a serial driver for a PC.  Well defined
interface to hardware, right?  When I started having difficulties with
misbehavior, I took a look at IBM's driver that was included with OS/2.
IBM's driver had a bunch of extra code to identify the maker of the serial
hardware and disable specific features that didn't work for specific
hardware.  Better to use someone elses work on this.

Also, I have run into several cases when I asked vendors about library
support for Ada (thinking they might already have a binding), the common
response is: can't be done.  I usually generate my own binding, which
demonstrates their ignorance.

Steve
(The Duck)

"Adrien Plisson" <aplisson-news@stochastique.net> wrote in message
news:41a47994$0$13459$ba620e4c@news.skynet.be...
> hello everyone !
>
> i wonder if anyone can explain me (or give me a pointer to an explanation)
how
> i can set up an interrupt handler under windows to interact with a PCI
board
> plugged into my computer.
>
> in my company we are using a PCI I/O board which is only programmable
through
> the use of a library available only for C, VB and Pascal. i would like to
> interract with this board from Ada, but writing a thin binding over the
library
> does not lead to anything useful. so i would like to create a really thick
> binding by interacting directly with the board.
>
> this board is very well documented: i have all the interresting values
address
> expressed in term of BASE address + offset and all seems ok for me to read
or
> write them (or they wouldn't have documented this).
>
> but i need to set up an interrupt handler to get notified of events. i
started
> using Ada.Interrupts but discovered that the I/O board interrupt is
reserved so
> i can't register my own interrupt handler.
>
> so, how can I override the default handler ? is it safe to do it ? what
about
> shared interrupts ? in short, i want to know everything you can tell me
about
> system interrupt handling from Ada...
>
> thanks in advance.
>
> -- 
> rien

Re: system interrupt handler programming on a PC under windows

[Adrien Plisson]

Steve wrote:
> IMHO it is very likely you would be better off interfacing to the vendors
> library using the C interface.
> 
> Ada has very nice capabilites for interfacing with C (see Interfaces.C).

well, that's what I already do. but their library is not really well designed 
especially in the field of interrupt handling.

the purpose here is to interface more cleanly with the hardware. but the second 
purpose (which i did not talk about in my first post) is to learn about 
interrupt handling. it's the first time that i have a board so well documented 
that i can talk directly to it without much headaches. it's the first time i 
fear not writing a "use" clause.

so, sticking with what i already have is a non-solution: it is just not moving 
ahead.

> In my experience interfacing with hardware only starts with following the
> documentation.  It is followed by identifying what features of the hardware
> don't work properly and creating work-arounds.

here i know my hardware and already wrote a C++ class which works around the 
limitations of the library. the class works perfectly well and is integrated in 
our current system (written in C++).

> Several years ago I started to write a serial driver for a PC.  Well defined
> interface to hardware, right?  When I started having difficulties with
> misbehavior, I took a look at IBM's driver that was included with OS/2.
> IBM's driver had a bunch of extra code to identify the maker of the serial
> hardware and disable specific features that didn't work for specific
> hardware.  Better to use someone elses work on this.

the hardware is well defined. it is a proprietary industrial I/O board. i mean, 
it's not a standard stuff you find in any computer. it does not use anything 
standard (apart from the PCI form factor of the board and the DB37 connector)(i 
think there not even a standard on I/O boards, and that sounds good to me). so 
i don't have to work-around badly implemented interface. and i think noone will 
ever write an Ada binding to this board.

so i have to do it, plus i will learn a lot in doing this.

> Also, I have run into several cases when I asked vendors about library
> support for Ada (thinking they might already have a binding), the common
> response is: can't be done.  I usually generate my own binding, which
> demonstrates their ignorance.

i had better success with strange demands since the common response I get is: 
"would you pay for it ? it will cost about <insert big number here>."

but vendors are clearly lazy when it comes to using some not-widely-deployed 
hardware or software. and they protect themselves behind inexistent limitations 
or impossibilities. everything is possible, it is just a matter of time and 
effort.

-- 
rien