Well, this isn't a particularly insightful comment, but my feelings about this are "fark :[". The AVR definitely has something Nordic about it. I first learned C when programming an AVR Butterfly eval board to take photos like [0] using [1]. I've found the AVR architecture to be much cleaner than 8 or 16 bit PICs. Atmel, for the most part, embraced GPL and GCC. Microchip has tried to squirrel GCC optimization features away from being truly FOSS.
IIRC Microchip's 8-bit PIC line had poor/nonexistent GCC support because their terrible instruction set provided no way to maintain a data stack. Their own compiler just allocated everything statically.
Granted, it's (thankfully) been over a decade since I had to use a Microchip microcontroller, and they've presumably improved since. But Atmel got it right from the start. GCC-AVR produced beautiful assembly and their ISA was a joy to use. RIP Atmel.
Calling AVR a "joy to use" is pushing it a little far. There are things to like about AVR chips as a package, but the AVR instruction set is pretty janky. I don't understand why they're so popular compared to the MSP430.
I found the AVR instruction set pretty straight forward. Granted, it was my first forray into assembly and I learned it around 17 years ago at age 14. Maybe everything seems easy in hindsight at that age.
I've never programmed MSP430s in assembly, but I have for PICs and found their instruction set to be more funky than AVR.
So first a couple caveats: (1) I'm sure AVR is a hell of a let better than PIC, (2) I come at this from a really weird place (exclusively emulators and compilers), and (3) I'm not talking about the AVR parts themselves, which might be more cost-effective for a given project.
That said:
* Harvard architecture (split I & D memory)
* 8 bit registers
* Not at all orthogonal, and particularly painful for pointer addressing
* The stack pointer is annoying to work with
* Address wrap at physical memory bounds, rather than the bounds of address space
I could pick a bunch more nits that would only really be relevant to someone writing an emulator (complicated instruction decode, IO addressing, &c) but those are my big complaints.
Those are all true (though that an 8-bit microcontroller has 8-bit registers is… unsurprising). However I am referring to the instructions themselves, which were well-engineered to match the needs of a compiler. The result is very compact assembly for most C programs that you would write on an 8-bit microcontroller (including things like 16-bit arithmetic).
I don't know that I would say Atmel has embraced GCC. Consider the case of the AVR32: Atmel's port is in a fork of GCC, and has not been merged upstream. Considering how long they've been maintaining their fork, I'm not sure it ever will be merged.
I believe they were working on upstreaming their changes at the time, but as the sister comment said, AVR32 never really took off and is now basically dead.
I still have a couple of AVR32 NGW100 dev boards, they were really nice to work with.
I think AVR32 is dead (also UC3, AP7 died years ago). I've not seen any development the last years. I guess they don't want to compete with their own ARM's.
In a few meet and greets, the Atmel app engineers mentioned that they always steer people to ARM parts unless they have a requirement that absolutely doesn't fit it, then they push AVR32 parts (and seemingly hesitantly).
Elegant, clean design (certainly compared to the old 8-bit PICs). Good taste. FOSS-friendly.
Microchip might be a Texan oilman in this comparison. Just keep pumping them PICs out don't listen to those commies with their 'GCC' and their 'lee-nux' - sounds foreign and suspicious.
This is obviously a tongue-in-cheek characterisation but I think that's what the OP was getting at.
I believe some consolidation helps them reduce costs and improve efficiency. I guess every market consolidates into two to three big players eventually.
It's already at 2-3 big players. Further consolidation gets us closer to monopoly tactics. Let's just say tech consolidation is usually bad for the consumer. I see no reason that two, neck-to-neck competitors becoming one company will help us in long-term. We've benefited from those costs and product efficiency was great so far.
I'm sure their costs and efficiency will improve. As usual. ;)
What is the 3rd player right now? AFAIK it's PIC or Atmel. I guess there are the various ARM boards but those tend to be more powerful than little 8 bit things.
But that's just Arduino, i.e. high level compatibility. You have a setup() and a loop() and the same way to do I/O, but not the same underlying instruction set.
The chips on these guys are regular ARM cortex uCs.
They might be just barely fast enough to do real-time emulation of the AVR INSNs though ;)
I literally just posted that and deleted it in a comment. It had something else that was inaccurate. I was about to repost it just saying Renesas had SOC's, SuperH chips, and their on fab then saw you comment. :)
Developers routinely rely on this fragmentation for more options in the feature set vs. price product space. Such a merger will most certainly lead to some edge case configurations go missing. Lowered prices may be the only actual upside - if it materializes in the light of shrinking competition.
Exactly. This market demands that to find the right fit for a product and best value in performance/IO/watts/dollars. More options is always good for us. Anyone wanting to learn less can stick to one product family.
Nah, there are lots of markets that have natural incentives against monopolies. For example, classic web hosting type things will probably never consolidate for a number of reasons ranging from the size and difficulty of the configuration space to being unable to retool when new technology comes along and new players enter.
Chip design and manufacture, however, I can easily believe converge toward a monopoly, mostly because research efforts compound like crazy.
That's true for fabs but I was talking HW development. Mainly, the EDA tools and the masks. It's why some companies can specialize in offering USB or whatever on certain nodes. It's just that expensive to develop something like that.
I think you kind of answered it yourself. Microchip probably offered a higher portion of the deal in cash and atmel shareholders find the cash to be worth more than dialog stock.
I think the value of the Dialog deal plummeted since a lot of it was to be paid in Dialog stock and their stock price dropped substantially since September.
This is surprising news to me. An analog with the microprocessor market would be Intel buying AMD!
I love Microchip's application notes. My first controller was a PIC16F877A and apart from the architecture quirks (and mediocre C compiler support) it is a good processor for beginners. In that sense, this acquisition nicely complements MT's own strengths.
I'm still not sure how I feel about the monopolization of the uC though.
I tried both PIC and AVR when first getting into embedded development. I very quickly grew a strong distaste for the PIC instruction set (their docs were admittedly very nice).
AVR was just so clean by comparison. It's a sad day, microchip really needed a good competitor.
This is a huge relief compared to the proposed acquisition by Dialog. Microchip is vastly more open. Crazily enough, You have to apply for a copy of a data sheet from Dialog instead of it being freely available on their website for everyone to download..
>People in this thread keep talking like this is the "death" of Atmel. I don't see it changing much other than being guided by Microchip management to meet higher profit margins. If you think that Atmel's compilers and IDE's are going to be dropped overnight in favor of MPLAB X and Microchip compilers, you are almost surely mistaken; there's a big gap between architectures so it would be a lot of work to get Microchip tools to support Atmel parts.
I suspect it won't - even if AVR started to disappear the Arduino guys have already got a handful of boards out using ARM Cortex M0 and Intel Curie chips. They're quite cleanly integrated with the same IDE and the boards are in roughly similar form factor, so from a dev's perspective if they moved to ARM/Curie completely it wouldn't be too tough I reckon. Not sure if there's any supply chain or manufacturing issues that could complicate things though.
[0]: https://c1.staticflickr.com/1/53/115619170_4445c593cd_o.jpg
[1]: https://c1.staticflickr.com/1/56/112758047_dc5b4bdc3b_o.jpg