Do you see any future to the 8-bit MCU's?

based on ARM-Cortex CPU's, at prices I'm currently paying for 8-bit devices, or even cheaper! This has brought me to benchmark them with the MCU independent part of my C++ code and surprisingly the results are quite similar.

Do you mean that the code size is similar, but runs at a faster speed? Otherwise, what is the advantage? The 32 bit devices tend to have more associated complexity such as requiring a seperate core voltage from the I/O voltage.

They will continue to be squeezed, but I doubt they'll go away for another decade or more, particularly in applications that don't need much memory and have few I/O (ie. where the core size represents more of the chip)

based on ARM-Cortex CPU's, at prices I'm currently paying for 8-bit devices, or even cheaper! This has brought me to benchmark them with the MCU independent part of my C++ code and surprisingly the results are quite similar.

the 8-bit's? I guess it is.

I just redesigned an old card using a 8051, an A/D converter, a static RAM (2 kilobytes) and some glue logic. The new card was done with a Stellaris Cortex, LM3S818. All the IC:s on the new card costed together less than the A/D converter chip on the old design.

When our current AVR -based designs need to be replaced, the Stellaris chips are the potential replacements.

The Stellaris chips run fast with minimal electricity, but there is the price of a quite complicated set-up of the master and peripheral clocks and port pins.

mostly based on ARM-Cortex CPU's, at prices I'm currently paying for 8-bit= devices, or even cheaper! This has brought me to benchmark them with the M= CU independent part of my C++ code and surprisingly the results are quite s= imilar.

d of the 8-bit's? I guess it is.

Except for the price of the tools. AVR and PIC tools are still much cheaper. We expect to spend around $1k for the new tools; unfortunately, the cheap/low cost version won't cut it.

I'm using the gnu-arm tool chain, built from source*. It works fine.

How much does CodeSourcery want for the 'real' tools?

• I'm not saying it was _free_, but I built the tool chain when I was between contracts, so it was relatively cheap.

For my last project, I downloaded the free CodeSourcery Lite binary toolchain. It works fine, and only took a few minutes to download/install.

There was some reason why that wasn't working for me -- but I can't remember what it was.

I think it was that I was getting much better luck with getting C++ to work with the gnuarm stuff (with options properly set) than I was with their binary.

'course, that may have changed now.

The flash is the biggest part of the die, no ? So why not 32-bit, as long as code density is reasonable ? For that matter, cutting the instruction set down from M3 to M0 is arguably not worth the extra cost in instructions/flash use...

I'm using an NXP LPC11xx Cortex-M0 at the moment, and it doesn't need a crystal, external reset mgt, or many other bits the 8051 this is replacing needed, so in total much cheaper than the 8-bitter it replaced.

So yup, I think nearly the end-of-the-line for most 8-bit applications ?

Best Regards, Dave

Does it work for Freescale's Cortex M4 w/ DSP?

Around 1K for most of them.

I don't know -- but it took to the Cortex M3 like wildfire. I suspect that the best you could hope for would be that the 'ordinary' C and C++ stuff would compile just fine, but anything DSP would have to be done in assembly, by hand.

But then, that's the best I've ever gotten out of a 'paid for' tool chain.

Then unless you're facing a period of forced unemployment, just plain want to learn how to build the tools, or head up a big group and can set one person to being "the tools guy" it's probably worth it to buy, or to try out their free tool chain.

Specific part numbers? Comparing TI Cortex M3 parts to PICs of similar pin counts is still coming down on the side of Microchip, for me (and a PIC will drive a lot more current than an ex-Luminary chip, which can make a difference).

Also compare power consumption. Renesas just came out with a brandy-spanking-new 8-bit chip family (they call it 16-bit but it's mostly 8-bit operations) specifically to address extreme low power designs.

mostly based on ARM-Cortex CPU's, at prices I'm currently paying for 8-bit devices, or even cheaper! This has brought me to benchmark them with the MCU independent part of my C++ code and surprisingly the results are quite similar.

the 8-bit's? I guess it is.

Excuse me, I do not quite understand ...

The 8051 tools were costly, IAR wit a dongle. For both AVR and the ARMs, I'm using self-generated GNU tools, where the only cost is own work.

Yes.

Actually $150, IIRC, for versions limited to a particular manufacturer (they certainly have a Stellaris-only version, I don't know if they have a Kinetis-only version). Or $400 annually, for the general ARM (including Cortex M4) version. They've got various prices according to the level of support you want and the extra libraries, but none of them will break the bank unless you are looking for the 24-hour support, priority bug-fix, add the features you want, etc., support levels.

And you can always go for Freescale Code Worrier. It's not as good a general compiler as gcc, but it is certainly not bad (at least on the PPC where I have used it), and it now comes with a decent Eclipse setup. You can get a free code-limited version which will be fine for many

There are lots of good reasons to actively choose 8-bit microcontrollers rather than 32-bit ones - but the price of tools is not one of them.

Dave,

maybe you aren't aware of it, but you are starting a new thread everytime you post an answer.

This is caused by Google Groups, and AFAIK there are ways to fix it. (Don't know details, however...)

Thanks, Tilmann

There is an application area for 8-bitters. There are application areas=20 best covered with 32-bitters. There are many applications even for=20

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

That may depend on the news reader or, possibly, on the Usenet server one is using. I don't see the new-thread issue occurring with Dave's posts. I agree it's probably a Google Groups side effect, on one end or the other...

ch

Yes, we are going to need DSP. I have fixed gcc and gas before. I can probably hack in the necessary DSP instructions. I still need some kind of JTAG/SWD programmer. Do TI/LMI and NXP programmers work on other chips? If not, i will get the Freescale one.

I am still waiting for the customer decision for this. If we buy, we would need at least two licenses. If we build on a virtual server, there is no limit.

Just thinking out loud here. An 8-bit core is obviously (?) going to be better on power consumption than a corresponding 32-bit core. OTOH, an 8-bit core isn't a good fit for most real-world data, nor for addressing, which is why 8-bit code spends a lot of time doing 16-bit work. So is it possible that 16-bits will become the preferred ultra- low-power sweet spot? More energy-per-instruction than an 8-bit, but fewer instructions? I know this flies in the face of "16 is dying, squeezed out by 8 and 32." Like I said, just thinking out loud...

Do you see any future for discrete, small-signal transistors? You can buy a few million for the same price as a single discrete; "same price, same [size]", etc.

I continue to be amazed at how many applications can adequately be addressed with smaller processors (recall Moto's "ICU"?). Low power consumption, small pin count (SOIC8 32b processor?), etc.

I lament the loss of really *versatile* counter-timers (imagine having a few 9513's "lying around" :> ) and would much prefer die real-estate being spent on things like that than on a more complex core... I can add a few instruction cycles and bytes of memory to get more complexity from a small processor. But, its awful hard to "emulate" good counter timers in a big fat core :-/