TNT 4882 chip read errors

[ScottieB]

That's a good point that GPIB Guru brings up...I was more in the controller-side mindset.  As a device-side application, even in the case of EOI, you'll still want to remain ready for data bytes because you're still a listener and the host could send another message to you.  I think the only time you'll want to end the transfer is when the controller makes you move on to something else (serial poll or talker or unaddress).

Scott B.

GPIB Software

National Instruments

P.S. Just saw your latest post on the several hours of uptime.  That's great news.  Hopefully you're all set, but keep us posted.  Thanks you Dittohead and GPIB Guru as well for providing their perspectives on this.

Message Edited by ScottieB on 01-19-2006 09:34 AM

[roni]

This is  a quote from a previos answer we received from you (reply 12 of 31)

“Reading the TA bit and accepting it as an indicator as when the device is addressed as a talker and should send data isn't entirely correct--as we have seen, a serial poll will activate this bit as well.  Also, reading the SPMS bit is of questionable value when determining when one should respond to a serial poll.  Ideally, one would use the STBO bit in ISR2 to know when to respond to a serial poll, and one would do so by writing to the SPMR.  As soon as you write to the SPMR, the STBO bit will clear.  Thus you won't run into weird timing problems that manifest themselves because SPMS does eventually go away, but only after the device has transmitted the serial poll response to the controller.

So, I wonder:

1)       Why use SPMS in ADSR instead of STBO in ISR2?”

Following your above answer, which indeed describe quite accurately the structure of our code, I have additional question:

As stated above, we are using the ADSR(TA) bit in order to check if our embedded device is in Talker mode. If so, we call the function that handles this mode.

Unfortunately, as you said, the TA bits is also activated when in active SPOLL  state.

We have bypassed this problem by checking ADSR(SPMS) bit as well, so that even if the TA bit is ON, we do not call our Talker function unless the SPMS bit is OFF.

This bypass works, but not in all cases, so we are searching for another method.

Your answer indeed indicates that monitoring the ADSR(TA) bit is not the correct way to know whether the Host is asking to read data (as it also activated by the SPMS). However, your answer didn’t include any hint regarding which bit should we use in order to be sure that the Host wants to read data from our device.

We found in the Reference Manual, that what we should look for is the TADS state. However, there is not bit to directly report this state. All that we have found is the ADSR(TA) ….

How can we, as an embedded device, know that the host is requesting to read data (not Serial Poll) ?

[GPIB_Guru]

>> How can we, as an embedded device, know that the host is requesting to read data (not Serial Poll) ?

The answer is simple, but requires a small leap of faith... The DO interrupt, which is in IMR1/ISR1 indicates that it is a don't care bit in One-Chip Mode. Ignore this. It has the same definition as in Turbo+7210 mode (or close enough). Essentially, it indicates whether you are in TACS. Real TACS, IEEE 488.1 TACS. Which means that you are not being serial polled. So, you can derive a new state machine for your device which is:

LA bit set -> Listener: (In IEEE 488.1 states, the T state machine is in TIDS, the L state machine is in LADS or LACS)
DO bit set -> Talker: (In IEEE 488.1 states, the T state machine is in TACS, the L state machine is in LIDS)
STBO bit set -> Serial Poll (In IEEE 488.1 states, the T state machine is in SPAS, the L state machine is in LIDS)

The only additional trick you need to know is that when you get in the DO state, you should enable the ATN and IFC interrupts to know when you got out of DO state so that you can re-enable the DO interrupt (you must disable the DO interrupt when you enter the TACS state; otherwise, it will continually interrupt you). Overall, just determine when you need to enable the various interrupts and when you can disable them to create your 3-state state machine. Noting that IFC takes you to TIDS/LIDS and ATN takes you from TACS->TADS.

Let me know if you need any additional clarifications.

[roni]

As you recall , we are  creating a device  with specific needs : it needs to respond to being addressed as a talker, listener, being serial polled, and being sent Device Clear via GPIB.  The way we know when to perform which task is via a global GPIB Status variable known as iGPIBStat that has bits labelled things such as TIMO, END, EOS, SPOLL, DCAS, TACS, LACS, UCMPL, ERR, similar to ibsta in the mainstream NI-488.2 driver.  The subroutine known as Update_INTERFACE_STATUS2() reads various bits from the GPIB card in the various Interrupts Service Registers (ISR's) and other registers to update this status word.  Then, they just run a loop that does something like this:

1. Update_INTERFACE_STATUS2()

2. Is the DCAS bit set in iGPIBStat ?  If yes, do a device clear & goto 1.

3. Is the SPOLL bit set in iGPIBStat ?  If yes, respond to serial poll & goto 1.

4. Is TACS set in iGPIBStat ?  If yes, talk & goto 1.

5. Is LACS set in iGPIBStat ?  If yes, listen & goto 1.

6. Goto 1.

we do not have success in stabilizing this communication to work fluently.

Do you have a code example that carries similar tasks and works without interrupts ?

Thank you

Roni

[GPIB_Guru]

I don't have any source code, but you should be able to change your Update_INTERFACE_STATUS2 routine to check different bits instead of the bits it does. Off the top of my head, the cases you care about:
TIMO : Never timeout, shouldn't be needed
END: ISR1: END RX
EOS: ISR1 END RX + ISR0 EOS
SPOLL: Possibly don't need if you just update the status byte whenever it changes (easiest way), otherwise, ISR0:STBO
DCAS: ISR1: DEC
TACS: ADSR: TA & !ISR0:STBO & ADSR:ATN (note that ADSR:ATN is inverse logic)
LACS: ADSR: LA
UCMPL: Probably unchanged to how you do it now
ERR: May not care about but can use what you are using right now.

I am guessing that the only change is how you determine TACS. Instead of just looking at ADSR:TA, you can look at a few different bits to come up with your correct TACS state. This would be that TA is set, ATN is unasserted and you are not in the STBO state. TA only tells you that you are in TADS, TACS, or SPAS. ATN unasserted tells you that you are not in TADS, and !STBO tells you that you are in TACS.

Just a thought.