I agree, Phil. On the other hand perhaps they are going to have their hands full with the competition from the east. Maybe it's better those two small American fish become one big fish.
What I wonder is...Microchip and Atmel have a huge overlap in the product ranges. Presumably in the interests of efficiency and rationalization a lot of duplicates will be deleted from the catalogue. I can't imagine a company churning out products that compete with each other. Isn't this going to cause a lot of pain for users at some point?
What I wonder is...Microchip and Atmel have a huge overlap in the product ranges. Presumably in the interests of efficiency and rationalization a lot of duplicates will be deleted from the catalogue. I can't imagine a company churning out products that compete with each other. Isn't this going to cause a lot of pain for users at some point?
It is only a true overlap when parts are physically and binary compatible, and I don't think any of the respective companies have drop-in replacements.
The closest to that I know of will be the SST89C and AT89C families, which are Binary compatible, so far as the 8051 core goes, but even here the Bootloader and SFR and ISP details are not exactly the same.
That means even that small area is not going to displace existing designs.
It is in areas like R&D investment that 'decisions will be made' that have long term impact.
Some families will gradually become 'mature' with no new R&D seen, but that effect happens even without a buyout.
Not binary compatible of course but similar products with overlapping feature sets and capabilities targeted at the same application areas.
Decisions could be made very fast. And could go like this:
We don't need two expensive R&D and dev teams developing similar products for similar design wins. Let's close down one, fire all the guys there, after head hunting a few of the best ones. Let's label all ATMEL parts as "Not suitable for new designs". We can keep the fabs churning out those deprecated parts for as long as there is demand to keep customers happy.
Is that an extreme vision of how it will pan out? Perhaps but remember what happened when Microsoft bough Nokia, Elop did exactly that in very short order. See his "burning platforms" speech.
You are right, these things can happen even without a buyout, perhaps ATMEL would slowly have slipped into bankruptcy and all that I describe happens anyway.
It's a pretty common business practice to buy a competitor to gain access to their market share, but the long term plan is to eliminate the competitor's products. A recent example would be Oracle buying Sun Microsystems and eliminating Solaris for Oracle Unbreakable Linux.
If I had some neat widget to make that could be made cheaper, smaller and simpler with a little micro-controller I would traditionally be looking at the Microchip and Atmel parts and arriving something that suits my needs.
What now? If I expect to supply and support this widget for a long time, under the circumstances, I might conclude that ATMEL parts are now effectively deprecated and therefore turn to the Microchip parts only.
Goodbye ATMEL parts.
With the huge influx of other options, ESP chips, tiny ARMs from STM etc etc I might consider not bothering with Microchip either.
Oh, forgot, as it is me I was talking about, as far as I know it's not possible to program Microchip parts with GCC. As such I never really looked at them anyway. The ATMELs can be programmed with GCC, hence their use in the Arduino (Not that I have ever used one of those)
If I had some neat widget to make that could be made cheaper, smaller and simpler with a little micro-controller I would traditionally be looking at the Microchip and Atmel parts and arriving something that suits my needs.
What now? If I expect to supply and support this widget for a long time, under the circumstances, I might conclude that ATMEL parts are now effectively deprecated and therefore turn to the Microchip parts only.
Goodbye ATMEL parts.
With the huge influx of other options, ESP chips, tiny ARMs from STM etc etc I might consider not bothering with Microchip either.
Goodbye Mircochip.
Ah well. Let's see.
Maybe..., but SST is perhaps a better, relevant example, and whilst those are 'mature' you can still buy them from Microchip.
Even before the buyout, both Microchip and Atmel 8 bit parts were looking less 'cutting edge', and losing on price.
ST and Silabs have better resource for less price in the 8 bit space, and Atmel was eating into their own 8 bit space with parts like the 14 pin SAMD10 (tho that is not Wide Vcc)
Oh, forgot, as it is me I was talking about, as far as I know it's not possible to program Microchip parts with GCC. As such I never really looked at them anyway. The ATMELs can be programmed with GCC, hence their use in the Arduino (Not that I have ever used one of those)
It would be very sad to lose the ATMELs.
The Microchip XC16/XC32 are ports of the GCC compiler.
Or you can look on the brighter side...
Get the best engineers from both sides and bring those new features to all the platforms.
Of course some rationalisation will take place.
Microchip should say that the optimizing part of the compilers is pay-only. Regular gcc with target mips produces pic32 compatible code and the objects can be linked directly with the objects produced with xc32, but gcc directly does not integrate with mplabx. Provided sources of xc32 do not compile without "finding" the missing files... Something Atmel didn't do... the AVR32 has full normal optimizing gcc...
I don't know what the situation with pic32mz is, they support another encoding (micromips) besides (or instead of) mips32... regular gcc supports that too...
Microchip bought the best of the 3rd party compilers a few years ago and it's like Ale said, the optimizing part of the compiler is pay-only.
But for the smallest parts, like the 16F54 sitting on my kitchen table and ticking along at 20MHz, it's all about assembly. It's how they were intended to be used from the beginning. One of the selling points in the literature is "only 33 single-word instructions to learn." In fact, that is the first bullet point on the first page of the data sheet.
For the simple but speedy requirements of my present project, it's *perfect. C would be contraindicated.
Microchip bought the best of the 3rd party compilers a few years ago and it's like Ale said, the optimizing part of the compiler is pay-only.
This is one part I don't understand. If they want to sell silicon why don't they make the tools to use it free. Preferably roll their optimization techniques into GCC or LLVM or whatever.
...it's all about assembly.
Perhaps that is my problem. I don't want to do that.
Having first learned to program in assembler in 1973 and having to resort to using it on many different architectures on occasion since then I just don't want to even think about it for yet another machine.
I gladly make an exception for the Propeller though, as its architecture is so simple, clean and elegant and PASM is so nicely integrated into Spin.
Perhaps that is my problem. I don't want to do that.
Having first learned to program in assembler in 1973 and having to resort to using it on many different architectures on occasion since then I just don't want to even think about it for yet another machine.
These days, you do not need to.
With ST and Silabs parts, with better cores than PICx, at around 30c, that have SDCC & other HLL support, now ASM is optional.
Microchip bought the best of the 3rd party compilers a few years ago and it's like Ale said, the optimizing part of the compiler is pay-only.
This is one part I don't understand. If they want to sell silicon why don't they make the tools to use it free. Preferably roll their optimization techniques into GCC or LLVM or whatever.
I don't have the answer to that. I just know that they recently reemphasized that there will never be a free version of their premium compiler or optimizer.
BTW, I don't recommend you pick up PIC assembly unless you have a particular need. It is clearly an old and primitive architecture/instruction set, and would be a step back for you. If old PICs weren't so useful, small, and cost-effective, I would have abandoned them decades ago. In fact, I did. Then Microchip sued Scenix/Ubicom. And the rest is history.
Having been involved in more than enough expensive projects that required migrating code from one architecture to another over the decades, often requiring a total rewrite in a high level language, I soon learned that it's nuts to waste your time programming in assembler unless you really have to.
The difference in asm between the pic24/dspic and previous pics is the difference between night and day.
You hit the nail on the head there. If one has products that have a major asm component then you are totally hosed when you want to move to a different architecture for whatever reason.
It is still asm though.
Which is not a selling point. The aim of the exercise is generally to make some functionality work and ship product. Not have fun learning yet another assembly language.
Having been involved in more than enough expensive projects that required migrating code from one architecture to another over the decades, often requiring a total rewrite in a high level language, I soon learned that it's nuts to waste your time programming in assembler unless you really have to.
Yeah. The story of my life. And most of it is not even assembler. I have constantly to rewrite stuff I did decades ago. Somehow commercial applications are like boomerang children. They always come back, even if you throw them out far.
Except Cobol. There I had just one recall lately. That stuff simply does what is it supposed to do and migrates nice to newer hardware once in a while without the need to rewrite it or even change the source.
But I kind of still enjoy programming in Assembler. Sometimes, and not commercial. Just for fun.
The difference in asm between the pic24/dspic and previous pics is the difference between night and day. It is still asm though.
Why do you say "it is still asm"? I've certainly programmed the pic24/dspic in C with free tools. I guess I didn't get the best optimization but it wasn't that bad.
@Heater and D. Betz
You completely misunderstood my comments. Asm programming on the 16 bit pics is far easier than on the older pics with respect to architecture and instruction set. My comments had nothing to do with C or optimization.
Way to many people on this forum and avr freaks bash pics based on their knowledge of the early pics. The instruction set and architecture has changed. And yes, I like asm, forth, and wait for it... interrupts. Welcome to the 21st century, Prop.
I'm pretty sure interrupts don't count as a 21st century thing. I doubt there is anything that counts as a 21st century feature here. Crosspoint switches might come close though.
I was not meaning bash PICs or AVRs or any other architecture / manufacture. I have no stake in that game.
It's a replay of the Z80 vs 6502 vs this vs that shouting matches of the late 1970's. And later the x86 vs 68000....
I have no doubt modern PICs are easier to program in assembler. Moving to 16 bits will do that. Then the PIC32 is a MIPS architecture, what could be easier than that? I really want to check PIC32 out myself, just for fun mind.
The instruction set and architecture has changed...
That is what I rail against. Having your products become architecture dependant is a royal pain in the long run. That is why nobody programs in ASM unless they really have to. That is why Microchip, and everyone else, makes their machines easy to support with an HLL. At least C.
I like asm, forth, and wait for it... interrupts. Welcome to the 21st century,
Had to chuckle. Not sure if you meant it as a joke or not. ASM, Forth and interrupts have been around since the dawn of time. That is certainly not the 21st Century.
I like ASM too. Slinging interrupts has never been a problem, within limits. Forth...well, no comment. But they are not things you want to see in software that has to outlive a few generations of architecture or even migrate between current vendors.
Way to many people on this forum and avr freaks bash pics based on their knowledge of the early pics. The instruction set and architecture has changed.
Yes and no.
Early PICS have not changed at all, what has happened, is more new core devices have been released by Microchip, still branded starting with PIC.
That is a marketing and branding decision, but it is not surprising "PIC" then ends up meaning so many different things.
EE351
Posts: 81
Comments
-Phil
What I wonder is...Microchip and Atmel have a huge overlap in the product ranges. Presumably in the interests of efficiency and rationalization a lot of duplicates will be deleted from the catalogue. I can't imagine a company churning out products that compete with each other. Isn't this going to cause a lot of pain for users at some point?
It is only a true overlap when parts are physically and binary compatible, and I don't think any of the respective companies have drop-in replacements.
The closest to that I know of will be the SST89C and AT89C families, which are Binary compatible, so far as the 8051 core goes, but even here the Bootloader and SFR and ISP details are not exactly the same.
That means even that small area is not going to displace existing designs.
It is in areas like R&D investment that 'decisions will be made' that have long term impact.
Some families will gradually become 'mature' with no new R&D seen, but that effect happens even without a buyout.
Decisions could be made very fast. And could go like this:
We don't need two expensive R&D and dev teams developing similar products for similar design wins. Let's close down one, fire all the guys there, after head hunting a few of the best ones. Let's label all ATMEL parts as "Not suitable for new designs". We can keep the fabs churning out those deprecated parts for as long as there is demand to keep customers happy.
Is that an extreme vision of how it will pan out? Perhaps but remember what happened when Microsoft bough Nokia, Elop did exactly that in very short order. See his "burning platforms" speech.
You are right, these things can happen even without a buyout, perhaps ATMEL would slowly have slipped into bankruptcy and all that I describe happens anyway.
Now, what about those customers? Say me.
If I had some neat widget to make that could be made cheaper, smaller and simpler with a little micro-controller I would traditionally be looking at the Microchip and Atmel parts and arriving something that suits my needs.
What now? If I expect to supply and support this widget for a long time, under the circumstances, I might conclude that ATMEL parts are now effectively deprecated and therefore turn to the Microchip parts only.
Goodbye ATMEL parts.
With the huge influx of other options, ESP chips, tiny ARMs from STM etc etc I might consider not bothering with Microchip either.
Goodbye Mircochip.
Ah well. Let's see.
It would be very sad to lose the ATMELs.
Even before the buyout, both Microchip and Atmel 8 bit parts were looking less 'cutting edge', and losing on price.
ST and Silabs have better resource for less price in the 8 bit space, and Atmel was eating into their own 8 bit space with parts like the 14 pin SAMD10 (tho that is not Wide Vcc)
SDCC supports some of the mid-range PICs (as well as 8051 and STM8)
http://sdcc.sourceforge.net/mediawiki/index.php/SDCC_tutorial
"The MPLAB XC16 C/C++ Compiler is a full-featured, optimizing compiler[..]
The compiler is a port of the GCC compiler from the Free Software Foundation."
http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/
Excellent. Seems like times have changed since I last checked.
And if you want the optimizing large memory model, you pay big bucks. So how does that work when you start with an open source product?
Get the best engineers from both sides and bring those new features to all the platforms.
Of course some rationalisation will take place.
Anyway, doesn't really affect me
I don't know what the situation with pic32mz is, they support another encoding (micromips) besides (or instead of) mips32... regular gcc supports that too...
You can program PIC32 with GCC. Of course, it's a MIPS machine.
That's still all new stuff to me. What about the good old 8 bit PICs ?
But for the smallest parts, like the 16F54 sitting on my kitchen table and ticking along at 20MHz, it's all about assembly. It's how they were intended to be used from the beginning. One of the selling points in the literature is "only 33 single-word instructions to learn." In fact, that is the first bullet point on the first page of the data sheet.
For the simple but speedy requirements of my present project, it's *perfect. C would be contraindicated.
*Only thing better would have been the SX.
<...rails against the Universe...>
Having first learned to program in assembler in 1973 and having to resort to using it on many different architectures on occasion since then I just don't want to even think about it for yet another machine.
I gladly make an exception for the Propeller though, as its architecture is so simple, clean and elegant and PASM is so nicely integrated into Spin.
With ST and Silabs parts, with better cores than PICx, at around 30c, that have SDCC & other HLL support, now ASM is optional.
BTW, I don't recommend you pick up PIC assembly unless you have a particular need. It is clearly an old and primitive architecture/instruction set, and would be a step back for you. If old PICs weren't so useful, small, and cost-effective, I would have abandoned them decades ago. In fact, I did. Then Microchip sued Scenix/Ubicom. And the rest is history.
Having been involved in more than enough expensive projects that required migrating code from one architecture to another over the decades, often requiring a total rewrite in a high level language, I soon learned that it's nuts to waste your time programming in assembler unless you really have to.
lol...
"I felt a great disturbance in the EE field, as if millions of Atmel vs. Microchip arguments cried out, and were suddenly silenced"
(I saw this on the EEVblog forums but couldn't figure out where it was originally posted)
Yeah. The story of my life. And most of it is not even assembler. I have constantly to rewrite stuff I did decades ago. Somehow commercial applications are like boomerang children. They always come back, even if you throw them out far.
Except Cobol. There I had just one recall lately. That stuff simply does what is it supposed to do and migrates nice to newer hardware once in a while without the need to rewrite it or even change the source.
But I kind of still enjoy programming in Assembler. Sometimes, and not commercial. Just for fun.
Enjoy!
Mike
You completely misunderstood my comments. Asm programming on the 16 bit pics is far easier than on the older pics with respect to architecture and instruction set. My comments had nothing to do with C or optimization.
Way to many people on this forum and avr freaks bash pics based on their knowledge of the early pics. The instruction set and architecture has changed. And yes, I like asm, forth, and wait for it... interrupts. Welcome to the 21st century, Prop.
I was not meaning bash PICs or AVRs or any other architecture / manufacture. I have no stake in that game.
It's a replay of the Z80 vs 6502 vs this vs that shouting matches of the late 1970's. And later the x86 vs 68000....
I have no doubt modern PICs are easier to program in assembler. Moving to 16 bits will do that. Then the PIC32 is a MIPS architecture, what could be easier than that? I really want to check PIC32 out myself, just for fun mind. That is what I rail against. Having your products become architecture dependant is a royal pain in the long run. That is why nobody programs in ASM unless they really have to. That is why Microchip, and everyone else, makes their machines easy to support with an HLL. At least C. Had to chuckle. Not sure if you meant it as a joke or not. ASM, Forth and interrupts have been around since the dawn of time. That is certainly not the 21st Century.
I like ASM too. Slinging interrupts has never been a problem, within limits. Forth...well, no comment. But they are not things you want to see in software that has to outlive a few generations of architecture or even migrate between current vendors.
Yes and no.
Early PICS have not changed at all, what has happened, is more new core devices have been released by Microchip, still branded starting with PIC.
That is a marketing and branding decision, but it is not surprising "PIC" then ends up meaning so many different things.