Multiple ADC reads, DAC output with K60 TWR

[markdoxbeck]

What would be the best way to perform the following tasks simultaneously

1) Collect ADC data on ADC0 Ch1 and ADC1 Ch2 at 210KHz
2) Outputing a signal on DAC0 at 21KHz
3) Collect ADC data on ADC3 Ch1 and Ch2 at 2.1KHz

I am using the K60 Tower system, and must use CW, MQX 4.0 with the Freescale compiler. This is my first Freescale program.

[markdoxbeck]

Sorry I wasn't very clear initially, to be more specific, I am sending out a signal on the DAC, which will be filtered by some external components. That signal is then being fed back into the processor (ADC0). The filtered signal is also sent to a sensor, whose response is being read by ADC1.

I finally got this to work. It took awhile to figure out that the PDB does not trigger the DAC like it does the ADCs.

I set up the PDB with Prescalar=1, Mult=1 and  MOD=284 to give me my base frequency of 211,267 Hz.

ADC's PreTrigger values are PDB0_CH0DLY0 = 40, PDB0_CH1DLY0=50. Again I'll note that if these 2 values are too close the 1st value read is incorrect. All subsequent values appear to be fine.

The DAC's PDB "Interval" is set to 284. The DAC is using a normal buffer that has 10 values.

DMA is being used to store the ADC results to ram.

I've been adjusting the ADCs sample timing and Hardware Average values to find the optimal settings. However the results are not what I had anticipated. To test this out I am reading DAC0 back into ADC0 on AD23, and ADC1 is connected to the K60's POT on AD20. I have both ADCs set for LongSampleTime ADLSMP=1, and High-Speed Configuration ADHSC=1. As I change the ADLSTS (Long Sample Time Select) from 2 extra ADCK cycles to 20 ADCK cycles, the standard deviation of the measured values actually increases. I am measuring 100 ADC values, and have run the test 3 times. The POTS measured values (raw data) have a STD of 20 at 2 extra ADCK's and it raises to 120 at 20 ADCKs, with hardware averaging off. I would have thought the opposite would have happened. And with the system using 4 Hardware averages, the STD is consistently 180, no matter how many extra ADCKs are use. (Yes I do calibrate the ADCs at the start of each test.)

I've been looking for information on the PDB Stall / ADC Overflow issue but have not found anything that resolved the issue. If you could you provide me with a link? I'm curious to know what these issues are and how to recover from them.

The last thing I still need to do is to stop the data acquisition after 100 data points have been read into each ADC. My plan is to use the DACs Buffer Read Pointer Top Flag Interrupt and have the ISR disable the PDB after a count of 10.

Does that sound reasonable?

Thanks

[mjbcswitzerland]

Mark

I know of no cure for the PDB stall on ADC overrun - from my experience, and not seeing anyone else solve it, I have put it down to a non-published errata.

Either the overrun needs to be avoided (eg. using DMA with no critical interrupts etc.) or the PDB needs to be fully re-initialsied afterward so that it can start operation again (with potential loss of base timing).

Regards

Mark

[markdoxbeck]

First, thank you both for replying so quickly and with some good suggestions.

I have looked at the uTasker pages, but without seeing how the various options are actually utilized I have not been able to make much use of it.

Jitter is a major concern. The system will not be running the ADC/DAC continuously. It will only be collecting about 100 data points from the 2 ADC channels while the DAC outputs the signal ( 10 data points). It will be doing this at rate up to 100 Hz. I would like to avoid interrupts if possible, and make this as automated as possible.

So any suggestions would be helpful.

In my latest test, I have the PDB triggering both ADC channels at 210KHz. They both have DMA enabled, and I collect 100 data points from each ADC module in separate arrays. Unfortunately the first data point of the ADC1 array contains a value that looks like the data from ADC0 (the data from ADC1 should be about 18000, and the data from ADC0 should be about 14000). All the rest of the data in the ADC1 array is good (18000), and all the data in ADC0 is good. (14000). I am unsure what is going on here.

[mjbcswitzerland]

Mark

The ADC document is a concept document - you would need to look at the code to see the full details and options.

Basically I think that you are on the right track because the PDB is the usual ADC triggering method, whereby two channels of a single ADC can be used if needed. Beware that any ADC overflow will cause the PDB to stall and it is necessary to re-initialse it to get it to start working again (contrary to user manual details) - I think that there are at least two threads dscussing this.

To avoid jitter I would sample the ADC to a larger buffer (not just 100 samples) so that it can "free-run" and use the half-buffer interrupt to signal when each 100 sample block is ready (along with futher samples that you are not actually interested in) the interrupt is not critical since it just gives the next level a heads-up that the data can be treated (at ones convenience).

If you have a second DAC buffer also free running with a half-buffer delay (could be less if synchronised accordingly) you have plenty of time to do any handling of the input samples and prepare them in the output buffer so that there is also no DAC jitter. As long as the input and output clocks are synchronised (eg. both generated from the bus clock) there will be neither jitter nor drift.

This is the principle of the "delay line" reference in the document that I pointed to (see especially figure 3 which shows the half-buffer ping-pong interrupt process). Basically the delay wins a bit of processing time and allows free-running with zero jitter and thus is the basis of most such operation and can be used in most such applications (rather than a pure delay line the signal can be filtered or saved to storage medium etc. etc. but the firmware framework is basically always the same).

I also asked whether your system has stringent delay requirements; for example if you cannot delay ADC->DAC at all (which I don't expect is the case because you are doing frequency adaptation as well) it gets a bit tougher and at some point the processor will no longer be adequate and an FPGA will be needed (since any processing delay would already cause failure with respect to the input->output delay, even if there were no jitter....).

Regards

Mark

[egoodii]

If it were ME, I would set the 210KHz accumulation to be triggered by a PIT and accumulated '10 at a time' by DMA, and on that DMA-block-complete interrupt (every 47.6us) do your DAC0 functions, and on every 10th one of THOSE run your slow-data-sampling.

But of course there are many factors to consider.  What you can 'overlap' in your interrupt routine depends on how long (samples and averages thereon) each manual ADC-sample takes, and what math or other data-handling functions you can do in the meantime to the accumulated-10-samples and DAC-output generation.

You will also need to carefully consider the 'jitter tolerance' for the slower DAC and ADC sample rates.  If they can't tolerate the vagaries of your interrupt response time, they will have to be triggered by more dedicated hardware.

[mjbcswitzerland]

Hi

Take a look at
http://www.utasker.com/docs/uTasker/uTaskerADC.pdf
for some extra details of HW sampling and DMA.

You didn't mention whether there can be a delay between the sampling and output - if there can be, a larger collection buffer can be used and processing performed easier 'off-line'.

There is a delay line binary at the following link for the K60 tower which demonstrates general DMA input/output with intermediate processing
http://www.utasker.com/SW_Demos.html
and the complete operation is included in the uTasker project (including simulation of the process).

If your project requirements specifies only MQX as OS you will need to see whether there is similar support included in their examples - if there isn't you may be able to
-port other reference examples
-learn and program the details, or
-see whether purchasing MQX support could help.

Regards

Mark
Kinetis for professionals: http://www.uTasker.com/kinetis.html