[SOLVED] NI AT-GPIB ISA card with linux-GPIB 3.2.11 driver: failed to allocate ioports
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
NI AT-GPIB ISA card with linux-GPIB 3.2.11 driver: failed to allocate ioports
I'm trying to get an ISA gpib card working, but I have no luck so far. I have a NI AT-GPIB 488.2 card, Rev e.2.
I'm using linux-GPIB 3.2.11. I've configured the gpib.conf like this:
Code:
interface {
minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
board_type = "ni_isa" /* type of interface board being used */
name = "violet" /* optional name, allows you to get a board descriptor using ibfind() */
pad = 0 /* primary address of interface */
sad = 0 /* secondary address of interface */
timeout = T3s /* timeout for commands */
eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is carriage
return */
set-reos = yes /* Terminate read if EOS */
set-bin = no /* Compare EOS 8-bit */
set-xeos = no /* Assert EOI whenever EOS byte is sent */
set-eot = yes /* Assert EOI with last byte on writes */
/* settings for boards that lack plug-n-play capability */
base = 0x2c0 /* Base io ADDRESS */
irq = 3 /* Interrupt request level */
dma = 5 /* DMA channel (zero disables) */
/* pci_bus and pci_slot can be used to distinguish two pci boards supported by the same driver */
/* pci_bus = 0 */
/* pci_slot = 7 */
master = yes /* interface board is system controller */
}
I've left the DMA on the default 5, the switched for the base IO address are on default to. I changed the IRQ to 3 on the card, the default 11 was already taken.
When I load the kernel module:
modprobe tnt4882
the following output comes in dmesg (nothing in the console:
gpib:/home/gpib # gpib_config --minor 0
failed to bring board online
failed to configure board
main: Operation not permitted
The dmesg output:
Code:
gpib: (debug) request module returned 256
tnt4882: failed to allocate ioports
gpib: interface attach failed
this is where I'm stuck. I'm running openSUSE 10.2, kernel 2.6.18.2-34-default. I suggestion I found somewhere on the net was that the switches on the card where wrong, this cuold be because of a wrong adress. I double checked the switched on the card of the base io address, and there on the default for 0x2c0.
I also have an HP 27209 (also isa), this one came just as far but with:
invalid base io address 0xffffffff
I haven't tried any further, in the config I set: base = 0xdc000 but that didn't came through.
small addition:
In the bios I set IRQ 3 and DMA 5 to 'yes' in the section for the legacy ISA cards. There is also a UMB section, but this doesn't cover the base io adress (it does for the HP card). pnpdump doesn't find anything, the card isn't plug and play.
Sounds like it could be as simple as requiring root privilege to load the modules and to configure the driver(s)("Operation not permitted", "failed to allocate ioports"). Are you sure that your board works and is compatible with the driver you are loading? There are at least a couple different versions of NI ISA cards, and I think some are supported by a different module.
--- rod.
I'm doing everything as root, so that shouldn't be the problem. I'm not sure of the condition of the board, but I think it is fine. There are different versions, I just checked and I did have the wrong card in the config, it should be "ni_nat4882_isa", but I changed this and the same error appears.
So, I tried it the other way:
Code:
gpib_config --iobase 0x2c0 --minor 0
only gives:
Code:
gpib: (debug) request module returned 256
in dmesg
When I now try ibtest:
Code:
gpib:/home/gpib # ibtest
Do you wish to open a (d)evice or an interface (b)oard?
(you probably want to open a device): b
enter name of interface board (or device) you wish to open: violet
trying to open board named 'violet'
You can:
w(a)it for an event
write (c)ommand bytes to bus (system controller only)
send (d)evice clear (device only)
change remote (e)nable line (system controller only)
(g)o to standby (release ATN line, system controller only)
send (i)nterface clear (system controller only)
ta(k)e control (assert ATN line, system controller only)
get bus (l)ine status (board only)
go to local (m)ode
change end (o)f transmission configuration
(q)uit
(r)ead string
perform (s)erial poll (device only)
change (t)imeout on io operations
request ser(v)ice (board only)
(w)rite data string
that is futher than I got before, so I may be on to something. Anyone ideas what is causing this? Now I can do this, does this mean the card work?
Yes, it probably does mean it is working. You should try opening a device. It will ask you for a GPIB address, and then you should be able to write commands and read replies from the instrument. By opening a board, you should be able to read the state of the bus, control the bus, etc. Not so interesting, IMHO. If you have udev enabled, you should see /dev/gpibXX appear after the kernel module loads (or maybe after it configures, I forget).
As for why it works by configuring it the way you did, versus just using the config file, I can only guess. Is your config file located in the standard /etc/gpib.conf?
--- rod.
I'm trying to get anything out of a Keithley 192 with the 1923 GPIB option, but I only get bus errors. I haven't got the manual of the 1923 options, so even the address of the DMM is a guess. But I tried practically all addresses with the same result:
Code:
gpib:/home/gpib # ibtest
Do you wish to open a (d)evice or an interface (b)oard?
(you probably want to open a device): d
enter primary gpib address for device you wish to open [0-30]: 7
trying to open pad = 7 on /dev/gpib0 ...
You can:
w(a)it for an event
write (c)ommand bytes to bus (system controller only)
send (d)evice clear (device only)
change remote (e)nable line (system controller only)
(g)o to standby (release ATN line, system controller only)
send (i)nterface clear (system controller only)
ta(k)e control (assert ATN line, system controller only)
get bus (l)ine status (board only)
go to local (m)ode
change end (o)f transmission configuration
(q)uit
(r)ead string
perform (s)erial poll (device only)
change (t)imeout on io operations
request ser(v)ice (board only)
(w)rite data string
: w
enter a string to send to your device: *IDN?
sending string: *IDN?
gpib status is:
ibsta = 0xc100 < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error
ibcnt = 0
Maybe I should try my HP 5334B instead, at least I have some documentation of it. And I'm going to check the cable.
edit: I just checked the cable, it's fine. The switched on the back of the DMM are probably set to address 7.
Hey bluefan, I am having your very same problems with an ISA hp82335.
My /etc/gpib.conf is presumably set correctly as well as the jumper settings on the card. However, running
# gpib_config gpib_config --minor 0
returns the same error messages that also reported.
By giving
# gpib_config --iobase 0xDC000 --minor 0
the card is apparently configured successfully as no message is displayed at the prompt (the base address I am feeding by the command line is the same in the gpib.conf)
By giving
# ibtest
I try to write a string and read out the response
enter a string to send to your device: *IDN?
sending string: *IDN?
gpib status is:
ibsta = 0xc100 < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error
ibcnt = 0
The same error message that you are getting.
A quick look at dmesg shows
gpib: (debug) request module returned 256
My question is, did you manage to get a bit further?
Besides all this, I am struggling with the concept of IRQ and DMA. How can I know if an IRQ is taken? By just screening the output of
# cat /proc/interrupts
and look for a number x: that is not listed? And how do I pick a good DMA number?
I didn't got any futher, I did try my HP 5334B counter, but as expected that wasn't the problem. I'll put in the HP card tomorrow, see if I have more luck than the NI card.
I have no experience with IRQ's and DMA's, I just tried to pick anything that wasn't in use.
I haven't got much time this weekend, but I'll try to get a little futher. And I'll see if I can get something out of the linux-gpib maillist.
I should be so simple...
Here's one possible interpretation of the error message: "There was no device that was addressed to listen to the command, and I got tired of waiting for one..."
Based on this interpretation, one could imagine writing a code snippet or iteratively using ibtest to write a message to each of 32 possible GPIB primary addresses, and see if you either get an actual response, or you get a different error message for one address.
Do you have write permission on /dev/gpib0 (--minor 0)?
What happens if you issue bus commands that do not require a specific listener, such as 'send (i)nterface clear'? What about writing arbitrary bus commands using the ibtest 'c' command? What about reading back bus status lines, especially with and without your instrument(s) attached?
Do you know that your instrument actually responds to the IDN? command? This is pretty standard, but by no means universal. I don't think this is your problem (yet), because sending a 'nonsense' command should not result in a timeout in most cases.
Do you have good evidence that your GPIB interface hardware actually works, such as functionality on some other platform ?
I execute everything as root, and I have the right permissions. I also tried with a HP 5334B, and with both the Keithley and the HP I get the same error message, no matter what gpib id I pick. I checked the cable. What I can do is check two other cards. I have no way to tell if any of the devices work, having three dead cards is a possibility. But I don't think that's the case.
I can see the bus status and things:
interface clear:
Code:
: i
Inferface clear sent
gpib status is:
ibsta = 0x130 < CMPL CIC ATN >
iberr= 0
ibcnt = 0
Line status:
Code:
: l
DAV off
NDAC on
NRFD off
IFC off
REN on
SRQ off
ATN on
EOI off
gpib status is:
ibsta = 0x130 < CMPL CIC ATN >
iberr= 0
ibcnt = 0
So I think the board is working. I just can't get anything out of the devices
Yes, I think the card is working, or at least partly working. It may not be working as a listening device. I think (speculating) that listening is where interrupts &/or DMA is used, probably generating an interrupt or DMA request in response to bytes received or complete messages received.
Are your HP &/or Keithly instruments configured to listen to the GPIB? Some instruments, especially HP instruments, have a switch to select front-panel vs. remote control. If the setting is for local control only, the device ignores the bus. There is usually some way of discovering the GPIB address of the device, as well. The most typical ways are through a front panel menu + display, or with rear-panel dip switches. The 5 least significant bits of the dip switches generally gives the GPIB address. Many devices have a front panel indication of data transfers via the GPIB.
If you can determine the GPIB address, try using ibtest to issue bus commands to the specified device (MTA,MLA,etc). See if these result in bus timeouts. These commands probably do not require IRQ or DMA, so if they work, but writing & reading data does not, then you can probably start looking for a better/different combination of interrupts/DMA.
If you have multiple cards, you may be able to use two cards in two different computers to help you solve you problems. If I recall correctly, the Linux GPIB driver package (you are using that, and not the NI package, right?) comes with a program to perform such a test.
Okay, I just did a quickie test on a NI PCI GPIB card that is running. It issues a query message every 2 seconds, and receives a reply string. I see about 45 interrupts per 2-second period, which corresponds pretty closely to the number of characters in the command string plus the number of characters in the corresponding reply. From that, I conclude that interrupts are generated on a per-character basis for both sending and receiving. At least on my hardware. Just thought this might be helpful.
My Keithley should work, but I don't have the manual and it's a quite old device. It dip switches imply addres 7 (the default for the device), but I'm not 100% sure, so I always try more than 1 addres with ibtest. The HP is very clear in this. I indeed use the linux gpib, haven't touched the NI stuff yet. That program would be interesting, but I have a little/big succes now:
I disabled DMA (set it to 0) just to have something less to worry about.
I also connected my HP counter, just because I have it's manual to work with. I set it to adres 3 and it displays "addr 3" when powering up.
So, I use ibtest to send something to the device with the addres 3:
REN should be remote enable:
Code:
: w
enter a string to send to your device: REN
sending string: REN
gpib status is:
ibsta = 0x2100 < END CMPL >
iberr= 0
ibcnt = 4
That's no gpib error this time, and my counter responded by displaying (on it's own display) "error 4.0" and the REM and LSN leds are now on. Not perfect, but there's communication going.
Ok, stupid me, REN is not a command to send as string. I'm new to gpib, so this can happen. If I send "FN2", it indeed starts measuring channel 2, just like the manual says it should. I can send ID (identification) without error, but how do I get to see what it responds?
Ok, nevermind, I just got again a little futher. The HP responds with 19 bytes, so I really shouldn't choose the default of 1024 bytes the read commadn of ibtest has. Picking 19 would be better:
Code:
: r
enter maximum number of bytes to read [1024]: 19
trying to read 19 bytes from device...
received string: 'F +9.9999999E+06'
Number of bytes read: 19
gpib status is:
ibsta = 0x100 < CMPL >
iberr= 0
Which is it's own 10mhz clock it measures.
Yay, it works!!!
What it did? I don't know, maybe the DMA, using the HP counter again, I'll see if I can find it.
As you recognized, the REN command is not sent as a string. REN is a uni-line command, which means that it operates by controlling the logic level on a dedicated signal conductor on the bus. The command is issued with ibtest using the 'e' command, and is one of the 'uni-line' class of bus commands.
There is another category of commands which can be issued to the bus, and these are accessed using the 'c' command of ibtest. Each of these will be a single byte, and the state of multiple bus lines will be affected. Some commands contain a device address in the lower 5 bits of the command. A table of the commands is in the Linux-GPIB driver package.
In communicating with a test & measurement instrument, the usual procedure is to first issue a command string to the instrument, followed by a read from the instrument. This would be the procedure to retrieve the device ID. When reading back from the instrument, you can usually allow for an arbitrarily large reply. The instrument + device driver + application software can determine that the reply message has terminated, and close the read operation appropriately. There are different methods used by different instruments, device drivers, and applications to determine when a message has completed. Tuning these methods is often necessary, and may be accomplished in different ways. The gpib_config file is one part that may be used by the Linux GPIB device drivers. This is often the most confusing aspect of using GPIB, especially when there are combinations of instruments that use different methods of signaling end-of-message.
Sometimes, as I think is the case with your HP counter, the instrument will send unsolicited data, simply by reading from it.
It looks like you are on the way to succeeding in communicating with other instruments, now that you have the controller working. One thing that may be playing a role for you is the possibility of a secondary address. To accommodate more than 32 GPIB addresses on a bus, there is a secondary address scheme. I've never had to use it, but I think if your instruments are configured to a non-zero secondary address, then you will need to either reconfigure them, or use the secondary addressing to talk to them. Sorry that I don't have the details on how to do this, but I though it is worth mentioning if all of your efforts fail.
I have had some success finding online documentation for older instruments; at least enough to get my GPIB communications working. This may be an option for you if you are unable to get your older gear to talk. There are also a few places that sell old manuals, although I've never used one of those.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
