STS1[IN] affect on GFIFO

[MGotcha]

I am porting some TNT4882 code (two chip mode) to the TNT5002 (one chip mode) and am running into a bit of trouble with the GFIFO use. Does the STS1[IN] bit only affect the direction of the FIFO relative to the GPIB bus, or does it also affect FIFO reads & writes from the program as well (must IN be set for my pgm to read from the FIFO and clr to write to it)? Are there seperate read & write FIFOs, or is the FIFO common to both? Thanks!

[Roland A.]

The STS1 register is read only, therefore you must use CFG[IN] to set or clear the IN bit.  Since this bit controls what direction the FIFO is going, you should not be transferring data into the FIFO unless CFG[IN] and therefore STS1[IN] are cleared.  To read data from the FIFO, you should have CFG[IN] set.  The TNT4882 Manual found here has an example set of steps to read and write from the FIFO and it includes setting the CFG[IN] bit correctly. I would also suggest looking into the TNT5002 manual here.

[MGotcha]

Looks like my real issue is delayed servicing of the ISR3[ADSC] interrupt (my TNT5002 code is interrupt driven). My test setup has my device setup to simply echo back messages it received, with the host sending one test msg after another. Normally, the ADSC interrupt lets me track send/receive status and I set the IN bit as needed and all works well most of the time.

My failures seem to occur when the ISR3[ADSC] interrupt is delayed long enough for the host to complete a sequence where:

> my device is currently a talker, sends the host a reply message ("IN" is clr),
> the host gets the reply message, it makes my device a listener, sends it the next message complete
> The host makes my device a talker to get the next reply message

(I am using a GPIB+ card & analyser software to verify)

Device does not get the interrupt until after these 3 events, and the "IN" flag is still cleared. At this point, I am showing ADSR as 0x4A, and ISR1[END] indicating I did get the message, but nothing is in the FIFO. I tried setting IN at this point if ISR1[END], but the FIFO is still empty (I would guess IN must be set before data from the GPIB bus can enter the FIFO).

Slowing the handshake in the GPIB+ analyser software seems to prevent the problem, allowing the interrupt to catch all ADSC events. Seems like I must be able to track talker/listener status real time to be able to set & clear the IN bit as needed for FIFO to GPIB bus transfers, as the TNT5002 will just continue GPIB data transfers regardless of the IN bit state. Is there any way around this besides disabling the FIFO and going back to using DO and DI to transfering single bytes?? Thanks!

[MGotcha]

OK, I have some more info. I am now running pretty much without fail. I am now using the ISR1[DO] interrupt to let me know when my FIFO has finished transfering to the GPIP bus. When this happens & I have no more data in my device's queue to send, I set the "IN" bit, atticipating being made a listener. If the ADSC interrupt is missed, then all still works well as I am setup to receive from the GIBE to the FIFO. The ATSC interrupt is definitely not being generated at times missing TA and LA transitions & causing this whole problem (I now use DO also to signal transitions to TACS instead) I thought maybe I had some interrupt service delay issues, but interrupts on the system are fast enough. Any known quirks about using the ADSC interrupt? I have also tried static & dyn ack interrupts (AUXRI[SISB]) with similar results (I am currently setting this bit & manually ack interrupts) Other interupts seem to be fine (DEC,END,ERR,DO,GFIFO_RDY,DONE).