Help with ADC speed

cdmiller

Member
I'm porting some stuff currently reading an analog accelerometer and gyro using arduino libs on an avr 328P. The bulk of time in my processing loop is calls to analogRead.

I timed a single call of analogRead(A0) on 3 boards, (nothing attached to pin) here are the results:

bare bones board (328p) 116us
chipkit uno32 6us
teensy 3.0 398us

Any examples for using the ADC options available on the arm m4 to do a faster analogRead would be much appreciated. Of course adding the extra functionality to the teensy3.0 analog.c library would be great.
 
I assume the Teensy 3 is slow since it always uses the highest resolution ADC mode (16 bits). I'm sure it would be faster if you drop the ADC mode back to 10 or 12 bits (instead of just truncating the 16 bit value as the T3 lib currently does), but you need direct register config do that. At some point I'll try to do that, assuming Paul doesn't make it easy for me first :)
 
Thanks in advance.

Looks like to simulate the arduino ADC I need to use the single ended 10 bit mode. Just have to figure out how to set the ADCx_CFG1 bits, patch the analog.c library to add the 8, 10, and 12 bit modes, then see if the hardware average is in use and monkey with that. Hopefully this weekend I'll get a chance mess with it. I'm always bit over my head with the embedded stuff but can tread water with the best.
 
OK, I have set the following in my setup():

analogReadRes(16); // prevents default 6 bit right shift in analog.c
ADC0_CFG1 = 0b01101000;
ADC0_CFG2 = 0b00010101;
ADC0_SC3 = 0b00000000;

And now timing a single analogRead on the teensy3 is 7us. Assuming I did it right it's set for the "typical conversion time configuration" from 31.4.4.6.1 in the user manual, which claims a 3.75us conversion time. I'm doing a call to analogRead(A0) and the time calculation (elapsed = micros() - mtimer;).

Setting ADC0_SC3 = 0b00000101 reports 33us, that should be for 8 samples using the hardware averager, corresponding to 3us for the call to analogRead and the time calculation.

Sweet!

Now to take some actual readings.

How to expose this within analog.c? Post ugly patches here?
 
Last edited:
One thing to note: the ADC on this chip has a calibration procedure. This happens in Paul's analog.c early in startup, before setup()/main() is called. In my very limited testing, it seems pretty important to redo this calibration procedure after changing any of the ADC settings. This seems to make the difference between getting real values or a random number generator.

Best,

-c
 
One thing to note: the ADC on this chip has a calibration procedure. This happens in Paul's analog.c early in startup, before setup()/main() is called. In my very limited testing, it seems pretty important to redo this calibration procedure after changing any of the ADC settings. This seems to make the difference between getting real values or a random number generator.

I did some tests. I'm happy to see this is waaaaaay faster than the defaults. As noted, there seems to be some calibration necessary though. It isn't random, but the range is severely limited. With these settings, the output were as if the result were shifted right by 6 bits, so an effective divide by 64. It sounds like the input signal simply hasn't had time to rise sufficiently. So in the current state, I can get Arduino levels of resolution by simply setting the resolution to 16 bits and reading the output directly as if it were a 10-bit sample. For my current project, this is certainly an improvement, since I'm migrating from an Arduino Uno and this will give me 8 more channels than I had, at 22 times the sampling speed. I'm currently getting 6000 samples per 5 seconds for each of 6 analog inputs, giving roughly 20 samples per 60Hz AC cycle. I'd like to bring that up, and with this device I can bring it up to 192 samples per 60Hz cycle, giving better RMS calculations.

Here's one of the projects for which I plan to use it: http://tricolour.net/smart_panel.html

I'll have a look at the boot analog calibration code when I get a chance.

Where did you get those register names and background information (to help save me the time to find it...)?

Thanks for all the information shared so far!

 
You can find all the magic register names and numbers in the K20 Sub-Family Reference Manual,

http://cache.freescale.com/files/32bit/doc/ref_manual/K20P48M50SF0RM.pdf

It's a 1200 page pdf so don't get impatient downloading it or trying to read it.

I've turbocharged my ADC conversion by simply adding the following to setup():

analogRead(0); // allow calibration to complete
analogReadRes(16); // use all sixteen bits
ADC0_SC3 = 0; // no averaging

That averages 15 usec per conversion, and I expect the calibration should still be good since the basic sampling and conversion parameters are unchanged.

Note if you change the values in ADC0_SC3 before the initial calibration completes, then the calibration fails, and the conversion gain registers won't get set properly, and you may well get random values.
 
(Something odd going on when trying to reply to this thread... hangs indefinitely. I was able to reply with quote previously without problem. My password also got reset surprisingly.)

I had already downloaded that 1200 page document, but hadn't started digging to find the information needed. I've found some of it on page 597.
So far, the tests I've done with recri's ADC0_SC3 setting alone is giving the expected results with about 10 times faster than the Arduino defaults. This completely solves my problem for DC signals sampled every 5 seconds. We'll see if it jumps all over the place with RMS AC readings.
 
(Something odd going on when trying to reply to this thread... hangs indefinitely. I was able to reply with quote previously without problem. My password also got reset surprisingly.)

I had already downloaded that 1200 page document, but hadn't started digging to find the information needed. I've found some of it on page 597.
So far, the tests I've done with recri's ADC0_SC3 setting alone is giving the expected results with about 10 times faster than the Arduino defaults(30 times faster than my first teensy tests). This completely solves my problem for DC signals sampled every 5 seconds. We'll see if it jumps all over the place with RMS AC readings.
 
Ok, "Edit Post", "Reply", "Reply With Quote" all seem to be broken since I first used the latter yesterday afternoon and I can't delete the duplicate post. Fortunately at least "Quick Reply" works.

So, peeking ADC0_SC3 reveals that indeed, hardware averaging of 32 samples was turned on, which fits with my quick estimate of 30 times longer to sample by default.
 
I'm in for a similar project. In the past, I used a variation of the openenergy monitor approach to read the voltage and current with an arduino.

I then tried to graduate to a energy monitoring chip like the ad7753. And failed spectacularly. Those chips are so complicated to program for, I gave up. Now I am up for another round with a straight-up MCU, which is much easier to debug than a ad7753 and its SPI bus.

What I am doing differently though is using the differential inputs of the teensy for the current sensor output as well as using a adc driver op amp to help the teensy with measuring the voltage input. Will be interesting to see how this compares to the quasi-10 bit adc on the arduino. The nice thing about the driver is converting the differential +\- 3V input from the transformer into two positive voltages. The AC coupling should prevent saturation or DC to come though and mess things up.

I've been told that the op amp approach is overkill, it may be. But my research suggested that the adc would benefit from such a stable driver and hence I implemented it. The boards are in production, more news in 2013, I suppose.
 
This website and forum is about electronic projects. I'd want to be open minded and accepting, but really, this isn't the right place to post personal ads. There are lots of "lifestyle" websites and clubs in most major cities for swingers. Those are the places to reach out to such couples.

I'm trying to figure out if this is spam. There aren't any links to websites. Does anyone have any opinions?
 
spam:

https://www.google.nl/search?client...rceid=opera&ie=utf-8&oe=utf-8&channel=suggest

When googling the same text, it appears on other sites as well.

This is a reply, not a new topic.
If this person would have taken the time to read the previous posts, he/she would have noticed the subject was quite different immediately.

At first I thought maybe ADC or PJRC is an acronym for something related to swinging, but I haven't found that connection so far...
 
Last edited:
Yup, you're right, it's spam. Robin will delete it and ban them.

This forum is still relatively new and we're learning some of this as we go.....

I'm not an expert on swinger subculture, but it seems like they're much more oriented to code-words and subtle phrases, rather than acronyms.
 
Hehe, the acronym thing was the only reason I could think of why it might NOT be spam but an honest mistake.
Couldn't find anything related, then I noticed the exact same post on other sites too.

Since all of them have been posted today, I think there is a new spambot with some bugs a.k.a. 'features' (spamming without links).
Still weird though...
 
Not necessarily. They may simply be conducting dry runs to see if they can successfully register and then spam. As best as I can tell, for spammers it's all about volume - they know that a very small percentage of the forum population is even going to click the link (never mind actually acting on whatever is being sold) , so they try and make spread their message as widely as possible. Part pof that effort is an ongoing cat and mouse game between forum developers and said spammers.

As a forum developer, you want to keep things standardized, but the downside is that success (i.e. widespread deployment) leads to your forum platform being targeted by spammers. As an admin, one has to balance the desire to let legitimate users register easily with the downside of making spamming easier too.
 
The term 'dry run' was new to me, but that was exactly what I meant with 'bugs a.k.a. features' :)
(sometimes I wish I was a bit more fluent in English)
 
Back
Top