Microcontroller with 12-bit a/d subsystem?

Ditto..grade 1 pain. I just love their memory segmentation. The only way to deal with a PIC is with C (some ppl would call that a high level language - your religion may vary). I've managed to convince some educational institutions to stop teaching this archaic architecture, and teach something with good isa attributes (e.g. generality, orthogonaliity, etc.) john

Sorry, I are an engineer...I only deal with marketing if I want a free lunch..lol

I made some simple designs with some of the integrated cpus and a/d subsystems. (kept parts count minimal, isolated power, followed rule of thumb routing/layout guides, designed filters with low noise components, high rolloffs, etc). Both accuracy and repeatability sucked mainly because of noise, inhibiting the cpu will cause problems when I scale up the #of channels. I didn't want to design an analog subsystem from scratch (more or less) but it looking more like that. Appreciate the input...thanks

ARM chips are 32 bits - quite a step up from the PICs. (probably in cost as well as performance) The extra cost might be worth it in development time if you only make a few of something.

Quite a few companies make/sell ARM based chips so the peripherals you get will vary. I like the Atmel SAM7 parts.

The people I know who work on ARMs generally use c. That's a reasonable environment for bit twiddling if you make a set of macros that are just constants that point to the IO registers and constants for bits and field masks/shifts...

--
These are my opinions, not necessarily my employer\'s.  I hate spam.

The performance ratio increases much moreso than the price does, at least if you compare to "high end" PICs. :-)

Indeed -- some of the newer ARMs are both cost and power competitive with traditional 8 bit offerings, and completely blow them away on performance. At least if you don't have to do *too* much bit twiddling, that is.

As far as I can tell stuff like AVRs and MSP430s are really meant for C as well -- relatively little RAM, but lots of flash ROM.

---Joel

micro

wet

having

life

up

the

cheap

the

Thanks. As it happens, an hour ago received an ad' describing Microchip's new 32 bit PICs. Seems they've now 1/2Mbyte of flash, DMA and run at 75Mhz!. Implies a

50nS cycle time and with the single cycle MAC, they outwardly look eminently tasty. I'm not having it though, as I just know the internals will be a train wreck, leading to the compiler writers rubbing their hands gleefully with profitable expectations. Thinking about it and reading the other responses, I reckon I need to be familiar with 2 micros. One 'clean' 8 bitter (5V) for bread and butter work, that will pay bills. One muscle 32 bitter that will handle stuff for the occasional 'what-if?' projects. Looks like the ARM is it for the specials, in which case it's worth the effort. The low ender looks like it's going to be the Atmel. I was loaned a pile of AVR stuff last week. Time to start reading!.

I've been happy with the AVR 8 bit parts. The peripherals are reasonably clean. (I haven't looked at the new 32 bit stuff.)

They have many parts, usually clusters with the same IO gear and different sized RAM/ROM(flash).

If you want to get started, their STK500 is probably the right board. Digikey has them for $84. It will program most of the 8 bit parts. It's got a few buttons/LEDs and a blizard of connectors/cables to connect to all the sockets. Check their documentation for the details.

--
These are my opinions, not necessarily my employer's.  I hate spam.

[...]

As I understand it it uses the MIPS core. This is another 20 year old(?) architecture that, like the ARM, was originally designed for powerful desktop/workstation use and is now finding a niche in embedded applications. Which makes a sort of sense, since single chip micros are now so powerful.

This is basically what I do too. ARM7 except for really tiny applications (

I'd been reading this post coz u talked abt ARM, I use an ARM7 core at work and its so so friendly I tell you. I think so close to our x51s. Moreover performance is multiplied a great lot. While programming in C dont have to worry so much about optimizing. Its a timing genius and so many peripherals on various chips.

-Monito