Does anyone know how to detect IEEE-488.2 query interrupted/unterminated errors with the TNT4882 chip while using the FIFOs?

[Todd_A._Hayes]

I am using a TNT4882 chip and taking advantage of the FIFOs in the implementation of my GPIB device.  I am using the chip in one-chip mode and my implementation is highly interrupt driven.  I am having trouble figuring out how to handle the following two situations.  Any help from anyone would be great.

1) How to know the difference between a normal device read (my device is talked) and a serial poll sequence.  I am currently generating a query interrupted error when the chip enters the TADS state when I have received an incomplete command/query message.  The problem is that durring a serial poll sequence the chip leaves the LADS state and enters the TADS state.  My driver doesn't know if it is going to be a serial poll or the controller really wants me to abandon the listen and send it a response message.

2) How to detect query unterminated situations reliably.  I am running into similar concerns to the above.  I am having trouble differentiating between a talk when I have nothing to respond versus a serial poll sequence.  During the serial poll sequence the chip enters the TADS state prior to asking for the serial poll byte.  My driver is detecting the TADS transition and generating a query unterminated error when it shouldn't.

I can figure out how to handle these situations if I use the DO interrupts with Turbo-1710 mode but not with one-chip mode and using the FIFOs.  Does anybody have any experience using the TNT4882 in one-chip mode with the FIFOs that might have some insights into how I could distinguish the IEEE-488.2 legal transitions versus the illegal ones?

[GPIB_Guru]

The DO interrupt works in one-chip mode. Ignore the documentation, it is wrong.

[JasonSmith]

Hi Todd,

The GPIB ASIC Reference Manual Errata confirms what GPIB Guru stated above, that the DO bit is valid for One Chip Mode.

Let us know how that works out,

Jason S.
GPIB & Serial
National Instruments

[Todd_A._Hayes]

I may have found an easier alternative way of doing this.  IEEE-488.2 section 6.2.18 says that a serial poll sequence must be performed in a particular way.  Of interest is that the SPE command should be issued before the TAG command.

I was trying to write my driver to accomodate the TAG and SPE comming in any order.  Some of the controllers I have used a long time ago (before .2) swap the order.  But, I think that any IEEE-488.2 compliant controller will issue the SPE first.  If this is true, then the SPMS bit in the ADSR should always be set when the chip enters TADS during a serial poll and not set when an ordinary talk is being performed.  I think I can use this to distinquish between serial polls and response requests.

What do you think?

In order to use DO, I am thinking I would need to wait for the DO before loading the FIFOs so I don't miss it when the data is automatically moved from the FIFOs to the CDOR.  At the least, I would need to be monitoring for another interrupt that I do not process now.  That would complicate my driver and reduce my throughput.  Reducing the throughput is something I'm not sure we can tollerate.  As such, I am really hoping that the above technique will work.

[GPIB_Guru]

To me, your way is (slightly) dangerous. Primarily because you have no control over the host. As a device, you should make every attempt to support whatever can be thrown at you. if your device will be used in a controlled environment, you will probably be okay. If you plan to mass-market this device, you may not be in as good of shape.

I typically have a state machine where I am either talking or listening. If I am talking, I care about interrupts that put me to be a listener (ADSC). If I am listening, I care about interrupts that could put me to be a talker (DO).

Startup: Enable DO interrupt, start a read
Rx DO interrupt: Enable ATN, IFCI, and ADSC interrupt to know when we go from TACS->!TACS, start a write
Rx ADSC Interrupt: If LA, clear ATN and IFCI interrupt and Enable DO interrupt to know when we go from LA->TACS, start a read.
RX ATN or IFC: Disable ATN and IFC interrupts, Enable DO interrupt to know when we go from !TACS->TACS.

I have had very good performance with this method. I don't recall all of the nitty gritty details since there are a few of course, but in general I try to only cancel my read when I actually go to TACS (DO interrupt) and I only cancel my write when I actually go to LA (ADSC interrupt if LA). I don't 100% recall why I need to know TACS->!TACS, but I think it had to do with knowing everytime BRQ came or disappeared for the 488.2 MEP state machine.

[Todd_A._Hayes]

Ahh, I think I get it.  You don't even look at ADSC when deciding to become a talker.  You only use DO to transition to the talk state.  I didn't think of doing that and that might get rid an extra interrupt.  I still have the extra latency of loading the FIFOs after the DO instead of starting the load prior to the ATN dropping but that might not be as bad as I first thought.  It certainly brings sanity to trying to manage the MEP.  Until you showed me this I was a little frustrated because I couldn't figure out when we went into and out of the TACS state but only the TADS state which isn't enough information.

You have given me some good insights.  Thank you.

[GPIB_Guru]

Glad to hear it. Yes, we came up with that idea after we decided that we didn't like the ADSC for TA since for 488.2 you really need TACS and not just TA. For listening, LA is fine. You do have the negative of not being able to load until DO, but the overall loss of time is pretty small since there are only a few registers to write to start a transfer. Let me know what your results are and if you need any other pointers....