LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices



Reply
 
Search this Thread
Old 06-05-2009, 12:42 PM   #1
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Rep: Reputation: 0
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:
Code:
Linux-GPIB 3.2.11 Driver
gpib: registered ni_isa interface
gpib: registered ni_isa_accel interface
gpib: registered ni_nat4882_isa interface
gpib: registered ni_nat4882_isa_accel interface
gpib: registered ni_nec_isa interface
gpib: registered ni_nec_isa_accel interface
gpib: registered ni_pci interface
gpib: registered ni_pci_accel interface
Available NI PCI device IDs:
When I try to configure the board:
Code:
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.
Code:
gpib:/home/gpib # cat /proc/interrupts
           CPU0
  0:    1575834          XT-PIC  timer
  1:         16          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:      22670          XT-PIC  eth0
  7:          1          XT-PIC  parport0
  8:          2          XT-PIC  rtc
 10:          7          XT-PIC  aic7xxx, uhci_hcd:usb1, uhci_hcd:usb2
 11:        407          XT-PIC  iop0, Ensoniq AudioPCI
 12:        140          XT-PIC  i8042
 14:      40424          XT-PIC  ide0
 15:      75048          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:          0
MIS:          0
I'm almost new to non pnp isa cards, I'm used to the plug-and-forget hardware, so I'm learning here. Any help is welcome.

Last edited by bluefan; 06-05-2009 at 12:53 PM.
 
Old 06-06-2009, 11:50 AM   #2
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
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.
 
Old 06-07-2009, 01:09 PM   #3
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
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?
 
Old 06-07-2009, 02:12 PM   #4
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
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.
 
Old 06-08-2009, 08:45 AM   #5
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
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.

Last edited by bluefan; 06-08-2009 at 01:22 PM.
 
Old 08-06-2009, 04:38 AM   #6
zampala
LQ Newbie
 
Registered: Aug 2009
Posts: 1

Rep: Reputation: 0
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?


cheers,

mirko
 
Old 08-07-2009, 04:39 PM   #7
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
Hey Mirko,

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...

regards,
Johan
 
Old 08-10-2009, 05:41 PM   #8
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
It could be the termination character:
http://digital.ni.com/public.nsf/all...2566570074A501
But I don't think so.

It may just be something with the interrupts:
http://osdir.com/ml/linux.hardware.g.../msg00026.html
Because:
Code:
gpib@gpib:~> cat /proc/interrupts
           CPU0
  0:     599586          XT-PIC  timer
  1:        200          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  3:          0          XT-PIC  atgpib
  5:      20836          XT-PIC  eth0
  7:          1          XT-PIC  parport0
  8:          2          XT-PIC  rtc
 10:          7          XT-PIC  aic7xxx, uhci_hcd:usb1, uhci_hcd:usb2
 11:        396          XT-PIC  iop0, Ensoniq AudioPCI
 12:       8636          XT-PIC  i8042
 14:      99085          XT-PIC  ide0
 15:      26772          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:          0
MIS:          0
That 0 at IRQ 3 is just what seems wrong. Too bad the answer isn't given in the link...

I still have my NI AT GPIB in by the way, can you check your /proc/interrupts? It's probably the same problem.
 
Old 08-16-2009, 08:55 AM   #9
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
I've changed the card to IRQ 9. Giving all options in the gpib_config doesn't change anything:
Code:
gpib_config --board-type "ni_nat4882_isa" --dma 5 --file /etc/gpib.conf --iobase 0x2c0 --irq 9 --minor 0
It still gives:
Code:
gpib command timed out
gpib: error writing gpib command bytes
in dmesg when trying to read or write anything
 
Old 08-16-2009, 12:51 PM   #10
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
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 ?

--- rod.
 
Old 08-18-2009, 12:48 PM   #11
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
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
 
Old 08-18-2009, 02:32 PM   #12
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
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.

--- rod.
 
Old 08-19-2009, 07:47 AM   #13
bluefan
LQ Newbie
 
Registered: Jun 2009
Posts: 10

Original Poster
Rep: Reputation: 0
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.

And this command does use an irq:
Code:
gpib@gpib:~> cat /proc/interrupts
           CPU0
  0:     461406          XT-PIC  timer
  1:         16          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:      12969          XT-PIC  eth0
  7:          2          XT-PIC  parport0
  8:          2          XT-PIC  rtc
  9:         10          XT-PIC  atgpib
 10:          7          XT-PIC  aic7xxx, uhci_hcd:usb1, uhci_hcd:usb2
 11:        379          XT-PIC  iop0, Ensoniq AudioPCI
 12:        152          XT-PIC  i8042
 14:      19001          XT-PIC  ide0
 15:      21684          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:          0
MIS:          0

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.
 
Old 08-19-2009, 11:06 AM   #14
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
Very good progress. A few points:

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.

Good luck.

--- rod.
 
  


Reply

Tags
bus, error


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NI PCMCIA-GPIB on CentOS 4.4 (RHEL 4.4) IBM ThinkPad T22 primorec Linux - Hardware 1 02-18-2007 04:01 PM
configuring linux-gpib for pcmcia-gpib card Calibus Linux - Hardware 0 03-21-2006 08:07 AM
need 64bit GPIB drivers. know where? LaserNut Linux - Software 1 10-31-2005 03:59 PM
Drivers for National Instruments GPIB Card not Working MadScience314 Linux - Hardware 4 10-31-2005 02:45 PM
GPIB interface on REDHAT7.3 rpinatel Linux - Hardware 2 09-02-2003 10:28 AM


All times are GMT -5. The time now is 01:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration