Atmel Bought by Microchip

Can you explain that?

Sure. There are better alternatives.

New information: Microchip is significantly increasing AVR development. Go figure.

That's not a very informative answer. Concrete suggestions would be helpful. ;-)

The sessions at their summer program include AVR and Cortex M7.

I'm optimistic (don't care that much about AVR but some folks do).

--sp

"Better" in what way?

I guess they know a winner when they see it.

If you can't find them, you need your head examined. ;-)

Faster, cheaper, and alternate sources (for both hardware and software).

I guess they know there are a lot of heads that need examining.

They know they have a lot of "trapped" AVR customers. Again, I can't imagine anyone choosing it today, unless they had a lot of investment (or inertia) they were protecting.

We dumped the AVR a couple of years ago. ...but there is an argument to be made that we jumped on the M7 a little too quickly. We probably couldn't have done it at all if we waited until "it was ready", though.

I'm just a software geek but the AVR looks pretty versatile to me and I know that lots of hardware folks like it. Yeah I suppose there's inertia. Still don't know what you're advising instead. You mentioned the Cortex M7 but that's at a completely different level of cost and complexity. The M0 is closer, but I don't know of any M0 (or other ARM) parts directly comparable to the more popular AVR's.

Faster is seldom a discriminating criterion for selecting an MCU. Fast enough is what is required. AVRs are in the same ballpark as other 8 bit devices and even 16 bit devices.

Cost is in the same ballpark as other product lines as well.

Which MCUs have alternate sources other than the 8051?

You are saying Atmel would change the functionality of a part in production? That's pretty bad!

It's not *bad*, but my experience is that the same part number may not be 100% compatible with older revisions later on. If you have something with a 5-year lifespan, could be a problem.

There are a lot of choices. ARM Mx, PICxx. PICxx has many of the same single-source problems as AVR, but I've never caught them in the same "new revs are different" trap as with AVR.

The smaller PICs seem horrible to program. AVR and ARM at least have decent gcc-based tool chains. As mentioned, I don't know of ARM parts directly comparable to the more popular AVR's (PDIP packages for breadboard prototyping, 5-volt tolerant i/o, etc). ARMs also seem more complex to program than AVR (e.g. in terms of the stuff required on startup) but maybe that's my imagination.

I was a fan of the TI MSP430 line for a while, since it has a nicer cpu architecture and some unique features, but again the available parts don't have the configuration and packaging options that the AVRs do. Plus, I think recent ARMs have surpassed the 430's in power efficiency despite being 32 bits wide instead of 16. TI itself seems to be moving away from the 430 line towards the Cortex M4.

In comp.arch.embedded Paul Rubin wrote: ...

Take a STM32 Nucleo 32 and you can use it as PDIP with USB port for debugging, communication and file upload...

This is key, as far as I am concerned. When choosing a microcontroller for a job, having a good gcc port which is supported by the manufacturer is high up on my list of deciding factors.

PICs have good peripherals and are very robust microcontrollers - but you have to use painful development tools and think in PIC-style C rather than writing normal C code. (The same applies to 8051, and other such C-unfriendly cores.)

The AVR has a few quirks regarding C compatibility and programming (separate address spaces for flash, and poor pointer support) - it is a sort of middle-ground between unpleasant processors and nice ones. It is a nice cpu for assembly programming, though it's a long time since I have done much of that.

The ARM is great for programming. It is a nice, clean 32-bit C friendly architecture. It is hard to see what could be better in this regard. (There are plenty of other equally good ISA's, such as PPC, 68K, MIPS, etc.)

PDIP packages are hardly the popular ones. For prototyping with AVRs, I expect most people use ready-made boards so that the packaging doesn't matter. It must be well over a decade since I have seen any use of breadboards for prototyping or development.

There are few microcontrollers of any sort these days that will drive 5V signals, but certainly the Freescale/NXP Kinetis (Cortex M0+/M4) series are mostly 5V tolerant and some drive 5V outputs.

It is a bit of a generalisation, but it is roughly correct. It is an inevitable consequence of greater flexibility of peripherals and core modules. An AVR runs at a given clock speed - determined by an external crystal or internal oscillator and a few "fuse bits". An ARM microcontroller might have a couple of internal oscillators, a low-power

The msp430 cpu is very nice - it's the cleanest 16-bit C device I have used. (The 20-bit extensions are horrible, however.)

It's always a challenge to define power efficiency - it can mean so many things. One device might have lower leakage power in standby mode, another might have lower energy required for a given calculation. In general, simpler devices like the msp430 or AVR are likely to have lower static power, but a Cortex M0+ will take much less power for processing tasks.

Il 28/07/2016 09:03, Paul Rubin ha scritto:

Regarding 5V tolerant I/O, take a look at ARM Cortex-M0+ SAM C2x from Atmel. They can be supplied directly with 5V.

Regarding ARM in DIP packages, I think there is something in NXP LPC MCUs

We used PIC16s heavily when they were the only 16- or 20-MHz processors we could get for, like, a buck. They were pretty cute to program in assembler, and we could do the things we needed to do well within a couple of hundred instructions so assembler was no problem. With the proper setup, between the FSR and the bank-select bits, the processor could zip around in (what in C would be) an array of structs with no trouble at all. C compilers seem to have trouble keeping such close tabs on what will be in the bank-select bits come runtime.

For my own stuff, I usually start with AVR because of general availability and the AVRDudes' toolchain.

I still say, considering a project that I'm contemplating moving to ARM, that I did the whole project with about the same effort it will take to set up the ARM clocks. I can re-use those results later, but still ...

Mel.

The M4/M7 are inline with the price of the AVRs. The M0 is more in the PIC class. ...even lower end PICs. Big differences.

Bullshit. Performance is very important. Cost is equally important. Cost/performance is king.

Good grief. ARM