I have been using the VC707 with a FMCOMMS3 board attached. I am trying to determine the suitability of the AD9361 for our target application. Currently I am trying to evaluate the ability of the device to create a continuous frequency sweep (beginning at f = 200MHz and finishing at f = 300MHz). I am using the No-OS files contained here : GitHub - analogdevicesinc/no-OS: Software drivers for systems without OS
I would just like to confirm some details about operation:
1. In the Config.h file I have uncommented DAC_DMA_EXAMPLE, so the output should be coming from sine_lut(). I have also read in past discussions that I can replace sine_lut() with my own values or even a new LUT with a different length. I would like to know if it is OK for me to use a LUT I have defined called chirp_lut(). This LUT has a length of 32768 and contains datapoints for a twos complement chirp function. My goal is to use this LUT as a 'sweep' function.
2. If I want to receive the data (i.e. I have transmitted and am going to receive the continuous data), my understanding is that I should modify adc_core.c to implement a 'double buffer scheme' for the DMA where the first buffer fills with data and while the second buffer is filling, the data from the first buffer is processed and prepared again for capture. I am very much a hardware engineer and do not properly understand how to write the code to do this, I believe it shouldn't be too difficult, I just do not know where to start - Could you please offer some advice on this?
3. After using the SDK to run the configuration I have set up, do you have any advice for how I can build in 'triggers' for commencing a sweep or commencing another function? Would this require a modification of the Main.c where I would create some form of input handlers? Again, I am not a software engineer and these solutions are not obvious to me.
If it helps, my overall goal is to attach a simple LC resonator circuit, transmit a sweep function and plot the reflected spectra which will be captured. The goal is to determine the resonant frequency.
Any advice would be greatly appreciated!
Support for continuous cyclic capture using interrupts for the MicroBlaze environment has been added. It has not been merged with master yet, but code is available. Will be merged soon.
I've finally gotten around to looking at cyclic capture using interrupts and I am having some difficulty understanding how to use the code.
Should I expect that calling adc_capture() from main.c will execute a continuous cyclic capture? if so, is it then safe to assume that I could create a loop which continuously prints the data to the console?
From outside, the adc_capture() function works the same even if the interrupts approach is used. It is only an example of how the desired amount of data can be captured through multiple transfers versus only one transfer.
The function should be updated according to your application's requirements.
Thanks for the response.
Sorry, but I am not sure I completely understand. There are two cases:
1. Using standard single capture, no interrupts - In this case, I call the adc_capture function with a desired capture length (for example, 32768). 32768 samples of data are captured and stored in 32768 DMA locations, starting at dma_start_address. This works well and is fine.
2. Using Interrupts for extended capture - In this case, I call the adc_capture function with a desired capture length that is larger than ADC_DMA_TRANSFER_SIZE (For example, lets set ADC_DMA_TRANSFER_SIZE to 32768 and I call adc_capture with a length of 65536. ) Should I expect to see 65536 samples of data, stored in 65536 DMA locations, starting at dma_start_address?
If I call adc_capture() while the interrupts method is enabled, the device becomes unresponsive even if I capture only 10 samples of data, it stops working. I've never used interrupts and interrupt controllers before so I have a very limited understanding of how to debug this.
Any advice would be much appreciated!
The answer for the second question is yes. Note that the length of one transfer should be multiple of the maximum between DMA_DATA_WIDTH_SRC and DMA_DATA_WIDTH_DEST. In our FMCOMMS2-3 design, DMA_DATA_WIDTH is set to 64.
Have a look here as well: https://ez.analog.com/linux-device-drivers/microcontroller-no-os-drivers/f/q-a/107338/adc_dma-with-ad9361/318362#318362
OK, that makes sense.
Is it possible to stream an 'endless capture'? For instance, if I want to start capturing data with a command and be able to leave it for an arbitrary length of time before I send a trigger to stop capturing, is this achievable? I had thought about nesting the adc_capture() call in a while loop, but I want it to be gapless in the capture.
Keeping calling adc_capture() in a loop would not give give you a continuous capture. You should use adc_capture() as an example for your application.
The original function waits while(dma_start_address < (start_address + length + ADC_DMA_TRANSFER_SIZE)) - update this condition according to your requirements.