This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi all,
Looking for a working example that successfully perform ADC and then data acquisition on multiple
channels (2 at a time) given the abovementioned system. This is not our first inquiry on this problem
and already have chatted with our friends there Devin Cottier and Joseph Casuga.We really appreciate
their suggestions and thoughts on this. Both Devin and Joseph have suggested that we look into the
two examples: adc_soc_epwm and adc_soc_continuous, both available at
.../device_support/f2837xd/examples/cpu1.
To exactly quote one of really useful Joseph's message from few months ago:
-- "There are several examples too in C2000Ware where you can see how concurrency for ADC conversions work.
One example is suggest for you to look at is "adc_soc_epwm". In this example, it shows you how to configure the
epwm to trigger ADC conversions. Each EPWM has 2 start of conversion (SOC) triggers. You can use these SOC
signals from the epwm to trigger different channels from different ADC modules of the TMS320F28379D for true
concurrent conversion where 2 channels are converting at the same time. In the "adc_soc_epwm" example, only
one ADC module is shown. You can just duplicate the ADC setup to configure the other ADC module you want to
use for concurrent conversion (note that the TMS320F28379D has 4 ADC modules). In this context, 2 ADC modules
have to be running exactly at the same time (same ADCCLK rate and ACQPS for the ADCs that are active) and
conversion is triggered by the same epwm SOC.
There is also another mode where you can convert on different channels on the same ADC but conversion has to
follow the SOC order (e.g. - SOC0 converts first before SOC1 and SOC2 has to convert before SOC1....and so forth),
but this is not concurrent and rather sequential. A good example to look at that illustrates how this is carried out
is "adc_soc_continuous". " --
Also wonderful feedback and suggestions from Devin and to quote one of his messages:
-- "The next step you need to take is to thoroughly read the ADC chapter of the TRM and then run
the workshop lab. Look at each line in the code and reference against the bit and functional descriptions
in the TRM until you understand why the lab works. Repeat for the epwm example.
Once you understand both examples, use the hints from my previous post to extend one example
or the other to sample multiple ADCs in parallel. Note that there is also a mini code-snippet example
in the TRM about sampling multiple channels simultaneously that you can refer to."
My colleagues and I have followed closely these suggestions in regard to adc_soc_epwm example
as well as one of the examples (Lab2) from the following multi-day workshop: processors.wiki.ti.com/.../C2000_Multi-Day_Workshop
Lab2: Analog-to-Digital Converter
None of our tries have been successful so far and only detected & achieved data acquisition
through a single channel. The Lab2 example works nicely using sinusoidal data but only
for a single channel. We modified the example's code in order to handle multiple channels
but nothing were detected for more than a single channel.
** I think we are either totally misunderstanding the hardware or quite likely have missed
specifying some very key components in our code. If someone has an example regardless
of how simple or complex it is and willing to share it with us just to try out we would appreciate it.
Any type of ADC example that would do concurrent data acquisition over multiple channels would be
fine. The objective here is to see how such a setup is done. Once we understand the framework
we will continue trying out our understanding for other examples as we continue using the hardware.
The key point here is just understanding not copying someone else's work.
The hardware is relatively new (roughly over a year or so) to all of us involved and plan to use it
extensively over the coming months in conjunction with other processors for a number of radar
and sensing projects we currently have in the pipeline. Therefore it is crucial that we thoroughly
understand it via running different examples over cpu1 and cpu2 exploiting and utilizing all of
of the channels in different ways (sequential, concurrent, parallel, etc.) in order to harness the true
power of the system.
Many thanks,
Saleh, Joel, Glen and other colleagues.
Hi Saleh,
Fundamentally:
Note that A channels (e.g. A0, A1, A2, etc.) can only be sampled on ADCA, B channels only on ADCB, etc.
It may also be useful for your understanding and to verify channel hook-up to build an example where you sample multiple channels, but sequentially. e.g. setup ADCA SOC0, SOC1, and SOC2 to use the same trigger, any valid ACQPS settings, and different channels. After the trigger occurs and the results are available, result of channel selected by SOC0 will be in ADCRESULT0 of ADCA, result of channel selected by SOC1 will be in ADCRESULT1 of ADCA, and result of channel selected by SOC2 will be in ADCRESULT2 of ADCA
Hi Saleh,
No worries; you can develop on any schedule that works for you. (We may close the thread if it is idle for a week or two; if so feel free to reply to the thread to re-open it, or use the 'ask a related question' button to continue the discussion)
Once you have decided on the configurations you want to use, I find that a good sanity check/debug strategy is to run through all the initializations (or maybe even into the active portion of the code) and then:
If the actual configurations match what was intended to be written, but the system still doesn't work, then you need to go refine your understanding. This avoids the very confusing situation where a missing 'EALLOW' or some vestigial code prevents or overwrites your intended configurations, resulting in bad operation even if your intended configurations are otherwise correct.
If you stop the code in the active portion, you can also use this method to go examine the ADC or ePWM module state (e.g. ADC RR pointer or current ePWM count), which can be another useful debug or sanity check.