advice on choosing mcu

'huge volumes' may need to be qualified with an actual number, and you do not mention pin-count. All uC are cheap in huge volumes :) Look at : Cygnal C8051F, Philips LPC9xx, maybe Infineon SABC868, AT89C51ACx, CC0x, and Gencore have FLASH+ADC comming.

-jg

Take a look at renesas H8/300 (H8/3068 or 3069) or H8S (H82674) micros. GCC/NewLib, GNU Tools and many OSes (H8/OS ...etc) support it for years.

Cheers

Possibly better match would be H8/Tiny Range H8/3664N 32KB Flash 2KB RAM Uart I2C master/slave 8ch 10bit A/D 512byte EEPROM 3 timers (one can be used as timebase) 1 watchdog

Address break H/W function for easier debugging

"Calvin Chan" skrev i meddelandet news: snipped-for-privacy@4ax.com...

ATmega32 (or if you fit inside 16kB, The pincompatible ATmega16)

points, EEPROM

Look on ww.Keil.com they have a 8051 core search tool

I would recommend an Atmel AVR. I think they offer better performance and value that the PIC 18 series. Not sure about MSP430 and 8051 derivatives.

The PIC18 series needs two clock cylcles per instruction whereas the AVR only needs one due to piplelining. So the PIC needs double the Xtal frequency, which can cause increased EM radiation. Many 8051 based micros have the same issue or worse, but a few of them are fast.

If using C language, I think the AVR is also more efficient than the

I don't have any experience with MSP430, but I believe it has similar abilities to the AVR since it handles double the data width at roughly half the MIPS.

regards, Johnny.

I agree that AVR would be well worth a look. The price vs performance is very good and they are well supported with both free tools such as AVR Studio (from the Atmel web site) and WinAVR (GNU C) and 3rd party development tools (see avrfreaks.com).

Rog.

In article , Roger writes

However the GNU G is hardly optimised.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

I take it you mean GNU C...

I don't think gcc holds many records as being absolutely the best optomising compiler available on any particular platform, but it is pretty solid on many systems, and is generally close to all but the most expensive commercial compilers. In particular, the front-end optomisations of gcc 3.4 are very impressive - they are driven by the big users of x86 and other major ports, but work equally well on small ports - that's an advantage of having a clear front-end / back-end split.

Fortunately for people using gcc on small uControllers like the HC12, the x86 architecture is a rather badly designed one with a hopelessly small set of registers -- thus requiring some pretty sophisticated optimizations to get usable code size and performance. If the x86 wasn't completely crippled by backwards compatibility with the 8080, I doubt there'd be nearly as much work put into optimization in gcc, and it probably wouldn't be able to generate code at all for things like the HC12.