Why do people not like Microchip?

[NorthGuy]

I like Microchip.

MCUs are good. Periphery is good. Documentation is Ok - better than most. Microchipdirect is good. Compilers are fine.

Of course, there are things I don't like, such as MPLAB X. I don't like that they bought Atmel. If they didn't, I believe the PIC line would progress more and everything would be less messy.

[peter-h]

Microchip bought the Hitech compiler, probably when Clyde Smith-Stubbs (who wrote all their compilers - Z80, H8/332, etc) retired.

Isn't this the compiler they are selling?

[JPortici]

XC8 is the hitech compiler (their own was discontinued)
XC16 and XC32 are C30 and C32 respectively

I like Microchip.

MCUs are good. Periphery is good. Documentation is Ok - better than most. Microchipdirect is good. Compilers are fine.

Of course, there are things I don't like, such as MPLAB X. I don't like that they bought Atmel. If they didn't, I believe the PIC line would progress more and everything would be less messy.

same. But i insist that MPLABX is not the worst of the free IDEs

[bd139]

MPLABX is based on netbeans which is basically someone trying to fix the sins of eclipse and only succeeding in creating another Cthulhu shaped monster to terrorise you.

My only comment is at least it’s not visual studio.

I prefer standalone tools than IDEs these days. Many times I’ve been let down by IDEs right in the middle of shit hitting the fan moments. My entire day job is high profile shit hitting the fan moments so I can’t afford the risk.

[Warhawk]

Microchip is OK. I miss a free and open-source compiler. I like 5-V support and packages that always fit the requirements.
Every micro has its own quirks. I find people complaining about this or that MCU annoying. Professionals take what they are given, learn architecture and quirks and do the job. During my career, I've seen real issues just a few times. Most of the other problems were just lazy coders, bad habits, wrong MCU selection, or wrong software architecture.
Yes, bugs are present. I am not aware of a single MCU without errata.

[snarkysparky]

Why people bring up the old 8 bit pics is beyond me.   The PIC24 series is awesome.   Flat memory and hardware multiply.  What's not to like.

[Circlotron]

Well, first of all the 8-bit PIC architecture is UGLY by modern standards.  It's designed to allow assembly language programmers to write very small programs that fit in the very small memory

My language of choice (and the only one I understand) is assembly, and trying to figure out PIC assembly is a deal breaker for me. Yeah, I know, I'm stuck in the 80s, but the only thing that makes sense to me is HC08 and S08 assembly and it does exactly what I need to make a living.

[Bud]

Why people bring up the old 8 bit pics is beyond me.   The PIC24 series is awesome.   Flat memory and hardware multiply.  What's not to like.

Horses for courses. There are a lot of small tasks 8 bit microcontrollers will do perfectly. I do not need hardware multiply to i initialize a DDS or scan a keypad.

[mikeselectricstuff]

Why people bring up the old 8 bit pics is beyond me.   The PIC24 series is awesome.   Flat memory and hardware multiply.  What's not to like.

Yes, PIC24 is pretty nice, but higher cost, and no 5V operation.
I like the 16F15xxx 8-bit parts - two UARTS,CLC, NCO, four PWMs, fully pin-mappable,plenty of RAM and cheap

[bd139]

Regarding the old 8 bit PICs, as much as I bitch a lot, I rather like the PIC10F320. There's a lot of power in a SOT23! Saves pissing around with individual gates/logic ICs.

[bhave]

I think people that complain have not used the newer stuff Microchip has developed in the last few years.  The dsPIC C and CH series just flat out perform.  The newer 8-bit PIC16 and PIC18 series have fixed quite a few of the old memory issues and offer some really nice peripherals.  The way you can remap pins makes development so much easier and allows lots of flexibility when designing a board for future expansion.

Ultimately, I jump between various brands and models of MCUs based on peripherals, packaging, price, and availability.  The architecture is way down my list when choosing something.  When I am working on something that requires expanded temperature ranges or certain certifications, my choice is more limited and Microchip almost always has an offering.

[hans]

I like the 16-bit PICs as well. That architecture is C-compiler sanity proof, while still low level enough to work directly with the I/O space.

I don't use the 8-bit PICs extensively anymore. Only if I need some simple if-this-then-that functionality that doesn't require processing lots of data.

I don't really like MPLABX or the XC compilers. MPLABX feels so sluggish and buggy. XC compilers are based on GCC but also locked down and often out of date. But.. it does work, is easy to install on Windows/Linux/Mac, and a single cable to a PICKIT 3 has one up and running with hundreds of parts in 1 click.

It's completely beyond me why a powerful architecture like the 16-bit PICs does not have a C++ compiler. You can even get dual-core 90-100MIPS 16-bit PICs right now with 64kB+ RAM. That's "more MCU" than you get with a jellybean STM32..

I like the PIC32 scheme. The PIC32MX was my first step into 32-bit MCUs, and I like the simplicity of it's peripherals while still offering reasonable amount of horsepower at the same time. I've yet to try the PIC32MZ (I still need to order a mockup devboard to use the samples I've got laying around..), but it seems like a very capable part.

I'm not really familiar with the Atmel 32-bit ARM parts. Their part catalog's naming scheme is completely beyond me. But I've seen some neat parts in there..

So I'm as mixed on Microchip as I'm on any other MCU manufacturer. I jump around a lot between manufacturers, but I also like to reuse common code between my projects. That makes standardized/open tools like GCC a must, and I think that's something where Microchip can improve. I don't understand why Microchip wants to earn money in toolchain sales; for what overall benefit?

[peter-h]

I have a production design using the old Atmel 90S1200. Bought a big load on the last time buy, £0.50 each. Still have some left, then will have to redesign. Did a redesign using the 2313 and Atmel dropped it by the time I finished

I see they still do the ATtiny2313A and maybe they will still make it by the time I get around to it The price is in the right ballpark but only for the square-package one - ATTINY2313A-MU. The rest all cost a lot more and are sold out.

The code just reads a dipswitch and loads a timer with a value based on that.

There are loads of applications for these little micros, 50 pence in volume. The learning curve is not big either, and the assembler runs (or used to run; not looked at the 2313 setup) in a DOS box, out of a simple batch file.

Never used any of the "real Microchip" stuff. But I do remember the original "PIC" from the 1970s, made by General Instrument, which was called AY-something and had a totally bizzare instruction set. They sold millions of masked ROM versions.

[Nominal Animal]

What do you mean by "like Microchip"?

I use lots of Microchip products, and like them.  (I do have both originally Atmel parts, as well as originally Microchip parts, that I like.)

I dislike Microchip the company, because of their business practices.  As a hobbyist, I don't like how they need to make profit on every single aspect. I know perfectly well why they do that, and how it makes sound business sense for them.  I just don't like it personally; I have no interest in being that sort of a customer.  (The situation would be different if I made commercial projects, of course.)

I especially don't like how they used calculated legal subterfuge for years to keep their customers unaware of their rights with respect to their GPL-licensed compilers.  Even today, some still insist –– incorrectly! –– that their customers do not have the right to remove the artificial limitations or license checks from the GCC-derived compiler.  (They do have that right.  Any license or agreement that forbids that between Microchip and the customer would void Microchips' own rights to redistribute the parts that they didn't own copyrights to.)  GPL is a simple license, and having FUD spread about it is annoying.

(Once again: No, I am not a GPL zealot. Tux is my mascot, not my idol.  Licenses are just another tool, and I happily use both proprietary and copyleft licensing, whatever makes most sense in a given particular situation.  My beef wrt. GPL is that it is a simple tool that is being twisted to look like something it is not.  That affects things I've licensed under GPL, and I don't like that at all.  Any kind of widespread license misunderstanding annoys me the same way.)

I like the fact that Microchip is moving to LLVM/Clang, because now they don't need to spread FUD to bolster their bottom line.  The license –– Apache License 2.0 with LLVM exceptions –– is much more suitable for their business model, and there is a good possibility both Microchip and their customers will benefit.

Atmel was a company who understood how to leverage open source software properly.  I was sad to see it bought by Microchip, because Microchip definitely does not.
Companies like Atmel are relatively rare.  I've been looking into Chinese Rockchip recently; they too seem to get it right, including pushing support directly upstream into the vanilla Linux kernel by actual paid engineers.  Similarly for ARM (the company), although the Nvidia acquisition is likely to change that much more drastically than the Microchip acquisition of Atmel, because Nvidia is still actively hostile to anything open source, and is more likely to use their acquisition to restrict competition than bring anything useful or worthwhile to their customers, when considering Nvidia's past business practices.

So, "not like Microchip" can have many different reasons, and it does not exclude liking their products.  Moreover, Microchip having nice products does not mean you cannot dislike their business practices or the company as a whole due to their behaviour.  My own opinions are subject to change if my own needs change.  Finally, there is no reason to be extreme, and claim people dislike Microchip for the wrong reasons, because these are just opinions.  The interesting bit, really, is the reasons behind those opinions.

[SiliconWizard]

I think people that complain have not used the newer stuff Microchip has developed in the last few years.

With that sentence, you're like putting all points in the same basket, while there are various reasons that have been exposed. The dev tools are definitely one.
Then, fitness of products for given applications is all really dependent on everyone's environment and projects. Myself, except for the temperature range which is mentioned below, Microchip MCUs in general just have not much to offer compared to other vendors I've picked lately. But that's just my own consideration.

As to erratas, I confirmed the I2C issue on some PICs, but to be honest, apart from this, I have not been bothered that much by Microchip erratas compared to other vendors. They are not particularly worse in general.

When I am working on something that requires expanded temperature ranges or certain certifications, my choice is more limited and Microchip almost always has an offering.

Yes, that's one reason for using Microchip parts these days. I've used a PIC24F with 150°C operating temp in a project that would require working properly and over a long period of time at temperatures up to about 140°C. Not a lot of corresponding offers from competitors, or sometimes at unacceptable prices.

[woofy]

I do remember the original "PIC" from the 1970s, made by General Instrument, which was called AY-something and had a totally bizzare instruction set. They sold millions of masked ROM versions.

Do you have any more info on that?
As far as I'm aware, the first PIC was the PIC1650 series which ranged from the 18 pin PIC1645 (256 bytes of ROM) to the 40 pin PIC1650 (512 bytes ROM).
I know they made quite a few AY series chips from sound generators to pong games, but I've never heard of an AY series processor and a quick google didn't reveal anything.

[SiliconWizard]

I dislike Microchip the company, because of their business practices.  As a hobbyist, I don't like how they need to make profit on every single aspect. I know perfectly well why they do that, and how it makes sound business sense for them.  I just don't like it personally; I have no interest in being that sort of a customer.  (The situation would be different if I made commercial projects, of course.)

To be honest, I've used Microchip MCUs in the past both in professional settings and as a hobbyist. I never really found Microchip was difficult to deal with as a hobbyist. Their MCUs were always fairly priced, the doc was good, and the dev tools could be had basically for free for hobbyist use. So nothing really problematic here.

I especially don't like how they used calculated legal subterfuge for years to keep their customers unaware of their rights with respect to their GPL-licensed compilers.

Sure, what they did with GCC is pretty odd, and more than questionable. Not completely sure how they managed to get away with this from a legal POV, but I'm sure they have a bunch of lawyers.

I'm not against the fact a given company charges for dev tools (that might be something that could drive me away if I'm using products as a hobbyist, but otherwise, it's fine.) Doing this licensing thing would have been "fine" if they had developed (or acquired) their own compilers. But doing this from a GPL compiler is, certainly, just plain wrong.

Now in theory, they are not doing anything fully wrong either, I guess: they have released source code, and - already disscussed - even though their compilers are a bit annoying to build compared to vanilla GCC, that's still doable, and any company can charge money off open-source stuff. I agree the gray area here is that they were never clear regarding using compilers built from source, but nothing can prevent anyone from doing so. It IS open source! In the end, thinking about it, Microchip has a right to sell XC compilers even if it's open source. Crippling them with license checks is questionable though, but I guess this is the only way they found for enforcing buying them. The more reasonable approach, as any other company would do with open source software, would have been to distribute their compilers built from source without any license checking, and sell customers support for those willing to have support. That's usually how you deal with open source software as a commercial company.

[oPossum]

I do remember the original "PIC" from the 1970s, made by General Instrument, which was called AY-something and had a totally bizzare instruction set. They sold millions of masked ROM versions.

Do you have any more info on that?
As far as I'm aware, the first PIC was the PIC1650 series which ranged from the 18 pin PIC1645 (256 bytes of ROM) to the 40 pin PIC1650 (512 bytes ROM).
I know they made quite a few AY series chips from sound generators to pong games, but I've never heard of an AY series processor and a quick google didn't reveal anything.

The first PIC (Programmable Intelligent Computer) was the PIC1650. The 16C54/55/56/57 where the next generation of PIC and featured OTP PROM rather than mask ROM of the the PIC1650.

[woofy]

The first PIC (Programmable Intelligent Computer) was the PIC1650. The 16C54/55/56/57 where the next generation of PIC and featured OTP PROM rather than mask ROM of the the PIC1650.

That's what I thought too. Peter-h may have been thinking of the CP1600 series, a 16-bit CPU used in the Intellivision games controller. That's the only other GI series I know of.

[Nominal Animal]

I'm not against the fact a given company charges for dev tools (that might be something that could drive me away if I'm using products as a hobbyist, but otherwise, it's fine.)

Well put.  As a hobbyist, I don't like it.  If I were doing commercial stuff, it would not bother me at all to pay for dev tools.  (I have, lots, in the past, when I ran a software company.  When doing business, it is not a good idea to be thrifty when it comes to tools.)

With LLVM/Clang, the licensing is clear, and matches the business pattern well.  It does not preclude Microchip from also pushing support to open-source toolchains (consider e.g. the Arduino/PlatformIO environment).  Also, since they now really do control their own toolchain, they won't need to try and use the Hardware Abstraction Libraries for customer retention; those devs can concentrate on making the libraries better, instead of deliberately trying to keep things non-portable.  Might affect documentation, too: some companies have drifted a bit towards documenting their hardware through their HAL, which I definitely don't like.

Now in theory, they are not doing anything fully wrong either, I guess: they have released source code, and - already disscussed - even though their compilers are a bit annoying to build compared to vanilla GCC, that's still doable, and any company can charge money off open-source stuff. I agree the gray area here is that they were never clear regarding using compilers built from source, but nothing can prevent anyone from doing so.

Yes, I agree. Selling GPL-licensed software is absolutely fine.  You just cannot restrict the rights granted by GPL without violating the GPL license itself.  (Selling custom software to an organization using the GPL license is often an excellent choice for both: the organization can develop it further with anyone they choose, but cannot really develop it into a product they'd sell as a commercial product, except under the GPL license itself.  If you do customization and integration for a specific type of business, it is a pattern worth considering.)

My objection was mainly how they let especially their user forums propagate the lie that removing the license restrictions would violate copyrights or Microchip EULA.

At the core, I dislike companies conflating things they wish from their customers, and things they can require from their customers by law/statute/license.
It can sound petty/useless since it is rather common nowadays, but it is my opinion, based on my personal experiences.

[DavidAlfa]

When you went with low end models, you had a lot of drawbacks. But you get used to them.
If you wanted power, the dspic33s were beasts. 40 MIPS, mostly single-cycle instructions, 48KB ram in a 28PDIP... crazy and expensive!

The harward architecture has its benefits. ARM core can only access the work registers, so first it needs to load the address, fetch the data and then work with it, while pics usually can address anything, ignoring the bank selection thing.

For example, toggling a GPIO:
- PIC, clear/set/toggle RA3: bcf/bsf/btg LATA,3
- ARM: Load address of GPIOA->ODR into the register (pointer)
           Get the value
           Modify the bit(I barely know any thumb/arm asm, but I guess it uses a OR/AND/XOR mask, so at least another 2 instructions)
           Write back the new modified data using the already set pointer
           But also arm is pipelined, so the real behavior is different.

The xc8 compiler works pretty well. Last time I checked the disassembly, the optized code was really good.
But I also remember manually adding assembly instructions in a pic24 because mplabc c16 (Now xc16) didn't use the hw div instructions.
About the peripherals... Some were really buggy.  But also stm32 has some serious issues.  Even the newest ones.
So it seems there's crap everywhere. I'm starting to think there's no mcu on earth that works like in the papers.
Lots will require reset and initialization when something goes wrong.

"Use the enable/disable bit to reset the spi peripheral"- Best joke of the last 20 years!  

I don't hate pics, but they got really old once the arm came into the game.
Never understood why there isn't GCC for them. AVR is pretty similar and has been supported since long time ago.

[bhave]

I think people that complain have not used the newer stuff Microchip has developed in the last few years.

With that sentence, you're like putting all points in the same basket, while there are various reasons that have been exposed. The dev tools are definitely one.
Then, fitness of products for given applications is all really dependent on everyone's environment and projects. Myself, except for the temperature range which is mentioned below, Microchip MCUs in general just have not much to offer compared to other vendors I've picked lately. But that's just my own consideration.

I guess that was an unfair overgeneralization.  The dev tools are what I consider about average.  I find Mplab X no better or worse than the many other iterations of vendor supplied development studios over the years.  I have certainly dealt with plenty of bugs in Code Composer Studio (before and after Eclipse), Keil, IAR Workbench, the ST program of the month, MCUXpresso, ... etc.

The Microchip compilers are what they are and work fine.  The fact they are functional safety qualified is nice and the pain of going through that is probably why they charge for premium versions of what is otherwise a free compiler.

Ultimately, I have a collection of development tools and invariably choose the MCU that meets the needs of a project based on functionality rather than brand.  I like having someone to call when something does not work properly and really just want to install tools, get the project working, and move on to the next.

I originally commented on this because I find Microchip MCUs fine and never understand the hatred toward them.  Like any other tool, there are suitable uses for them and uses that are not suitable.

[JPortici]

MPLABX is based on netbeans which is basically someone trying to fix the sins of eclipse and only succeeding in creating another Cthulhu shaped monster to terrorise you.

My only comment is at least it’s not visual studio.

 
always to the point

[JPortici]

I have to say i also don't agree with their business practises, but microchip is a company that MUST be profitable at every quarter. Good for current investors, good for parts availability, bad in the long run for innovation ST for example on OTOH is more focused on innovation and long term returns, thats what enabled them to come up with just stupidly powerful automotive components, like their cortex R with hardware virtualization for high performance ECUs

Anyway, AFAIU in the current state of things, here's what you get with the compiler license:
- The Highest degree of optimization, as up to -O2 is free for every compiler (the engineering team fought like beasts to get -O2 from the beancounters. They are currently fighting for freeing all optimizations), i'm okay with this as O2 is already hard enough to debug/inspect. Sounds good to me
- Support. Nobody can argue against paid support
- The functional safety versions, which are the same as the current version but verified against whatever standard then you get the required documentation and support. Again, nobody can honestly argue about this
- Propietary tools like code coverage or profiling tools, they are proprietary so they can do whatever they want.

XC8 is not GCC because at the time HiTech made the best compiler for 8bit PIC (that produced the overall best code, even though it never supported the extended instruction set for PIC18) and the Hitech Compiler was not based on GCC. No point in throwing away decades of good product for the sake of open source.

And please, nobody start with the bullshit about XC8 adding intentional bloat in free mode. That has been discussed to death. loading "1" and adding with carry instead of using the INC instruction for char++ is just the generic approach that was not optimized due to a bug, it was corrected. Unnecessary bank selection is also the generic approach that was not optimized due to a bug, it was corrected. Whenever something very very very stupid happens in a new update for the compilers is a bug. not a way to screw you free folk. report it and see that it's fixed in a hurry.

[westfw]

XC8 is not GCC because at the time HiTech made the best compiler for 8bit PIC

XC8 is not GCC because there is no gcc for 8bit PICs, and essentially CAN NOT be a gcc for 8 bit PICS because the PIC architecture is too far away from what GCC thinks a CPU should look like.