AVR8 vs Cortex-M???

[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.