AVR8 vs Cortex-M???

[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