[comp.sys.misc] GPIB

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

	

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.