What next for microcontrollers?

1/20/2010 7:53 AM EST

Hello, probably a nice article, however using word ARM in every second sentence and
not even trying to compare it to other existing 32-bit architectures discouraged me to read it whole. Maybe if another name was used for the title, like "Advantages of ARM Thumb2 over 8- and 16-bit architectures" or similar, the reader would not be so surprised that this is such a PR.

2/9/2010 4:43 AM EST

Nice article, but for me sounds like an ad on TV where you can call one number to buy some stuff. And Fig.7 from "Cost of migration" part is irrelevant in my opinion, I understand that cost migration should be showed at single and the same moment of the time. And let's be sincerely and not compare price of 8 bits MCU's with 32 bits MCU's.

3/2/2010 10:52 AM EST

Hmm

3/22/2010 11:59 AM EDT

A note too biased for my taste. No account is taken of the AVR32 and ColdFire V1 are excellent 32-bit machines.

3/24/2010 5:19 AM EDT

Indeed the whole article is just too biased to be regarded as serious. While I am leaning towards 32-bit myself, I don't buy the arguments presented at all.

- If the program is too complex for your 8-bit micro, it isn't the micro's fault, you simply picked the wrong micro for the project, i.e. poor engineering. And if I don't need ten times more performance, what good comes out of it? Nothing but extra EMI noise.

- I don't see any difference what so ever in portability between 8-bit and 32-bit. Where did the author of the article get that silly idea from? It seems the article assumes that every single program in the world is still written in assembler.

- Code size isn't an argument either, if the code will fit in the on-chip flash, that's fine. As we can see from various research, 32-bit means slightly better code density, not immensely better code density. Sure, if you compare a 8051 (anno 1980), or a PIC (anno 1975), with a Cortex (anno 2010), the Cortex will look awesome... It is funny how the 32-bit preachers always pick the two oldest, crappiest arcitectures on the market for comparison. It is like comparing your sports car from 2010 with a regular car from 1975, instead of a regular car from 2010.


- "...functions can be accessed recursively"
How is this a good argument for any embedded program? The only use for them are various search and sort algorithms that you will likely never have a need for in embedded programms. Recursive functions are also banned by MISRA-C.


- "and there is no need to worry about saving of special registers value in interrupt handlers as this is handled by the processor during interrupt entry"
All sane 8-bit MCU architecturers have done this too, during the past 30 years.

- "enum 8 bit/16 bit" etc. Sorry, but enum size is the same as sizeof(int) no matter platform. Since the article is concerned about portability, perhaps the author should stick to ISO C. (See ISO 9899:1999 6.4.4.3 and 6.7.2.2)

- Floating point size isn't set in ISO C. You can't assume that it has a certain size, or your program won't be portable. There are several 8/16 bit MCUs that can handle 64 bit floats.

- "This should be changed to the following for running on ARM based microcontrollers to avoid an unnecessary increase in ROM size: const short int mydata"
While this reduces ROM size, you lose speed during computation, as the integer promotion rules in ISO C will convert the constants to temporary 32-bit int variables. In this case a 16-bit MCU will outperform a 32-bit, as the 16-bit can do the calculation in C without integer promotions. A 32-bit program written in the C language can never perform any form of calculation on integers less than 32 bits, because of the integer promotions.

- There are plenty of MCUs of any kind using JTAG or BDM, this isn't something exclusive for ARM.

3/28/2010 3:20 PM EDT

While the article is biased, I completely disagree with Lundin comments:

"If the program is too complex for your 8-bit micro, it isn't the micro's fault, you simply picked the wrong micro for the project, i.e. poor engineering. "

Microcontroller vendors often give people wrong idea what their micros can do. We had been burnt on this several times. The micros they sell has plenty of peripherals, but the C compiler isn't good enough and end up many parts of the code has to be done in assembler.

"And if I don't need ten times more performance, what good comes out of it? Nothing but extra EMI noise."

Just run the core at lower frequency, saving power and reduce EMI - nowadays many ARM MCU have the option to scale down CPU frequency while peripheral still run at normal speed.

"I don't see any difference what so ever in portability between 8-bit and 32-bit. Where did the author of the article get that silly idea from? It seems the article assumes that every single program in the world is still written in assembler."

Almost all of the LCD driver code we had for EPSON Seiko and NEC 8-bit MCU are done in assembler for speed and code size. And we often need to port a software product from one MCU to another in a short time.

"It is funny how the 32-bit preachers always pick the two oldest, crappiest arcitectures on the market for comparison."

Yet these are still the most popular 8-bit architectures.

" ...functions can be accessed recursively...

How is this a good argument for any embedded program? The only use for them are various search and sort algorithms that you will likely never have a need for in embedded programms. Recursive functions are also banned by MISRA-C."

You didn't seems to realize this is important if you want to share a function between thread and interrupt handler, or shared a function between two different tasks in OS environment.

" ...and there is no need to worry about saving of special registers value in interrupt handlers as this is handled by the processor during interrupt entry...

All sane 8-bit MCU architecturers have done this too, during the past 30 years."

Many popular architectures don't.

"enum 8 bit/16 bit" etc. Sorry, but enum size is the same as sizeof(int) no matter platform. Since the article is concerned about portability, perhaps the author should stick to ISO C. (See ISO 9899:1999 6.4.4.3 and 6.7.2.2)

Many C compilers for 8-bit MCU have feature to allow user to use the smallest possible data type for enumeration. Because integer performance is bad in 8-bit mcu, many people use these features.

"Floating point size isn't set in ISO C. You can't assume that it has a certain size, or your program won't be portable. There are several 8/16 bit MCUs that can handle 64 bit floats."

There is nothing wrong for the article to highlight the floating point issue. Many people don't know. I'm glad that it does get mentioned.

"While this reduces ROM size, you lose speed during computation, as the integer promotion rules in ISO C will convert the constants to temporary 32-bit int variables. In this case a 16-bit MCU will outperform a 32-bit, as the 16-bit can do the calculation in C without integer promotions. A 32-bit program written in the C language can never perform any form of calculation on integers less than 32 bits, because of the integer promotions."

No, you don't lose speed. Almost all modern 32-bit architectures allow reading of a 16-bit data and convert it into 32-bit in a single instruction. (Including ARM, PIC32, etc).

"There are plenty of MCUs of any kind using JTAG or BDM, this isn't something exclusive for ARM."

While it is not exclusive to ARM, ARM Cortex got serial wire debug that only use two wires. You can still use JTAG if you want to.
You can also use serial wire trace to see which interrupts has been executed before program crash (need one more wire).

3/29/2010 8:05 AM EDT

>> "If the program is too complex for your 8-bit micro, it isn't the micro's fault, you simply picked the wrong micro for the project, i.e. poor engineering. "
> "Microcontroller vendors often give people wrong idea what their micros can do. We had been burnt on this several times. The micros they sell has plenty of peripherals, but the C compiler isn't good enough and end up many parts of the code has to be done in assembler."

Then it seems that the fault would be the false advertising and not the micro in itself. But if you have no margins for adding code for solving such problems, how can you have margins for future expansions?


>> "And if I don't need ten times more performance, what good comes out of it? Nothing but extra EMI noise."
> "Just run the core at lower frequency, saving power and reduce EMI - nowadays many ARM MCU have the option to scale down CPU frequency while peripheral still run at normal speed."

And what exactly have you achieved with that, instead of picking a 8-bit micro with enough performance for the task? It doesn't sound ideal to pick a too powerful CPU just for the sake of it, and then down-clock it.



> > "I don't see any difference what so ever in portability between 8-bit and 32-bit. Where did the author of the article get that silly idea from? It seems the article assumes that every single program in the world is still written in assembler."
> Almost all of the LCD driver code we had for EPSON Seiko and NEC 8-bit MCU are done in assembler for speed and code size. And we often need to port a software product from one MCU to another in a short time.

How is this getting better/worse in a 32 bit MCU then? It is still assembler, the data bus width has nothing to do with portability.



> >" ...functions can be accessed recursively...
> > How is this a good argument for any embedded program? The only use for them are various search and sort algorithms that you will likely never have a need for in embedded programms. Recursive functions are also banned by MISRA-C."
> You didn't seems to realize this is important if you want to share a function between thread and interrupt handler, or shared a function between two different tasks in OS environment.

Umm... no I don't realize that. Correct me if I'm wrong, but I think you are mixing up recursive functions with re-entrant functions?



> > " ...and there is no need to worry about saving of special registers value in interrupt handlers as this is handled by the processor during interrupt entry...
> > All sane 8-bit MCU architecturers have done this too, during the past 30 years."
> Many popular architectures don't.

Tough luck, switch to a sane one instead :)



> > "enum 8 bit/16 bit" etc. Sorry, but enum size is the same as sizeof(int) no matter platform. Since the article is concerned about portability, perhaps the author should stick to ISO C. (See ISO 9899:1999 6.4.4.3 and 6.7.2.2)
> Many C compilers for 8-bit MCU have feature to allow user to use the smallest possible data type for enumeration. Because integer performance is bad in 8-bit mcu, many people use these features.

Yes, but just because a compiler has a feature, it doesn't magically make that feature ANSI/ISO C. If you aren't writing portable code in pure ISO C, you only have yourself to blame for it. As I wrote elsewhere in my post, you cannot perform integer operations on 8-bit integers in the C language anyway.

And if NVM size is really that big a problem, you shouldn't be using enum at all! This particular space problem should be solved by using global const 8-bit integers instead of enums. If you use enums, the constant values will typically be hard-coded into the machine code (just as if you used #defines), rather than accessed through the address of a global const table.

4/6/2010 9:23 PM EDT

Besides being too biased, there are several misconceptions on this article. I agree with Lundin's all comments. And I have one more to add:

"Even if an 8-bit or 16-bit microcontroller could cope with the requirements for the current project, it poses a serious risk of limiting future product upgrade opportunities, and the ability to re-use code across developments."

That's a really valid thought. When developing, lets say, a new $5 mouse why not use 32, may be 64 bits achitecture? This way one would not limt all the possible future upgrade opportunities for this complex product. Who knows what complex floating math and huge amount of memory my new mouse model will require any time soon?

In real life, not all applications are made equal and there is a lot that are quite simple and self contained, not demanding "future evolutions" neither upgrades. Have you think that?

4/8/2010 5:55 PM EDT

I've done a number of things on an ARM7 that I used to do on a DSP. For that, the ARM7 is great.

On the other hand, I have other projects that require very low power and do not require computational power. I have yet to see an ARM7 compete in this area with an MSP430.

The ARM7 processors I've used have been excellent, but there's been some miss leading marketing on behalf of ARM. For example, comparing active cycles against what, and 8051? Let's see the same thing against a PIC24, or an MSP430. Something with a more modern sleep draw. I think the practice of comparing individual features against worst in class is not very inspiring.

As for code density, I can't remember ever choosing a micro-controller based on that metric.

I've done audio processing on TI Luminary ARM7 and the Microchip PIC24. Both worked great. Since the Luminary will run at a higher clock rate (80MHz versus 40MHz), I was able to get a bit more performance out of it, but that doesn't make it better. I can drop a PIC24 on to a solderless breadboard and go. When I prototype with Luminary (I like the LMS1968) I have to grab an eval board.

Now back to power for a moment. When I have a power sensitive application, I turn to the MSP430. I've had applications where my average draw was around 40uA. That includes both the wake and sleep cycles. Check the data sheet on your favorite ARM7. A comparable sleep mode draw is around 0.14mA, but only on the variant mentioned above which has the lowest I've seen on an ARM7. Others are much higher. And that's just for the sleep mode. When you factor in the sleep/wake, the average will be much higher.

To put this in perspective, you can run an MSP430 on a 200mA coin cell battery for months. It comes out to about 200 days, but in practice it was a bit less for me. It came out around four months, but I didn't use a fresh battery and I blinked the LED a lot.

You would be hard pressed to get two weeks with an ARM7. Sure, you could use hibernation, but what good is a processor in a coma?

These processors are all excellent, but one size does not fit all. It comes down to the specific needs of your application: performance, battery life, and let's not forget peripherals.

4/8/2010 11:34 PM EDT

Hermanator,

Do you mean ARM v7 when comparing to the PIC24 as in Cortex-M3 or did you mean ARM7TDMI (ARM v4)? I didn't realize that Luminary ever made any 7TDMI based parts...

11/23/2010 2:38 AM EST

Good English !! Sort of marketing kind of article and a real technical note.

9/24/2011 4:38 AM EDT

yes ARM processors are now a standard, they are good, but which will be the differences between various microcontroller competitors? Only the cost? Why some vendors still develop families of microcontrollers with proprietary 32-bit core beside 32-bit ARM core?