Re: arm7 core with fast monolithic 12-bit ADC

On Thu, 12 Feb 2009 12:34:17 -0800 (PST), rickman <gnuarm@xxxxxxxxx>

On Feb 12, 1:46 pm, Jon Kirwan <j...@xxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 12 Feb 2009 10:19:14 -0800 (PST), rickman <gnu...@xxxxxxxxx>

There are actually few ADC that give you the same number of effective
bits as resolution.

I never imagined differently.  Resolution is almost a waste to care
about.  The only thing it does is provide a __suggestion__ about the
care they took in designing it.

The extra bits are useful if you want to do averaging. They are not
meaningless, they are just in the noise. A 12 bit with 10 ENOB is
better than a 10 bit with 10 ENOB.

Yes, if the extra bits aren't fixed at 0 or 1. The point you are
making assumes a nice Gaussian around the 10 bits in the extra 2.
Which is very useful, for obvious reasons.

I know that isn't bad.  In fact, as I mentioned earlier, my
expectations are only for about 10.5 bits ENOB, 65dB SINAD.  I'm not
expecting the impossible here.  Just something that isn't garbage.

Not to beat a dead horse, but what is your requirement again? I
thought you said you wanted 12 bits and 10.5 ENOB which is reasonable
and many parts deliver that. I guess I'm not sure I am helping at
this point... 8*

What I'm pushing for is that this is monolithic, that the core is ARM7
or compatible, and that the speed is better than 1.5MHz in delivering
the rest. 10.5 ENOB is acceptable, though of course I'd like to push
that, too.

If you need much better than that, you are unlikely to find it
without using a higher bit resolution device.

Which, obviously, would mean "slower" when talking about monolithic
designs with the microcontroller.  It's the combination of speed and
ENOB that I'm looking for in a monolithic design and frankly I think
it isn't entirely out of the ballpark.  It's a doable, not unreasoned
goal I'm looking for.

There are other tradeoffs than just speed. You can run fast, accurate
or low power... pick two. I think we are agreeing on 12 bit with 10.5
ENOB. But I think you said somewhere that you wanted *more* than 1
MSPS and/or you were going to average the samples.

Yes, I said more than 1MHz (though I could [and may] settle for 1MHz.)
Past experience in the application space is 1.5MHz at 11.3 ENOB, which
I know is more than enough to get the job done. That would be a
perfect fit, but I don't expect it monolithically.

But as others have said, uncorrelated noise can be averaged out...

Obviously.  Gaussian distribution (integral of Poisson) is the
assumption that goes into the very idea.

No, I don't think it has to be Gaussian distributed, but maybe it has
been too long since I used any of the theory. I believe the basic
assumption is normally that noise is Gaussian, but in this case it
only has to be uncorrelated. Does that imply Gaussian?

Let me put it this way. The only case I know well is Poisson events.
These do, when summing, integrate into Gaussian curves. Gaussian
distributions around a mean provide predictable results when averaged.
If there is another distribution that you feel can achieve predictable
results, that is not Gaussian in nature, I'd have to examine it using
mathematics to see. So far as I'm aware, in practical experience,
it's Gaussian or else you get distortions that are difficult to
remove. But I'm open to suggestions that I can analyze that aren't
Gaussian, are found in these circumstances, and can be used without
distorting the result (in uncorrectable ways.) My experience is
admittedly limited in many ways and I'm sure that there are many ideas
out there that I haven't thought about before.

*if* it is uncorrelated.

Of course.  Correlated noise violates the assumption.

It is common for the noise to be related to the clock.


After all, the same master clock is driving the MCU and the ADC.

I know.

I might expect this kind of lecture had I asked for something crazy. I
didn't.  Perhaps someone else learned something, though.

Yeah, that is what I am thinking. I guess you started out asking for
practical advice and this turned into a discussion of theory.

Yeah. I needed less advice on theory and more on what's out there or
what might be finessed into working for what I want to get.

best answer I can give is the ADI ARM7 microverter parts. They have
the best ADC/DAC in an ARM MCU that I am aware of. I think someone
else already mentioned these parts. They are only so-so in the MCU
department, at least in terms of speed. But speed is not always what
a design is about.

In this case, I am not looking for flat out speed of the ARM7. I've
had to write every line of this application on entirely integer
processors in assembly code and I pretty much know exactly where the
time sinks are and what to do about them. I was already aware of the
ADI parts, though I haven't used them before, and have one or two
parts here, in fact. (Requested samples just sitting here on the
possibility.) The idea of running the converter faster was just
suggested and that makes the part more interesting for a time. So
I'll look into it.

You can see an older comparison chart of some ARM7 devices at, go to Resources and scroll down to "ARM device
comparison chart". It is getting rather long in the tooth now,
especially with all the CM3 chips coming out. I would love to see ADI
come out with a CM3 microverter clocking at 80 MHz from Flash and
their 12 bit converters.

Okay. I may take a look over there. I seem to recall a spurt of
activity here about that site (from you), now that you bring my
attention to it again. That may be a big help, at least in
eliminating things to look at, if not finding ones to spend time on.