VME view into GPIB card

[niRDW]

Hi.

I have a few of the VME-based ni-488 dual-GPIB cards.  They have their VME base addresses set to 0x2000, according to the onboard switches.  I am starting with the DDK and modifying for vxWorks with the diab compiler.  After a few minor changes to compile, run, and trace through the DDK SW, it seems that I am stuck at a particular place.  In going through ib_probe then ib_vme_probe then the ni_presence_detect, there is a "test1" where a 0x93 is written to adr and a 0x13 is expected at adr1.  This test fails.  My sysBusToLocalAdrs call maps my reags to 0x90002000, so adr would be at 0x9000200C and adr1 (aka eosr) would be at 0x9000200E.  I can see that the 0x400 region mapped at 0x90002000 is stuck at 0xFF's.  All other built-in debug items look sound up to this point.  The card is seated well -- sysFail LED comes on at powerup for several seconds, then goes dark.  Two differnet cards yield the same results.  The only edit of the code was to remove the ddi_peekc / GPIBOut/InTest calls as I do not have the source for a ddi_peek.

Additionally, it is interesting that in the reg init code that copies ibt addresses into ibo, the .f8.a and .f8.b elements do not appear in the expected order -- b's address is earlier than a's address.  Any ideas about that?

Thanks.

[niRDW]

I did not add the TNT BASE to my numbers in the last post (0x90002100), but the facts are otherwise as stated.

Here is a small output showing the f8.a and f8.b

ib_vme_read_conffile:PortNumber: 0, Port A
ib_vme_read_conffile:   Raw Address = 0x2000, Mapped Base Address = 0xffffffff
ib_vme_read_conffile:   PortNameA = 'gpib0'
ib_vme_read_conffile:   Mantis Base = 0x90002000
ib_vme_read_conffile:   DMA Base = 0x90002200
ib_vme_read_conffile:   TNT Base = 0x90002100
ib_vme_read_conffile:   Interrupt level Port A: 5, Interrupt Vector Port A: 0xf5
ib_vme_read_conffile:   BusRequestLevel = 3
ib_vme_read_conffile:PortNumber: 1, Port B
ib_vme_read_conffile:   Raw Address = 0x2000, Mapped Base Address = 0xffffffff
ib_vme_read_conffile:   PortNameB = 'gpib1'
ib_vme_read_conffile:   Mantis Base = 0x90002000
ib_vme_read_conffile:   DMA Base = 0x90002300
ib_vme_read_conffile:   TNT Base = 0x90002180
ib_vme_read_conffile:   Interrupt level Port B: 5, Interrupt Vector Port B: 0xf1
ib_vme_read_conffile:   BusRequestLevel = 3
ib_vme_read_conffile:out
ib_vme_probe:in
ib_vme_probe:probing VME-GPIB
ib_vme_regs_init:in
ib_vme_regs_init:ibo=0x2564f10 ibt=0x90002100
ib_vme_regs_init:ibo->cdor=0x90002100
ib_vme_regs_init:ibo->admr=0x90002108
ib_vme_regs_init:ibo->cfg=0x90002110
ib_vme_regs_init:ibo->tnt_keyr=0x90002117
ib_vme_regs_init:ibo->fifo.f8.a=0x90002119
ib_vme_regs_init:ibo->fifo.f8.b=0x90002118
ib_vme_regs_init:ibo->fifo.f16=0x90002118
ib_vme_regs_init:ibo->cmdr=0x9000211c
ib_vme_regs_init:out

[niRDW]

BTW, I am stuck on the tool that emails to support because a window coming up that says "undefined" when

Software Details: Other version = N/A

Beardware Details: OBSOLETE GPIB (since VME-GPIB is not a choice) and

Driver Version = anything

[walterxu]

hi,niRDW

I buy vme-gpib with dual ports too.And I also use vxworks (powerppc) to control the board.

I have the niDDK488.2,and when I try to build the driver,I find there only source code for solaris.If I want to use the code for vxworks,lots of functions are come form solaris system.

Have you write the board' driver yourself? 

[niRDW]

walterxu,

Yes.  I have found it slightly challengin, but rewarding to use the Solaris drivers with some slight modifications.  My product does not have a file system, so a change in the functions that try to open("dev\gpib",...) are required, plus the normal replacement of the generic zalloc, mutex, etc calls.  I can't share any source, since I am working for hire, but I can say that I think it is worth modifying the Solaris drivers.

My original problem I reported here has been "resolved", BTW.

Good luck.

[Chriso]

niRDW,

I am doing something similar and have encountered the same problem. What did you do to reolve your problem? In my case it looks like writing to the Mantis to enable interrupts may be causing it but it's unclear.

TIA,

Chriso

[niRDW]

I have some pretty good luck with this package now, except for the interrupts.  I had been working with the very helpful support crew at NI.  However, interrupts are not running right now.  I would like for them to operate, but I have set that mission on a back burner.

I should add that I don't see any case where trying to enable the interrupts has caused any extra trouble -- unless you were successful at enabling them and I was not;  and when I do enable them successfully, I would catch up to where you are at.

Message Edited by niRDW on 01-11-2008 06:26 AM

[walterxu]

Since i can not use the function which defined by solairs,so i creat new file to run the function of ib_vme_regs_init.

But when i run it under tornado,i only can get something like below

-> ib_vme_regs_init
ib_vme_regs_init
ibo=0x0
 ibt=0x0
ibo->cdor=0x0
ibo->admr=0x8
ibo->cfg=0x10
ibo->tnt_keyr=0x17
ibo->fifo.f8.a=0x19
ibo->fifo.f8.b=0x18
ibo->cmdr=0x1c

i dont know why.

Maybe i should put base address somewhere?

Thank you very much!