I see that RS Components is now listing all our favourite microprocessors under the Microchip brand.
...R
Yep; Microchip has been doing a relatively speedy job of integrating the AVRs (and other Atmel chips) under their own brand. AVRs and SAM chips have been showing up in the Microchip parametric search for a couple months now, Atmel Studio downloads from the Microchip web site, and I've received all sorts of marketing emails about "New Microchip 8bit chip: ATtiny1617" and similar.
I'm not sure whether this is a good thing, overall, or not. Being somewhat familiar with how difficult this sort of merger/acquisition can be, it's pretty impressive. At least it doesn't look like microchip bought atmel just to be able to "bury" their products (which some people were worried about.)
I think what @westfw has said is reassuring - Microchip seem intent on continuing the Atmel products. Otherwise they would not waste money on re-branding.
...R
travis_farmer:
in any case, i am thinking that if Microchip is taking over the Atmel products, i wonder what new features they may bring to the table in the future.
That's a whole other story!
Will there be new products that reflect an Atmel parentage or will all the new products be derived from Microchip concepts.
Associated with that is the question of what sort of new chips will there be? For example will there ever be any new 8-bit chips or will everything be 64-bit and 80 MHz plus?
Maybe there is a business opportunity for you in a new family of 8-bit microprocessors 
...R
There always will be a market for 8-bitters in mundane jobs like domestic appliances, but it's so cheap to cram massive capabilities onto silicon these days that why not do it?
The ESP8266 type products - note designed as well as made in China - may be the way things are going.
Allan
allanhurst:
There always will be a market for 8-bitters in mundane jobs like domestic appliances,
Of course. But I was really wondering if there is a need for any new designs of 8-bit MCUs
If you can program an ESP8266 with the same IDE as an Attiny24 there is no "software" value in using an 8-bit MCU even if the "bigger" MCU is complete overkill. Then it all comes down to the hardware cost saving when you are using 100,000 units.
...R
Migrating between processor families used to be montrously expensive. If you went for say Intel chips in the 80's, and paid a couple of man-years salary for the development kit, you were pretty much stuck with it, even if you later decided you'd rather have gone with a Motorola or some other device. The great thing with Intel stuff was their in-circuit-emulation - who hears of that these days?
Third party IDE suppliers - Keil, IAR etc - have supported various families for years, but again the full version of their software was expensive, and swapping between targets wasn't free.
So long as the IDE is OK , I really don't care who made the target silicon , or ( in most cases ) the detail of the chip so long as it's up to the job.
The Arduino IDE is nowhere near as sophisticated as these products, but, hey - it's free and not bad. And if kind souls supply ports for other processor families than the Atmel little stuff, I'm very happy.
It's a brave new world!
Allan
Robin2:
I think what @westfw has said is reassuring - Microchip seem intent on continuing the Atmel products. Otherwise they would not waste money on re-branding....R
On the other hand, they may be just clearing out old stock.
Paul
allanhurst:
The Arduino IDE is nowhere near as sophisticated as these products, but, hey - it's free and not bad. And if kind souls supply ports for other processor families than the Atmel little stuff, I'm very happy.
I wrote some assembler code for a PIC years ago without any IDE. I made some sort of code uploader that used a PC parallel port.
I presume there is no reason in principle why the Arduino IDE could not be extended to work with PIC chips.
...R
"drooool, "64-bit and 80 MHz plus", i can't even imagine the possibilities."
I can - huge software projects. Not what I am in for, no time to be writing that much code.
And this speeds will not be 5V parts, so dealing with 3.3V will be the norm.
I can - huge software projects.
The arduino IDE is not adequate for this - you need version control of the many modules involved and issuing of them to the many programmers developing various parts of the project among other things.
I certainly started out with keyboard input systems, makefiles and all the rest. And parallel port programming through a home made JTAG interface to prototype hardware.
But for a single user the Arduino IDE is adequate.
I presume the original writers decided on Atmel devices through either experience with them or a liking for the products. I'm sure they had no connection with Atmel , financial or otherwise.
To that extent their choice was arbitrary - there are and were many other families available with similar architectures and features.
Perhaps we could ask them?
Allan
allanhurst:
...it's so cheap to cram massive capabilities onto silicon these days that why not do it?
Reliability. Each transistor added is another potential failure point.
Your pc probably contains billions of transistors and doesn't often fail through silicon faults.
If properly done reliability isn't a big issue.
Would you have us all use stuff made with 54 series TTL?
Allan.
My PC rarely spends time controlling a pipeline carrying pressurized hydrocarbons in -40 °C weather.
My PC rarely spends time managing a critical power system without the protection of Earth's atmosphere.
The extremes by which embedded processors have to be reliable are significantly different than the extremes by which PC grade processors have to be reliable. A single high profile failure of an AVR processor could easily leave Microchip (Atmel) out of business. A single high profile failure of a PC processor could easily leave Intel not giving a damn.
Look at it from this perspective... How has Intel fared since...
https://www.google.com/search?q=pentium+fdiv+bug
Would you have us all use stuff made with 54 series TTL?
"Made with" is not the same as "how many of".
Though that is a good example of fallacy.
OK
I've done mil-spec , radiation-hardened ( with TTL ) and hazardous environment stuff - but that's a different ballgame from the average Arduino user and their applications.
I didn't use Atmel processors.
Allan
In which case you should understand the math involved and why "more of" results in a higher probability of failure.
they may be just clearing out old stock.
They wouldn't have to advertise to do that; just gradually let the existing customers deplete them...
I presume there is no reason in principle why the Arduino IDE could not be extended to work with PIC chips.
In practice, there is no adequate open-source C compiler (for the 8-bit PICs. The 16bit PIC C compiler is gcc, and might be interesting, and the 32bit PICs have had "Chipkit" and "mpide" (now an Arduino "board type", thanks to the enhanced 3rd-party support) for years now.
There was a PIC-based product ("USB Bitwhacker") that showed up about the same time as Arduino with a USB bootloader that was "this close" to being a contender. But it was essentially hardware-only; no compiler, no libraries, no evangelists. 
I presume the original writers decided on Atmel devices...
To that extent their choice was arbitrary - there are and were many other families available with similar architectures and features.
Perhaps we could ask them?
It's been written up. https://arduinohistory.github.io/ (While this was sort of written in response to the whole "who owns Arduino" controversy, it also contains excellent early history of the board and software.)
Original processor choice: Parallax Javelin Stamp, because it ran Java (sort of?)
Lack of open-source tools was a big problem; while there are a lot of 32bit chips where the answer is "just run a version of gcc", gcc doesn't work on most 8bit cpus, and in 2004 when all this was happening, 32bit microcontrollers were still in their infancy (expensive, difficult to deal with, etc.) The original Wiring boards were expensive and had poor distribution channels, too.
westfw:
In practice, there is no adequate open-source C compiler (for the 8-bit PICs.
Seems strange - any idea why?
...R
In practice, there is no adequate open-source C compiler for the 8-bit PICs.
Seems strange - any idea why?
It'a a horrible, ugly, architecture to try to map to the C language. The call stack isn't hardware accessible, the RAM isn't contiguous, only one register does real math, there's no real "indexed addressing", etc. By the time you get to PIC18, things have improved "slightly." It makes the compiler hard to write, the generated code can be lousy, and pretty much anyone who has written a compiler wants money. It's also OLD, from a time before Gnu, and before OSSW tools were a big thing. GCC is a wonderful thing, but relatively limited in terms of the "architectural models" that it supports. RISC was the "best thing ever" for gcc (and probably vis-versa!)
(Interestingly (?), it's not so bad writing assembly language for typical microcontroller things. There are a bunch of direct bit-manipulation instructions, and there are many "interested" ways to try to be clever.)
In which case you should understand the math involved and why "more of" results in a higher probability of failure.
I have ( I had to ) but the numbers you plug into the equations are guesses - 'what's the reliability of a soldered joint?' for example - it strongly depends on the process. And their reliability is an issue - which is why VLSI to reduce chip and hence joint numbers is a good idea.
The pentium fault you quote was a design fault, not a process one
Enhanced life testing, through high temperature runs of a number of samples give some idea of MTBF etc, but real world life tests as in millions of pc's at room temp suggest that a 32 or 64 bit processor can be very reliable.
Allan