How do I communicate with a GPIB device which uses a TNT4882 interfaced to 8051 microcontroller

[sada]

Hi!!

     We have developed a GPIB device using TNT 4882, for power supply control.
The voltage and current variation is carried out through a 8051 microcontroller,
which is interfaced to the TNT 4882. We have connected this device to a
GPIB-USB-HS controller using a GPIB cable. Now, when i use MAX to scan for my device,
MAX replies that it didn't find any instruments. Can anyone help me in resolving this
problem.

Thanks!!

Sada.

[Collin M]

I need to ask a few basic questions first. Have you written a driver for your device and is that driver running on the 8051? It is the responsibility of the driver to provide the response to the scan for instruments. The hardware (TNT4882) just sees that as a generic data transfer. If your driver is running on the 8051 does the 8051 get an interrupt when the scan for instruments happens?

[sada]

Hi Collin,

   Thanx for your reply.

We have written a driver for our device and the driver is running on the 8051 microcontroller.  We have verified that the 8051 initializes the TNT4882,  but we donot get any interrupt on 8051 when the scan for the instruments occurs.

[Collin M]

I forget exactly how the scan for instruments protocol works, but I think it should be addressing your device to listen and then sending *IDN?.

What interrupts are you enabling in the IMRs? Are you clearing pon and the end of the initialization? Is the GPIB address of the device different than that of the controller? How did you verify the 8051 initilized the TNT4882?

[ScottieB]

Collin is right, the Scan For Instruments procedure addresses all primary addresses one-by-one and checks to see if anyone will accept bytes.  If they will, it will send *IDN?.  You should definitely get some interrupts if you're becoming a listener (and they're enabled in your IMR's), and then your 8051 software will have to read the bytes in and respond to *IDN?.  Note that to get "scan" to work, you actually don't need to respond to the *IDN?, you just need to accept bytes.  But a proper instrument should respond to *IDN? (and do a lot of other things in a specific way too).

Scott B.
GPIB Software

[sada]

Thank you Collin and Scott, for your replies. Here are the inputs from my side.

1. We haven't used any interrupts for TNT.Our detection procedure consists of continuous polling of the register ADSR for it to be set as a talker/listener.

2. The initialisation of the TNT has been done and verified. We have sent the talker/listener address of the TNT through hard wired wires and noticed that the TA/LA bits are set in the ADSR register. After it has been set as a listener we have sent ASCII codes of messages which were read by the TNT as well. For eg we have placed the ASCII code of *  i.e. 2A and it was read by the micro controller. The data transfer has been done according to the protocol mentioned in the TNT4882 Programmer Reference Manual Appendix C page number C-13. My understanding is that the communication cannot happen if the device is not initialised.

3. We are clearing the pon at the end of initialisation.

4. Doesn't the controller issue IFC before scanning for primary addresses of the talker/listener devices?

 Looking forward to your replies....

Sada

[Collin M]

Ok, it sounds like your driver is running.

Scan for instruments detects devices by sending a listen address and then checking the state of the NDAC signal. If a listener is present at that address it will be asserting NDAC. One possibility that the TNT4882 is not being detected is that it has the same address as the controller. The controller doesn't scan for a device at its own address. What address are you using for the TNT4882?

I don't think the controller necesarily asserts IFC prior to doing a scan for instruments. Someone please correct me if I'm wrong.

Have you tried using ibic to send individual commands from the controller to your device? That may be easier to debug than doing a scan for instruments.

[ScottieB]

I believe that IFC is asserted/deasserted with every Scan for Instruments (at least it was when I did it twice just now).  IBIC (Interactive Control) would be more helpful for precise testing.  Open up Interactive Control and type these commands

ibfind gpib0 (assuming your board is gpib0, else replace this with gpibX)

ibpad 0 (set the controller's pad to 0, which is usually what you want.  make sure the instrument address is NOT 0 in this case.)

ibrsc 1 (does nothing on the bus, makes sure the controller can assert IFC)

ibsic (assert/deassert IFC)

ibln 1 0 (assuming your device is at address 1 and secondary address 0.  adjust as necessary)

The ibln command should give a TRUE/FALSE output determining whether or not it found a listener at that address.  You can repeatedly call ibln for different addresses (which is exactly what "Scan For Instruments" does).

Scott B.

GPIB Software

Message Edited by ScottieB on 05-03-2006 10:38 AM

[sada]

We have noticed few anamolies which we think are causing the device to be undetected:

1.We have selected "dual primary addressing mode" by writing 0x31 into ADMR register at offset 08. We have assigned GPIB primary address of 01 to our board and writing this into the ADR register at offset 0c. We have written 0x01 into the ADR register.We have disabled the secondary address by writing 0xe0 into ADR. According to the manual we can read back the primary address from ADR0 register at offset 0c. But the read back data is not 0x01, it shows different values like 0xba, 0x9a,0xda etc. Also the ADR1 register isn't giving the data 0xe0 on read back.It shows 0xf0 i.e. EOI line is asserted which is unexpected.  

     What could be the possible reason behind this?    

Another query which we have is should we drive the NRFD and NDAC lines through the micro controller and assert/deassert them by writing into the register BCR at offset 1f. Our understanding is that the TNT 4882 takes care of the handshaking scheme and we(i.e. the microcontroller) have to focus on receiving/sending bytes.  

Sada

[Collin M]

Sada, the TNT should automatically handle the hardware handshaking signals, including NRFD and NDAC. Your driver should never need to access the BCR.

It sounds as though register accesses to the TNT might not always be working. There are four count registers, CNT0 through CNT3 in the TNT. Can you write some unique value to each of these and then read it back? For instance, write 0xAA to CNT0, 0xA5 to CNT1, 0x5A to CNT2, and 0x55 to CNT4. Verify you can read each register correctly. Also, can you do a register dump of the TNT before and after initialization? By this I just mean read each readable register and record its value. Post the results to this thread. Also, can you verify your register address constants in your firmware are correct?

I want to make sure the hardware is working properly before anything else.