A while back I followed an example on how to set the DMA unit up to work with a SAR. What I am trying to do is to specify, with a constant, an N number of samples to capture from the SAR. When it is done capturing the samples, an interrupt fires, telling the main routine to write the results to the terminal. It is writing incorrect results to the terminal. I verified that my analog front end is working with a loop. It works flawlessly. The problem has something to do with the DMA configuration.
Can someone assist me in tracking it down. The project is attached.
current_data_flag must be declared as volatile because it is changed in an interrupt handler.
The TdSetConfiguration specifies a transfer count of 4 times NO_OF_SAMPLES, but your target array is only half of that size.
I changed the flag to volatile as well as the CyDmaTdSetConfiguration to 2 * NO_OF_SAMPLES.
It still is printing incorrect results. Something else is happening as well.
I took the liberty to change some lines in your project.
Your main issue will be that you generate 100,000 samples/s which you cannot send over the uart wire with that speed. While sending, new values get generated...
There was an error within your Global.h -file where you included more than once the same declarations. This is usually done using the extern keyword. As a rule of thumb: Only declarations in a .h-file, no definitions/instantiations of variables or procedures.
I changed the interrupt handling, so that you can keep the handler within your own files and not within a generated file. Have a look into the "System Reference Guide" under Creator -> Help, search for "CY_ISR"
This problem is being stubborn. Your updated firmware is definately better C programming, but the DAC is still displaying the same old garbage when I run it. I fooled around with the array size constant and making it big (above 2048) changes the nature of the garbage. I think it is something to do with the configuration of that DMA. Either that or I maxed out the memory.
I have the differential inputs shorted at present. This should yield 0 volts. WIthout DMA usage, it does. With it, it spits out the incorrect results. Instead it bounces between 1.01 and 1.05 volts, clearly incorrect.
Bob already told you: you are limited by time of sending data (UART)
You'll have to wait until the transmission in UART before starting a new measurement.
Check out my project, I strongly reduced data rate.
I hope you have already done a search on the forum:
Shorting the +- inputs together does not mean that you read a zero as input, compare your setting to the explanation on page 6 of the SAR-datasheet. so the values 0x07ff are not unusual.
I am confused. Reading straight off the converter outputs the proper results (near zeros) when the input is shorted. When the input is not shorted, it displays the proper differential reading (or does it?). Your description and Page 6 somehow does not make it seem proper. The DMA and direct reads are giving different results bottom line. I would think they would square up.
Weird. What is really happening? Is the direct read somehow reading single ended?
I just went through the sources and found out that there IS a difference when reading via GetResult16() or using DMA. GetResult16() subtracts a variable named "_shift" which aligns the measured result to 2's complement. This cannot be done in DMA (no operations possible) and so the difference in the values. Look at page 17 of the SAR's datasheet.
Ah, that explains it.
Right now I am just subtracting the average of a bunch of values that appear on UART with the input shorted from the differential reading.
Is this the way it is usually done?
Not necessarily this way. The variable CURRENT_SENSE_shift is set during the initialization and has the value of 0x0800 for your configuration, but you may check for yourself.