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