AVR8 vs Cortex-M???

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