I am looking for a micro with a 12-bit a/d subsystem on it. I've searched quite a few mfg, but seems 10-bits is the maximum. Anybody have any suggestions for microcontrollers that have a 12-bit a/d? Thanks John
You didn't look very hard. AD, BB/TI, TI. Silabs, Microchip and others..
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Few, if any, of those will actually be good to 12 bits. A/D converter bit count in microcontrollers has become a big marketing game, and accuracy has gone by the way side.
I'd sure be interested in a microcontroller that had an honest 12 bits to it, though.
-- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Right. The accuracy of the 12bit ADC of TI 28xx is nothing but a disappointment.
Look at the ADUC series from AD. It is a x51 core with a decent ADC. There also used to be the ADSP218x with the delta-sigma audio codec.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
They do the ARM7 core as well (ADUC7000 series). The ADCs seem as good as any other 12 bit type. They are 1us so quite fast too - OP may be able to reduce any transition noise with some averaging.
-- John Devereux
TI has "16 bit" sigma-delta ADCs, and others have 24-ish nominal bits. also in sigma-delta. As always, ENOB depends on the sampling, and probably other factors.. BB claims very low noise (sub 100nV) but their stuff is pretty pricey. Usually for control applications, a high resolution is better, all other things being equal, so a 16-bit converter with 12-bit accuracy (and maybe the LSB is mostly noise) will be better than a really solid 12-bit converter.
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Unfortunately, whenever I put the words '8051' and 'microcontroller' together, the phrase 'lousy excuse for' starts floating around in my head...
Be that as it may, you're probably right. I take that line of ADCs the way ADI markets them -- they're not microcontrollers with ADCs tacked on, they're ADCs with microcontrollers tacked on. This is not a bad thing, and I should take a close look at the ones with the ARM cores.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
Come to think of it, I've used the TI one -- but I neither carefully studied the data sheet nor did I characterize my processor in circuit, because my application wasn't that critical. I still suspect that for SAR circuits the last few bits of the 12 are there for chest-beating.
You're correct about the resolution vs. accuracy issue -- getting those last few bits, even if you can't trust them for more than a few seconds, can make a big difference in a control system's behavior.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
The MSP430 series come to mind. Dunno if they are 12 bit though. However, their analog behaviour is very good according to some people...
-- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl
LOL
I've been severely bitten by the ARM bug. Been playing with one of these recently:
Hmmm... for my furnace controller, I keep a running average of the temperature's ADC. It's resolution is 0.03C (13 bits as 7.5 fixed point, plus a sign bit) but its rated accuracy is +/- 2C and in reality individual measurements are +/- about 0.2C (~9 bits).
So I have a 32 sample buffer, and average the 16 median samples. That seems to work for me, but I can't say if that's "real" accuracy or not. The performance graphs look right, though, which is good enough for me ;-)
Actually I did. I have used a few as well..MicroChip, Renseas, Atmel. Both performance and accuracy is pitiful....
You didn't say you needed 12 real bits rather than marketing bits. ;-)
I have not done much with on-chip SAR converters lately, but 10-bit ones are so stable and noise-free that I suspect that the 12-bit ones are not too bad, even if they are not any better. That's assuming the layout is good, the supply voltage is reasonably high and clean, there is as good ground plane, there are not large untamed currents flowing around, and all the other usual analogish stuff. I have no doubt that others can get worse performance out of them. ;-)
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
I'm not sure what your "few seconds" comment refers to.
I generally divide ADCs into two types.
The old style are rated in terms of linearity of low bits. They work for things like measuring temperature or voltage that changes slowly.
The new style are intended for dynamic signals - audio or radar. They are rated in ENOB - Eveective Number of Bits, usually the data sheet has an FFT picture.
-- These are my opinions, not necessarily my employer\'s. I hate spam.
The peripherals sometimes seem a bit basic compared to other "microcontrollers with ADCs tacked on" - although this also means they are relatively simple to understand.
There are also some oddball design choices, such as the embedded programmable logic array, or the DDS synthesiser with "100 ohm line driver". Presumably a customer-specific part released to the masses.
My impression is that this family is not as active as lines from other manufacturers. And the parts seem slightly more expensive; I guess you are paying for the analog performance.
I've just noticed a new one with dual 16 bit delta-sigma ADCs!
And it operates directly from 12V! See what I mean about oddball?
-- John Devereux
What are your specific problems with those devices (just so I'll know in the future)?
Was looking at an ARM development board on Sunday. Are they straighforward to program in assembly?. I've now had 10 years of PICs and am heartily fed up with their obtuse, infernal internals. On average I get through maybe 4 jobs a year that use a PIC and each time round I have to relearn the bit settings, the register defaults, the interrupt sequencing, the pin allocating, the ... . It's a grade#1 pain. Maybe it's because I'm not really interested in programming and see it as just a means to an end, yet I still find it very easy to read Z80 assembly listings from 15 years back and could still program one from scratch. I reckon the PICs are doing my head in. There must be something better out there. Perchance the ARM?.
I really like the instruction set, much more powerful than the typical micro IMO.
;-) I wanted to do some work in C and learn something about ARM, so I finally got around to getting a dev board. The dev board in the link I posted is my second one. I started with a LPC2106 board to get my feet wet and then bought the second board a couple of weeks later. I've been having a ball with this one, what with all the nifty peripherals that I haven't played with before. :-)
I don't think the ARM architecture is going to make you suddenly enjoy programming, but I think you will find the instruction set allot easier on your sanity. My biggest problem with PIC chips is the W reg, it makes life so tedious.
Something I noticed pretty quickly about the ARM world is that while the instruction set is the same between manufacturers, the way the built in peripherals work can vary quite a bit. I originally had planned to start using Atmel SAM7 parts, but due to a shortage in the dev boards, I ended up going with the LPC(NXP/Phillips) part. I'm kinda glad I did as I like the GPIO port design in the NXP parts better......I think. ;-)
This may be somewhat of an apples/oranges issue. IMO the PIC will always have its place because of its ruggedness and reliability not to mention the miniscule amounts of power it uses. OTOH, the ARMs are getting really cheap and they are just sooo frigging fast it's amazing. I'm used to PIC instructions taking .5 to 1 uS to execute, now I'm burning the place down with instruction cycle times < 15nS. Seems so odd to call a subroutine to delay for 1uS, but I'm not complaining mind you. ;-) OTOH, welcome to the world of wait states when running from flash. :-( I guess you can't have everything.
I agree. The PIC assembly code is horrible. I recommend a low-level PIC-compatible C compiler.
The 32-bit ARM instruction set has to be the "cleanest" instruction set in existence. The 16-bit version which is widely used on uC versions is still a lot neater than typical 8/16-bit microprocessor instruction sets.
However, that's just the core instruction set. Once you start dealing with all the "bundled" extras (MMU, FPU, SIMD, I/O, Java, etc), things start getting more involved.
It's also worth bearing in mind that the architecture was originally conceived as the CPU for desktop systems rather than for twiddling I/O pins, so the overall system is vastly more complex than a typical uC.
OTOH, there's likely to be less of a benefit to using assembler when you have 16x32-bit registers and 128/256/512KiB flash and 32/64KiB of RAM with a flat address space.
You might want to take a look at the datasheets for the AVR32 family to get an idea:
If you're looking for overall system simplicity, you probably don't want a
32-bit RISC chip which is capable of being used as the main CPU for everything from mobile phones to TCP/IP routers to Unix workstations.ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.