653X/AT-DIO-32HS Burst Protocol ACK+REQ lines

[Raminta]

I am programmaing the AT-DIO-32HS card with the burst protocol mode. I have it configured so that the PCLK is reversed (data is output from the card at a rate that I specify). I have an external peripheral that will assert the REQ line when ready for data.

My questions are:

#1) from the board's point of view, does it matter the order in which the REQ and ACK lines are asserted, or must the REQ line be asserted first, followed by the ACK line, and then the data follows?  Suppose the ACK line is asserted before the REQ line....would data still be clocked out ?

#2)  if during data transfer either of the ACK or REQ lines become invalid, does the PCLCK still 'run', but data not made available on the data lines ?

Thanks so much !

[jcarbonell]

---

@Raminta wrote:

I am programmaing the AT-DIO-32HS card with the burst protocol mode. I have it configured so that the PCLK is reversed (data is output from the card at a rate that I specify). I have an external peripheral that will assert the REQ line when ready for data.

My questions are:

#1) from the board's point of view, does it matter the order in which the REQ and ACK lines are asserted, or must the REQ line be asserted first, followed by the ACK line, and then the data follows?  Suppose the ACK line is asserted before the REQ line....would data still be clocked out ?

#2)  if during data transfer either of the ACK or REQ lines become invalid, does the PCLCK still 'run', but data not made available on the data lines ?

Thanks so much !

---

For (1), there is no ordering with respect to REQ and ACK.  On every rising edge of the PCLK signal, the DIO-32-HS will sample REQ.  If the DIO-32-HS is asserting ACK on this edge of PCLK, then the DIO-32-HS considers the sample to have been transferred.  If you need some kind of ordering between REQ and ACK you should consider using the Asynchronous Handshake protocols.

For (2), as long as the DIO-32-HS can accept data (if it is doing input) or produce data (if it is doing output), the ACK signal will asserted.  It is never invalid.

Hope this helps,

Jeff

[Raminta]

ok, well I seem to be running into a few issues with trying to get the burst protocol to work for me. Maybe I could tell you how I am configuring the card first ? This way I know that the problem is not a configuration/setup issue.  Thanks so much!

[Raminta]

ALSO, I want to know if the following is correct:

suppose I want to *output* 100 4-byte values at one 'shot' via burst protocol.

- Lets also assume I have configured the card correctly.

-Isn't it correct then that when I execute the statement in my code, DIG_BLOCK_OUT(...), that the card will assert the ACK line  immediately ?

- And then next, when the REQ line is asserted (if it has not already been asserted), it will begin 'outputting' each of the 4-byte values on the rising edge of the PCLK that I am 'outputting' from the card to the peripheral ? 

- Then, only when all 100 values have been output, the card will de-assert the ACK line ?

I think I might need clarification on EXACTLY when (with respect to my code) the ACK line is asserted and exactly when it is de-asserted.

[Luke_G]

Hi Raminta,

I recommend that you look at the example DOsingleBufBurstHandshake653x.PRJ which installs with traditional DAQ driver to C:\Program Files\National Instruments\CVI81\samples\daq\do. 

In response to your previous post, DIG_BLOCK_OUT asserts ACK immediately.  The ACK line will only be de-asserted after the output of the 100 values. Further, it is true that when the output corresponding to the PCLK will occur when the REQ line is asserted.  This may be more clear if you look at the timing diagrams (such as figure 3-8) in the NI 653X User Manual for Traditional NI-DAQ.

Let us know if you have further questions.