[AVR] the new 8 bit micro to rule them all

[Simon]

That depends entirely on what ARM MCU you are looking at. NXP's documentation for their LPC ARM series is exellent and their peripherals are easy to use.

I have not seen a Cortex-M0+ MCU that was particularly hard to use. They all are about the same.

The common pattern I see is people assume that they are hard because of something they read on the internet and resort to manufacturers libraries, which are bad in all cases. And this further reassures that Cortex-M0+ MCUs are hard.

As you say you have to write your own libraries, the more registers the more complex it gets. As I set about writing code to enable the ADC on a mega644 to run "in the background" I know it will be all useless on the mega4809

[ataradov]

the more registers the more complex it gets.

This is a false statement. The reason there is more registers on most ARM implementations is more sensible redistribution of bits to logical registers, things are not as cramped and in 8-bitters. This makes life easier. Sure there are a whooping 3 registers to deal with interrupt (enable, disable, flags), but this just makes program easier to read and understand.

And also increased number of registers comes from increased capabilities. And even with a library, you still have to configure all those capabilities in the request to the library.

I do software support for a living, and in my experience writing direct initialization code for a peripheral on any architecture is shorter than calling a corresponding library. And the portability is also a myth, since features are different between different devices, you will still have to change library-based code if you want to move to a different MCU.

[nctnico]

the more registers the more complex it gets.

This is a false statement. The reason there is more registers on most ARM implementations is more sensible redistribution of bits to logical registers, things are not as cramped and in 8-bitters. This makes life easier. Sure there are a whooping 3 registers to deal with interrupt (enable, disable, flags), but this just makes program easier to read and understand.

And also increased number of registers comes from increased capabilities. And even with a library, you still have to configure all those capabilities in the request to the library.

I do software support for a living, and in my experience writing direct initialization code for a peripheral on any architecture is shorter than calling a corresponding library. And the portability is also a myth, since features are different between different devices, you will still have to change library-based code if you want to move to a different MCU.

After working over a decade with NXP's LPC ARM devices I have to say that the latter isn't true for these. I can use 90% of my hardware layer on the entire range from small to large devices and also on ARM7TDMI and ARM Cortex Mx.

[tggzzz]

That depends entirely on what ARM MCU you are looking at. NXP's documentation for their LPC ARM series is exellent and their peripherals are easy to use.

I have not seen a Cortex-M0+ MCU that was particularly hard to use. They all are about the same.

The common pattern I see is people assume that they are hard because of something they read on the internet and resort to manufacturers libraries, which are bad in all cases. And this further reassures that Cortex-M0+ MCUs are hard.

As you say you have to write your own libraries, the more registers the more complex it gets. As I set about writing code to enable the ADC on a mega644 to run "in the background" I know it will be all useless on the mega4809

... or trivial in the XMOS xCORE devices: just dedicate one core to the ADC, and leave other cores to do other processing. That core then waits until an ADC input is available before resuming processing (with a 10ns latency), sending messages to other cores as appropriate.

[madires]

The 0-series have multiple internal reference voltages which is quite helpful when measuring low voltages using the internal ADC.

[Simon]

Assuming they are reliable. the usual 1.1V reference an AVR is +/-0.1V!

[Kleinstein]

The CPU is still very similar to the old 8 bit AVRs (the mega series had a 2 cycle HW multipier - so nothing new here). The only difference I see is that that is a common memory space so that a single point could point to RAM or Flash. The separate address space was annoying with pointers in C, though it allowed for 128 k Flash and  up to some 60 K SRAM (in theory).

The periphery looks a little like in the ARM based µCs or the XMega series. It might make it easier to switch between those 0 series AVR and some M0 / M3 based ARM µCs in either direction.
Using more registers sometimes helps, e.g. to avoid those read modify write cycles that sometimes cause trouble with interrupts. The downside is that only the lower registers have separate fast access.

[maginnovision]

Microchip have come out with a new µC. Looks like they are attempting an ARM style series and on paper these look great:

https://www.microchip.com/wwwproducts/en/ATMEGA4809

TBH I am getting very bored with the choice of uCs nowadays... so many and so little to differentiate.

Very true.

Now have a look at the XMOS xCORE processors and xC.

They are halfway to giving FPGA performance and predictability.

You can time any function to clock cycles if you have enough information. I've been using them for about 4-5 years. Predictability is equal, anything internal you can find you execution time thanks to a lack of cache. The performance is another thing though. Cores are only 400 - 500MHz and you're limited to 100-125MHz per thread depending on specific processor. Very useful for some things useless for others.

[T3sl4co1l]

Assuming they are reliable. the usual 1.1V reference an AVR is +/-0.1V!

The ATMEGA series has notoriously bad analog parts.  The "10 bit" ADC is barely worth 8 bits, and that's if you believe the datasheet.

I've also heard that the POR function fails at slow supply startup (dV/dt).  How do you screw that up?

The XMEGA series is much improved, having more, and more powerful, peripherals.  The ADC is 12 bits, and actually worth most of them.  It's 10 times faster.  The analog comparator is >100 times faster.  There are more references, that are actually fairly stable (though still nowhere near even the humble TL431).

Alas, XMEGA is more expensive than ATMEGA, which is overpriced already.  If they could cut their production costs they could bring them to compete with PICs.  I suppose it will be interesting to see how Microchip decides to play them out, if they'll leave them as they are and "let the market decide", or shift market share to optimize sales figures, or discontinue one or more outright (which is really just saying the same thing).

I don't get the feeling that any similar PIC can compete in terms of power and ease of use -- given I'm not deeply familiar with the PIC family.  I know they go up in bits, but now you're talking a different segment, and they still suck: few registers, quirky instruction sets, huge errata sheets.  And then there's the PIC24 abominations, and then PIC32 which is MIPS and therefore should compete with ARM and such instead (though I don't know if they have any that are nearly as powerful as Cortex >M0s).  So, it seems like AVR is a value to them, to fill in that hole between crappy 8-bitters and nice 32-bitters.

Tim

[tggzzz]

Microchip have come out with a new µC. Looks like they are attempting an ARM style series and on paper these look great:

https://www.microchip.com/wwwproducts/en/ATMEGA4809

TBH I am getting very bored with the choice of uCs nowadays... so many and so little to differentiate.

Very true.

Now have a look at the XMOS xCORE processors and xC.

They are halfway to giving FPGA performance and predictability.

You can time any function to clock cycles if you have enough information. I've been using them for about 4-5 years. Predictability is equal, anything internal you can find you execution time thanks to a lack of cache. The performance is another thing though. Cores are only 400 - 500MHz and you're limited to 100-125MHz per thread depending on specific processor. Very useful for some things useless for others.

Yes. Their strong points are the combination of 

• predictable hard realtime performance - unlike other all other processors on the market
• aggregate performance via up to 32 independent cores

It is quite possible to have some cores doing USB comms to a PC, others controlling LCD voltages (i.e. without the chip usually required to ensure no DC component), and others processing 100MB/s ethernet.

If, OTOH, you require single-thread speed and can tolerate unpredictable large latencies, then the xCORE are not the best devices.

Their strong points mean they are significantly different to most of the identikit processors on the market. There's no need to be bored! All you have to do is open your eyes.

[Simon]

I suspect microchip are going to use the faster AVR CPU and create a new range that will replace both the traditional AVR and the PIC. This is clearly not a one off, it's the start of a new line. Maybe the ADC is better as it has been clearly changed, maybe it was a 12 or 14 bit version from a better device that has been limited ready to be opened up in say the ATmega-1 series.

[coppice]

I've also heard that the POR function fails at slow supply startup (dV/dt).  How do you screw that up?

If you are persistent with trying many very slow startup patterns you can find a pattern that will cause the POR or brownout circuitry in many MCUs to misbehave. It seems very easy to design a flaky POR, and pretty hard to build a rock solid one.

[madires]

Assuming they are reliable. the usual 1.1V reference an AVR is +/-0.1V!

The datasheet for the 3209/4809 states +/-5% for all reference voltages at V_DD 1.8 - 5.5V and t -40 - 125°C. Of course it would be nice if the bandgap reference would be more accurate, but it's possible to reduce the error by an external voltage reference and a little bit of math. I agree with T3sl4co1l that the ADC isn't great. Still, it's usable by averaging multiple conversions. The analog comparator has an offset which can be determined.

[Simon]

With 10x the ADC speed some averaging can be done and a conversion obtained in the same time as before but better. Take 8 samples add them and shift 3 bits.