On Thu, 12 Feb 2009 10:46:39 -0800 (PST), Didi <dp@tgi-sci.com> wrote:>On Feb 12, 8:19�pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> On Thu, 12 Feb 2009 09:31:46 -0800 (PST), Didi <d...@tgi-sci.com> wrote: >> >On Feb 12, 7:05�pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> >> On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje >> >> ..... >> >> >Be vary, that F28xx (including the picolo family) internal ADC does >> >> >not deliver the promised 12 bits. Event the TI acknowledge this and >> >> >state thet the ENOB is around 10 bits (that was for the first members >> >> >of the family the F2812). >> >> .... that 10.5 bits would be >> >> enough. I use integration, so if the noise is essentially gaussian I >> >> may be able to deal with this, satisfactorily. �If not, could be an >> >> issue. �I'll read up and thanks for the pointers! >> >> >Gaussian noise is the least likely issue they have. �Most if not all >> >of the 12 bit ADCs I have seen on MCUs are in reality more like 10 >> >bits, INL is just that bad (DNL is 12-bittish, they have no missing >> >codes after all). >> >> I see a specification on the data sheet (one of the very few things >> they actually talk about regarding the ADC) of DNL +- 1 bit, INL +- 2 >> bits. �Did you look at the datasheet? �(Not that it should be >> believed, but I'm just wondering where you came up with the >> "12-bittish" for this device.) > >No, this is just my general experience with ADCs speaking. I have >looked through a fair number of MCU ADCs, and I do not remember >having seen one like the one you describe, that's all. > >If they specify INL as +/- 2 *bits*, not LSBs, this might be >reason to raise some suspicion. It may mean the 2 lowest bits >are meaningless, which will match my observation on MCU ADCs >lately. IIRC I saw one - I think on some Microchip part I was >reviewing for someone - which was true 12 bit or sort of, but >was much much slower (double integrating IIRC).Sorry, I screwed up. They specified it in LSBs. Any fault there is mine.>I have been spoilt by ADI when it comes to ADCs, I guess, >but I know only their standalone ones (their specs are >really trustworthy).Yes, me too. It's what I've been using in the past, btw. Jon
arm7 core with fast monolithic 12-bit ADC
Started by ●February 11, 2009
Reply by ●February 12, 20092009-02-12
Reply by ●February 12, 20092009-02-12
On Thu, 12 Feb 2009 18:35:54 +0000, John Devereux <john@devereux.me.uk> wrote:>Jon Kirwan <jonk@infinitefactors.org> writes: > >> I'm just getting into a project which "prefers" the ARM7 for business >> reasons, not technical ones. I do _not_ have experience writing for >> the ARM7 beyond some modest playing around, but will muddle through >> that part when the time comes. >> >> I'm looking for an ARM7TDMI core (or upward compatible) that includes >> a monolithic (unless someone goes through all the trouble of >> wire-bonding in packaging for reasonable prices) 12-bit minimum width, >> 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V >> signals is fine.) Pipelined sampling and conversion stages is okay to >> get the speed, as only one signal needs to be measured. Flash >> programming of code, 1000-5000 pc qtys. Other features are far less >> important, but RAM should be at least 2k (4k would be safer) and flash >> should be at least 32k-64k (128k would probably be massive overkill.) >> I/O required is probably less then 20 I/O pins (12, I'm counting right >> now, outside the ADC input.) So a 44-pin package is well more than I >> need. >> >> There is a core algorithm involved that processes the data, but to be >> honest I don't need a blazingly fast cpu here -- the core parts that >> require very fast speed will be written in assembly. I won't be using >> floating point, except for a few custom routines I'll write. A fully >> combinatorial barrel shifter with the ability to find the leading bit >> and record the number of shifts required is a plus, though. I already >> know that division is an issue for the ARM7 (software), but that is >> okay as I keep division to a minimum, using wider 'registers' and >> multiplicative sums and tracking divisors, holding the division parts >> till the very end. >> >> I've seen a few cases with fancy debug trace buffers available over >> JTAG and that would be "high cotton" if I could find that, together >> with the ADC. But it really isn't necessary. >> >> The main thing I'm looking for a fast, decent 12-bit or better ADC >> inside an ARM7TDMI (or upward compatible) cpu. The 1.5MHz minimum >> requirement is a bit of a stretch, perhaps. But it is important and >> I'm currently using an external ADC for this (which easily reach much >> higher than this and with decent bits.) Pushing towards 2-3MHz would >> be pure ecstasy. >> >> Right now I'm just trying to compile a list for examination. So even >> things that are close (1MHz, for example) would be okay to include. >> I'll talk it over, later, to see what we may have to accept. > >The ADUC7k family has a 12 bit, 1MHz ADC (as you probably know). It >seems pretty good for an "embedded" ADC. As one might expect from an >ADC manufacturer. It does in fact work at 2MHz if you set the clock >divider bits appropriately, but to what extent that violates the spec >I don't know. (I tried it just for fun once, and seemed to work >fine!). ><snip>Now there is an interesting suggestion!! (Yes, I knew about it.) I may even have one or two of their devices sitting in a nicely packaged (sealed) box to try out. In any case, I didn't know that was possible so I'll go take a look at the datasheet to see for myself. It might be worth some playing. These are some of the kinds of detailed suggestions to examine that I was hoping for to help me expand the possibilities -- difficult to find in a google survey and yet worth thinking about as a shot in the dark. Thanks, Jon
Reply by ●February 12, 20092009-02-12
On Feb 12, 1:46=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:> On Thu, 12 Feb 2009 10:19:14 -0800 (PST), rickman <gnu...@gmail.com> > wrote: > > >There are actually few ADC that give you the same number of effective > >bits as resolution. > > I never imagined differently. =A0Resolution is almost a waste to care > about. =A0The 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.> I know that isn't bad. =A0In fact, as I mentioned earlier, my > expectations are only for about 10.5 bits ENOB, 65dB SINAD. =A0I'm not > expecting the impossible here. =A0Just 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*> >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. =A0It'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. =A0It'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.> >But as others have said, uncorrelated noise can be averaged out... > > Obviously. =A0Gaussian 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?> >*if* it is uncorrelated. > > Of course. =A0Correlated noise violates the assumption. > > >It is common for the noise to be related to the clock. > > Indeed. > > >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. =A0Perhaps 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. 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. 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. Rick
Reply by ●February 12, 20092009-02-12
On Feb 13, 7:19=A0am, Jon Kirwan <j...@infinitefactors.org> wrote:> On Thu, 12 Feb 2009 09:31:46 -0800 (PST), Didi <d...@tgi-sci.com> wrote: > >Please keep us posted if you find a true 12bit/1MSPS ADC on MCU, this > >would be something worth seeing. > > If I'm lucky enough to find something interesting, I will. =A0The XMEGA > specification is entirely TBD. =A0So there is absolutely no information > on it, btw.As others have intimated, a vendor that excels in ADC's, is much more likely to offer a uC with better class of ADC. That should move ADI to the top, with TI close behind. [SiLabs have a 16bit 1MSPS device, but that's 8 bit CPU] 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. You are also more likely to get better results from a faster ADC averaged, that a slower ADC over-clocked With TI's high precision PWMs you could self-test the ADCs for transfer quality fairly easily. -jg
Reply by ●February 12, 20092009-02-12
rickman <gnuarm@gmail.com> writes: [...]> Yeah, that is what I am thinking. I guess you started out asking for > practical advice and this turned into a discussion of theory. 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.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.> 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. > > Rick-- John Devereux
Reply by ●February 12, 20092009-02-12
On Thu, 12 Feb 2009 12:34:17 -0800 (PST), rickman <gnuarm@gmail.com> wrote:>On Feb 12, 1:46�pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> On Thu, 12 Feb 2009 10:19:14 -0800 (PST), rickman <gnu...@gmail.com> >> wrote: >> >> >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. >> >> Indeed. >> >> >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.>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. Jon
Reply by ●February 12, 20092009-02-12
On Thu, 12 Feb 2009 12:40:58 -0800 (PST), -jg <Jim.Granville@gmail.com> wrote:>On Feb 13, 7:19�am, Jon Kirwan <j...@infinitefactors.org> wrote: >> On Thu, 12 Feb 2009 09:31:46 -0800 (PST), Didi <d...@tgi-sci.com> wrote: >> >Please keep us posted if you find a true 12bit/1MSPS ADC on MCU, this >> >would be something worth seeing. >> >> If I'm lucky enough to find something interesting, I will. �The XMEGA >> specification is entirely TBD. �So there is absolutely no information >> on it, btw. > >As others have intimated, a vendor that excels in ADC's, is much more >likely to offer a uC with better class of ADC.Agreed.>That should move ADI to the top, with TI close behind. >[SiLabs have a 16bit 1MSPS device, but that's 8 bit CPU]Yes. Thanks for reminding me about the 8051 Cygnal core. I may look at that. Problem will be in the analog section leading up, though, if I try 16 bits. Best to catch noise in the first stage input, though, and it is a good idea to consider a redesign on that side given a good ADC on a cpu. I think I could live with the 8051, by the way. Have to think more closely about it, but it's possible.>Atmel tend to be at the generic end, and their ADC specs rarely give >worst case promises on anything - just typicals.Thanks for that.>They are also very new to offering 12 bit ADCs on any uC.Okay.>You are also more likely to get better results from a faster ADC >averaged, that a slower ADC over-clockedI think this is an excellent point to consider in the context of overclocking the ADI ARM's ADC.>With TI's high precision PWMs you could self-test the ADCs for >transfer quality fairly easily.Hmm. I hadn't considered that idea here. Thanks for bringing my attention to it. Jon
Reply by ●February 12, 20092009-02-12
On Feb 12, 1:46=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:> Which, obviously, would mean "slower" when talking about monolithic > designs with the microcontroller. =A0It'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. =A0It'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) 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.
Reply by ●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
Reply by ●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
