Perhaps but AVR has no reason for being. Any new customer has to have their head examined.
...except for all the bugs and incompatibilities in the new releases. I think they use Xilinx' software development group. ;-)
I don't see any of the above to be true. Well, the AVR part probably is. It's superfluous. I don't see them forcing expensive tools down the throats of 8-bit micro developers.
I'm exactly the opposite. I like their support better and the company is run *far* better. Atmel dropped the ball several times on their ARM M7 rollout. I think MicroChip will listen to our needs better, too.
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?
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.
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
32 kHz crystal, and a high speed crystal. Internally, it will perhaps start in one mode but software will switch it to another, maybe even with dynamic changes while running. Different parts of it will run at different speeds. There is simply more to configure - and that's just for the clocks.
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.
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 ...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.