Reply by John Devereux February 26, 20092009-02-26
-jg <Jim.Granville@gmail.com> writes:

> On Feb 26, 3:14&nbsp;pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> Thanks. &nbsp;Although 'future' at Atmel has unique meaning to me (not in a >> good way), > > :) > >> I do at least enjoy seeing some promises on the subject. >> The more the better. &nbsp;More likely one will get through the vaporware >> stage. > > back in October 2008, Ulf said this > "Ulf Samuelsson wrote: > The AT32UC3C will have a 1,5 MSpl 12 bit ADC, CAN, SPI > (but not Ethernet), but it wont be sampling until early next year. > > and it is now early 2009.... Ulf ?? :)
What's your problem? - it's still true :) -- John Devereux
Reply by -jg February 26, 20092009-02-26
On Feb 26, 3:14=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> Thanks. =A0Although 'future' at Atmel has unique meaning to me (not in a > good way),
:)
> I do at least enjoy seeing some promises on the subject. > The more the better. =A0More likely one will get through the vaporware > stage.
back in October 2008, Ulf said this "Ulf Samuelsson wrote: The AT32UC3C will have a 1,5 MSpl 12 bit ADC, CAN, SPI (but not Ethernet), but it wont be sampling until early next year. and it is now early 2009.... Ulf ?? :) -jg
Reply by Jon Kirwan February 25, 20092009-02-25
On Wed, 25 Feb 2009 14:57:26 -0800 (PST), -jg
<Jim.Granville@gmail.com> wrote:

>On Feb 13, 9:40&#2013266080;am, -jg <Jim.Granvi...@gmail.com> wrote: >> Atmel tend to be at the generic end, and their ADC specs rarely give >> worst case promises on anything - just typicals. >> They are also very new to offering 12 bit ADCs on any uC. > >Another (future) data point from Atmel - they have a family brochure >showing the AVR32uC3C as having Dual 1.5MSPS 12 bit ADCs >and 12 bit DACs and tagged as 'future' in status, > >Arrow do show a part code > AT32UC3C0128-ALUT, >so maybe not too 'future'.? > >That is the CAN/USB variant
Thanks. Although 'future' at Atmel has unique meaning to me (not in a good way), I do at least enjoy seeing some promises on the subject. The more the better. More likely one will get through the vaporware stage. Jon
Reply by -jg February 25, 20092009-02-25
On Feb 13, 9:40=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> Atmel tend to be at the generic end, and their ADC specs rarely give > worst case promises on anything - just typicals. > They are also very new to offering 12 bit ADCs on any uC.
Another (future) data point from Atmel - they have a family brochure showing the AVR32uC3C as having Dual 1.5MSPS 12 bit ADCs and 12 bit DACs and tagged as 'future' in status, Arrow do show a part code AT32UC3C0128-ALUT, so maybe not too 'future'.? That is the CAN/USB variant -jg
Reply by steve February 13, 20092009-02-13
On Feb 13, 10:37=A0am, emeb <ebromba...@gmail.com> wrote:
> On Feb 12, 1:47=A0pm, John Devereux <j...@devereux.me.uk> wrote: > > > > > > > rickman <gnu...@gmail.com> writes: > > > [...] > > > > Yeah, that is what I am thinking. =A0I guess you started out asking f=
or
> > > practical advice and this turned into a discussion of theory. =A0The > > > best answer I can give is the ADI ARM7 microverter parts. =A0They hav=
e
> > > the best ADC/DAC in an ARM MCU that I am aware of. =A0I think someone > > > else already mentioned these parts. =A0They are only so-so in the MCU > > > department, at least in terms of speed. =A0But speed is not always wh=
at
> > > a design is about. > > > I get the impression that they took a pretty good ADC (+ good DACs), > > and managed to get a mediocre ARM onto the same die. > > > Whereas the other manufacturers have higher performance ARMs, with > > better peripherals - except for their mediocre ADCs. > > That's a pretty good summary. I've done some work with the ADI > ADuC7026 part and while the analog I/O is good (4 parallel DACs!), the > ARM processor is hamstrung: > > * No DMA - all I/O must be programmed through the CPU > * No VIC - Only IRQ/FIQ available and vectoring must be done in > firmware > * Program flash is only 16-bits wide - must use Thumb mode for zero > wait state code access > * SPI interface is limited to ~3MHz clock rate, 8-bits only. > > On the upside this part has a parallel external memory bus that comes > in hand for some kinds of interfacing, and it's pretty easy to develop > for. Just don't expect screaming fast performance. I ended up porting > the application intended for the ADuC7026 to a Microchip dsPIC with a > quad SPI DAC and saw about a 2x improvement in throughput. >
but does that really matter?
Reply by Jon Kirwan February 13, 20092009-02-13
On Fri, 13 Feb 2009 07:37:55 -0800 (PST), emeb <ebrombaugh@gmail.com>
wrote:

>On Feb 12, 1:47&#2013266080;pm, John Devereux <j...@devereux.me.uk> wrote: >> rickman <gnu...@gmail.com> writes: >> >> [...] >> >> > Yeah, that is what I am thinking. &#2013266080;I guess you started out asking for >> > practical advice and this turned into a discussion of theory. &#2013266080;The >> > best answer I can give is the ADI ARM7 microverter parts. &#2013266080;They have >> > the best ADC/DAC in an ARM MCU that I am aware of. &#2013266080;I think someone >> > else already mentioned these parts. &#2013266080;They are only so-so in the MCU >> > department, at least in terms of speed. &#2013266080;But speed is not always what >> > a design is about. >> >> I get the impression that they took a pretty good ADC (+ good DACs), >> and managed to get a mediocre ARM onto the same die. >> >> Whereas the other manufacturers have higher performance ARMs, with >> better peripherals - except for their mediocre ADCs. > >That's a pretty good summary. I've done some work with the ADI >ADuC7026 part and while the analog I/O is good (4 parallel DACs!), the >ARM processor is hamstrung: > >* No DMA - all I/O must be programmed through the CPU >* No VIC - Only IRQ/FIQ available and vectoring must be done in >firmware >* Program flash is only 16-bits wide - must use Thumb mode for zero >wait state code access >* SPI interface is limited to ~3MHz clock rate, 8-bits only. > >On the upside this part has a parallel external memory bus that comes >in hand for some kinds of interfacing, and it's pretty easy to develop >for. Just don't expect screaming fast performance. I ended up porting >the application intended for the ADuC7026 to a Microchip dsPIC with a >quad SPI DAC and saw about a 2x improvement in throughput.
Interesting. Thanks. Jon
Reply by emeb February 13, 20092009-02-13
On Feb 12, 1:47=A0pm, John Devereux <j...@devereux.me.uk> wrote:
> rickman <gnu...@gmail.com> writes: > > [...] > > > Yeah, that is what I am thinking. =A0I guess you started out asking for > > practical advice and this turned into a discussion of theory. =A0The > > best answer I can give is the ADI ARM7 microverter parts. =A0They have > > the best ADC/DAC in an ARM MCU that I am aware of. =A0I think someone > > else already mentioned these parts. =A0They are only so-so in the MCU > > department, at least in terms of speed. =A0But speed is not always what > > a design is about. > > I get the impression that they took a pretty good ADC (+ good DACs), > and managed to get a mediocre ARM onto the same die. > > Whereas the other manufacturers have higher performance ARMs, with > better peripherals - except for their mediocre ADCs.
That's a pretty good summary. I've done some work with the ADI ADuC7026 part and while the analog I/O is good (4 parallel DACs!), the ARM processor is hamstrung: * No DMA - all I/O must be programmed through the CPU * No VIC - Only IRQ/FIQ available and vectoring must be done in firmware * Program flash is only 16-bits wide - must use Thumb mode for zero wait state code access * SPI interface is limited to ~3MHz clock rate, 8-bits only. On the upside this part has a parallel external memory bus that comes in hand for some kinds of interfacing, and it's pretty easy to develop for. Just don't expect screaming fast performance. I ended up porting the application intended for the ADuC7026 to a Microchip dsPIC with a quad SPI DAC and saw about a 2x improvement in throughput. Eric
Reply by Jon Kirwan February 13, 20092009-02-13
On Thu, 12 Feb 2009 14:05:35 -0800 (PST), steve
<bungalow_steve@yahoo.com> wrote:

>On Feb 12, 1:46&#2013266080;pm, Jon Kirwan <j...@infinitefactors.org> wrote: > >> Which, obviously, would mean "slower" when talking about monolithic >> designs with the microcontroller. &#2013266080;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. &#2013266080;It's a doable, not unreasoned >> goal I'm looking for. > >die designs that are good for CPU's are not good for quiet >fast accurate A/D's, that's why most A/D's in micro are not even >speced out > >I wouldn't design a product with an internal micro A/D unless I had a >complete spec or >I was using it for a simple low res monitor system (<6 bits)
This is a low cost device with loose tolerances, which drove me to at least look at the possibilities available.
>The ADU series is about the only SAM7 micro A/D that has a decent spec >(with at least typical SNR/THR/Spurious Noise/Crosstalk >speced out), it more like a A/D with CPU surrounding it, they put much >effort into making it meet spec with the core running, whereas most >other onboard A/D's are an afterthought. SiLabs has speced micro A/D's >too, but only 8051 based.
That seems to be the wisdom of the day. I am looking into experimenting with both, as well as one or two other options. Jon
Reply by rickman February 13, 20092009-02-13
On Feb 12, 3:55 pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Thu, 12 Feb 2009 12:34:17 -0800 (PST), rickman <gnu...@gmail.com> > wrote: > > >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.
If the bits were fixed, then they wouldn't really be part of the resolution, eh? Actually, the point I am making is that I am pretty sure you ***can't*** assume a Gaussian curve, but I don't think that is needed. It only has to be uncorrelated so that it averages out. Gaussian is symmetrical, so it will average out, but other shapes will average out as well.
> >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.
I thought you said it needed to be an ARM7. I see in another post you are also considering the Cygnal parts.
> >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.
Ok, at this point I think you just need to look at the parts out there.
> >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.
I think at this point you may be over analyzing the issue. You don't need to characterize the noise mathematically. You just need to characterize the operation of the device. So grab an eval board and collect some data. Then run it through your signal analysis software on the PC and, voila, a value for ENOB!
> 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.
I hear you. Often people don't analyze things this carefully. They either grab a part and live with the results or they pick a part that gives them some margin of safety (in this case that would be two parts, an ADC and an MCU). So you are not likely to get any more useful info without analyzing some parts.
> >The > >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 > >http://gnuarm.com/, 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.
Good luck! and let us know what you find... Rick
Reply by rickman February 13, 20092009-02-13
On Feb 12, 4:02=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Thu, 12 Feb 2009 12:40:58 -0800 (PST), -jg > > >You are also more likely to get better results from a faster ADC > >averaged, that a slower ADC over-clocked > > I think this is an excellent point to consider in the context of > overclocking the ADI ARM's ADC.
Just a quick note on overclocking. Overclocking a flash is not uncommon because of the difference of the accuracy of the converter and the bandwidth of the chip input. But most MCUs use successive approximation and that can get you into real trouble if you overclock it. I am not an expert on these devices, but from what I understand about them if you don't give enough settling time on each bit, you can get an answer that is way off. I guess you could just stop the converter before it has converted all the bits, but that would require access to the converter at a low level. I guess I am saying that if you want to overclock a successive approximation converter, be sure to test this thoroughly before you put that in your plan. Rick