Differences between TNT4882 and TNT5004 for an OS driver writer?

[dl8dtl]

Hi,

I'm currently polishing up the GPIB drivers and libraries of the FreeBSD operating system.

As FreeBSD is not officially supported by the NI suite, we have to maintain our own OS drivers

for the cards.  Another FreeBSD developer wrote drivers for the ISA and PCI cards a few years

ago, which have been working for him.  I now changed the ISA driver a little, as I got hold of

an old ISA PCIIA, and thus know my GPIB itself is working.  Now, I borrowed a PCI card, and

tried that driver, but it fails to communicate on the bus.  It still probes though, which means

the PCI IDs are still the same, as well as the hardware passes various functional self-tests

which are supposed to be described in an NI Application note 095 which I did not manage

to find.

Anyway, the major difference between the PCI card my colleague has been using some years

ago and mine is that his card was using the TNT4882 chip, while mine is using the new TNT5004.

So my question is whether anyone could give me some hints about what differences might

exist in the low-level handling between the TNT4882 and TNT5004 ICs.  As both cards announce

the same PCI VID/DID , the question would then also how to tell both ICs apart (I suppose

through the version number)? 

[Steven_T]

Hello dl8dtl,

You may have already guessed this, but there is no major difference between the two types of PCI-GPIB cards.  For NI-488.2 there is no minimum driver version necessary to specifically use a PCI-GPIB with a TNT5004.  As long as the driver supports the old PCI-GPIB it will support the new one as well.

You should probably make sure that your driver still works with the old board.  If it does and you still get failures on the new board, we should probably look at the part numbers to verify (sometimes labeled as assembly number....it is on a sticker on the board).

There is a NI-488.2 DDK source code package that can get you started with the driver development.  It works with all flavors of the PCI-GPIB cards.  It comes with a few example operating system layers that would need to be modified to work with your OS. 

I hope this helps,

Steven T.

[dl8dtl]

> You should probably make sure that your driver still works with the old board.

OK, will do.  Alas, that turns out to be a little difficult, as I could get my hands

only onto a new card. I have to see where I could get a TNT4882-based one

then.

>  There is a NI-488.2 DDK source code package that can get you started with

> the driver development.

OK, thanks for the hint.  I wasn't aware it contains source code examples for

an OS driver implementation, that's indeed a good idea then.

Thanks for the help!

[dl8dtl]

Just reading documentation now...

Curious, I found a programming  reference for the TNT4882, and a technical reference

for the TNT5002, but just a datasheet for the TNT5004.  What's the difference between

the latter two? 

[dl8dtl]

Hmm, in the TNT5002 documentation, I don't see a CDOR mentioned anymore.

My driver used to use this register for output to the bus.  I guess that could make

the difference, couldn't it?

Is it safe to just use the DCR instead, or will I have to change more logic around

that? 

[Steven_T]

Hello,

The TNT5002 and TNT4882 are both talker/listener GPIB ASICs that allow instrument vendors to implement a GPIB port on their instruments.  The old PCI cards actually had a TNT4882C (the C is for Controller).  This ASIC allowed for talker/listener/controller functionality.  The TNT5004 has the same relationship with the TNT5002 (TNT5004 = talker/listener/controller, TNT5002 = talker/listener).

I had not anticipated that your old code used the CDOR to transfer data.  The TNT4882C has a more efficient way of sending multiple bytes out of the GPIB port using the FIFO and the TNT5004 only implements the FIFO data transfers.  You will need to start with the TNT4882 manual which has information about how to transfer data using the FIFOs. 

I hope these resources help,

Steven T.

[dl8dtl]

> I had not anticipated that your old code used the CDOR to transfer data.

🙂

The PCI driver frontend and the ISA driver frontend (for the old PCIIA card)

simply share the same µPD7210 backend by now.  Apparently, that provided

an easy migration path for the author of the PCI TNT4882 driver back when

he wrote that code.

> ...  and the TNT5004 only implements the FIFO data transfers.

I was afraid of that after reading a little more in the manual.   I guess I'll keep

the common µPD7210-style backend driver anyway (as it does a lot more than

just the actual data transfers), and then add an optional FIFO-mode IO path to

that, which is going to be used by the PCI frontends, while the ISA frontend can

continue using the old code.  (These ISA cards are pretty cheap to have now, so

they are not as uninteresting as it might seem at first.  Just pick an old ISA-capable

board, make it a GPIB controller with such a card, and then only work across the

network on it.) 

>  There is also a source code package that works as a talker/listener only.

I've already had a look into that, but it was before I discovered the programming

manuals. 

Thanks for all the help so far! 

[dl8dtl]

I've got my first successfull FIFO transfers (instrument in unaddressed mode sending

hardcopy print data to TNT5004 as a listener), so there's progress.

Curious, later on, I'd like to use the same code path I'm writing now to handle the

TNT5004 later on also for TNT4882-based cards (rather than the old µPD7210

compat mode they are using now).  Am I correct that, for maximum compatibility

between the TNT5004 and TNT4882, I have to operate the 4882 one in "One-chip

mode"? 

[dl8dtl]

Alas, I didn't manage it so far to start the SH function (in order to send commands,

i.e. as a controller). I think the reason is that I could not persuade the TNT5004 to

become controller-in-charge.  Both my existing driver as well as the linux-gpib

driver I had a look at do this through the respective NAT7210 AUXMR commands

(0x11 -- take control asynchronously, or 0x12, take control synchronously,

respectively). This didn't show any effect on the bus lines for me, and I noticed that

even the TNT4882 manual does not list these commands.  (It's not surprising the

TNT5002 one doesn't as it's a listener/talker-only chip, and there's not TNT5004

manual to verify.)  I guess I am not supposed to poke on the bus lines directly

through BCR, am I?  Is the omission of these commands in the TNT4882 manual

rather accidentally, or is there another method now?  Searching the manual for

"take control" didn't reveal anything that would have helped me.

[dl8dtl]

Sorry for talking to myself here...

> This didn't show any effect on the bus lines for me, and I noticed that

> even the TNT4882 manual does not list these commands.

Well, I think I realize why this is the case: the publically available reference

is for the TNT4882 only, which does not have controller functionality, but

the reference for the TNT4882C (or 5004) is not public.   Thus, the controller

functionality is simply not mentioned in either of them.

That doesn't tell me why the original driver's approach didn't work, and made

my card the controller-in-charge though.

Suppose I were signing an NDA to obtain a TNT5004 reference manual, would

I still be allowed to use that manual in order to write an opensource OS driver

for the basic functionality (i.e. listener/talker/controller, nothing like fancy

bus monitors etc.)?