Using TNT4882 ASIC in an embedded system, can I slow down Sync GPIB I/O?

[russp94037]

Hi,

I'm writing code for an embedded system using the TNT4882 ASIC as a GPIB interface. Relatively slow peripherals in the system, require that delays be inserted in Host PC code for proper operation. Test software on the Host PC has been written using LabVIEW (8.5.1) and VB ComponentWorks (v2.0, its old) using GPIB Synchronous Reads & Writes.

Rather than rely on users inserting delays in communciation software, it is preferred to program the embedded system to regulate GPIB traffic. For our customers use, the maximum delay needed is 20ms; internal company use requires EEPROM writes that can occupy the system for up to 100ms (we can insert delays for this requirement without too much angst).

I thought that I could use Ready For Data (RFD) Holdoffs to delay the GPIB hw handshake while a command parser executes instructions and builds responses for the GPIB. Using the AUXMR register, I've tried to use "Holdoffs on End", "Holdoffs on All Bytes", and the "Immediate Holdoff."

These attempts seem to have no affect on the timing of calls. Typically, NI spy reports a set of calls all that start and finish at the same reported time in milliseconds. I insert delays in the embedded system code to simulate hardware delays; but regardless of the RFD Holdoff settings I get the same fast execution reported by NI spy. The command traffic becomes garbled, and the embedded system reports command errors to the host.

The only delays that do appear come randomly with no apparent relation to what the embedded system is doing, perhaps from the Windows operating system interrupt.

Any comments or ideas are welcome,

Russ

[Steven_T]

Russp94037,

When I was reading your post, I imagined that holdoffs would be the thing that would help you.  However it looks like you have already been down this road.  However, I think this is the least of your worries.

<quote>Typically, NI spy reports a set of calls all that start and finish at the same reported time in milliseconds. I insert delays in the embedded system code to simulate hardware delays; but regardless of the RFD Holdoff settings I get the same fast execution reported by NI spy. The command traffic becomes garbled, and the embedded system reports command errors to the host.</quote>

1. So the embedded system (instrument) is not receiving the commands that are coming from the controller?  Can you give an example of what your instrument is receiving and how it is different from what your instrumetn expects?

2. Is there any other strange behavior?  Does the command garbling only happen under certain conditions? 

I am much more concerned about the garbled data because, it indicates either race conditions or firmware that doesn't follow the instructions for transfers.  In the TNT4882 guide, chapter 4 goes over some instructions for initialization, setting the gpib address, and data transfers (reading and writing).  If your routine follows these directions, you should not be missing any data bytes (even if it takes a while to parse them and queue up a response).  To verify these problems, you should probably enable prints for anytime you read a byte out of the FIFO in your code.

I hope this helps,
Steven T.

Message Edited by Steven T on 07-02-2008 02:01 PM

[russp94037]

Thanks for responding Steven,

Your questions & suggestions are appropriate.

Firmware is being altered to handle FIFO data faster (reading the FIFO in an ISR; instead of in a thread that responds to messages from the ISR). I think my use of garbled was perhaps too strong -- printf output from the command parser has been viewed -- what I have seen is concatenation of commands sent to the parser that should have been discrete. From the parsers point of view, this is garbage. Of course, I will have to work this part out.

Please clarify for me what I should expect when RFD Holdoffs are enabled. I thought that GPIB data traffic would stop (because NRFD is asserted) until the holdoff was released with the AUXMR command (NRFD not asserted). Is this correct?

With HLDE set in AUXRA, a 40ms delay was inserted before the holdoff was released, but I saw no changes in the NI spy command flow. If I should have seen a delay in the command traffic, then HLDE wasn't actually working & code isn't being executed as intended.

I'm setting up hw now to probe NRFD (access was blocked by ME hw) -- that should show what is really happening on NRFD.

The code being written does follow the initialization in the Programming Considerations section of the reference. Reading the Interface Register section, I think that register AUXRA (where the Data-Recieving Mode is stored) is only cleared in a chip reset (writing 0x02 to AUXMR does this near the start of init).

Another clarification: is it sufficient to write AUXRA w/ HLDE once during chip init or does it need to be written at the every start of listening?

Thanks for your patience,
Russ

[Steven_T]

Hello,

Sorry for the delay in getting back to you.  Last Thursday and Friday were holidays at NI.

Anytime a hold off is getting enforced, all GPIB traffic should be stopped.  When NRFD holdoffs happen only instances where a talker is trying to send your instrument data (like a query) will stop.  Your instrument will not be prevented from writing.

<quote>With HLDE set in AUXRA, a 40ms delay was inserted before the holdoff was released, but I saw no changes in the NI spy command flow. If I should have seen a delay in the command traffic, then HLDE wasn't actually working & code isn't being executed as intended.</quote>

With HLDE enabled, a holdoff will happen only when the end message is received.  The end will only happen under a few conditions:

1. all data being read (the counter registers make it to 0)
2. the EOS character is encountered
3. the EOI line is set

Your controller is likely sending something like "*IDN?(LineFeed)".  End will occur when the line feed happens because it is the EOS byte or EOI was set because it was the last character in the string.  NRFD hold offs will only prevent further characters from coming in.  The message is already sent and the Spy capture will likely not be affected.  You should see a difference if you try sending this string "*IDN?(LineFeed)*IDN?(LineFeed)".  The first time line feed is encountered it sets end because it is the EOS character in your instrument.  The holdoff will be experienced and captured by Spy in this case.

Writing the HLDE bit once is all that is necessary for your application.  Have you seen this bit get cleared under different circumstances?  I may need to do a few experiments if you have seen any strange behavior with this register.

I hope this helps,
Steven T.

[stifen]

Hi, We meet the silimiar problem now, we need add at least 100ms delay between any 2 SCPI commands, can you update the solution of this problem? thanks!

[Steven_T]

Hello,

Are you currently developing this instrument?  Can you share which chip you are using for the GPIB implementation?  Is it exactly the same problem with hold-offs?

Or is it that you have an instrument from another manufacturer and you notice that you must have a wait between commands?  This is actually an instrument bug, so you must fix it by alerting the manufacturer.

Thanks,

Steven T.