How to know when to conduct GPIB Receive with TNT4882 and ESP-488

[Trevor Page]

I am using the NI TNT4882 GPIB chip together with the ESP-488 drivers (non-interrupt version) which I have successfully integrated into my application based around a PIC18F6720 microcontroller.

The drivers are working great, and I am able to transmit and receive GPIB strings from a GPIB controller card I have sitting in a PC. Obviously to initiate a GPIB receive, I use the Receive(buffer,50,EOI) function, then blast some data via the correct address from my GPIB controller, and bingo, it works.

What I really don't get, however, is how my application should know when to use the Receive() function. Okay - so at first the controller sends a message, and the TNT goes into LADCS state. My software sees
that the LACS bit within INTERFACE_STATUS is asserted and calls Receive() to get the data. So far, so good.

But how do I know when to call Receive() again in order to get any string that may be sent in the future? Assuming that the controller does not ever UNlisten the TNT between message strings, and the TNT remains idle in listener active state, how do I know when there is new data being received so that I can call Receive() again to fetch it? The problem with Receive() is that it is assumed that there IS data on the way. If there's no data, it'll timeout (if you're using timeouts) and report an error. Surely there is a more elegant way though of seeing if there's any data in the first place.

Am I being daft or missing something very obvious here? Maybe it is not conventional for the controller to leave a GPIB device in listener state once it has finished sending a single message?

Any help on this one would be most appreciated!

Kindest regards,

Trevor.

[ndiamond]

> But how do I know when to call Receive() again in
> order to get any string that may be sent in the
> future? Assuming that the controller does not ever
> UNlisten the TNT between message strings, and the
> TNT remains idle in listener active state, how do I
> know when there is new data being received so that I
> can call Receive() again to fetch it? The problem
> with Receive() is that it is assumed that there IS
> data on the way. If there's no data, it'll timeout
> (if you're using timeouts) and report an error.

That's how I did it in my work.

> Surely there is a more elegant way though of seeing
> if there's any data in the first place.

When HPIB (Agilent Interface Bus ^u^) was invented,
neither C nor Pascal existed yet, though BASIC an
d
Algol and IBM mainframe JCL did. Subsequently Pascal
was invented and died, and C turned into C++. And
you're asking for elegance?

[DiegoF]

Hi Trevor,

I believe that is how the queues are handled. The Queue Interrupt handler is called on the adsc (Address status change). If the interface is addressed as listener the receive operation is setup. If the interface timeouts, the transfer is setup again.

Maybe the queue handling mechanism can give ideas for the non-interrupt case.

DiegoF
National Instruments.