DMA Read and Write with DRQ signal

[Franck74]

Hi there,

I am writing a firmware to use the NI TNT4882 GPIB chip in one chip mode, with DMA. In order to get launched, I try to handle the *IDN? request from my PC running VISA interacive control.

The listen part works fine. The PC sends the "*IDN?\n" request, and the fifoB (8 bit mode) gets filled up, so the DRQ pin toggles accordingly.

I have set my host MCU to get interrupted on the DRQ pin, it reads the FIFOB until the Not Empty Fifo bit of the ISR3 register is cleared. my host MCU did receive the *IDN\n" request.

First question: if I set IMR0 to 0x80, and IMR1 & 2 to 0x00, the DRQ signal remains still. however if I set the REMC bit of IMR2 to 1, then the DRQ signal toggles properly... Is this a side effect or I am missing something?

Then, I poll (get interruption in a near future...) the TACS bit of the ADSR register to detect if the controller addresses me as a talker. If so, I clear the IN bit of the cfg register.

The DRQ pin toggles, so I (try to) fill the fifoB with my data, but it never gets sent to the controller.

Moreover, I have found little information on the way the DACK pin should be used.

Best regards

Franck

[Steven_T]

Hello,

The ESP-488 is an example source code package that demonstrates how to communicate with the TNT4882.  The examples show how to perform DMA and other operations in software.  There should not be any reason to require REMC interrupt to be enabled for the transfor to work correctly. 

Perhaps you are in a different chip mode than One-chip (NAT7210 mode) and you are writing REM instead of REMC?  Use the ESP-488 as a guide for performing DMA.

This datasheet should let you know a little more about how the DACK timing should work.

https://www.ni.com/docs/en-US/bundle/372014b/resource/372014b.pdf

Thanks,

Steven T.

[Franck74]

In fact, I did not send the STOP command at the end of the transfer to release the DRQ line in write mode

It works fine now ( as far as I can see )

Thanks for your support

Franck

[Franck74]

Hi NI crew,

thanks to your support I can write and read in one chip / DMA mode.

However, although I went through ESP488 example code and TNT488 datasheet and programmers guide, I still struggle on a couple of issues:

> If I use queries, so my PC app write to, then read from the embedded TNT488, it works fine.

> If I use several write in a raw, it gets stuck, and I get no DRQ assertion for the second write...

> I have just noticed a pretty annoying issue:

I use GPIB analyser on a PCI-GPIB+ card to validate the signal behaviour.

Also, I use two GPIB clients to test my embedded system: NI MAX and its NI-488-2 Communicator

My custom app based on visual C++ on top of ni488 API.

If I change the GPIB analyser settings and untick the "participate in acceptor handshake", then NI-488-2 Communicator is still able to query the TNT 4882;

However, My custom app gets stuck at the end of the write command...how in details the GPIB analyser participate in acceptor handshake that my app should do?

thanks for your ideas

Franck

[Steven_T]

Hello Franck,

If you are using an NI GPIB interface to test out your TNT4882 instrument, there are some behaviors you may not be expecting.  When you write two times in a row, the NI-488.2 driver will NOT readdress the bus by default.  It will simply remember the state it was in, realize the addressing is already correct, and attempt to send data.

If the instrument is addressed to read, it will read until it hits the EOI (last byte in the message).  However, it must continue to try reading until it is addressed to no longer read.  If this is too much work, there is a setting that can be configured in the NI-488.2 driver that will force the driver to always re-address.

ibconfig(ud, IbcREADDR, 1);

Can you tell if your instrument is continuing to attempt a read even after a successful message is sent?

Thanks,

Steven T.

[Franck74]

Hi Steven and NI support crew,

In fact, here is a more detailled behaviour of what I witness:

- I get the ADSC interrupt to update the GPIB read or write mode. Then I get a DRQ interrupt to either read or write to/from DMA, until EOI or until counters reach 0. Then there is an unexpected behaviour that stops the TNT4882 from reading / writin several requests/responses in a row:

- if I dont clear the ADSC interrupt flag, then the INTR signal remains low, and the DMA transfers occurs fine, but the next ADSC interrupt will not be noticed...

- if I clear the ADSC interrupt, the DMA transfer does not occur.

I fully understand that these 2 behaviours should not be related, but it is where Im stuck...

So, either I stop the TNT4882 after the first EOI, and It can be readdressed by a ADSC interrupt, but no way to receive several commands in a row, or I don t stop the TNT4882 to be able to receive several commands, but the INTR remains low and the TNT will miss the next ADSC interrupts...

I hope the issue is clear enough for you to have a clue...

Thanks for your support

Franck

[Franck74]

Hi again,

WHile I wait for any clue from your side, I try to compare my code with ESP488 example...

What is the meaning of:

char ptr_size *buf ???

This will not compile in C, as far as I know...

thanks again

Franck

[Franck74]

ok, I ve found the ptr_size define, so I undefined it, and it compiles...

test time now !

[Franck74]

Hi NI crew,

Thanks to your support and ESP488 example code, I ve managed to get things going....

Now I want to fasten Throughput up to 1MB/s, then 8MB/s in HS488 mode.

Although I ve had a close look at the ESP488 you provide, I still struggle on the DMA Write...

Unlike the Intel chip you have used to interface with the TNT4882, I use a more basic chip, where I probe the DRQ and drive the DACK through GPIO pins. (maybe there is the problem...)

> For DMA read, I do not need to assert the DACK pin to access the Fifo at full speed. I can see DRQ rising once the Fifo is not empty, so I just read the fifo as long as the Not Empty Fifo flag is true. I can achieve 1MB/s to do this.

> However, to do DMA Write, I do need to assert the DACK pin. therefore I cannot access any register but the FIFO from there (expected behaviour). I write to the FIFO, but I cannot check wether the FIFO is full or not, therefore some bytes are dropped during the Write process.

How can I make sure I do not attempt to write to a full FIFO once the DACK pin is asserted ?

Once this is sorted, I ll also switch to the HS488 mode...

looking forward hearing from you

Franck