AVR8 vs Cortex-M???

[technix]

When I chatted with my professor and a few of graduate students on his team today, they gave me this question again: why are you still using 8-bit MCUs instead of Cortex-M?

So why people find Cortex-M so attractive?

To me, I feel that Cortex-M is in an awkward position on the price/performance chart. For entry-level applications 8-bit MCUs like AVR, PIC, maybe even 8051 have all the required functionalities already while being cheaper than the entry-level Cortex-M's. Also those 8-bit MCUs can be found in tiny 6-pin or 8-pin packages but I still yet to find a 8-pin Cortex-M chip. When the performance requirement go up 16-bit MCUs like PIC24 and MSP430 start to become serious contenders, and yet the 16-bit ones are still cheaper. Then for the most demanding uses the Cortex-A line start to become appealing (Allwinner A13, a Cortex-A8 chip in TQFP package, is available at $2 each; and a quad-core Cortex-A7 Allwinner A31s is available at $5 if you don't mind BGA)

[nctnico]

ARM is a learn once-fits-all solution which is also very efficient to use with a C compiler.

Here is your 8 pin DIP ARM cortex-M0 (don't look at Farnell pricing though; they are high at single quantities but will do free delivery even if you only order one):
http://uk.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-dip/dp/2320692

From there you can go all the way to the LPC1800 series (COrtex M3 at 180MHz) without needing to re-learn the chip or the peripherals since NXP kept these (virtually) the same across their entire range.

[botcrusher]

Personally, I'm a sucker for those 8-bit ATmega chips. They're cheap, plentiful, well supported, and can do some fairly robust things. My main application for them is driving things like servos and chains of lights. Admittedly, this is where they start to sputter. Eventually, you run out of ram with longer runs, or you can no longer keep up the bit bashing required for driving common led chains.

This is where Cortex-M would come in for me. I have yet to get my hands on one and use it, but i have a rough grasp of the stuff it could pull off.

[hans]

When I chatted with my professor and a few of graduate students on his team today, they gave me this question again: why are you still using 8-bit MCUs instead of Cortex-M?

So why people find Cortex-M so attractive?

- Cost
- Toolchain independent of manufacturer
- Therefore purchased tools & compiler can be used for m0's up to m7's. Additionally, set up toolchain and workflow is similar.
- 32-bit is more powerful than 8-bit in math operations.
- Typically more MHz
- Memory is usually less scarce

To me, I feel that Cortex-M is in an awkward position on the price/performance chart. For entry-level applications 8-bit MCUs like AVR, PIC, maybe even 8051 have all the required functionalities already while being cheaper than the entry-level Cortex-M's.

Depends. AVR is not as cheap as PIC. 8-bit PIC have very horrible performance, and once you outgrow one of those 64MHz PIC18s you're out of luck on that architecture.

Also those 8-bit MCUs can be found in tiny 6-pin or 8-pin packages but I still yet to find a 8-pin Cortex-M chip.

LPC800

Have to admit, if you're shopping for a 14-pin or 18-pin ARM chip, you'll come short compared to PICs and AVRs. Most ARM chips start at 32-pins.

When the performance requirement go up 16-bit MCUs like PIC24 and MSP430 start to become serious contenders, and yet the 16-bit ones are still cheaper.

I am not sure about prices in your area, but cheapest PIC24 (PIC24F16KA101) with 16KB FLASH is 2 euro each, and the cheapest STM32F0 (STM32F030) I can get from Farnell is like 1,20 euro.

Additionally:
- That PIC24 has 1.5K of RAM, STM32 has 4K.
- PIC24 runs 16MIPS, STM32 runs 48MIPS.
- Both 20-pins
- Peripherals are neither here or there. PIC has 1 UART more, but STM has 12-bit ADC, DMA and more timers.

Then for the most demanding uses the Cortex-A line start to become appealing (Allwinner A13, a Cortex-A8 chip in TQFP package, is available at $2 each; and a quad-core Cortex-A7 Allwinner A31s is available at $5 if you don't mind BGA)

Which almost forces you to use Linux, which brings in a whole slew of other problems.

The m3 and m4 chips are serving a very good purpose; they are powerful enough to do some 'heavy lifting' for an application, yet bare metal enough to work directly on hardware, you're not debugging a linux bootloader, etc.
OTOH you need more work to get even any networking up.

[technix]

ARM is a learn once-fits-all solution which is also very efficient to use with a C compiler.

Here is your 8 pin DIP ARM cortex-M0 (don't look at Farnell pricing though; they are high at single quantities but will do free delivery even if you only order one):
http://uk.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-dip/dp/2320692

From there you can go all the way to the LPC1800 series (COrtex M3 at 180MHz) without needing to re-learn the chip or the peripherals since NXP kept these (virtually) the same across their entire range.

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M. AVR are equally as optimized for C, and the same peripherals goes from tinyAVR to megaAVR all the ways up to AVR UC32 chips (maybe different base addresses but with good programming habits that isn't that much of a problem.)

[technix]

Personally, I'm a sucker for those 8-bit ATmega chips. They're cheap, plentiful, well supported, and can do some fairly robust things. My main application for them is driving things like servos and chains of lights. Admittedly, this is where they start to sputter. Eventually, you run out of ram with longer runs, or you can no longer keep up the bit bashing required for driving common led chains.

This is where Cortex-M would come in for me. I have yet to get my hands on one and use it, but i have a rough grasp of the stuff it could pull off.

Well my use pattern is usually AVR8 + Cortex-A, using AVR8 to handle the interfacing of the hardware directly and use high-level commands from the Cortex-A which runs Linux.

[nctnico]

ARM is a learn once-fits-all solution which is also very efficient to use with a C compiler.

Here is your 8 pin DIP ARM cortex-M0 (don't look at Farnell pricing though; they are high at single quantities but will do free delivery even if you only order one):
http://uk.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-dip/dp/2320692

From there you can go all the way to the LPC1800 series (COrtex M3 at 180MHz) without needing to re-learn the chip or the peripherals since NXP kept these (virtually) the same across their entire range.

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M. AVR are equally as optimized for C, and the same peripherals goes from tinyAVR to megaAVR all the ways up to AVR UC32 chips (maybe different base addresses but with good programming habits that isn't that much of a problem.)

Just looking at the price is a bad idea in 99.9% of the cases. In the end you just waste more time than money is gained. Even when doing a hobby project banging your head against the wall due to a limit of an archaic 8 bit controller for an hour is a waste of money. If you spend that hour to deliver papers, work in a grocery store, etc you will make more money than the price difference of the chip.

[technix]

When I chatted with my professor and a few of graduate students on his team today, they gave me this question again: why are you still using 8-bit MCUs instead of Cortex-M?

So why people find Cortex-M so attractive?

- Cost
- Toolchain independent of manufacturer
- Therefore purchased tools & compiler can be used for m0's up to m7's. Additionally, set up toolchain and workflow is similar.
- 32-bit is more powerful than 8-bit in math operations.
- Typically more MHz
- Memory is usually less scarce

- Not really cheap.
- AVR have that too, in the form of avr-gcc, avr-libc and avrdude. The fact that Atmel themselves uses avr-gcc and contributes code does not affect the FSF ownership of avr-gcc.
- The same can be said for AVR too. Let's not forget that avr-gcc, being a FSF project, is free in both the sense of rights and the sense of price.
- Do you really need that? If maths start to get intense the $2 Allwinner A13 start to look attractive, and that puppy comes with a 800MHz Cortex-A8 and a Mali-400 GPU.
- Again, do you really need that for low-end applications?
- This may be a point, but again, for lower end applications, do you really need that?

To me, I feel that Cortex-M is in an awkward position on the price/performance chart. For entry-level applications 8-bit MCUs like AVR, PIC, maybe even 8051 have all the required functionalities already while being cheaper than the entry-level Cortex-M's.

Depends. AVR is not as cheap as PIC. 8-bit PIC have very horrible performance, and once you outgrow one of those 64MHz PIC18s you're out of luck on that architecture.

Well here in China AVR and PIC cost about the same. AVR is a good performer which offsets the price anyway. Where PIC18 ends is pretty much where Cortex-A starts for me.

Also those 8-bit MCUs can be found in tiny 6-pin or 8-pin packages but I still yet to find a 8-pin Cortex-M chip.

LPC800

Have to admit, if you're shopping for a 14-pin or 18-pin ARM chip, you'll come short compared to PICs and AVRs. Most ARM chips start at 32-pins.

LPC800 costs 10x the price of ATtiny85. So moot point.

When the performance requirement go up 16-bit MCUs like PIC24 and MSP430 start to become serious contenders, and yet the 16-bit ones are still cheaper.

I am not sure about prices in your area, but cheapest PIC24 (PIC24F16KA101) with 16KB FLASH is 2 euro each, and the cheapest STM32F0 (STM32F030) I can get from Farnell is like 1,20 euro.

Additionally:
- That PIC24 has 1.5K of RAM, STM32 has 4K.
- PIC24 runs 16MIPS, STM32 runs 48MIPS.
- Both 20-pins
- Peripherals are neither here or there. PIC has 1 UART more, but STM has 12-bit ADC, DMA and more timers.

Ever tried MSP430?

Then for the most demanding uses the Cortex-A line start to become appealing (Allwinner A13, a Cortex-A8 chip in TQFP package, is available at $2 each; and a quad-core Cortex-A7 Allwinner A31s is available at $5 if you don't mind BGA)

Which almost forces you to use Linux, which brings in a whole slew of other problems.

The m3 and m4 chips are serving a very good purpose; they are powerful enough to do some 'heavy lifting' for an application, yet bare metal enough to work directly on hardware, you're not debugging a linux bootloader, etc.
OTOH you need more work to get even any networking up.

Why do you have issues with Linux? I use them day-to-day and you should be able to just KISS and use the stock kernel the manufacturer gave me, with everything I need written in user mode started using systemd.

[technix]

ARM is a learn once-fits-all solution which is also very efficient to use with a C compiler.

Here is your 8 pin DIP ARM cortex-M0 (don't look at Farnell pricing though; they are high at single quantities but will do free delivery even if you only order one):
http://uk.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-dip/dp/2320692

From there you can go all the way to the LPC1800 series (COrtex M3 at 180MHz) without needing to re-learn the chip or the peripherals since NXP kept these (virtually) the same across their entire range.

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M. AVR are equally as optimized for C, and the same peripherals goes from tinyAVR to megaAVR all the ways up to AVR UC32 chips (maybe different base addresses but with good programming habits that isn't that much of a problem.)

Just looking at the price is a bad idea in 99.9% of the cases. In the end you just waste more time than money is gained. Even when doing a hobby project banging your head against the wall due to a limit of an archaic 8 bit controller for an hour is a waste of money. If you spend that hour to deliver papers, work in a grocery store, etc you will make more money than the price difference of the chip.

I never have run into such limits. Since when I plan to use a microcontroller I first plan out features I need, and then I shot for the chip offering all the required features while hitting the price/performance sweet spot. So maybe you got your system design procedure back to front?

[asgard20032]

There are still some advantage to use 8 bit mcu. For example, most of the time, the core voltage is highter, and thus have better noise immunity. They are also able to have more current per i/o. Finally, they ofyen have better real time capability when it come to interrupt latency and predictibility, because of the lack of any pipeline. No pipeline = slower, but everything is more predictable.

[nctnico]

Why do you have issues with Linux? I use them day-to-day and you should be able to just KISS and use the stock kernel the manufacturer gave me, with everything I need written in user mode started using systemd.

I strongly doubt you ever build a mass produced product using embedded Linux. The stock kernel and bootloader often need a lot of bug fixing and modifications to become suitable for a product. Also getting support for the Allwinner chips outside China (let alone in understandable English) will be very hard. In the Western world it is better to stick with TI or NXP (formerly Freescale) for SoC which can be bought in small quantities and have guaranteed long term availability.

Just looking at the price is a bad idea in 99.9% of the cases. In the end you just waste more time than money is gained. Even when doing a hobby project banging your head against the wall due to a limit of an archaic 8 bit controller for an hour is a waste of money. If you spend that hour to deliver papers, work in a grocery store, etc you will make more money than the price difference of the chip.

I never have run into such limits. Since when I plan to use a microcontroller I first plan out features I need, and then I shot for the chip offering all the required features while hitting the price/performance sweet spot. So maybe you got your system design procedure back to front?

If the time for maintaining/learning several toolchains and learning several completely different chips is free then you can apply your method. In my experience it is better to concentrate on one large family with closely related peripherals to come up with a cost effective solution. Engineering is often the most expensive part of a project so cost savings there are easy money. Besides that knowing a certain family of microcontrollers very well helps to push them to the limits if necessary.

There are still some advantage to use 8 bit mcu. For example, most of the time, the core voltage is highter, and thus have better noise immunity. They are also able to have more current per i/o. Finally, they ofyen have better real time capability when it come to interrupt latency and predictibility, because of the lack of any pipeline. No pipeline = slower, but everything is more predictable.

By the time an 8 bit MCU has entered an interrupt an ARM probably has already executed it due to the much higher clock frequency and more efficient instructions. Remember a Cortex Mx saves the registers using hardware where an 8 bit MCU typically has to push these on the stack one by one.

[ade]

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M.

What kind of pricing are you getting there?

Here through normal distributors ATtiny85 is around 75 cents US (qty. 2000).  There are plenty of Cortex-M0 processors cheaper than that... STM32F030 is just 57 cents in similar quantities.  And Cypress PSoC 4 can be had for just 35 cents in 8-pin SOIC.

So unless you're getting ATtiny85s for 3.5 cents a piece I don't see this 10x price difference?

[technix]

Why do you have issues with Linux? I use them day-to-day and you should be able to just KISS and use the stock kernel the manufacturer gave me, with everything I need written in user mode started using systemd.

I strongly doubt you ever build a mass produced product using embedded Linux. The stock kernel and bootloader often need a lot of bug fixing and modifications to become suitable for a product. Also getting support for the Allwinner chips outside China (let alone in understandable English) will be very hard. In the Western world it is better to stick with TI or NXP (formerly Freescale) for SoC which can be bought in small quantities and have guaranteed long term availability.

All "modifications" done using user-mode code.

Also check the flag next to my (nonexistant) avatar before commenting on the language barrier. Also the linux-sunxi project did a fairly good job at documenting Allwinner chips in readable English.

Just looking at the price is a bad idea in 99.9% of the cases. In the end you just waste more time than money is gained. Even when doing a hobby project banging your head against the wall due to a limit of an archaic 8 bit controller for an hour is a waste of money. If you spend that hour to deliver papers, work in a grocery store, etc you will make more money than the price difference of the chip.

I never have run into such limits. Since when I plan to use a microcontroller I first plan out features I need, and then I shot for the chip offering all the required features while hitting the price/performance sweet spot. So maybe you got your system design procedure back to front?

If the time for maintaining/learning several toolchains and learning several completely different chips is free then you can apply your method. In my experience it is better to concentrate on one large family with closely related peripherals to come up with a cost effective solution. Engineering is often the most expensive part of a project so cost savings there are easy money. Besides that knowing a certain family of microcontrollers very well helps to push them to the limits if necessary.

So your practise in maintaining code portability is terrible. Ugh stinky code detected. When you mask off the difference between architectures and chips using BSP routines and good system design the choice of chip will become trivial. I am a CS major, so detecting this type is code problems is almost instincts.

There are still some advantage to use 8 bit mcu. For example, most of the time, the core voltage is highter, and thus have better noise immunity. They are also able to have more current per i/o. Finally, they ofyen have better real time capability when it come to interrupt latency and predictibility, because of the lack of any pipeline. No pipeline = slower, but everything is more predictable.

By the time an 8 bit MCU has entered an interrupt an ARM probably has already executed it due to the much higher clock frequency and more efficient instructions. Remember a Cortex Mx saves the registers using hardware where an 8 bit MCU typically has to push these on the stack one by one.

And you just burned off 10% more energy than the 8-bit puppy.

[nctnico]

If the time for maintaining/learning several toolchains and learning several completely different chips is free then you can apply your method. In my experience it is better to concentrate on one large family with closely related peripherals to come up with a cost effective solution. Engineering is often the most expensive part of a project so cost savings there are easy money. Besides that knowing a certain family of microcontrollers very well helps to push them to the limits if necessary.

So your practise in maintaining code portability is terrible. Ugh stinky code detected. When you mask off the difference between architectures and chips using BSP routines and good system design the choice of chip will become trivial. I am a CS major, so detecting this type is code problems is almost instincts.

There is more to maintaining portable code. Actually my standard library runs on many different microcontrollers from 8 bit to 32 bit but there is much more to it. If you need to write a BSP to support many different microcontroller then you have to put time and effort into supporting different UARTs, different SPI peripherals, different I2C peripherals etc. That is time and money wasted if there is no clear advantage (=benefit for the customer) between one microcontroller and the other. Also in many cases you need very fine control over a peripheral which makes a universal library (BSP) extremely bloated and heavy. For example: I'm currently working on a 'driver' for an SPI based AD converter which needs very specific and command dependant wait times between commands, reading data and finishing an SPI transaction. Ofcourse it is a nice software excersize to add such functionality to a generic (portable) library but it doesn't add any benefit/profit for the customer.

[Brutte]

So why people find Cortex-M so attractive?

Old "Why is ATMega2560 so expensive when compared to 32-bitters" discussion on avrfreaks.

[nctnico]

Why do you have issues with Linux? I use them day-to-day and you should be able to just KISS and use the stock kernel the manufacturer gave me, with everything I need written in user mode started using systemd.

I strongly doubt you ever build a mass produced product using embedded Linux. The stock kernel and bootloader often need a lot of bug fixing and modifications to become suitable for a product. Also getting support for the Allwinner chips outside China (let alone in understandable English) will be very hard. In the Western world it is better to stick with TI or NXP (formerly Freescale) for SoC which can be bought in small quantities and have guaranteed long term availability.

All "modifications" done using user-mode code.

Good luck making a user selectable kernel boot logo that way. Oh, and centre it on screen while you are at it.

[hans]

.... post on my reply .....

What I meant to say with compilers & toolchain is, that you're not "locked in" to 1 vendor. What I tried to say is, AVR is not an ARM core which so many vendors now share.
If I decide to roll into Atmel today, I need to install another compiler on my system (not a problem on Linux), but also need my projects to cope with that. That also means programmers, etc. In case of AVR, the odds are not that bad because they have lots of OSS goodness, but for Microchip or 8051 these odds are a lot lower.

You can write all the BSP code you want to hide platform differences, but once you have some intense interaction with a peripheral that's all worthless. After all the power in using microcontrollers is close interaction with the hardware and peripherals, not particularly the ability to abstract everything.
This is not something a Cortex Ax CPU with Linux can capture. E.g. some applications I have had need interrupts processed at 100-500kHz rate, each with a latency and completion of <1us.


I think pricing is different here in Europe/US than in China. From my experience, Atmel has always been really expensive compared to Microchip, and that is now really expensive to some ARM chips if you compare just on performance and peripherals like I said. The LPC800 is about as expensive as an attiny85 at Farnell.

If I talk about a really "low-end" application; I mean read a switch, blink a LED, and be done. Sure use a PIC/AVR/etc. I use them for this sole purpose only. For anything else, I move on from 8-bit.
An IoT device can also be low-end, but outgrow an AVR in terms of memory requirements. There are Cortex m0+ boards from Freescale that have good low-power performance compared to 8-bit chips.

The $2 Allwinner A13 is quite an unfair comparison for "high end" stuff. Yes it's a nice chip for it's power & cost, but it's also obsolete by the manufacturer (unless you buy 10k) after a year because the consumer market moves on. The ARM Cortex chips you compare them with should be available for 10+ years if the manufacturers reputation is anything worth.

Additionally, you need to route DDR2/DDR3 RAM, which only comes in BGA, needs more layers, more engineering time, which is not exactly cheap.
And on top of that: what about power? Those Cortex Mx's consume like 100mW ; how much MHz can you get from a A13 in say 500mW coupled with FLASH + DDR3 memory/termination?

Can't comment on MSP430, but for what I know it's all very similar. They are both 16-bit. Starter chips both run in the 10-30MIPS. Starter chips both are <2K RAM range. And MSP430 may have some nicer analog peripherals. I just happen to pick PIC24 because that's what I work with.


Don't get me wrong - I love linux. I use it as my daily driver. But linux is a very complex system to debug. Sure there are very powerful tools available, but what is the equivalent of a "blinky" on a SoC? Successful kernel boot + all peripherals configured + memtest OK? Although once you've reached that stage you got a lot more power available on Linux than bare-metal, it's also a lot more intensive process to first set up than anything else.

[rstofer]

Simply put, the ARMs are a virtual garbage can for holding code.  You can write until you're blue in the face without worrying about space (well, hardly worrying).
There's a place in the spectrum for everything.  Even the 8051 and clones are still dominating a portion of the market.  That device will never die!  There are PICs like that as well.  The 16F877 is a very nice 40 pin chip.  I have used a couple of others that I like but it has been years.

In the land of PICs, particularly the smaller devices like the 16F series, the architecture just sucks.  Banking and paging are archaic.  The compilers generate more code to deal with these two issues than they do for the application.  Just look at the assembly code!  For the assembly language programmer, they are a PITA.  Move some code around and you can wind up with page breaks.  Ugly!

The AVRs have a much nicer architecture and C compilers work well.  They have a lot of peripherals and, in general, are much superior to 16Fs.  But nobody cares!  That's why Microchip is buying or has bought Atmel.  A whale eating a minnow.  Obviously, nobody asked me!  Kind of like VHS versus Betamax.  Everybody knew Betamax was superior but everybody bought VHS.

At this point, the ARM architecture is EVERYWHERE.  There is a huge selection and speeds are pretty good.  Compilers are well developed and code generation looks pretty good.  And you don't have to spend a moment thinking about paging or banking.  You do have to define your memory layout for the linker script but that's about it.  It's just plain easier to get the code written.

However...  If I have to interface with the 5V world, I'm going to look long and hard at the AVRs.  But the 5V world is disappearing.  Next we'll be dealing with the 1.8V world.  Everything changes.

When you write your resume, detailing your experience with the smaller PIC family won't get you an interview.  The PIC32, yes, PIC16, no.  ARM will get you an interview.

[dannyf]

the architecture just sucks. 

When was the last time that it mattered to you?

I often find it ironic that the people who bring up "architecture" arguments tend to have the least understanding of architecture.

A form of over-compensation?

The compilers generate more code to deal with these two issues than they do for the application. 

What statistics do you have to back that up?

When you write your resume, detailing your experience with the smaller PIC family won't get you an interview.  The PIC32, yes,

when you have a company that hires you for your pic32 skills, run away from that company,

[Jeroen3]

An ARM Cortex M with it's linear address space allows for more complex software architectures, and it is no longer a no-go to use C++. Even in the M0's.
The instruction set and design are also newer, they put more thought in using them with C(++) and operating systems.

But if you're looking for an 8-pin Cortex-M chip, then your application is probably simplistic, or overly complicated, who knows that i2c devices you have.
The silicon of an ARM chip is too large for an 8 pin plastic. You can get WLCSP though.

Remember that for ARM, you pay royalties. That is why 8051 is cheap, the IP is not expensive.

[rstofer]

the architecture just sucks. 

When was the last time that it mattered to you?

I often find it ironic that the people who bring up "architecture" arguments tend to have the least understanding of architecture.

A form of over-compensation?

Every time I write any PIC assembly code.  True, I haven't played with them in several years but I used to use them for just about everything from robotics to Halloween effects.
I do know just a bit about architecture.  MSEE in computer design, for example.  Minor in software.  Alas, it was a long time ago - back when DEC was king of the minis and the 8080 was just hitting the hobby community ('76)

Seriously, table lookups using RETLW?  Sure, it works but it seems awkward.

The compilers generate more code to deal with these two issues than they do for the application. 

What statistics do you have to back that up?

Just a brief perusal one day and I noted that every call to a function, regardless of where it was located, was surrounded by page switching.  There was a lot of bank switching as well.  Numbers, statistics, not so much.  I just saw the code and shrugged.  It all adds up to overhead both in terms of code space which tends to be limited and execution speed.  Does it matter?  I suppose it depends on the application.  When I was working with PICs, I did very little coding in C.  I rather enjoyed the transition to the AVR stuff.  I'm just too lazy to want to do a lot of assembly coding.

When you write your resume, detailing your experience with the smaller PIC family won't get you an interview.  The PIC32, yes,

when you have a company that hires you for your pic32 skills, run away from that company,

I kind of like the PIC32 mostly because of the sample code that includes a complete TCP/IP stack for wired or wireless.  I certainly felt more at home than I did with the STM32 when I first started playing with it.  For the last several years, I have been playing with chips like the LPC2106, LPC2148 and LPC1768 (mbed).  I really like having the ability to drag and drop the executable onto the mbed virtual disk drive.  If I was prototyping a project and needed performance beyond the Arduino, the mbed would be my first choice.  Actually, it might be my first choice anyway.  It doesn't hurt that the user doesn't even need to install a toolchain because everything can run through a browser.  Very cool!

I also used a PIC32 to create a USB HID device and wrote a little shim C code on the PC to add physical knobs and dials via the PIC32 straight into Microsoft Flight Simulator.  That was a cool project!

The PIC32 is based on the MIPS architecture and instruction set.  This type of device is built by a number of manufacturers of which Microchip is only one.  Nice chip!

[Psi]

Going quickly from nothing to a working solution is easier on AVR8 compared to STM ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the STM peripherals are harder to understand compared to AVR.
That said, once you learn it all, it's not that bad.

[nctnico]

Going quickly from nothing to a working solution is easier on AVR8 compared to ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the peripherals are harder to understand compared to AVR.
That said, once you learn how all the clocks/peripherals work its not that bad.

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

[rstofer]

Going quickly from nothing to a working solution is easier on AVR8 compared to ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the peripherals are harder to understand compared to AVR.
That said, once you learn how all the clocks/peripherals work its not that bad.

Yes, the ARM User Manual is a lot thicker than the AVR8 manual and there are a lot of gotchas.  But it still gets down to what you have been using lately.  Sure, I can use the PIC 16F and some of the AVRs but I haven't touched them in about 5 years.  I could start an ARM project with no special research.  But that is also one of the strong features of the Arduino - it may be an AVR but the library wraps around it pretty well and there is a ton of sample code around.

Why do people ever use a Basic Stamp?  Because there is a ton of sample code.  The solution will not be elegant but it will be done fast.

ALL of my projects are hobby level.  As such, the cost of the uC is unimportant.  My time is worth some number even though I am retired.  If I price it at $100/hr then, really, component cost is meaningless.  What can I get working, fast?  That's the only question.  What's laying on my desk and how can I get it to work?  I'm only going to build one, cost isn't a factor.

[Psi]

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

yeah, I edited that. You were too quick.
Meant to say STM ARM

[nctnico]

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

yeah, I edited that. You were too quick.
Meant to say STM ARM

I decide not to mention ST earlier but I agree; from what I have seen and experienced (the latter a long time ago) the ST peripherals are all over the place. NXP is much better in that respect: consistent between devices and well documented. Each chapter for a peripheral starts with how the peripheral's power, clock and I/O pins must be setup with clickable links in the PDF straight to the right table.

[technix]

Going quickly from nothing to a working solution is easier on AVR8 compared to ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the peripherals are harder to understand compared to AVR.
That said, once you learn how all the clocks/peripherals work its not that bad.

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

If I want to run my ATtiny85 at 16MHz internal PLL as the clock source (a fairly complicated setup) I need zero setup code. Just program the fuse bits appropriately and go.

[westfw]

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M.

What kind of pricing are you getting there?

This is an important question that you seem to be avoiding answering.
At Digikey, I can get an ATtiny85 for about $1.40 (q11)  (seems "too expensive" to me, but that's what I get.)
In similar quantities, the follow ARM chips (with 32 pins or less) are cheaper.  All have faster clocks, more memory, and (arguably) better peripherals (ie a UART!)

NXP (freescale) MKL03Z
Atmel SAMD09D14
NXP (freescale) MKL02Z
SiLabs EFM32ZG108F16
ST STM32F030F4P6
NXP LPC812M
SiLabs EFM32GZ110F16
Nuvoton Mini54

there are some more (including 8pin chips) if I reduce the requirement to 8k program space (like the tiny85.)

As other people have pointed out, the pricing issues get  (even less clear for bigger parts.  The cheapest AVR I can find with 128k of program memory is about $7 (and frankly, the AVR architecture starts to get ugly above 128k.)  There are 25+ PAGES of ARMs before I hit that price/memory combination.  In fact, the cheapest (about $2) has 256k of program space.

I like AVRs.  They are simpler to use.  But the added complexities of an ARM are hardly insurmountable!

Now, the vendors that market a 8k ARM to replace a 8k 8bit cpu worry me, because a lot of the code that one puts on a small 8bit cpu is NOT the sort of thing that gets smaller because you have a 32bit micro. But I don't have much fear that a 16k ARM won't work.  And it's getting to the point where that WILL be the more economical choice.

[technix]

At 10x the price of ATtiny85 this is why I say at the low end the price/performance is not optimal for Cortex-M.

What kind of pricing are you getting there?

This is an important question that you seem to be avoiding answering.
At Digikey, I can get an ATtiny85 for about $1.40 (q11)  (seems "too expensive" to me, but that's what I get.)
In similar quantities, the follow ARM chips (with 32 pins or less) are cheaper.  All have faster clocks, more memory, and (arguably) better peripherals (ie a UART!)

NXP (freescale) MKL03Z
Atmel SAMD09D14
NXP (freescale) MKL02Z
SiLabs EFM32ZG108F16
ST STM32F030F4P6
NXP LPC812M
SiLabs EFM32GZ110F16
Nuvoton Mini54

there are some more (including 8pin chips) if I reduce the requirement to 8k program space (like the tiny85.)

As other people have pointed out, the pricing issues get  (even less clear for bigger parts.  The cheapest AVR I can find with 128k of program memory is about $7 (and frankly, the AVR architecture starts to get ugly above 128k.)  There are 25+ PAGES of ARMs before I hit that price/memory combination.  In fact, the cheapest (about $2) has 256k of program space.

I like AVRs.  They are simpler to use.  But the added complexities of an ARM are hardly insurmountable!

Now, the vendors that market a 8k ARM to replace a 8k 8bit cpu worry me, because a lot of the code that one puts on a small 8bit cpu is NOT the sort of thing that gets smaller because you have a 32bit micro. But I don't have much fear that a 16k ARM won't work.  And it's getting to the point where that WILL be the more economical choice.

That is exactly what I am talking about. For smaller project there is little point using a 32-bit MCU, and when the project grew beyond that I start to slice it into smaller, usually swappable modules each with a 8-bit on it arranged in a bus controlled by an Cortex-A at the central location. Maybe it is my CS background and the UNIX philosophy (do one thing, do it well, and no other) at play.

[westfw]

there is little point using a 32-bit MCU

At what point do you say instead "There is little point to NOT using a 32bit MCU"?
Personally, I decided that I really don't like the warts that get grafted onto 8bit architectures to handle address spaces bigger than 16bits (in either RAM or Program space), so if an application looks like it will get that big, I'll be reaching for a 32bit CPU.  With today's GUIs and Networking stacks, this happens all too often...)

I see having a basically identical architecture that spans from 8k/2k to 4M/256k to be a big win, too.  Once you start using those bigger 32bit chips for your bigger apps, it becomes harder to justify using a different architecture just because your app is smaller.

A more troubling question is when you should throw away your custom microcontroller design and  throw in one of those $10 linux modules.
(Don't use a linux command-line app running as root to blink your LEDs, though!  http://www.theregister.co.uk/2016/04/04/devastating_bug_pops_secure_doors_at_airports_hospitals/ )

[nctnico]

Going quickly from nothing to a working solution is easier on AVR8 compared to ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the peripherals are harder to understand compared to AVR.
That said, once you learn how all the clocks/peripherals work its not that bad.

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

If I want to run my ATtiny85 at 16MHz internal PLL as the clock source (a fairly complicated setup) I need zero setup code. Just program the fuse bits appropriately and go.

Having to set fuse bits during programming is even worse! It is an extra step in the production process and that often needs manual intervention in smaller companies. In other words: time and money gets wasted very easely if someone forgets about the fuse bits. Better have one self containing firmware file which gets programmed into a microcontroller and sets up everything the way it should be.

[Jeroen3]

A proper production programming tool will do 1 single run to write the ROM and program the fuses.
There is no "forget" unless you use AVR Studio for production programming, which shouldn't be used for production in the first place.

The people doing production will need a one button application, which ends with a green or a red screen.

[nctnico]

A proper production programming tool will do 1 single run to write the ROM and program the fuses.
There is no "forget" unless you use AVR Studio for production programming, which shouldn't be used for production in the first place.

The people doing production will need a one button application, which ends with a green or a red screen.

And now ask yourself who is going to setup that production tool to write both the hex file AND the right fuses. Then ask yourself what is going to happen if that person leaves the company and someone new needs to take over his/her tasks.

[Jeroen3]

The production chief, according to the documented procedures. If there are not procedures, leave the place and don't look back.

[nctnico]

The production chief, according to the documented procedures. If there are not procedures, leave the place and don't look back.

It is easy to clad everything with procedures and papers but if a procedure can be avoided then it makes life a lot easier because people don't read or forget. With self contained hex files you only have one recipe which is equal for every product. If fuses need to be set then things get more complicated quickly because you have to document that all the way down to the production floor. It is the simple things which are often underestimated by just looking at component cost and/or what looks easier to the engineer.

[technix]

Going quickly from nothing to a working solution is easier on AVR8 compared to ARM. Simply due to the ARM complexity, sorting out all the clocks etc, and the peripherals are harder to understand compared to AVR.
That said, once you learn how all the clocks/peripherals work its not that bad.

Nonsense. Just use some simple startup code from an example and you are all set. Whether the peripherals are harder depends on which vendor you choose. Some have complicated peripherals while others have simple ones (which do the job just as well BTW).

If I want to run my ATtiny85 at 16MHz internal PLL as the clock source (a fairly complicated setup) I need zero setup code. Just program the fuse bits appropriately and go.

Having to set fuse bits during programming is even worse! It is an extra step in the production process and that often needs manual intervention in smaller companies. In other words: time and money gets wasted very easely if someone forgets about the fuse bits. Better have one self containing firmware file which gets programmed into a microcontroller and sets up everything the way it should be.

Not really if you use the right tools. avr-gcc as well as Atmel's flash tool both support direct ELF flashing which means that the fuses is just part of the code itself. avrdude don't support this natively, but adding support is as simple as a little Makefile trick

[botcrusher]

32bits? Who needs arm! I can just coax four AVRs to run at the same time!
_{if you can get passed race conditions, among other things}
No Its not practical for most use cases, but in all my applications i could get away with this.

[Brutte]

Meant to say STM ARM

I have inserted a link to a GPIO blinky for AVR8 and STM32 in my previous post. Please point out which of these three LOCs are so complicated.

If someone has a similar peripheral comparison on register level (like SPI, UART or I2C) in between STM32 and AVR8 I think it would be interesting to show it here. I'd be surprised if there was anything more required than 1:1 correspondence in between both codes.

Mind some peripherals are impossible to compare as for example ADCs on STMs are 30 times more advanced/feature rich as dumb ADC on AVR8s but there are other peripherals that provide quite similar functionality (like for example motor control AT90PWM or XMega and some simpler STM32 timers).

As of the clock tree - the power-up internal RC runs absolutely fine on all STM32s I have used.
These require exactly 0 lines of code to configure HCLK (most of them for 8MHz). Typical STM32 at 8MHz is still around 2 times faster than 32MHz AVR8 in terms of processing power. Concluding, STM32 is more complicated than AVR8 in that clock-tree matter only if you want to push it to the HCLK limit. If you do not want to dig into clock tree then either leave a default RC or use an ST template or wizard for system_init.

BTW, I wonder if AVR8s are sooo clock-tree easy, how come half of the avrfreaks posts start from

Help, i have misconfigured a clock tree/fuses, cannot communicate with the device!

[dannyf]

I am willing to use any chip if I have to, for better performance.

I'm slightly different: I am willing to use any chip if I have to, for good enough performance.

I use a broad range of chips in my hobby but prefer the 8-bitters for simplicity and the challenge - it requires considerable amount of work to get more out of attiny85 than a stm32f3103. and that's fun.

For professional work, the 8-bit market is dead for new designs, and costs, at least for the kind of work I do, are dominated by software costs: development, licensing, certs, and maintenance. Because of that, 32-bit chips are far more preferred.

[glenenglish]

simple answer

the AVR is a more simple device. the peripherals (chip hardware) are simple, the core is basic.
but it is 100% of what 90% of people need.

if you are learning microcontrollers, the AVR is the right place to start.

the cortex M* is very  complex in comparison. like the timer in an AVR has 2 registers, in the cortex, it might have 16 ....

If you dont understand enough at the low level end, my opinion is that you will never be truly effective with micricontrollers.

So, get proficient with AVR, and then move to cortex.  I recommend writing all the interfacewith the chip hardware yourself, only then will you understand it. I don't use the peripheral driver libraries, either in STM for same reason.

Glen
35 years of microcontroller experience.

[dannyf]

So, get proficient with AVR, and then move to cortex. 

Agreed. an AVR, or a 8051, or a PIC, isn't fundamentally different from an ARM chip. What varies is the complexity, both in software and in hardware.

I recommend writing all the interfacewith the chip hardware yourself, only then will you understand it. I don't use the peripheral driver libraries, either in STM for same reason.

I took a different approach: I wrote my own middle layer on top of the oem library. It gets me up and running quickly. However, if I were to move to a different oem library (hopefully not) or to write my own library for performance, I don't have to re-write my application code as I can simple rewrite the middle ware and the rest is fully transparent to my application code.

[nctnico]

simple answer

the AVR is a more simple device. the peripherals (chip hardware) are simple, the core is basic.
but it is 100% of what 90% of people need.

if you are learning microcontrollers, the AVR is the right place to start.

the cortex M* is very  complex in comparison. like the timer in an AVR has 2 registers, in the cortex, it might have 16 ....

Sorry but this comparison is nonsense if you don't specify which controller you are referring to. Please stop spreading FUD!
An ARM Cortex-Mx may have 16 registers for a timer but there are also those with simple timer peripherals and/or you don't need those 16 registers to setup a timer. On an NXP ARM Cortex Mx it takes 7 lines of code (I just counted them) to setup a timer interrupt (including clock, power and interrupt controller). Also the interrupt function doesn't need special C syntax to declare it as an interrupt handler.

[Jeroen3]

There are major differences between timers on AVR, NXP and ST.
Where AVR and NXP feature simple timers. Up/Down, match, outputs and interrupts. But NXP has 32 bit timer, where AVR have 16 if you're lucky.
ST has overfeatured timers, it starts with 3 different types of timers. And they can do almost everything you can think of.

[donotdespisethesnake]

AVR is obsolete, I wouldn't be surprised if Microchip ditch the whole range.

I see a lot of jobs looking for ARM experience, none are looking for AVR.

[eck]

the cortex M* is very  complex in comparison. like the timer in an AVR has 2 registers, in the cortex, it might have 16 ....

"might" is the keyword here. But consider for example the Cortex M0 based Kinetis MKL03, it's timer is inherited from the HCS08. So is the I2C module. Ancient 8 bit stuff. Or consider the STM8 (nice 8 bit architecture!), where some peripherals are common with the bigger STM32. And if you're counting registers, take the LPC800 which uses four registers for its timer (I couldn't BTW see how you got to two registers for the AVR timer).

The lines are blurred, and I find it much more important to look at other criteria like tool support, vendor support, library quality, third party community, upgrade paths, and vendor viability when selecting an MCU.

[dannyf]

But consider for example the Cortex M0 based Kinetis MKL03, it's timer is inherited from the HCS08. So is the I2C module. Ancient 8 bit stuff. Or consider the STM8 (nice 8 bit architecture!), where some peripherals are common with the bigger STM32. And if you're counting registers, take the LPC800 which uses four registers for its timer (I couldn't BTW see how you got to two registers for the AVR timer).

those chips (MKL03, LPC800, and STM32F0 - which shares just the simplest timers with STM8) are mostly low-end chips meant to compete with 8-bit chips.

On the other hand are chips with far more complex peripherals, like the LM3S chips, or the advanced timers from ST, they require far more to configure than the ones mentioned above.

A good example is the gpio modules. A few registers for 8-bit chips but generally a gazillion of registers for the bigger ones.

I think the original point of increased complexity holds in general.

[Svuppe]

I work for a company where we use both AVR and ARM processors in several products. AVRs have some advantages in startup time (practically instant vs booting an OS on the bigger ARM). And the very low standby power of some of the AVRs are hard to do on larger systems.

[nctnico]

But consider for example the Cortex M0 based Kinetis MKL03, it's timer is inherited from the HCS08. So is the I2C module. Ancient 8 bit stuff. Or consider the STM8 (nice 8 bit architecture!), where some peripherals are common with the bigger STM32. And if you're counting registers, take the LPC800 which uses four registers for its timer (I couldn't BTW see how you got to two registers for the AVR timer).

A good example is the gpio modules. A few registers for 8-bit chips but generally a gazillion of registers for the bigger ones.

I think the original point of increased complexity holds in general.

No it does not. You are mistaken 'more possibilities' with 'complexity'. For simple tasks a potentially versatile timer module is still simple to setup (if it is well designed). If you just need a timer to fire an interrupt at a certain interval the complexity of setting up the timer is equal on about every microcontroller (unless the timer module has been designed in an obfustigated way -look at the archaic 8051 for a good example-).

[Kleinstein]

On big difference between AVRs and ARMs is that on startup the AVR has every clock active (maybe except the ADC clock) - an an ARM you have to configure all the clocks first. So this makes small beginner projects a little more complicated. An definitely more to read in the manuals. In more complex cases you may have to disable parts in the AVR to save energy.

One good think about the AVRs (except the early Xmeags) is the rather short list of erratas - this really helps if nearly everything works as in the manual. What is something like a second IRQ level on the PIC18 good for it the errata says don't use it because it does not work (not sure if still valid for newer ones). Just the more complex hardware makes the erratas for the ARMs longer - at least as far as I saw it.

Once you need more memory (e.g more than 16 K) the AVRs and 8 bit PICs tend to be rather expensive. So the the M0..M4 cortex chips have there place.

[asgard20032]

But if its 0.5 ua + 2 ua for some divider and others components + limit->0 for mcu, its better than 0.5 ua + 2ua for some divider + 1.3 ua for mcu. Also, since mcu incorporate more and more, there is less and less of other components. So its just logic to optimize the mcu.

[richardman]

For the simple things that AVR can do, our JumpStart API makes it just as easy (for the STM32F0xx and STM32F4xx for now, and more later). Need to set up a clock (and who doesn't?) and initialize an UART and the SYSTICK timer?

   
    jsapi_clock.SetSystemClock(0, 8, 0, 96, 5);
    jsapi_cortex_core.SysTick_Timer(SYSTICK_MILLISECOND);

    //Initialize serial port, this works for STM32F411RE
    usart1.SetPins(&portb, 6, 7, &portb, 7, 7);
    usart1.MakeUSART(9600, 8, 1, true);

    printf("\n\nAttempting to configure CC3100.\n");

I am not entirely clear why cost is such a concern for personal / hobbyist uses. I mean if you are doing a one-off moisture sensor for your plants, does it matter whether it's a $0.50 chip or $2.50 chip? And for quantity purchases, as many people mentioned, the Cortex-M0 and -M3 are quite cost effective. Finally, if you move to Cortex-M4 and -M7, there's nothing in the AVR that can compare.

[dannyf]

Finally, if you move to Cortex-M4 and -M7, there's nothing in the AVR that can compare.

So what? the fact that no AVR competes with CM4/CM7 makes the CM4/CM7 superior?

If you move to a SOT23 package, there is nothing in CM4/CM7 or even Pentium Xeon that can compare. Does that make a PIC10F200 better than any of those mentioned?

Obviously not. You pick a chip for an application. an AVR is obviously not meant to compete with CM4/CM7, just as a CM4/CM7/Xeon isn't meant to compete with 10F200. That doesn't make one chip superior to others. It just makes one more suitable to a given application than others.

[nctnico]

I am not entirely clear why cost is such a concern for personal / hobbyist uses. I mean if you are doing a one-off moisture sensor for your plants, does it matter whether it's a $0.50 chip or $2.50 chip?

Well people want to get things cheap and only look at component costs because they lack the ability put a value on their time. Sometimes I'm a sucker for the appearantly cheaper option too but I'm trying hard to change which is hard when being Dutch...

[technix]

Finally, if you move to Cortex-M4 and -M7, there's nothing in the AVR that can compare.

So what? the fact that no AVR competes with CM4/CM7 makes the CM4/CM7 superior?

If you move to a SOT23 package, there is nothing in CM4/CM7 or even Pentium Xeon that can compare. Does that make a PIC10F200 better than any of those mentioned?

Obviously not. You pick a chip for an application. an AVR is obviously not meant to compete with CM4/CM7, just as a CM4/CM7/Xeon isn't meant to compete with 10F200. That doesn't make one chip superior to others. It just makes one more suitable to a given application than others.

It's the 21st century, and why people still think SOT23 == small?
I've been using DFN and QFN chips for 6 years, and I simply do not use any TSSOP that is bigger then TSSOP20, and no SOIC bigger than SO8 anymore.
With DFN or QFN packages, there are tons of candidates smaller than SOT23, you do not even have to touch any BGA or LGA.
PS, I have higher soldering yield on xFN than xSOT/xSOP. The center pad auto centering is just a wonderful gift form god himself.

Good luck hand soldering those DFN/QFN packages with a properly soldered pad connection. I have not seen any DFN/QFN physically smaller than a SOT-23, and when you put the perspective of available board space those DFN/QFN's consume more board area than SOT23's or SO's (since you can put tracks and vias beneath those leaded packages, but not DFN/QFN's)

[Bruce Abbott]

It's the 21st century, and why people still think SOT23 == small?

Some of us still only have 20th century eyes!

[richardman]

Finally, if you move to Cortex-M4 and -M7, there's nothing in the AVR that can compare.

So what? the fact that no AVR competes with CM4/CM7 makes the CM4/CM7 superior?

If you move to a SOT23 package, there is nothing in CM4/CM7 or even Pentium Xeon that can compare. Does that make a PIC10F200 better than any of those mentioned?

Obviously not. You pick a chip for an application. an AVR is obviously not meant to compete with CM4/CM7, just as a CM4/CM7/Xeon isn't meant to compete with 10F200. That doesn't make one chip superior to others. It just makes one more suitable to a given application than others.

I am saying that for any future designs, the Cortex-M lines do seem to have a lot going for them :-) For example, we just released an OEM production ready wifi module. The default config uses the STM32F411 for high performance, but for quantity purchases, customers can order the F070 option for low cost products. We made sure the pinouts are mostly the same so there are very compelling reasons to go with the STM32 lines for that. Probably we can also have gone with NXP or some other lines too. The point is that we cannot have designed these lines of products and offer a choice of MCU for quantity purchases with the AVR. The plan is to have a low power STM32L0 option as well, but we have not done enough research on how feasible that option is yet.

Then we have even newer products in development that will have an M7 core with 64MBytes of SDRAM. The JumpStart API equalizes the access API across the STM32F lines, without going to the full abstraction of the Arduino software and lose capabilities, so this is a plus for our customers.

[ez24]

 

[richardman]

It's the 21st century, and why people still think SOT23 == small?

Some of us still only have 20th century eyes!

20th Century! I can't even see those damned legs

[glenenglish]

I'd stay clear of XMEGA though. I think ATMEL went backwards with that. The simplicity of accessing IO pins just about went out the window.
and AVR32- why bother when ARM is around.

If you need XMEGA you probably should take the step the cortex ARM. 

I used Codevision on AVR.

I use STM - L1, F3, F4, F7 and use  Rowley Crossworks IDE.

[Kjelt]

Obviously not. You pick a chip for an application. an AVR is obviously not meant to compete with CM4/CM7, just as a CM4/CM7/Xeon isn't meant to compete with 10F200. That doesn't make one chip superior to others. It just makes one more suitable to a given application than others.

I agree with Danny here.
I think most decisions engineers make are based on what they already know and have the tools for, then when finally there comes a project that is not possible with the available uC's + tools they decide to look further.
Still the current ARM offering is in the 3P's (price / packagesize / power) so good and wide that it is hard not to start.
Some project that will not fit on that 8 bitter will sooner or later come to your doorstep and you better be prepared.

[westfw]

an AVR is obviously not meant to compete with CM4/CM7, just as a CM4/CM7/Xeon isn't meant to compete with 10F200.

Sure.  But the ARM marketing folk have been touting/advertising/etc the Cortex M series chips as "8 bit replacements" since the first Luminary Stellaris (the first available CM3) chips came out, and the question now is "when exactly does that make sense, and when does it not make sense?"
Why exactly would a 100pin 256k/64k CM3 chip (ATSAM3X4CA) NOT compete with a 100pin 256k/8k AVR chip (ATmega2560)? (at about the same price, BTW.  And the ARM has CAN, Ethernet, and USB not present on the AVR.  And I can jump the RAM to 512k/96k while the AVR is already "end of the line.")

[BravoV]

Comparing the AVR8 vs Cortex-M is just plain wrong since the beginning or from the 1st post guys !

To me, I feel ....

Especially using "feeling" to make the decision at such heavy technical and/or business driven/oriented subject, thats ain't right.

Better change the topic into art discussion.

My 2 cents.

[Jeroen3]

An art discussion won't end either.

[technix]

I'd stay clear of XMEGA though. I think ATMEL went backwards with that. The simplicity of accessing IO pins just about went out the window.
and AVR32- why bother when ARM is around.

If you need XMEGA you probably should take the step the cortex ARM. 

I used Codevision on AVR.

I use STM - L1, F3, F4, F7 and use  Rowley Crossworks IDE.

AVR32 and XMEGA are never something I would consider, so id Cortex-M7. My default processor choice go from tinyAVR to megaAVR to maybe Cortex-M3 to Cortex-M4 to Cortex-A7.

Since I am a UNIX person (OS X and Linux are my daily drivers) I used avr-gcc & avrdude for AVRs and clang/LLVM & OpenOCD for ARM.

[Svuppe]

I'd stay clear of XMEGA though. I think ATMEL went backwards with that. The simplicity of accessing IO pins just about went out the window.

I am curious. What do you find troublesome with the IO of the XMega series?
I have used AVRs from the earliest 90S1200 to the XMega of today, and i haven't noticed any radical change in how IO should be handled. Yes, the XMega has more possibilities with pull configuration  (and extra registers to configure this), but in the end you still have the IN, OUT and DIRECTION ports just as the normal AVRs.

[JPortici]

Using pics, not avrs... but as mentioned before: in the end it's about complexity and how good you know the chips..

I'm a sucker for pic10 and pic12: really small footprints if needed, sub uA sleep current, advanced peripherals so that most time the only thing that the core actually do is move registers around and check flags. Same applies to dspics, when i need to do some math

why do i need 32 bits for that? you can use a ferrari to go from point a to point b, but it might be 10 meters away so you could just walk.

[zapta]

why do i need 32 bits for that? you can use a ferrari to go from point a to point b, but it might be 10 meters away so you could just walk.

Because if you drive those 10 meters, you don't need to learn walking, just driving. That is, why spending time learning niche skills and local optimizations?

[nctnico]

I'm a sucker for pic10 and pic12: really small footprints if needed, sub uA sleep current, advanced peripherals so that most time the only thing that the core actually do is move registers around and check flags. Same applies to dspics, when i need to do some math

why do i need 32 bits for that? you can use a ferrari to go from point a to point b, but it might be 10 meters away so you could just walk.

Imagine you had shoes you could use for both walking and running at 100mph. That is what ARM gives you in one package: shoes to walk slow, run and be superman at the same time! That is why starting with an 8 bit architecture is so bad nowadays. It is a waste of time and effort because it gives you no advantage at all.

[Kleinstein]

If you really need it very small, very low standby current of direct 5 V interface the ARMs just don't do it. Another thing that is difficult with an ARM based µC is using the delay from code run time to get accurate timing - the simple 8 Bit µCs have very predictable timing and thus can use the execution speed for exact timing, even if this usually needs ASM coding.

Many applications just don't need a lot of CPU speed - so even an AVR running at 32 kHz can work.

[JPortici]

And limit yourself to only one option? what if you have to work with last year electronics? (i am thinking to start learning 8051 as it still pops up more frequently than i would expect)

[Jeroen3]

8051 is very cheap because the IP (hdl design) is cheap, even open, and everyone can buy and use it. For ARM you pay royalties, and AVR/PIC are proprietary. Pushing the costs up.
You can do a lot of general purpose stuff with 8051, but during development you're maneuvering around the limitations of the architecture and the extra's built in by the vendor.
Not very suitable for rapid development though. But if you're looking to put away thousands of units or maybe you already know your way around 8051 it a great tool.

[dannyf]

"For ARM you pay royalties, a"

Of a typical asp for cm0 or a cm3/4 chip, how much of that is due to licensing?

[Kjelt]

In 2001 we wanted to include VHDL Arm core for a security project. We needed around 500 prototypes asked for a quote: came out $50000.- probably because under that amount they do not do anything at all 
We had to use an Altera NIOS core instead

[Scrts]

In 2001 we wanted to include VHDL Arm core for a security project. We needed around 500 prototypes asked for a quote: came out $50000.- probably because under that amount they do not do anything at all 
We had to use an Altera NIOS core instead

Was that FPGA? Because in FPGA it probably would not run faster than Nios. On the other hand, LatticeMico32 is free on all platform.

[Kjelt]

Thanks but as said that was 15 years ago in 2001

[dannyf]

"came out $50000."

That's nice chunk of money. But it amortizes to practically nothing per chip if you are making millions of those things.

It is generally accepted that licensing per chip is in the pennies for some of the bigger chips.

[MT]

why do i need 32 bits for that? you can use a ferrari to go from point a to point b, but it might be 10 meters away so you could just walk.

or bicycling.....could be slightly faster...but 32 bitter's are like taking a flying carpet while 8 bitter is a like taking a child's tricycle for those 10 meters!
However the startup procedure for a flying carpet takes way longer then a  tricycle but again a flying carpet takes you way longer under substantial comfort in the long run.

[6thimage]

Arm currently offers a $40k fast track license for the cortex m0 (http://www.arm.com/products/designstart/index.php), which is quite expensive. But unlike their other processors, there are no royalties for the cortex m0 (Arm is trying to take out the 8/16 bit market).

In a spartan 6 FPGA a cortex m0 can run up to 60 MHz with a simple SoC design, more complex designs drop it down to around 45 to 50 MHz. A NIOS II/e is up to 220 MHz, with the II/f being up to 170 MHz in a cyclone v. But the NIOS II/e only does 0.15 DMIPS/MHz, compared to the cortex m0's 1.03 to 1.04 DMIPS/MHz (this should really be 0.98 to 1.04, but GCC's small-multiply option really makes quite a difference), so you get 50% more DMIPS at a lower operating frequency. Of course, the NIOS II/f gives better performance (1.13 DMIPS/MHz), but takes up more resources.

In terms of resources, the cortex m0 is around 3500 LUTs and 1000 registers, with the NIOS II/e using 1200 LUTs and 900 registers, and the II/f using 2500 LUTs and 1900 registers.

Overall the cortex m0 is quite good in a SoC, but only if you can get away with the lower clock speed (or implement CDC on your peripherals). If you need something small and fast, it is much better to ignore the NIOS II/e and instead go for the PicoRV32 (https://github.com/cliffordwolf/picorv32), which uses 1400 LUTs and 600 registers (same rough size as the II/e) but gives 0.327 DMIPS/MHz instead of 0.15, and has a maximum frequency in excess of 200 MHz.

Xilinx's microblaze (on minimum area settings) is a bit better than the cortex m0 - it uses roughly the same amount of resources as the NIOS II/e but has around 1.07 DMIPS/MHz, but it is only free on 7 series devices (expensive licenses if you are targeting the spartan 6, although not in the same region as the cortex m0).

Microsemi's use of the cortex m1 on certain FPGAs is a little different - it is provided as a mapped and routed encrypted IP, so it can only fit into a certain place on the FPGA. I haven't used it, but I would imagine this would really hit clock speeds of larger designs as it will interfere with any place and route optimisations.

[6thimage]

If a company can have access to genuine Cortex M0 (not the crappy Amber ARM compatible cores) for roughly the same price of a single engineer's workbench, it is really wiping out 8 bit controllers.

I think that is the idea - for any other Arm processor, there are always royalties and the initial cost is higher. For silicon devices, they have partnerships with semiconductor manufacturers to reduce costs (so they never give you access to the core, the manufacturer is just allowed to add it to your devices), but they are still considerably more expensive. They want everyone to give up on 8 and 16 bit processors, so making the cortex m0 royalty free is a no-brainer. On their website they compare 32 vs 8/16 bit in terms of performance and code size to show that you are almost always better off with a 32 bit processor waking up from a low powered sleep mode to perform tasks.

The only reason I can see to stay with 8 or 16 bit processors is if you need a very simple task to be done and the 8/16 bit processors are significantly cheaper - one example I can think of is Agilent/Keysight uses an 8 bit microcontroller to control the power state of their multimeters (the 3446xA series) as there is no need to have a bigger, more powerful processor.

[donotdespisethesnake]

Judging from recent reports, Atmel's product lines are going to get shredded http://www.eetimes.com/document.asp?doc_id=1329412

The following statement from Microchip CEO Sanghi is particular ominous:

Atmel is the “worst performing company we ever bought,” Sanghi said.

Microchip had operating profits that were 29.5% of sales in its December quarter compared to 9.4% for Atmel. “For the March quarter Microchip got better and their results were terrible,” he said.

Atmel revenues in 2015 were down 17.6% from 2014. In the March 2016 quarter revenues were down 31% from the same quarter in 2015, he said.

“This company is atrophying…it’s in trouble and a lot of improvements need to be made to bring it up to the Microchip level in technology, management and sales,” Sanghi said.

Unfortunately, it became a self-fulfilling feedback loop when distributors and customers starting cutting orders in anticipation of Microchip wielding the axe - which now they are forced to do. Microchip were looking to find savings of $200 million (aka layoffs) before the merger, they will need to find more saving now. All the former Atmel execs are out, but they got a nice payoff though...

I wouldn't bother with Cortex M0, they are too crippled, for low end stuff PIC will be a better choice.

[nctnico]

  Cortex M0 crippled? How on earth do you get to that conclusion?

[donotdespisethesnake]

Cortex M0 crippled? How on earth do you get to that conclusion?

I tried using one. As noted earlier, the only point of M0 is for ARM to say they have an entry level which competes with 8 bitters. Except that M0 has the complexity of Cortex without the power and speed of M3, and is not as cheap 8 bitters.

Possibly the only reason for customers to use M0 is to have a common toolset, vendor and knowledge base across the range M0 to M4.

[nctnico]

Cortex M0 crippled? How on earth do you get to that conclusion?

I tried using one. As noted earlier, the only point of M0 is for ARM to say they have an entry level which competes with 8 bitters. Except that M0 has the complexity of Cortex without the power and speed of M3, and is not as cheap 8 bitters.

Possibly the only reason for customers to use M0 is to have a common toolset, vendor and knowledge base across the range M0 to M4.

IOW: You tried it but failed and now Cortex M0 is crap? Sorry but you have to do better than that! For example NXP has more than 100 different Cortex M0 controllers going from 8 pin DIP to TQFP100. I use several Cortex M0 controllers in various designs and don't have any problems with them.

[Jeroen3]

You underestimate the power of a well applied cortex M0. It could be as effective as an average programmed M3.

[dannyf]

Many times I wish I could run my chips slowly, like 100khz.

Performance can mean vastkt different things to different people.

[nctnico]

Many times I wish I could run my chips slowly, like 100khz.

Performance can mean vastkt different things to different people.

You can. On the NXP Cortex M0 I'm using in a project currently on my bench I can divide the clock by (up to) 255 so when using the internal 12MHz RC oscillator it can go as low as 47kHz. In another project I went for a Cortex M0 instead of an MSP430 and I plan to clock the Cortex M0 at 1MHz to keep power consumption down. IIRC the current per MHz is on par or lower for the Cortex M0 than the MSP430.

[6thimage]

In another project I went for a Cortex M0 instead of an MSP430 and I plan to clock the Cortex M0 at 1MHz to keep power consumption down.

Depending on what you are doing, it can be more beneficial to use a high clock speed with the low powered sleep modes, than running a microcontroller continuously at a lower clock speed. It might take a bit of redesigning to take full advantage (i.e. performing the processing in interrupts), but it might be worth considering.

[Jeroen3]

You can probably also use the RTC crystal or oscillator as clock source and divide that by 255.

[dannyf]

it can be more beneficial to use a high clock speed with the low powered sleep modes, than running a microcontroller continuously at a lower clock speed.

Absolutely true.

That's the argument TI makes for its MSP430 family: its "instant-on" crystal oscillator.

And I'm a big believer in that: low power consumption is primarily a software thing.

[nctnico]

it can be more beneficial to use a high clock speed with the low powered sleep modes, than running a microcontroller continuously at a lower clock speed.

Absolutely true.

That's the argument TI makes for its MSP430 family: its "instant-on" crystal oscillator.

And I'm a big believer in that: low power consumption is primarily a software thing.

That may be but the time between a wake-up event and the CPU starting doing something useful is also critical so hardware is definitely a factor!

[mikerj]

Cortex M0 crippled? How on earth do you get to that conclusion?

I tried using one. As noted earlier, the only point of M0 is for ARM to say they have an entry level which competes with 8 bitters. Except that M0 has the complexity of Cortex without the power and speed of M3, and is not as cheap 8 bitters.

LPC811 8k Flash, 2K SRAM, 30MHz, 2 USARTS, SPI/I2C, built in bootloader etc. all for £0.37 (2500 quantity).  Is there anything in the 8 bit world that offers that much memory and performance for less?

The complexity of the Cortex might be daunting if you used to 8 bit micro's but they aren't hard to use.

[dannyf]

Except that M0 has the complexity of Cortex without the power and speed of M3,

True. Code density on those things is pretty bad so 16KB is likely the bare minimum, even for casual uses.

and is not as cheap 8 bitters.

I don't know. I have about 1000 STM32F030F4 and I got them for <$1 each. I have also quite a few LM3S628/811 and they went for less than $1 each, like 10 years ago.

Possibly the only reason for customers to use M0 is to have a common toolset, vendor and knowledge base across the range M0 to M4.

Knowledge base (including code base / my own library played a huge part in my decision to use CMx parts. As a matter of fact, they are the single biggest reason I use them.

[nuno]

I'm always finding myself in lack of more RAM, never of more code space. I wonder... Have plenty of ideas for projects that don't fit a uC (8 or 32) because of lack of RAM.

[TheDirty]

I don't know. I have about 1000 STM32F030F4 and I got them for <$1 each. I have also quite a few LM3S628/811 and they went for less than $1 each, like 10 years ago.

Now there's a blast from the CM3 past.  Damn, that was 10 years ago.  Testing out the LM3S811, next to my test SAM7 ARM7 test board.  You want complex peripherals, try out those old ARM7 chips.
http://higginstribe.com/uc/Stellaris/LM3S811/20090703-stellaris-pcb-006.jpg

[dannyf]

'You want complex peripherals'

Yeah. Whenever someone says those chips are simple, I show them gpio or gptm register map for those chips and it typically shut them down quick.

Nasty ADC to program around, though.

[MT]

I'm always finding myself in lack of more RAM, never of more code space. I wonder... Have plenty of ideas for projects that don't fit a uC (8 or 32) because of lack of RAM.

ST have made peculiar decisions on the amount of ram on some device families. Chant.."More RAM to the people..

[westfw]

Cortex M0 crippled? How on earth do you get to that conclusion?

The M0's thumb-only instruction set is sort-of depressingly "spare", compared to other ARM chips.  In addition to be "Reduced", you get quite a few restrictions on operand ranges and modes that are not immediately apparent when you compare to another ARM.  It's a bit like having a PIC or AVR set of basic operations, without having most of the bit-oriented or "immediate addressing" "microcontroller" instructions, and with additional restrictions resulting from trying to cram 32bit address capabilities into 16bit instructions.

On top of that, it's not clear that the C compilers have quite caught-up with those limitations.  arm-gcc for CM0 doesn't have an optimized set of software floating point routines, for instance, causing it to fall back to the (rather bloated) generic gcclib versions.

Most of this  you wouldn't notice at all, if you're "typically" programming in C on a very program-memory-rich chip running much faster than most 8bit chips.  And it's not clear that other things (GP register multiplier, barrel shifter, 32bitness) don't compensate in a comparison with 8bit chips.  But it's "intellectually annoying" if you actually look at the code that gets produced.

16KB is likely the bare minimum

Nah.  There are PICs and AVRs with 256-instruction-word flash memories.  There are things where CM0 code is less dense than 8bit code, but it's not 32x less dense!  Just avoid the bloated vendor libraries, and take the same shortcuts you would on a limited-size 8bit chip (take advantage of default reset state, put code where the vector table would go if you were using interrupts, etc.)

[andyturk]

... put code where the vector table would go if you were using interrupts, etc.

eh?

[Sal Ammoniac]

Chant.."More RAM to the people..

And please make it contiguous too. Too many vendors scatter their RAM in multiple blocks all over the address space. Usually this doesn't matter, but sometimes you need large areas of contiguous memory.

[technix]

Chant.."More RAM to the people..

And please make it contiguous too. Too many vendors scatter their RAM in multiple blocks all over the address space. Usually this doesn't matter, but sometimes you need large areas of contiguous memory.

M7F got a MMU, just map all memory into one logically contiguous chunk.

[Dielectric]

... put code where the vector table would go if you were using interrupts, etc.

eh?

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

[Sal Ammoniac]

M7F got a MMU, just map all memory into one logically contiguous chunk.

This is news to me. As far as I know, the MPU in the Cortex-M7 is the same as the one in the M4, and the ARM architecture manual explicitly states:

MPU support provides control of access rights on physical addresses. It does not perform address translation.

[Jeroen3]

Some vendors alias the memory. Same goes for bit-banding.

[andyturk]

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

Maybe that worked for earlier ARM processors (haven't tried it myself), but the Cortex-M treats the vector table as a bunch of 32-bit addresses--no opcodes. One of the benefits of the architecture is that the hardware stacks some registers automatically on an exception entry, so there's less need/opportunity to play those kinds of tricks.

[westfw]

... put code where the vector table would go if you were using interrupts, etc.

eh?

At the beginning of the ARM address space is a "vector table" that normally holds the addresses of the handlers for exceptions and interrupts and such.  It's pretty big.  On an Atmel SAMD21 there are 16 words worth of CM0-common vectors, and 28 words worth of Atmel Peripheral interrupts.
A C program normally fills them in with pointers to "unhandled_exception" or similar.   That's 176 bytes of program space, and it's one of the reasons that ARM code looks so bloated even for trivial programs.   Now, the first two words hold the initial stack pointer and the reset_handler address, which are pretty important.  But the remaining 168 bytes are only useful if you actually implement handlers for the exceptions or interrupts that they handle, so they can be reclaimed if you're really desperate.
(On a STM32f103 you have 16 words of CM3 vectors and 60 words of ST Peripheral vectors.  304 bytes!)

There are intermediate hacks - most chips seem to allow you to relocate the vector table to RAM (handy for OSes) (This is an ARM "optional" feature.)  So you can omit the table from FLASH and "build" it in RAM - if you need only a couple of interrupts (UART and SYSTick?), the code to build a RAM table probably takes less space than leaving the whole table in flash.

[Brutte]

On a STM32f103 you have 16 words of CM3 vectors and 60 words of ST Peripheral vectors.  304 bytes!

out of 128kiB. It is a const array of pointers. It has exactly the same size members as the ones on mega AVR8s, that is 4 bytes per one IRQ. Cannot see a spectacular difference.

[Jeroen3]

The fact that you think 304 bytes is a lot means you're pushing the envelope on your current platform. Wake up, get smaller silicon!
I toss around lookup tables all over the place on ARM since you have A LOT of flash and there is no significant speed penalty reading random from flash. (there is some penalty for cache miss)
That same STM32F103 you mentioned is available with 1 MegaByte of flash. Which will only be used when you start loading images for your LCD application.

On the last project (custom PLC-ish core) I wanted to output some human readable debugs strings when an input (one of ~400) was triggered. I copied the entire schematic netlist into ann char* array. Whopping 10KB of debug content. No worries.

[westfw]

Yeah, yeah.  But if you're going to say "the ARM is so horribly code-bloating that a 16k part is the minimum you should consider", it's worth pointing out that the same tricks people use to get their code working on small 8-bit micros will work on small ARMs, too (say, 4k - still "mid-sized" by 8bit standards.) (4k is also the minimum I've seen on an ARM microcontroller, I think.)

[Jeroen3]

With thumb instructions a 4k flash part is really small. Comparable to a 2k AVR parts, like ATtiny's.
If you're looking for chips in this region, the price should be the determining factor.
But remember that the price consists of the chips, the work, and the tooling. If you have to buy the tooling again for low volume, it's not going to win. Same applies if you have to educate your developers again.

[nctnico]

The problem I have found with ST's devices is that their peripherals are allover the place and knowledge gained on one chip is totally useless for the other. You have to consider those costs as well. Just saying their evaluation boards are cheap is like saying you should buy whatever has the most shiny parts without looking under the hood.
If you are in low volume stuff (<10000 units) then it makes more sense to choose for a broad microcontroller family with consistent peripherals so you can share a lot of code between projects without having to rely on bloated hardware abstraction layers.

[dannyf]

As a result of maker movement, MCU boards are pretty cheap these days.

I don't know if that's because of the maker movement. MCU prices have gone down significantly, and manufacturing technology has advanced also, so the cost of producing a mcu board has gone down significantly. I don't dispute that the maker movement has broadened the demand and economy of scale has helped drive down the total cost.

But I think the maker movement is more a result of low prices rather than a driver of low prices.

[Brutte]

(..)4k is also the minimum I've seen on an ARM microcontroller, I think.

Frankly, why would a hobbyist wanted to buy a uC that is below 128kiB? These go like $2 a pop. I would not buy a 4kiB chip even if it were $0.01 a pop. It is simply not worth saving a buck and hitting "now please skip to assembler (or rewrite a library) because we are out of flash".
Perhaps, if it were a 10k volume. But even then I doubt I'd use a 4kiB ARM.

[Kjelt]

What I see happening all around is that people that have limited SW/HW engineering skills but want to produce something with a lot of ADC/GPIO/I2C/SPI/LCD/TCP-IP etc. take a pi or BBB.
And considering all the topics on this forum how get things going with an Cortex chip I find that a very good and wise decision.
My advice to hobbieists at this moment: simple projects: arduino/8 bitter, more advanced projects: pi or BBB or generic pcb's like that.

But the TS is no hobbieist, he is a SW engineer following education, and then you have to prepare for what a future employer wants from a fresh employee.
Then comes the decision what kind of product:
- embedded low end stuff (standalone not internet connected) my advice: Cortex M is the way to go since for any significant amount of production they will use that kind of uC's.
- embedded high end stuff (internet connected): go learn embedded linux and seperation kernels, so microprocessors with MPU/MMU that is the future where the entire IIOT v4 (Industry Internet of Things) is going to IMO.
The last I see more and more developing currently, and the requested jobs are shifting towards this esp. in the western world.

[westfw]

why would a hobbyist wanted to buy a uC that is below 128kiB? These go like $2 a pop. I would not buy a 4kiB chip even if it were $0.01 a pop.

Well, yeah.  The relevant question is more like "are the $0.50 ARM chips that vendors are targeting at the same sockets currently using $0.50 8-bit chips, actually capable of doing the same job?"  (and some of them only have 4k 4kib.)  And I'm claiming that the answer is generally "yes."

It is simply not worth saving a buck and hitting "now please skip to assembler (or rewrite a library) because we are out of flash".

how do you feel about "pay $0.10 more for the chip in the same package that has more memory"?

Now, you can also see vendor claims of the sort: "ARM is so wonderful that our 16k SAMD10 chip will easily replace your 32k ATmega328." (ok, usually not that blatant.  More like "we're not even going to sell 32k SAMD10 chips, even though we do sell 32k AVRs in similar package sizes.")
This seems rather unlikely...

[dannyf]

"embedded high end stuff (internet connected): go learn embedded linux and seperation kernels, so "

At the application level, as well as human capital management level, it is definitely true that more encapsulation (aka dumbing down) is needed. Starting up on cortex m chips isn't difficult for a competent embedded engineer but many times people less than struggle.

Here, tools like arduino present an attractive alternative. They have dumbed down the chips so much that pretty much anyone can use it.

I'm actually surprised that no OEM has taken the approach that 8051 ipcore vendors have some: they provide turn-key solutions that comes with a single purpose ide, libraries that perform 99 PCT of the targeted applications, and reference hardware designs.

This approach would have totally isolated the designer from the hardware.

Personally, going to a full blown OS like Linux is an overkill. A much simpler OS or heavy encapsulation would work.

[Kjelt]

Well the reason I said that is that no company with a right mindset will sell internet connected devices without an (online updatable) security suite.
If you look at the requirements and footprints of such security solutions a lot of microcontrollers (incl. cortex m3 imo) are out of their league.

Be aware that last year was a breakthrough year where in the US companies were pursued by the FTC because their devices lacked basic security mechanisms (see attachment)
Very interestng developments

[Dielectric]

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

Maybe that worked for earlier ARM processors (haven't tried it myself), but the Cortex-M treats the vector table as a bunch of 32-bit addresses--no opcodes. One of the benefits of the architecture is that the hardware stacks some registers automatically on an exception entry, so there's less need/opportunity to play those kinds of tricks.

Yeah, this is on older 8-bit machines (like a PSoC M8C), I don't even know how I'd attempt it on an ARM.  Actually, I wouldn't try it on ARM because the interrupt controller is too spiffy.  If I thought I needed that kind of optimization, I'd reconsider my assumptions because I'm probably doing something wrong.   

[Sal Ammoniac]

But I think the maker movement is more a result of low prices rather than a driver of low prices.

And the maker market is so totally insignificant compared to the general market that it's lost in the noise as far as the manufacturers are concerned.

[nctnico]

But I think the maker movement is more a result of low prices rather than a driver of low prices.

And the maker market is so totally insignificant compared to the general market that it's lost in the noise as far as the manufacturers are concerned.

I wouldn't be so sure about that. A manufacturer needs both high volume clients and a large user base to be succesful. The first to sell in quantities the second to create chances to get into high volume designs.