Why is Atmega2560 so expensive compared to 32-bit MCU?

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmega2560 is only an 8-bit MCU but it is so much more expensive compared to 32-bit MCU used in Arduino Due. I am puzzled. Isn't Atmel killing off Atmega2560 by pricing them far more expensive over more powerful 32-bit MCUs? What are the advantages of Atmega2560 compared to the cheaper and yet more powerful 32-bit MCUs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are several/many extensive threads here on the rise of the CortexM (especially), and the "future" of 8-bit.

Short answer: Atmel needs to have a pricing structure for its AVRs. 2560 is the biggest AVR8 (?). So it probably is priced the highest.

Now, in your comparison, you probably should take into consideration the Xmega series from Atmel--more power and stuff, at generally lower prices.

Mega2560 is $10/qty. 100; Mega1280 is $9. 8K of SRAM.
[Remember that back when I was your age, an AT90S8535 was over $5...]

Xmega128A1U is about $4/qty. 100. 8K of SRam.

Quote:

...it is so much more expensive compared to 32-bit MCU used in Arduino Due.

Now, I'm not an Arduino person. I put "arduino due" into Gooogle, and came up with

Quote:
The Arduino Due is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU

Looking up tat model, it appears to be a 144-pin package. So not really a direct comparison. Anyway, in qty. 100 the pricing is about $7.50. 100K of SRAM. ;)

Even if you decide Cortex is "better" or "best", is Atmel going to destroy the pricing structure of AVR8? I'd think not, but your guess/opinions are as good as mine.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it is an understandable/reasonable policy and pricing.
This is a replacement chip that the current AVR8-based products will have to use in the near future. When your product uses m128 or m1280 then this is the only way for any upgrades without expensive redesign of the software.

For new products IMHO nobody is going to pick ATMega2560 even if it was under 2$/piece because there is no way you can evolve and upgrade it later. What is more - AVR8 cannot execute from ram. If you run out of code space on 8051 or STM8 or ARM then you can still load part of the slower code from external eeprom to ram and execute. With AVR8 - no way to do that.

Now, how to compare a pricing of m2560 (86 IOs, ~10MIPS) with some competing stuff??
Comparing m2560 with the above ARMv7M - you are kidding.

Perhaps OT, but if I were to decide to pick m2560 or "something else", then I would consider this stuff:

BOM below 1.5$ at 100 pieces and a lot of possibilities to expand/tailor.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are several things that ultimately set silicon price. The ultimate is silicon area. It could be that the physical mm^2 of a 2560 may be more than a small M3 (esp if the latter is more modern and fabbed on a smaller geometry). Then there's desired margin on the part of the vendor. Atmel can more easily make a margin on AVR as it's a niche product so if someone chose it (familiarity with tools etc.) they may be willing to pay a premium. Allied to that is supply/demand which ultimately means "competition". The Cortex market has more suppliers, is more cut throat and margins are bared to the bone. This is all good news for the consumer; it's a buyers market!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If they made the 2560 on the smaller transistor process to make it cheaper, it would have to be all 3.3V, so the 5V IO capability that we like so much would be kaput.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But I like 3v parts!

The newer and bigger parts always put pressure on the older and smaller parts. This is good. Thinking about not using these mega 1284's and getting some of the SAM parts for this very reason.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do I turn on a 3.2V blue led with a 3.3V avr?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
How do I turn on a 3.2V blue led with a 3.3V avr?
Close enough for, er, a resistor to deal with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lightaiyee wrote:
Atmega2560 is only an 8-bit MCU but it is so much more expensive compared to 32-bit MCU used in Arduino Due. I am puzzled. Isn't Atmel killing off Atmega2560 by pricing them far more expensive over more powerful 32-bit MCUs? What are the advantages of Atmega2560 compared to the cheaper and yet more powerful 32-bit MCUs?

No, not killing off... they're taking advantage of historical inertia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any analogy with 1,2,3,4,5,6,8,10,12 and 16 cylinder engines?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compared to most folks here, experience and knowledge wise, I was like born yesterday, but isn't it that barring some loyalists and hobbyists, almost nobody wants to touch a 8-bit uC anymore, for new projects ? That's an honest question.

The loyalists are perhaps loyal more due to historical reasons and intertia, as stevech wrote, and hobbyists are rallying around it, because AVR8's have been historically popular (like the PIC's), with a large community around it, and most-importantly, DIP. "DIP" is non-existent AFAIK, in Cortex-M world (barring, maybe one outlier from NXP).

So, thanks to these market segments, which are perhaps, here to stay, I think Atmel has no immediate reason to reconsider it's pricing.

However Arduino Due, and few other Cortex-M based projects, that lower the software development difficulty bar, significantly lower, with more low-cost development tools/boards becoming available, the balance would definitely shift eventually in Cortex-M's favour.

Well, that's my (partly) educated guess.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In terms of CPU power and resources, the Cortex wins hands down.
In real life you probably want to drive some relays / LEDs / detonators.
So you have to add up the cost of a single-chip AVR or a clever ARM that needs external driver chips.

The Cortex chips are a lot more complicated and hence are less attractive for simple hobbyist projects. For any commercial product, the component cost is more significant than the development cost.

The market will adjust to what the big industrial customers actually want / need.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The Cortex chips are a lot more complicated and hence are less attractive for simple hobbyist projects.

Again, this is exactly opposite than I believe.
If you sort all contemporary uCs w.r.t. the development support they offer to hobbyists, with production OTP chips at one end (doable, but 0% support) and full-featured, state of the art toolchain and emulator support on the other end (hypothetical 100% support), you will notice AVR8 is quite close to a production chip.
With tn4 on far left, then goes m8, tinies, megas and I suppose xmegas.
I would say PIC12 (without header) fit in parallel with tn4, then those PIC12 with header in between m8 and tinies, PIC14 in between tinies and mega and PIC16 are between mega and xmega.
And after that there come PIC30, ARM, MIPS...
Most of the rest of uCs cannot be classified in this category either because of the price (either toolchain is $$ or not available or the chips are hard to buy or development tools have astronomical prices, etc).

I am not an uC expert but the recent ARMv7M (Cortex-M3) offer so much for a hobbyist that there is no way a hobbyist market can withstand the pressure.
And it is not because these chips are darn fast, low power or cheap as dirt. IMHO that has minimal influence on hobbyist market, when you buy 20 pieces/year.

I think ARMv7M chips were ( also ) targeted for hobbyist market - with such enormous development support that whole build process, debugging, tracing, profiling, code coverage is available for a regular hobbyist! No need to buy anything more expensive than 15$ starter kit and a bunch of uCs for 2$/piece.

A major misunderstanding that 32-bitters are more difficult than 8-bitters is because most of them have quite advanced peripherals.
So typically without deeper understanding freaks load a 740kB Ethernet demo, forget to pick valid clock source at startup, push a 400kB webpage into a 100kB SRAM chip and then "Help, my ... HardFaults, ARMv7M are difficult".

My advice is to not to start with running through peripherals libraries at the beginning because 1200 pages of datasheet can discourage - that is understandable.
All ARMv7M have identical core. Increment a register, jump in a loop, try to understand what happens when you call something with uninitialized stack, when you press reset button, etc.
After that, when you +- know what is it all about, it is time for blinking a led.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So far, there does not seem to be any strong reason for using Atmega2560 over 32-bit Arm chips which are cheaper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If they made the 2560 on the smaller transistor process to make it cheaper, it would have to be all 3.3V, so the 5V IO capability that we like so much would be kaput.

If you want to know more about how AVR8 core is made, how it operates and what are all the guts inside, then this information is/was not confidential and here is the application note from Atmel that describes all in details.
Mind this is a document that dates from the times of ATMega128 and ATMega169 when the core was powered with 1.8V - 3.6V. Perhaps more modern A or P versions go even lower, but I suppose it is more a matter of technology not the structure of the core.
My conclusion: ATMega2560 is not 10$ because it has 5V IOs :)

That topology is about identical with other uCs - I suppose there is an internal LDO inside that powers the core (~15mA, with some low power mode to cut down idle current) and Vcc that powers IOs directly.
Search for Nuvoton - their ARMs have 2.5V core and 5V IOs.
Or better: tiny LPC2103 which do not have LDO inside and requires two separate voltages.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A major misunderstanding that 32-bitters are more difficult than 8-bitters is because most of them have quite advanced peripherals.

But that is a major part of the problem. Unless you program in assembler, the complexity (or not) of the CPU is not a major player on the board.

It's when you actually try to do something with your microcontroller the complexity of the ARM chips show up.

Take simple digital output:

The AVR scheme with PORTx/PINx/DDRx is very simple and straight forward.

The Cortex-M3's that I've been dealing with are not in any way impossible to handle, but they are much more complex. Configuration for driving capabilities, bitbanding and whathaveyou..

Similar for timers.

Taking the complexity of the peripherals out of the equation is a (little) bit like saying "cars with manual gear-boxes are just as easy to drive as those with automatic gear-boxes - after all, both types of cars have engines".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The Cortex-M3's that I've been dealing with are not in any way impossible to handle, but they are much more complex. Configuration for driving capabilities, bitbanding and whathaveyou..
Like (3.3V) Xmega you mean ;-)

Anyone who can understand/program an Xmega and its peripherals should have no more problem with Cortex.

While I personally like "bare metal" programming the other thing is that from about the Xmega complexity upwards almost all vendors have a BSP such as Atmel's ASF. So if you prefer the simplicity of Arduino-like programming it's almost always available. (personally I'd prefer to learn the peripheral directly than the library code that's supposed to make it "easier").

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Is there any analogy with 1,2,3,4,5,6,8,10,12 and 16 cylinder engines?

If the 16 cylinder engine put out 16 times the power of the 1 cylinder, cost 1.23 instead of 0.78 and used 1/2 the fuel, you bet!

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan wrote:
But that is a major part of the problem.

Lets take first in a row ARMv7M core chip from my desk. STM32L.

    1. Startup code:

    avr -> that is added automatically when you start a project in AS
    stm -> the same thing, that happens when you pick and tick some default coocox or uVision project

    (I hope nobody is going to start with writing their own crt and ld from the first day)
    2. Add IO definitions (not to be confused with peripheral library)

    avr -> #include "avr/io.h"
    stm -> #include "stm32l1xx.h"

    3.

    int main(void){

    4. Enable peripheral

    avr -> PRR = ... power saving functionality is disabled by default so nothing to do in here
    stm -> RCC->AHBENR |= RCC_AHBENR_GPIOBEN; //enables peripheral (GPIOB in this case)

    5. Set B1 as output

    avr -> DDRB |= _BV(PB1);
    stm -> GPIOB->MODER |= GPIO_MODER_MODER1_0; //bit 0 is GPIO (push-pull is default at reset)

    6. while(1){

    avr-> PORTB ^= _BV(PB1);
    stm-> GPIOB->ODR ^= GPIO_ODR_ODR_1;

    7.

    }return 0; }

The only thing that changes really are the names of the registers (and lengths of the names). It is also true that you can make some additional magic with stm but that is not mandatory - just ignore those features.

Johan wrote:
Unless you program in assembler

No, you should not program in assembler (HLL and OS should be used) but to understand the underlying architecture you have to know that the chip has stack, that it has memory, breakpoints, registers, IRQs etc. That is essential. The only way to get the idea of how it works is to step through asm (and manual).

Johan wrote:
Taking the complexity of the peripherals out of the equation is a (little) bit like saying "cars with manual gear-boxes

I would say that it is more like running a manual gear-box compact car and a manual gear-box sport car. Nobody said you have to use gears 4,5,6,7 and 8.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So far, there does not seem to be any strong reason for using Atmega2560 over 32-bit Arm chips which are cheaper.


Well, then go for it. You >>do<< realize that you are posting on an AVR8 forum. The responses have been non-attacking. As I said earlier, the topic has been quite heavily discussed before.

So, which am >>I<<--hobbyist or loyalist? Certainly there is quite a bit of inertia, for several reasons--knowledge, tools in place, supply chain/buying power.

I suppose you youngsters can put together code much faster than this old bit pusher. A full 32k AVR app is a 6-month project IME. Y'all that start with 128 and 256 and bigger--that is a year+ project. Yet it seems that the questions, like this one, are coming from a situation where it is unlikely that year-long app dev is being attempted.

Revisiting the price thing--it depends on the app. Industrial controllers at 100/year with the microcontroller cost <1% of BOM -- doesn't matter whether $2 or $3. Somewhat higher volume apps, small micro -- AVRs are cheap enough.

Now, is your app a million microwave ovens? Then you have a whole team counting pennies and fractions thereof and responses here don't matter much. Apparently, they don't anyway--respondents are either hobbyists with no real impact, or loyalist fan-boys. So what kind of answer(s) >>do<< you want? "Go West, young man!" -- Horace Greeley

Remember that 10 years ago AT90S4433 and Mega8 were about $5. Now Mega48 and '88 are between $1 and $2. How can a loyalist complain?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Sun. May 12, 2013 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

32 bits does not necessarily mean advanced peripherals! Look at the Analog Devices aducm360. The peripherals are rather crude compared with the AVR. It does have a 24 bit adc though but so does their 8051 based part. If the OP wants us to convince him to use an AVR based on the given cost comparison, then I'd suggest he go for the 32 bit device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
32 bits does not necessarily mean advanced peripherals! Look at the Analog Devices aducm360. The peripherals are rather crude compared with the AVR. It does have a 24 bit adc though but so does their 8051 based part.

If a manufacturer has an existing 8- or 16-bit line, chances are they'll use exactly the same peripherals. This makes sense, the IP is well known and it it helps existing users transition to the new parts (though sometimes the results are a bit silly. Eg. Microchip's USB peripheral uses multiple 8-bit registers to specify a buffer address even on their 32-bit parts.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

another example: The UARTs from PC-land (16550) are used in ARM CPUs. 8 bit registers. But lots of C code already exists for these UARTs, and they're mostly debugged. I worked long and hard to get the TX and RX FIFO code to work correctly for these - most sample code doesn't enable the 16 byte FIFOs. Needed for busy high speed serial-in. Reduces the interrupt rate dramatically - as you copy-in the FIFO in one interrupt.