Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

9914 and sending data back across the bus.

We are programming a device with the 9914 chip, and we can write commands to the device, but are having trouble getting the device to write data back. When using the interactive tool, by executing "ibrd 100" is the device addressed as the talker? What is a fairly straight forward method for passing 1 byte of data from the device to the controller? We have a routine that waits till the TA bit in ISR1 sets, before it placed the byte in the CDOR. But the TA bit never sets, even after we execute ibrd 100 with the interactive tool. Is there something else we need to do? Any help would be appreciated.

Thanks

Rick
0 Kudos
Message 1 of 6
(3,687 Views)
Rick,

Are you using a board or device handle in the interactive control utility? If you are using a board handle(eg, you should see gpib0:) then you must first perform an ibcmd call. The buffer that you should use for the ibcmd call should consist of the following:

UNT(untalk)0x5f
UNL(unlisten)0x3f
MTAx(make talk address PAD of 9914)0x60+PAD
MLAy(make listen address PAD of board)0x40+PAD

So, if your board PAD is 0 and the PAD of the 9914 is 3, you should do the following in ibic:

gpib0: ibcmd "\x5f\x3f\x63\x40"
gpib0: ibrd 100

You may also be interested in using the GPIB analyzer functionality of the PCI-GPIB+ or PCMCIA-GPIB+ cards to help you debug such GPIB issues.
0 Kudos
Message 2 of 6
(3,687 Views)
We are using a device handle, so after we see gpib0 we call

ibdev 0 3 0 13 1 0

then we see ud0

Unfortunaly we are using the PCMCIA-GPIB card and it does not support the analyzer feature. I will try what you have stated earlier about the ibcmd call.

Thanks

Rick
0 Kudos
Message 3 of 6
(3,687 Views)
Since you're using a device handle, it should send the addressing command bytes for you. We should probably look at the code on the 9914 side of things.

You said that you're waiting on the TA bit to be set in ISR1. According to the reference manual for the NAT9914, there is no TA bit in ISR1. You should be waiting on the MA bit to be set. Make sure that you have enabled interrupts on the MA bit by writing to IMR1, or it will not get set when the chip gets the MTA command. Following the setting of the MA bit, you may check the TA bit in the ADSR register.

Hope this helps.
0 Kudos
Message 4 of 6
(3,687 Views)
That is actually what I was doing. I should have been more carefull last night when posting my question. We are not using interupts though, we are just polling the registers to see when the appropriate bits set. MA, then LA or TA depending upon what we want, then the BI or BO bits. I will try enabling interupts to see if that causes the bits to set.

Thanks

Rick
0 Kudos
Message 5 of 6
(3,687 Views)
Enabling interrupts should not have an affect. Can you give me a summary of how you are setting up the chip? For example, what are you setting in the ADR register? This register sets the addressing mode of the chip. If you are not setting it up correctly at address 3, you would, of course, not get an interrupt.

So, lets assume you are setup correctly. There are a couple of different things to try.
1) You can look at the MAC bit in ISR0. This is the My Address Changed bit, which should set everytime your addressing mode changes.

2) Note that the NAT9914 does not have static bits in the ISR registers. If you read a register, the bit will clear automatically. Just in case something else asserted along with MA and you hand
led it but forgot to check MA, you will lose it.

3) You can try setting MA IE. This will not generate an interrupt if you have interrupts disabled, but it will cause an NDAC holdoff. In this case, the ibrd 100 should timeout on the host side if the device is actually doing the holdoff.
0 Kudos
Message 6 of 6
(3,687 Views)