Simple example, DMA with two ADC inputs

Status
Not open for further replies.
Is there a simple (iminal) example of DMA with two analog inputs?
Thank you

I quote from other thread
i was unable to construct my system from the available documentation. i want to output a short waveform while simultaneously reading two channels of analog input, at a clock rate as fast as the simple can run.

what do you wanted to do with input and where does the output come from?

Even if you will develop your system step by step, it is very important to know the overall picture of what you wanted to achieve, in order to help you efficiently.
 
Is there a simple (iminal) example of DMA with two analog inputs?
Thank you

You want to have a simple example:
here comes one
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioInputAnalogStereo   adcs1(A2,A3);          //xy=331,263.2          //<<<< change Analog ports if needed
AudioOutputUSB           usb1;           //xy=501,263.2
AudioInputUSB            usb2;           //xy=629.4,261.8
AudioOutputAnalog        dac1;           //xy=794.2,255.2
AudioConnection          patchCord1(adcs1, 0, usb1, 0);
AudioConnection          patchCord2(adcs1, 1, usb1, 1);
AudioConnection          patchCord3(usb2, 0, dac1, 0);
// GUItool: end automatically generated code


void setup() {
  // put your setup code here, to run once:
  AudioMemory (16);

}

void loop() {
  // put your main code here, to run repeatedly:

}
compile with Serial + MIDI + Audio

Using a USB headset on PC and connecting the DAC pin with A2 and A3 you should hear your own voice.
(I'm in the field and have no means to test it)

In other words, forget initially about DMA, Audio Library does it for you. Once you have a working example you always can dig into the code and learn how it is done and the examples discussed on this forum how to modify the functionality.
 
Not sure if that meets the requirements of the OP since he wanted "at a clock rate as fast as the simple can run" while the audio library limits everything to the poor sample rate of 44.1kS/s. With thoughtfully hand crafted code, one should be able to obtain up to 8 times higher rates.
 
Not sure if that meets the requirements of the OP since he wanted "at a clock rate as fast as the simple can run" while the audio library limits everything to the poor sample rate of 44.1kS/s. With thoughtfully hand crafted code, one should be able to obtain up to 8 times higher rates.

Sure, and I could easily augment the code to do that, as it is in the code I referred to in the other thread.
But the point is, to use the audio library as starting point (concerning DMA , stream processing etc.)
Once we know what he wants to do with the ADC data and where the DAC data came from, one could giver better advice.
Nevertheless, I find it amazing how little user code you need to get a functioning audio system.
 
Nevertheless, I find it amazing how little user code you need to get a functioning audio system.

That is definitively amazing! But there is also an inherent danger: Some people will tend to think that there is no more need for years long study programming and cpu architecture at all if everything can found for free on the internet and if even complex software can be "written" with a little copy and paste and a few mouse clicks. Personally, I rather tend to give specific hints and pointers but never ready to use code, just to reveal the people's scientific curiosity, so that they make the effort to learn and understand everything by themselves which opens at long term a wider horizon to them. Following that pedagogic approach, a library is not code to be used, but a proof of concept and a tutorial or inspiration on how things can be done. The coder should remain in control of every single bit, though, instead of assembling black boxes.
 
Hi Theremingenieur,

I would agree with many of the things you said, but this one:

The coder should remain in control of every single bit, though, instead of assembling black boxes.

I am not a software scientist, so I do not agree. And, when I started with Teensy, I did a lot of assembling black boxes and suddenly I had a working software radio :). But you are right, I try to look into the black boxes and understand them. But I am still very far from (and will probably never ever reach that point) "controlling of every single bit" of my own Software defined radio code.

Have fun with the Teensy,

Frank DD4WH
 
I'd like to chime in here.

I come to this with about 40 years experience in real time and systems. I've deployed code on platforms from DSPS to racks and with data rates at the physical limits of the underlying hardware. Most of what I do is for experiments in physical sciences. The commercial systems that I've built include real time holographic imaging systems, sonar devices, video distribution for flight training, and components for a nation-wide communications network.

The trends towards drag-and-drop, c++, and by some DSP vendors, towards microsoft style programming environments, is for people who have limited experience working with hardware and don't really understand what it is about. You might be able to do something like that if you have a narrow range of uses and your application does not place much demand on the platform.

Put another way, when you hide what is going on, in something like an elaborate c++ class library, or a drag and drop interface, you may be at odds with the reasons you chose to use a particular hardware platform. Often those reasons include close specs in bandwidth, memory and power.

And further, to meet specs of that sort, you almost always need to have some familiarity with theoretical concepts in computing and hardware architecture, understand the actual hardware, and needless to say, you need to know what your program is actually doing. And so, c++ and drag and drop interfaces, might not be a good match to that purpose.
 
And so, c++ and drag and drop interfaces, might not be a good match to that purpose.
You asked for a simple example.

I hope you understand that having a complete functioning (I hope) example, with a the source code easily available, can be the best tutorial to understand how Teensy can work. If you do not like the way it is working, simply change it, or build on it. Progress is standing on the shoulders of giants (i.e. Paul and other brilliant contributors of this forum).

If you have worked with DMA before, the way the processor does it becomes easy to understand, in particular if you check Paul's code, or why not the code of other peoples code discussed on this forum.

Obviously this forum works best if there are specific technical questions. General questions allow too much interpretation and tend to generate arbitrary answers.
 
I worked it out, from the hardware documents. Its about 10 lines and runs two adc channels at 330 kHz, with a dac write in the loop, and all with less than 0.1% jitter. That should tighten-up with two more lines of code. Once I was ready, it took about half an hour to code and debug it.

P/S I did peak at source code, in the arduino and teensy tree, generally using grep. It was helpful in clarifying some things. One of the open issues is to understand whether or why the second ADC seems to access only a few of the low number inputs. Its workable using A2 and A3 for the dual channel function, but it might be nice to have some more flexibility.
 
Last edited:
Status
Not open for further replies.
Back
Top