feuling@astroatc.UUCP (Lindsay Feuling) (01/08/91)
I am currently developing software on a 80386 clone that communicates with several HP devices. I am using an interface card from National Instruments to handle the GPIB (IEEE-488) protocol. I ran into a problem, however, and that problem appeared when I wanted to call the GPIB driver routines inside an interrupt service routine (using interrupt 1c hex). I haven't gone into too much detail yet for the reason why there were problems, but I suspect the GPIB driver is doing some things that should not be done after an interrupt calls such a routine. In talking with a technician from National Instruments (hopefully he's not reading this), I told him what I wanted to do, and he immediately responded by saying that I need to BUY an additional package by them called ESP. My original reaction, kept to myself, was that he just wanted to sell something to me. Upon reading the catalog on this software package, there is no indication that this software has any advantages to solve the interrupt problem over what was supplied with the interface card. My questions are: 1) Has anyone out there dealt with simular circumstances, and, if so, what have you done about it? 2) Has anyone used the ESP software at all? If so, what have you been able to do with it? 3) Has anyone hacked around with the GPIB driver from National Instruments ? If so, could you please send me some info on I/O registers, memory maps, whatever, that have been so nicely undocumented? 4) Comments, cliches, criticisms? Thanks in advance
dubner@hpspkla.spk.hp.com (Joe Dubner) (01/08/91)
I too am developing PC software that uses the National Instruments GPIB card. Actually, it supports either the H-P card (with a TMS9914 IC, which is well documented in the TI data book) as well as the National Instruments card. However, my application doesn't require calling any drivers inside ISRs so I can't offer you anything except my sympathy. But if you learn anything about the N.I. card, I'd like to know it too. One technique you may try, however, is to set a flag inside the ISR and exit quickly. Then call the driver from outside the ISR if the flag is set. That's easy with a multi-tasking operating system, but not impossible with DOS. Perhaps you've already tried this; if so, pardon me for stating the obvious. Regards, Joe dubner@hpspkla.HP.COM
thomas@everexn.com (Thomas Poff) (01/10/91)
[flame on] Oooooooooooooooh I'm glad you brought this up. I had exactly the same problem with National Instruments very recently. I called them up, and they gave me the old sales pitch for their $300 software package, otherwise known as God's (pricey) gift to mankind. I wonder what ESP really stands for? It's pure greed. I urge everyone NOT to support these people until they alter their software support for their boards. These people are end-user hostile. [flame off] The problem with is with their software configuration. They have written a Microsoft C interface that talks to an MS-DOS driver which is loaded when the machine boots up. At first this seems like a feature, as you have access to these cushy C routines that talk to the driver for you. This causes two problems for programmers. Firstly, the total amount of code that is required for use with this board is more than it should be. By the time you add up the [memory] cost of the driver, the C code, and the C runtime library, the total is in excess of 80kb. Since it gnaws on so much System Memory, it is a problem for my project. Secondly, since the C runtime library must be included, this means that the interface cannot realistically be put in a TSR. DOS reentrancy problems abound if you try. So, what did I do? Well I gnawed on the ear of a National representative, and then my boss evidently gnawed on the ear of a National representative, AND THEN, lo and behold it became apparent that there was a $80 assembly language interface package available. We thought our problems were solved. Alas, it was not to be. National Instruments delivered the assembler interface package. The software was delivered in a similar configuration to that of the C GPIB interface. It included assembler source code that talks to an assembled module that talks to the driver that talks to your output device. This seemed mediocre to me, so I started modifying my driver (a TSR program) to interface with it. I compiled it and ran my code. It crashed. After checking everything, I elected to take a look at their driver interface code, (which they DID NOT include sources for), via CODEVIEW. I immediately found an INT 21h call, meaning that my next step is to make the INT 21h not allow itself to be called more than once at a time. This change will probably allow the program to work alright. Meanwhile, 100 other things have been going on here, and I have no more immediate time to spend on this project. This should have been a nearly trivial project, really. The bottom line is that if you are using the Nationalist Software interface that is included with the GPIB board, you will not be able to make an TSR version of the program unless you have totally unlimited patience and time. If you order the $80 Assembly language interface, the project will simplify itself by an order of magnitude but you will still need to have a lot of time to figure what the heck's going on and how to make everything work correctly and consistently. Apparently, if you wanna buy the $300 software package (which really should be free), a TSR version of your program should be a pretty easy thing to write. Make sure you read the fine print in the NATIONAL propaganda sheet before you order it though. If anyone else has any other solutions, I'd sure like to hear them.. [ The opinions contained in this posting do not reflect the opinions of EVEREX, but just might be shared by individuals within earshot of my desk. ] thomas@everexn.com -- Bruce Springsteen is to Rock and Roll what Guy Lombardo was to Jazz.