Why do people not like Microchip?

[Pineapple Dan]

Inspired by comments in the other thread I created

I have never really used any other MCU unless it came pre-packaged on another board (Arduino, pyBoard) but anything I designed the PCB for I have used PIC8 and PIC16. Not trying to start a flame war just interested to see what people don't like about them and what do they use instead.

For me the biggest problem is how finnicky the ICD3 and Mplab have always been - ordered a Pickit 4 so hopefully this will be better. Just when I think i'm getting somewhere with a project I get random 'Transmission error on endpoint -2' messages, next thing the MCU has blown up, soldering on a new one has failed, rebooting yields new error messages and before I know it the PCB is completely shagged and I'm miles out at sea with no life jacket and a large shark fin circling around me.

[ace1903]

I miss good quality c compiler. Architecture of their 8 and 16bit micros  does not allows efficient stack implementation.
Compiler needs to be smart when needs to use 8 bit pointers and when 16 or 32 bit pointer.
I am forced to use CCS compiler that is like a toy. They sell it without mentioning that does not support any C standard.
If you have larger array of data trying to achieve atomic operation is mission impossible. They even not support PIC's built in instructions for efficient index operation.
Never tried Microchip's XCC compiler. Would like to  hear opinions.
ICD4 is garbage and never tried Pickit4 although pickit3 is very stable.

Debugging USB implementations is difficult   without USB analyzer. Sometimes USB stack on pc side is in inconsistent state if device stops responding due to some breakpoint.
Frequent PC restarts are required.
My experience is that micros are well designed and stable. Only issue I had with them was that RC oscillator frequency was dependent on power supply voltage and temperature.
Easily goes out of spec when both are changing.

[woofy]

Why do people not like Microchip?

Perhaps because people who are happy with Microchip just don't make a noise. For me, Microchip are the goto processor supplier. I'm reasonably familiar with the architecture and tools, so I select the lowest cost processor that gets the job done.
I mostly use the XC compilers, so the architecture is irrelevant, either it gets the job done or it doesn't.

[luiHS]

Expensive microcontrollers.
Expensive evaluation boards.
Expensive C compiler.
Not compatible with other manufacturers.

Just the opposite of ARM microcontrollers.

[SiliconWizard]

I personally used to like Microchip. They had nice chips and were well positioned IMO. Pretty good documentation too. Until, I would say, about 10 years ago.

At that point, I started to lose interest in their products. The offering for ARM-based MCUs (from very low power to pretty powerful stuff) literally exploded, and you could use 100% free and open-source tools with them. MPLAB X was also not really good news either for me. Not being able to use standard JTAG on most of their MCUs ended up sucking really bad too.

Sure they now also have ARM-based MCUs with ATMEL, but that kind of was too late for me. They kind of missed the train with the PIC32 line. Don't get me wrong, it wasn't bad at all, but their venture with MIPS was eventually questionable, and the end result was less powerful and more power hungry than many other 32-bit MCUs from competitors.

That said, even though I think it's not as good as it used to be, Microchip's documentation is still pretty good compared to many other vendors. Oh, and I rather liked the DMA in PIC32. Pretty cool.
Another point is that if you stick to the 8-bit or 16-bit Microchip MCUs, they are much simpler than most 32-bit MCUs on the market, much easier to master, so that can be a real plus. I personally don't have a need for those anymore, but they are certainly still plenty usable in many applications.

But really - as many others think too - the main issue is with their dev tools IMO at the moment.

[SteveyG]

Microchip are great, especially when it comes to choosing a microcontroller for something that will hit production.

Some people dislike using MPLAB, but again when it comes to needing a validated tool, this makes things easy.

Also worth noting that Microchip have huge stores of bare die ICs for almost every PIC they have produced and can package these very quickly if there's ever a stock shortage.

[bd139]

Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

At least STM32 bugs are mysterious 

[SiliconWizard]

Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

Ah, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

[jpanhalt]

Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

At least STM32 bugs are mysterious 

Like you say, the real datasheet is in two parts.  The first part is how Microchip planned the chip.  The second is what the chip is really like.  I learned a long time ago to always check the errata.  The good part is that as bugs get fixed, the errata is updated.  That practice dates way back to its earliest chips, e.g, 16Cxx with interrupts. 

[bd139]

Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

Ah, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

dsPIC33 too. Man I got angry with that one. Fortunately it was a personal project so it was canned.

I picked up some AT89C2051 out of spite after that 

[janoc]

I picked up some AT89C2051 out of spite after that 

Don't bash the AT89C2051! That was the first micro I have learned on, back in 1998 or so. Heck, made an ultrasonic 3D mouse with one of these and another one was meant to control a small mining locomotive instead of a huge metal box full of a Z80-based control system.

Those things were surprisingly good, especially when compared to the EPROM-based '51s ...

[bd139]

Oh yes 100% not knocking the things. I was merely saying fuck you to Microchip 

[lucazader]

For me its mostly about the toolchain.
Open toolchains that can be used with modern build systems, to allow ci and unit tests are a must.

[bd139]

As someone who maintains modern CI systems, I’d rather use a shitty old tool chain at this point.

I miss my entire build stack being make or a single cmd file on windows.

[jenniferkim]

The main reason is their compiler ..... Their official compiler is MPLAB, which is so out of date.

When I have to work on PIC Microcontroller, I normally use MikroC as it has built-in libraries plus examples.

On the other hand, Arduino compiler is too user friendly, they have built awesome libraries, so programming Arduino Nano is way too easy.

[nctnico]

Inspired by comments in the other thread I created

I have never really used any other MCU unless it came pre-packaged on another board (Arduino, pyBoard) but anything I designed the PCB for I have used PIC8 and PIC16. Not trying to start a flame war just interested to see what people don't like about them and what do they use instead.

For the 8 bit devices the banked memory is the major downside; you can't write normal C for it as you can for controllers which have a single memory space (and thus support pointers natively). Needing a proprietary C compiler is also a big downside. I've standarised on GCC for all microcontrollers I use so I can re-use code across various platforms using the same compiler specific extensions.

But in general I consider every part from Microchip to be low quality & troublesome so I don't use anything from Microchip (including the formerly Atmel parts). The exception are the formerly Microsemi parts.

[bd139]

The main reason is their compiler ..... Their official compiler is MPLAB, which is so out of date.

When I have to work on PIC Microcontroller, I normally use MikroC as it has built-in libraries plus examples.

On the other hand, Arduino compiler is too user friendly, they have built awesome libraries, so programming Arduino is way too easy.

The trick with the arduino is to steal the avr-gcc toolchain out of the IDE and use that with a half decent text editor instead.

[T3sl4co1l]

FYI, Code::Blocks is quite comfy, and easily set up for GCC on AVR, ARM, etc.  I haven't used AVR Studio in ages, and good riddance (and never touched Arduino ).

If nothing else, resorting to Notepad++ or the like, is certainly an option, but you won't have project visibility, function prototypes, comments, etc. handy as you would in a proper IDE.

Tim

[westfw]

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 (it does that OK, and it was first, cheapest, and most readily available for a long time.)  The ugly architecture means that HLLs are hard to write, which means that there are fewer of them, and they tend to be "expensive."  (especially compared to the "free" gnu compiler(s) that many other CPU architectures support with "not much effort" on vendors' parts.)

Hobbyists get misled by "projects" from the decade-or-so when the PIC16F84 was THE go-to choice, leading them down paths that are frustrating to watch.

For the non-8bit-PIC architectures, Microchip flouts the spirit of OSSW by taking gcc and selling it, with a "free" version that removes some of the features that were present in the non-Microchip versions.  They're slow to publish their source modifications (required by gpl license), and even slower at remaining current with the changes from FSF (Microchip avr-gcc is at 5.4, FSF avr-gcc is at 11.0)

The choice of MIPS architecture (instead of ARM) for PIC32 is generally not well received.

Microchip has been somewhat "greedy", corporate acquisition-wise.  (I think they've done pretty well WRT continuing product lines/etc, but I'll bet there are some ZeroG and Roving customers that are less happy.)

There are the usual bugs and sub-optimal behavior in hardware, software, library, and configuration tools.  (Are there really any microcontroller vendors that are "well-liked" by everyone?)

[mikeselectricstuff]

Not compatible with other manufacturers.

Just the opposite of ARM microcontrollers.

Are you serious? The CPU simply doesn't matter when you are writing C. It's ALL about the peripherals, and ARM manufacturers are as different from each other as they are with Microchip

[jpanhalt]

Those who refer to RAM blocks have not used more recent 8-bit chips.   All of the RAM is mapped to contiguous linear memory.  If total ram is 4096 bytes, you can access all of it without changing Banks, if that is what you need (16-bit FSR is used).  Ii addition, Common ram (usually at 0x070 to 0x7F (16 bytes)), which is accessible from any Bank,  is still available.  My current project uses that linear RAM for a FIFO cyclic buffer.  Of course, you may also want to preserve Common RAM for other things, so you can still address user RAM in an appropriate Bank.  For example, I use Bank 4 for some constants to refresh an SPI GLCD.  That avoids Bank switching and does not use Common RAM.

I code in Assembly, but I assume anything Assembly can do, C can also do.

[mikeselectricstuff]

I think a lot of the anti-Microchip people are basing opinions on the older architectures and heresay.

Everyone has different requirements. From my point of view, these are some of the reasons I like Microchip. I can't compare with others as I've yet to feel the need to look elsewhere. 

Availability - this has always been a strong point. While all the ST/NXP/whoever people are tearing their hair out right now trying to get parts, I can still get pretty much any PIC I need from Digikey. And if a particular part is thin on the ground, there's a very good chance there is either something pin-compatible that is available, or the same part in a different package

Devtools - maybe a bit controversial, and admittedly I don't do big projects, but the fact that I can use exactly the same IDE AND programmer , with the same ISP header,  for everything from a 6-pin PIC10F to a 200MHz PIC32MZ part saves me a ton of learning time.
The fact that the whole IDE and toolchain is well integrated means that where needed, I can give a customer my project directory, tell them to install MPLABX, buy a Pickit 3, and they can be up and running in 10 minutes.
One instance I recall this being invaluable was when a customer with zero MCU knowledge wanted to be able to create different LED brightness curve lookup tables.

Similarity of peripherals across the range - again, from an 8 bit to a 32 bit part, a lot of the peripherals (and peripheral register names) are either exactly the same, or similar enough that there is minimal learning curve. On the larger parts with more complex peripherals, they tend to default to working the same way as the lower-end ones until you explicitly configure them otherwise.
Even stuff like self-programming for bootloaders is very similar across the whole range.

Pin mapping flexibility - this varies across the range, but in most cases there is enough flexibility in mapping pins and/or choice of multiple peripherals (UART1 vs. UART2 etc) that PCB layout is greatly simplified.

Package flexibility. Most parts from 8 bit to 32 but have a choice of 3 or 4 packages - DIP,SO,SSOP, DFN/QFB, QFP. Yes, 32 bit parts in DIP or a 20 pin SSOP or QFN20. In many cases a wide range of pin counts for the same basic part.

Pre-programming - MicrochipDirect will preprogram , mark and re-reel PIC10s for about 4 cents, with about 1 week leadtime and negligible setup cost. PIC32s from memory about 30c. AFAIK no other manufacturer offers this, and third-party programming services can cost more then the chips. Digikey has a programming service but only for US customers. Pickit 3's programmer-to-go functionality is also extremely useful for production by subcontractors - just send them a pre-loaded programmer, and all they need to do is connect and press a button.
Alternatively I can easily talk them through setting  up a pickit 3 themselves.

MIPs vs. ARM is simply not an issue when everything is in C.
Yes the 8-bit architecture sucks, but C hides most of it well enough to rarely be a problem. I've done projects with application and a serial bootloader in the 512 words of a PIC10F, all in C.




 

[AaronLee]

Microchip are great, especially when it comes to choosing a microcontroller for something that will hit production.

Some people dislike using MPLAB, but again when it comes to needing a validated tool, this makes things easy.

Also worth noting that Microchip have huge stores of bare die ICs for almost every PIC they have produced and can package these very quickly if there's ever a stock shortage.

The availability issue is the primary reason I (ie. my customers) keep using Microchip. I much prefer to develop for ARM MCUs, but with decades of experience with Microchip, I can bang out a project very quickly, the customer typically doesn't need to worry about part availability, and even though Microchip cost/performance ratio isn't very good, my customers know it'll work and be reliable, and they don't really want to change. Just last week I had a project where once again the customer wanted to use a Microchip, and a part number which I've done dozens of projects for. I just copied various sections of code from previous projects, added the appropriate new code, compiled right off without any errors and ran on the target without any bugs / need for debugging. Took all of 30 minutes to do. The customer was very impressed, and it made me feel very good that it was one of those rare occasions where everything just worked exactly right the very first time.

[AaronLee]

Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

At least STM32 bugs are mysterious 

Yup, the old I2C completely unusable issue. For most of my projects, speedy operation isn't necessary, so I just start out with using my bit-bang I2C library. Only if the bit-bang speed isn't sufficient do I change to hardware I2C, and of course in that case must select a part which has working I2c. With lots of I2C devices in some projects, and for various reasons we don't want to share the same I2C bus, often I don't have sufficient I2C ports anyways, so bit-banging is a must. The same for SPI.

[AaronLee]

The main reason is their compiler ..... Their official compiler is MPLAB, which is so out of date.

When I have to work on PIC Microcontroller, I normally use MikroC as it has built-in libraries plus examples.

On the other hand, Arduino compiler is too user friendly, they have built awesome libraries, so programming Arduino is way too easy.

Having a MCU and environment that is "way too easy" is fine for some quick hobbyist project. But for most professional projects I do, it likely wouldn't work. Admittedly, I've only used an Arduino a few times for a quick and easy personal project where I based it off of an existing public domain design, so I don't have lots of experience. But in general, when it comes down to professional projects, there's very often some key issue that requires tweaking things in ways that standard libraries can't handle, and which takes time to get it right. That's not to say I want to waste time with poorly designed tools and libraries, which is a problem with Microchip. But I definitely don't want a MCU where I'm required to use "high level" "easy to use" stuff that ultimately never allows me to do exactly what I want to do. And Microchip Harmony is probably the worst offender of all. I hate that piece of turd Harmony. Other MCU vendors though are also gravitating towards similar approaches. I prefer to hand code definitions for each of the pins I'm using, manually initialize each pin/port, and just do everything at a low level, often with my own library of drivers, not even touching the vendor's libraries, other than sometimes for MCU initialization. If my goal though was just as a hobbyist or someone designing really basic/simple projects, I'd likely see things differently.