Unable to configure NAT7210 as GPIB system controller.

[Chris_kr]

Hi,

I'm developing board with Atmega64 and Nat7210.
1. What is the correct procedure to read Data In register and Interrupt Status Registers. Can I read Data In Register before reading Interrupt Status Registers in interrupt handling procedure??

2. I'm trying to sent *IDN? to device and get answer from device. Is below procedure correct?
7210 address is 0, device address is 5

*(GPIB_R0)=0x10; //take control asyn
*(GPIB_R0)=0x40; //mta 0
*(GPIB_R0)=0x25; //mla 5
*(GPIB_R0)=0x10; //gts
*(GPIB_R0)=0x2A; //send *
*(GPIB_R0)=0x49; //send I
*(GPIB_R0)=0x44; //send D
*(GPIB_R0)=0x4E; //send N
*(GPIB_R0)=0x3F; //send ?
*(GPIB_R0)=0x11; //take control asyn
*(GPIB_R0)=0x45; //mta 5
*(GPIB_R0)=0x20; //mla 0
*(GPIB_R0)=0x10; //gts

regards,
Chris

[Collin M]

You can read the Data In Register prior to reading the ISR, but I think a problem may be determining IF you should read the DIR. Reading the ISR should tell you that.

I don't understand the code you posted. This looks like C code but I may be missing something. I can make some general comments:

Is this code run on the NAT7210 while it is a standby controller? tca will only cause the 7210 to become a controller if it is a standby controller. A standby controller is a controller-in-charge that was issued the gts (go to standby) command. If the 7210 is an idle controller (never been controller-in-charge) then gts will have no effect.

It is correct to send GPIB addressing commands (MTA, MLA) and then the gts command. This causes the controller-in-charge to become a standby controller to allow devices to exchange data.

I'm not sure how your code is architected, and I've never claimed to be a good software writer. However, it may be better to have some higher level function to which you can pass an entire string to, instead of sending one byte at a time. The low-level interface to the 7210 can only accept one byte at a time but it will probably be better to abstract away from that interface.

One more comment, it appears each line in the code you posted is writing to the same memory address by de-referencing a pointer. There is certainly no single register in the 7210 to which you could write all the commands you listed. If you write to 7210 registers by derefencing a pointer the code usually looks something like this:


#define AUXMR_OFFSET 0x0A

*(NAT7210_Base_Address + AUXMR_OFFSET) = 0x02; // chip reset

And the offset changes for each register.

Also, if you are new to GPIB programming you may find it useful to read the TNT4882 or TNT5002 programming manuals which are available at ni.com. Each of them gives a good overview of the required firmware functionality.

[Chris_kr]

> You can read the Data In Register prior to reading the > ISR, but I think a problem may be determining IF you
> should read the DIR. Reading the ISR should tell you
> that.

> I don't understand the code you posted. This looks like > C code but I may be missing something. I can make some
> general comments:

> Is this code run on the NAT7210 while it is a standby
> controller? tca will only cause the 7210 to become a
> controller if it is a standby controller. A standby
> controller is a controller-in-charge that was issued the > gts (go to standby) command. If the 7210 is an idle
> controller (never been controller-in-charge) then gts
> will have no effect.

Yes before that code I configure 7210 as a CIC and issue gts command. I have problem, because when I'm tring write to DIO (for example *, or I) i get interrupt with error message.
If I'm right understand I should write GPIB commands to AUXMR. And when I'm sending *IDN? I should write one by one byte (*,I,D,N,?) to Data Output register after issuing gts. It is correct ??

> It is correct to send GPIB addressing commands (MTA,
> MLA) and then the gts command. This causes the
> controller-in-charge to become a standby controller to
> allow devices to exchange data.

> I'm not sure how your code is architected, and I've
> never claimed to be a good software writer. However, it > may be better to have some higher level function to
> which you can pass an entire string to, instead of
> sending one byte at a time. The low-level interface to
> the 7210 can only accept one byte at a time but it will > probably be better to abstract away from that interface.

In future i'll make this function, but now I'm tring to start chip.

> One more comment, it appears each line in the code you
> posted is writing to the same memory address by de-
> referencing a pointer. There is certainly no single
> register in the 7210 to which you could write all the
> commands you listed. If you write to 7210 registers by
> derefencing a pointer the code usually looks something
> like this:

> #define AUXMR_OFFSET 0x0A

> *(NAT7210_Base_Address + AUXMR_OFFSET) = 0x02; // chip
> reset

> And the offset changes for each register.

This code should look like this below:
//set IFC
*(GPIB_R5)=0x1e;
//reset IFC
*(GPIB_R5)=0x16;
//listen
*(GPIB_R5)=0x13;
//gts
*(GPIB_R5)=0x10;
//take control asynch
*(GPIB_R5)=0x10;
//mta 0
*(GPIB_R5)=0x40;
//mla 5
*(GPIB_R5)=0x25;
//gts
*(GPIB_R5)=0x10;
//send *
*(GPIB_R0)=0x2A;
//send I
*(GPIB_R0)=0x49;
//send D
*(GPIB_R0)=0x44;
//send N
*(GPIB_R0)=0x4E;
//send ?
*(GPIB_R0)=0x3F;
//take control asynch
*(GPIB_R5)=0x11;
//mta 5
*(GPIB_R5)=0x45;
//mla 0
*(GPIB_R5)=0x20;
//gts
*(GPIB_R5)=0x10;
GPIB_R0 is DIO
GPIB_R5 is AUXMR

[Collin M]

Lets take a step back and look at everything that needs to happen for the 7210 to successfully send the data message *IDN? to another GPIB device.

1. Power is applied, hardware reset is unasserted, chip initialization is done, and pon is cleared by writing 0x00 to the AUXMR (offset 0x5)
2. The 7210 must become controller-in-charge. This is usually accomplished by writing the Set IFC (0x1E) command to the AUXMR. This implicitly asserts ATN.
3. The 7210 sends GPIB command bytes to address itself and another GPIB device for a data transfer. If the 7210 will send *IDN? to another device then it must address itself as a talker and the device as a listener. The specific GPIB command bytes are formed using the GPIB addresses of the 7210 and device.
4. The 7210 becomes a standby controller and implicitly unasserts ATN.
5. The 7210 is now a talker and sends the data message *IDN? to the device.
6. The 7210 becomes active controller (tca/tcs) and readresses itself to listen and the device to talk.
7. The 7210 becomes a standby controller, and the device is able to respond with some data message (if it is 488.2 compliant).

There are lots of details I left out but that is in essence what needs to happen.

The most common way to transmit commands/data is to use an interrupt driven method. The DO bit will set when a data byte can be written to the CDOR. The CO bit will set when a command byte can be written to the CDOR. The writes to the CDOR need to be throttled with CO/DO to allow time for the byte to be handshaked across the GPIB.

Most of this is covered in chapters 5 and 6 of the 7210 manual. Have you read these chapters?

Also, do you have a GPIB analyzer? The analyzer allows you to examine the state of the GPIB signals and can be invaluable when writing firmware.