Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

PCI6251: How to Largely Reduce AO FIFO Size or Disable AO FIFO in AO HW Timed DMA Operation?

Solved!
Go to solution

I took aoex5 as the basis for AO0 hw-timed DMA signal generation and it works well in my setup. At the same time two signals that depend on AO0 are measured at AI0/AI1 by hw-timed-DMA mode at max. rate (500 kS/s), and this works also well.

 

My objective is to apply a mathematically scaled positive feedback from AI1 to AO0, and the easy way would be to change the values in the AO DMA channel and/or the AO rate on the fly, while reading out the latest values from the AI DMA channel. Processor speed and DMA space would be quite sufficient. The problem is that the DACs are charged by the way of a FIFO buffer which has a size of 8192 samples for my board, and therefore changing a value in the DMA buffer wouldn't have any effect on the DAC output.

 

I tried to simply disable the AO FIFO buffer by setting AO_FIFO_Enable to 0, but this disabled the whole AO signal generation. Is there a way to disable AO FIFO and let the DAC get its values directly from the DMA buffer? Or can I programmatically reduce the AO FIFO size to a minimum number of samples (2 to 16)? I could survive with a small latency induced by a small FIFO buffer, because I can compensate this by changing the AO rate on the fly as well.

 

I know, that I can use sw-timed operation to achieve the goal, but I assume that AO DMA operation without FIFO would give me a lower feedback latency.

 

Many thanks in advance for any helpful ideas.

 

Best regards

 

Rolf

 

Message Edited by rolfheinrich on 11-24-2009 08:52 AM
0 Kudos
Message 1 of 6
(9,283 Views)
Hi Rolf,

There are a few things that come to mind.

While the STC-II doesn't provide a way to program FIFO depth, you can change how it requests more data with tAO_FIFO_Mode in the register tAO_Mode_2. aoex5.cpp sets the STC-II to request more data via DMA when the FIFO is no longer full, but you can run closer to the metal by choosing a different mode from the tAO_FIFO_Mode enum in tAO_Mode_2.

You may also want to use a smaller AO DMA buffer. aoex5.cpp's dmaSizeInBytes variable also programs the MITE's DMA channel transfer count register (via tDMAChannel.cpp's tDMAChannel::_configure()). With a smaller buffer, you won't be filling the FIFO as deeply as with a larger buffer each time the chip requests more data, giving you fewer samples waiting in hardware.

Alternatively, with a custom interrupt handler, you could use tAO_FIFO_Data to load data directly into STC-II AO FIFO.
Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 2 of 6
(9,277 Views)

Hello Joe!

 

Thank you very much for your reply.

 

I will do some tests for comparing the behaviour of feeding back AI into AO by using a very small DMA buffer in kAO_FIFO_ModeLess_Than_Half_Full or kAO_FIFO_Empty mode with that of directly writing single values to the DAC in a sw-controlled loop.

 

Many thanks again, and best regards

 

Rolf

 

Message Edited by rolfheinrich on 11-25-2009 07:45 AM
0 Kudos
Message 3 of 6
(9,263 Views)
Excellent! I wasn't sure if you had tried those approaches already. Would you mind posting a quick summary of the behavior you observe when you have time? I'm sure others in the forum would like to learn from your experiments.
Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 4 of 6
(9,258 Views)
Solution
Accepted by topic author rolfheinrich

Hello Joe!

 

I decided to start my experiments with sw-timed AO0 signal generation.

 

For the test purpose I set AI_Bypass_Cal_Sel_Pos to 7 and AO_Bypass_AO_Cal_Sel to 0, so that the generated signal is directly available on AI0. AI was programmed at the max. dual channel rate (500 kS/s) into a linear DMA buffer of 128 MB. For AO I programmed a triangle (ramp-up/down) of a span of 2 V that is represented by 12975 AO samples.

 

A tight software loop added a scaled average of the last 4 AI readings found in the DMA buffer to the AO value to be output next, and once the LSB of the raw AO sample changes, it is written to the DAC by board->DAC_Direct_Data[0].writeRegister(Uc).

 

I ran tests with various voltage scan rates from 0.1 up to 250 V/s. The AO sample rate at 250 V/s was 1.6 MS/s. The deviation of the curve at the highest rate to the one of the lowest rate was only 0.1 %.

 

Attached to this message you will find a diagram showing the magnification of the curves around the peak of the triangle. The green curves were taken at 100 and 250 V/s. The red to yellow ones at 0.1, 1, and 10 V/s. There is very small phase shift of 0.1 % at very hight scan rates perhaps because of feedback latency.

 

Honestly 1.6 MS/s in sw-timed AO mode including the feedback algorithm exceeds by far any expectations, and I have to admit, that I am perfectly happy with this results. Sorry, Joe, but with that, I lost the inspiration to try-out your suggestions, reducing the AO DMA buffer size and changing the AO FIFO mode. Anyway, many thanks for your replies.

 

Best regards

 

Rolf 

 

Message Edited by rolfheinrich on 11-26-2009 02:58 PM
0 Kudos
Message 5 of 6
(9,235 Views)
Hi Rolf,

Thanks for the update 🙂 I'm also surprised you were able to push software-timed AO to 1.6 MS/s, and I'm glad to hear you've got a working driver.
Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 6 of 6
(9,194 Views)