Please pass this on to Steve M. He asked for an update on streaming 8 kbyte buffers.
Also, I have a few questions about the AFE API. Could you have a look at this attached pdf? I've also attached code that is in a working state. Thank you.
I didn't understand your reply (do you know if Steve M. saw this? ... his page says he hasn't logged in since February 5th).
Any thoughts regarding my questions?
Apologies, I misread the question and assumed all questions were for Steve. I tagged him in my last reply, so he should have seen it.
Q1: This does look incorrect, but any non-zero value should have the same effect as 1, since the if statement on line 3086 only checks for non-zero value.
Q2: You are correct, but the durations are specified in us (microseconds), whereas the calculation is in samples/s. So instead of 160k/178samples/s, we now have 160k/(178*10^6), which is equal to 1/1112.5. To get rid of the decimal below the line, we make it 2/2225.
Regarding your calculation of the number of samples. Do you have the IVS switch enabled (SHUNTREQD == 1)? If so, the ADC will not measure during this time, so DURIVS1 + DURIVS2 will be subtracted from the overall time.
Q3: If you are trying to run the AFE continuously, you will not be able to do so with the adi_AFE_RunSequence function as it is written. This is a basic API which was written to facilitate the one time execution of a sequence in a simple way. It is not an efficient function, but it does all the necessary setup before running the sequence and does some tidying up after the sequence, including disabling things such as the FIFOs and the DMA. For continuous running, you will need to keep these running after the sequence finishes. This API is no longer suitable for your needs, so you will have to write a function that does.
Q4: There is only one DMA on the ADuCM350. Different peripherals have dedicated channels, but it is the same DMA that operates on each peripheral, with the same limitations. The size limitation of the DMA is that it can transfer a maximum of 1024 samples (these can be 8, 16 or 32 bits, this must be specified in the descriptor) in a single transfer. The SPI transfer limitation is a limitation of the software, not the hardware. As to the differences between using basic vs ping-pong for the DMA, I'm not sure if ping-pong will allow you to fill such large buffers. With basic, you should just have to change the memory pointer after each transfer.
Would you be able to email Steve M. (I guess the tag didn't work, the tag link still says he hasn't logged in since Feb 5).
Thank you for some of the answers. In my original post, I attached some code that "works" where by "works", I mean that I run the example AFE code and when it finishes, it can send the data in the double buffer out the SPI. However, because eventually I want to run the AFE continuously, my next step is to send the buffer data to the SPI port from within the AFE-DMA-done interrupt handler's callback, RxDmaCB, but when I move the call to adi_SPI_MasterTransfer() from the main program to RxDmaCB (see attached screenshot), nothing goes out the SPI port. :-(
The original AmperometricMeasurement.c example sends the buffer data to the UART from within RxDmaCB, so I would think what I'm trying to do would be analogous.
Can you see any reason why it doesn't work?
I can't see any obvious problem, but it could be a timing issue. Remember that any code to be executed in a callback is executed in interrupt context. It is good practice to minimise the code that is executed in interrupt context. A common practice is to set a global flag (or post a semaphore in an RTOS use case) in the callback/ISR and process that flag in the main code body.
Oh, I figured out that problem ... it was the ordering of two functions that had to do with initializing the clocking system. I had tried to combine the two examples, SPItoFTDI.c with AmperometricMeasurement.c and each had different calls to functions that had to do with setting up various clocks. When I combined the two programs, it turns out that it was important to get those two function calls in the correct order. I'm on to other problems now ... I can get the SPI to send out the first 1024 halfword transfer from the AFE, but none after that. I will keep pounding.
Retrieving data ...