The Atmel Microchip Thing, two years after

[Random Model Maker]

Hey everyone, this one comes probably from the category of the toilet session thoughts.

I was just wondering today, as it is now more than two years after Microchip bought Atmel, what the aftermath of that predicted catastrophe looks like.

I must admit that I am not the best resource considering this topic. I mainly work with AVR 8-bit microcontrollers, not really done the PIC thing before.

The great fear from the Atmel user camp, if I regall correctly, is, that we all had to use HV programmers now, and we'd have to deal with them weird registers PICs alledgedly use; then again I know many like me who never even tried PIC enough for what they have predicted.
But from my perspective, not too much has changed for better or worse. I am still using my Atmel Studio I am used to, with the same AVR ISP I was used to. There still are ATmegas and ATtinys, some of which we have been using before, some are all new and shiny.

When "it happened" back then, I recall thinking, whatever, nobody is killing that brand and architecture that quick, that being said, Atmel Studio 7 does boast a certain age now, to be honest. I only started out on Studio 6.2, so I honestly can't tell how long that has been out.

I just wondered if there were actual professionals hanging around here, who have noticed, or not, a notable difference to before?

[Kjelt]

Atmel support (helpdesk) in EU have been fired.
There were some real good subject experts there, colleagues of mine were pretty upset since there was no-one to talk to anymore on that level.
One year after the takeover the company switched to other supplier, but I am not 100% sure that this was the only reason, there were more issues (guess: prices went significantly up after the take-over)

[Mr. Scram]

I've heard some people say that the new Atmel Studio is much more bloated. But it honestly seems that two years isn't a very long time when it comes to two companies this size merging. We will really know what's up in about 8 years or so.

[Random Model Maker]

Atmel support (helpdesk) in EU have been fired.
There were some real good subject experts there, colleagues of mine were pretty upset since there was no-one to talk to anymore on that level.
One year after the takeover the company switched to other supplier, but I am not 100% sure that this was the only reason, there were more issues (guess: prices went significantly up after the take-over)

Oh, interesting to hear, I never had to call the helpdesk before, I am more the analog guy, so I don't get to do really complex stuff with microcontrollers.
I can however imagine that this is a problem for many people.

I've heard some people say that the new Atmel Studio is much more bloated.

I honestly couldn't tell. It looks a lot like Visual Studio to me though. Never been a big fan of that.
Until just now I was convinced that Atmel Studio came out in 2015 or 2016, so before the takeover? I could be mistaken though.

[bugi]

I noticed some MCU models were discontinued (some things that had been lingering on my to-buy list for quite a long while). Of course, there is no saying whether they would have been discontinued anyway, sooner or later. (I actually noticed the event only when I was once again checking what to buy next from my list, and was wondering why the "Atmel AVR" MCUs had Microchip in the company column o.O ...)

Anyway, if one has some project plans including Atmel MCUs that are good fits to the task and are not "general" MCUs, I'd recommend buying them right away (assuming that possibly wasted money on them is not a problem, if the plans change later).  One of my projects was half hit by such disappearance; the best choices were already gone, but some variants of the MCU were still available, so I bought a bunch of them, just in case.

[Random Model Maker]

I actually noticed the event only when I was once again checking what to buy next from my list, and was wondering why the "Atmel AVR" MCUs had Microchip in the company column o.O ...

Same for me, was going to buy a bunch of ATtiny167's from the Mouser's and I remember wondering why the hell they would'nt sell Atmel anymore.
That was actually right after the takeover, when Atmel still existed as a company, but Mouser had slightly jumped the gun. Funny though, I have been working with the AT167 for the past 5 years, and it still says Atmel on it.

As you say, microcontrollers get discontinued or replaced all the time, so it does leave you wondering wether they would have remained in production or not.
I am lucky enough to pretty much always find a chip to kinda sorta fit my admittedly limited needs so far; nevertheless I don't think I have figured out the Microchip parametric search tool completely (Mind you I am not sure Microchip understands it either).

[bugi]

The needs of that special project of mine were so peculiar (lowest weight and secondarily by size) that no parametric search would have helped. I was able to narrow things down a bit by using parametrics by package type to filter away package types I already knew. In the end, I had to just go through quite a few datasheets and find one that seemed to be the best fit (by a large margin).  (Still not sure if the idea will ever really work, but, it most certainly won't if I don't have a suitable component.)

[Karel]

..., microcontrollers get discontinued or replaced all the time, ...

With Microchip being the exception. It's one of the reasons we stick with them.

[Random Model Maker]

With Microchip being the exception. It's one of the reasons we stick with them.

Microchip in general or Microchip PIC?

[nuno]

Prices of old models increased, yes... but there are also improvements, there are new models now, cheap and quite improved. For example ATtiny1614/6/7, less than 1€ (no PDIP versions), 2KB SRAM 16KB flash, 3x DACs, 2x ADCs, 3x AC, custom logic, hw multiplier (no tiny has ever had hw multiplier, AFAIK), more pin placement flexibility, etc ... and there are other less visible improvements such as faster ADC (15ksps -> 115ksps) and AC (tpd: 500ns -> 35ns) and reduction of the number of cycles some instructions take (writes to SRAM, and CBI/SBI, now take 1 less cycle, meaning almost all ST instructions and CBI/SBI now take only 1 cycle), meaning they actually made changes to the AVR CPU core (probably the first changes in many many years).

[JPortici]

Two years after, i have a bad feeling about this

http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24_25Q10-Family-Silicon-Errata-80000797A.pdf
(on the document style, progressing towards atmel's.. unnecessary colors, icons, code and register in the same font as plain text)

to me this
http://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33EVXXXGM00X_10X-Family-Errata-DS80000619M.pdf
is far better. More information in less space, and yet easier to read. less graphical bullshit.

oh god, even on the datasheets. http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24-25Q10-Data-Sheet-DS40001945B.pdf
look at the tables and the circuits, what the hell are they thinking. Did they replace the wrong persons?

[trampas]

Well I have seen that some the ARM processors from Atmel are cheap on Digikey at the moment. However I put one on a board only to find out that they did not have documentation for the peripheral I needed (SDHC).

Generally I find that the biggest problem with any processor vendor is the documentation. Microchip/Atmel's datasheets are often just wrong when they do have the data.   Atmel Studio (AS7) is buggy and a pain in the butt.  The ASF in AS7 produces some nasty hairy code that I refuse to use.  They have created Atmel Start which still produces nasty code.  Seems they do code generation such that the code is easy to port between processors as that the Atmel engineers are often switch processors. However they did not realize that we engineers using the chips switch processors infrequently an as such the driver abstraction makes messy code.

After trying to find the SDHC documentation I started looking at other processors I have found that the ST Micro processors have better code generation tools and better documentation from a first look, however the parts are more expensive. 

I really wish Microchip would whip Atmel engineers into shape and write some good drivers and datasheets, however....

[Howardlong]

Two years after, i have a bad feeling about this

http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24_25Q10-Family-Silicon-Errata-80000797A.pdf
(on the document style, progressing towards atmel's.. unnecessary colors, icons, code and register in the same font as plain text)

to me this
http://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33EVXXXGM00X_10X-Family-Errata-DS80000619M.pdf
is far better. More information in less space, and yet easier to read. less graphical bullshit.

oh god, even on the datasheets. http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24-25Q10-Data-Sheet-DS40001945B.pdf
look at the tables and the circuits, what the hell are they thinking. Did they replace the wrong persons?

I strongly suspect that the Atmel way is designed to be “responsive” for online web publication as well as PDF, so the lowest common denominator rules. This seems to have been the way of the web since “responsive” took on a while new meaning, for the dumbed down consumer, where less is... well, less. The same applies to much Kindle rendered content, it’s often a poor experience particularly for technical content requiring good layout that includes illustrations.

I’m definitely not a fan, the way you navigate a technical document, it’s just not conducive to that at all, information needs to be dense but clear. The balance of the Atmel datasheets just isn’t right, there’s too little information. On a mobile device that we’re all told is the way everyone views stuff these days, you can only see one page at a time.

Here’s an example: TI offer a web version of their datasheets by default, and I hate them, the PDF is always the better representation.

One day I guess we’ll have to be online 24/7 to be able to view datasheets: I’ll resist that. While I don’t print out the whole datasheet, I do print out odd pages like pinouts and manually annotate with pen and highlighter during development. Digital annotation is nowhere near good enough to be able to do this as easily.

[JPortici]

I really wish Microchip would whip Atmel engineers into shape and write some good drivers and datasheets, however....

however for some retarded reason they seems to be using those same engineers for the MICROCHIP documentation

[Random Model Maker]

Well I always found the microchip datasheets quite meh; granted, Atmel's were awful, like decrypting an ancient document.

What I find remarkable is thet no one has bothered, before or after the sale, to correct the stupid ISP situation on the Atmega QFP64 chips; where the ISP pins are called PDI and PDO, and are on the UART pins, while there are still MISO and MOSI pins for the SPI right next to them.
Why only those few chips are not programmed on the SPI as is EVERY OTHER BLOODY AVR CHIP, no idea but I can live with it; once you know, you know.
What is really the issue is that PDO and PDI are not pointed out as programming pins in the pin description section of the datasheet, but rather it says it in one small line in the programming section; that section where those pins are referred to as MISO and MOSI anyways. It just says: "MISO is pin PE1 (PDO) and MOSI is in PE0 (PDI) on device". Well if that isn't clear...

[Howardlong]

Oh, don't misunderstand me, the older Microchip documentation is far from perfect!

For me, I find it terribly frustrating with the 16 & 32 bit PICs to have to refer to potentially dozens of different datasheets for each device: one for each peripheral or function, as well as the device's datasheet itself, plus the errata; and then manually figure out which potentially conflicting information I should be using. At least the 8 bitters are still just device datasheet+errata.

[Random Model Maker]

Oh, don't misunderstand me, the older Microchip documentation is far from perfect!

Now here's an idea for a thread! The search for the perfect datasheet.

I have yet to see a datasheet that says all that you need and nothing you don't. Not even for a bloody heatsink.

[Howardlong]

I’ve noticed increasingly that the accuracy of the datasheets has been deteriorating, and the size of the erratas has been increasing, in some case quite dramatically.

I think the worst offender has been the PIC32MZ EC series. I made quite an investment in time for product development for this device a few short years ago, dependent on the advertised performance of the ADC, which featured simultaneous sampling at several MSa/s. It took about a hear for Microchip to formally accept that it was broken beyond redemption. For several moths I assumed I was just not using it correctly.

[trampas]

Yea I was looking and it appears that ST Micro has better documentation than Atmel parts. As of today ST parts seem to be priced higher.

I hate the way Atmel does their ASF and Atmel Start, the tools generate a four layer driver abstraction that you can not follow.  Whatever happened to the good old days when the datasheets (or app notes) showed you how to setup peripherals by setting bits in the registers?

I really dislike how Atmel datasheets indicate that the Pull-ups and Pull-Downs on their parts can be turned on/off with their Sercom peripheral, which is just totally wrong.  This costed me a board spin....  Why would you not have the pull ups/down work with peripherals, I know it would save me some board spaces and allow lower power operation.

As far as Microchip goes, I use to use their parts until the DsPIC, after that part and spending hours debugging their compiler for them I decided I would never use a Microchip processor again.  Now it looks like they have corrupted Atmel too....  I do wish there was a good microprocessor vendor, with reasonable priced parts.... Heck this maybe an opportunity for China supplier like AllWinner to make some serious money....

[Howardlong]

As far as Microchip goes, I use to use their parts until the DsPIC, after that part and spending hours debugging their compiler for them I decided I would never use a Microchip processor again.  Now it looks like they have corrupted Atmel too....  I do wish there was a good microprocessor vendor, with reasonable priced parts.... Heck this maybe an opportunity for China supplier like AllWinner to make some serious money....

Hmm, while I’ve discovered my fair share of compiler bugs over the years, I’ve found Microchip’s compilers have been reasonably good in the long term. The few bugs I’ve found have been mainly in XC8. Bugs in the header files are slightly more frequent though, but mostly in the form of missing items rather than the wrong bit in a bitfield.

[Mr. Scram]

Well I always found the microchip datasheets quite meh; granted, Atmel's were awful, like decrypting an ancient document.

What I find remarkable is thet no one has bothered, before or after the sale, to correct the stupid ISP situation on the Atmega QFP64 chips; where the ISP pins are called PDI and PDO, and are on the UART pins, while there are still MISO and MOSI pins for the SPI right next to them.
Why only those few chips are not programmed on the SPI as is EVERY OTHER BLOODY AVR CHIP, no idea but I can live with it; once you know, you know.
What is really the issue is that PDO and PDI are not pointed out as programming pins in the pin description section of the datasheet, but rather it says it in one small line in the programming section; that section where those pins are referred to as MISO and MOSI anyways. It just says: "MISO is pin PE1 (PDO) and MOSI is in PE0 (PDI) on device". Well if that isn't clear...

I think you just saved me from a headache down the line.

[JPortici]

Oh, don't misunderstand me, the older Microchip documentation is far from perfect!

For me, I find it terribly frustrating with the 16 & 32 bit PICs to have to refer to potentially dozens of different datasheets for each device: one for each peripheral or function, as well as the device's datasheet itself, plus the errata; and then manually figure out which potentially conflicting information I should be using. At least the 8 bitters are still just device datasheet+errata.

i think the reason for the multiple documents is that they just have to update the single chapter of the reference manual and not the whole file. The dsPIC30F reference manual instead was a single file and THAT was a mess.

dsPIC33E (and the new dsPIC33C) on the other hand are bloody powerful beasts. The parts released in the last 5 years or so tend to have reasonable erratas.

Whatever happened to the good old days when the datasheets (or app notes) showed you how to setup peripherals by setting bits in the registers?

microchip still does that.

[ElektroQuark]

Who doesn't? Any example?