From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,53bba8695cf47299 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news2.google.com!proxad.net!newsfeed.icl.net!skynet.be!newspost001!tjb!not-for-mail Date: Wed, 24 Nov 2004 16:54:02 +0100 From: Adrien Plisson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: fr-fr, fr-be, fr, en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: system interrupt handler programming on a PC under windows References: <41a47994$0$13459$ba620e4c@news.skynet.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41a4add7$0$25064$ba620e4c@news.skynet.be> Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 658cef6a.news.skynet.be X-Trace: 1101311447 news.skynet.be 25064 81.242.46.252:3001 X-Complaints-To: usenet-abuse@skynet.be Xref: g2news1.google.com comp.lang.ada:6423 Date: 2004-11-24T16:54:02+01:00 List-Id: 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 ." 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