Unable to configure NAT7210 as GPIB system controller.

[sp]

I am developing an application to provide GPIB interface to my 8051 CPU board using keil IDE, NAT7210 and 75162 & 75160 transceivers.

I have been able to configure NAT7210 as a GPIB device ie. I can identify my board from MAX 3.

But I am facing problem in configuring NAT 7210  as a system controller. My init sequence is as:

 AUXI_MODE = set pon
 AUXI_MODE = set clock speed

 ADDR_MODE = 0x31;       // Set addressing mode , normal addressing
 AUXI_MODE = Assert GPIB IFC signal
 some delay
 AUXI_MODE = Unassert GPIB IFC signal

##### i expect a change in the state of IFC clear line on a oscilloscope, but the line is intact, in tristate

 END_OF_STRING = NEWLINE;  //configure newline to end incoming & outgoing gpib messages
 AUXI_MODE = 0x9C;         //write in AUX B reg; normal handshake mode & EOS  enable

 AUXI_MODE = page_in;
 BCR = 0x20;   //set GPIB interface clear control bit in NAT7210

 AUXI_MODE = 0x00;      //enable device to rx data & commands from the gpib n/w,same as pow on reset
 AUXI_MODE = Take control Asynchrounously

#### After this I check status of CO & CIC, but neither of them is setting.
 Your valueble suggestions are welcome.

Regards

Shradha

[Collin M]

How are you connecting the SC pin of the 75162? This pin determines the direction of IFC. If SC is unasserted IFC will be an input to the 7210. If SC is asserted IFC will be an output to the 7210. This pin should be in the opposite state as when the 7210 is configured to be a device.

[sp]

Hello Collin !

I have made the SC pin permanently high . It is exactly opposite to device configuration, where I made it low ( conected to GND).

SO the direction of the IFC and REN lines are opposite to device mode, as required for the controller configuration.

Any more clue.

Best wishes, shradha

[Collin M]

Do you have two different sets of firmware, one for device and one for controller? If the device code is different can you try to assert IFC after you are done initializing?

In your example code when you write 0x20 to the BCR do you see IFC assert? Can you look at IFC on both sides of the 75162?

[sp]

Hi Collin,

I am using same hardware and devloping different firmware for device mode and GPIB controller.

I added this instruction prior to asserting IFC , so now I can see a toggling of the IFC & REN lines. Now they are always asserted following a reset.

AUXI_MODE = page_in;
BCR       = 0x83;   //set ATN, IFC & REN control bits in NAT7210

At each step I check the status of CIC flag . At no point of time I find the CIC set,so my device is never becoming active controller

So now a lil bit progress is made , but still struck that CIC bit is not setting.

wishes, shradha

[Collin M]

Setting bits in the BCR will not change the status of the CIC bit. The 7210 will interpret that as some other device toggling those signals.

Can you confirm pon is being cleared? You clear pon by writing 0 to the AUXMR. If pon is cleared then writing sic (0x1E) to the AUXMR should set IFC.

You should be able to reduce your code to clearing pon and writing sic to the AUXMR to cause IFC to assert.

Do you have anything connected to the GPIB side of the 7210? If there were another GPIB controller connected it is possible it could already be driving IFC high. NI GPIB controllers are system controllers by default and will drive IFC when they are online.

[sp]

Hi Collin,

With just these 2 instructions( clear pon & writing sic (0x1E) to the AUXMR)  u mentioned I am getting CIC bit set. I think I had put extra code which might be troubling. Thanks for the valuable suggestion.

Now have connected Lecroy LP142 DSO as a GPIB device for my controller. It comes to remote state as soon as it receives a cmd. After the CIC is set, I sent  

CDOR =  0x25;   //MLA 5..address device with addr 5 to listen

Sent to GPIB "* IDN?\n" as per suggested in CH 6 with checking status of CO & ERR bits.

Am I making a mistake ? As there is no activity on the scope. How to proceed further.

[Collin M]

This is a subtle but important point. Commands such as MLA5, MTA2, or SPE are truly GPIB commands. They can only be sent by a GPIB controller when that controller is asserting ATN. The device interprets them as commands solely because ATN is asserted.

When you send *IDN? it must be sent as a data transfer. It may seem like a GPIB command but it is not. GPIB commands are only those listed in Appendix D of the 7210 manual.

The device will accept *IDN? if it is sent as a GPIB command, meaning that it will accept the GPIB command "*" (MLA10), the GPIB command "I" (MTA9), the GPIB command "D" (MTA4), and so on.

Because *IDN? is a data transfer you must first address the 7210 to talk and the Lecroy to listen. This is done by sending two GPIB commands (MLA, MTA) while the 7210 is the controller and while it is asserting ATN. After those commands have been sent the 7210 must unassert ATN (by gts, for example). Then the 7210 can send the data message "*IDN?". After that the controller must assert ATN and address the Lecroy to talk and the 7210 to listen, and then unassert ATN to allow the Lecroy to send a data message back.

The important thing to remember is the difference between GPIB commands and GPIB data transfers. ATN must be asserted for GPIB commands and must not be asserted for GPIB data transfers. The various GPIB devices and controllers also must be addressed to talk or listen for data transfers.

[sp]

Hello Collin.

I am able to get the concept of data and cmd transfer from ur explaination.

I am trying the following code to bring my controller in addressed talker mode::

 ADDR_MODE = 0xB0;   //talker only, set ton bit.
 ADDR_MODE = 0x30;   // must follow the talker only cmd, put in no addressing mode as per ch 3 of manual

 ADDR01  = 0x00;           //...controller address..

 AUXI_MODE = 0x10;   // go to standby

// here i check ATN & CIC and it is a standby controller

 wait for ADSC to set, it sets if TA, LA ,CIC or MJMN changes
 if (TA) display on serial port ("Programmed Talker")

But I am not getting TA as true, ie. my controller is not configured as a talker. please help again.

[Collin M]

Is there a reason you don't want to use GPIB commands to cause your controller to become a talker? That is the usual way of doing things. The 7210 will accept all command bytes it sends. For example, if the GPIB address of the 7210 is 0 and the GPIB address of the device is 5 then sending MTA0 and MLA5 will cause the 7210 to become a talker and your device as a listener.

The lon and ton bits are intended to be used in applications where there is no GPIB controller to send command bytes. An example of this would be connecting a GPIB instrument to a GPIB printer. The printer could be hard-coded as a GPIB listener.

I suggest after issuing the gts command you try sending GPIB addressing commands.