Why do people not like Microchip?

[IDEngineer]

My $0.02....

Long ago I stopped worrying about the ultra-fine details of compilers, linkers, IDE's, etc. While those are interesting mental exercises (and I AM very interested and those topics DO have a lot of merit) I am not paid to write and maintain the toolchain. I get paid when my designs and my products are delivered and meet spec.

I like Microchip. A lot. While their parts aren't always bleeding edge, they do what they say in predictable ways. That means a lot in the real world of delivering solutions. Are there other choices? Sure. Better choices for a given design? Perhaps. But their parts are generally available and stocked by multiple distributors (today's nonsense notwithstanding) and Microchip Direct will sell them straight to you if desired. Their documentation is better than most, you can give your customers debuggers (PICkits) for free to help them help you remotely, and frankly the ICD3 has been bombproof for me (I've avoided the ICD4 since the ICD3 has no problems I'm need to fix).

I've also never, EVER had any other company support me like Microchip. Two examples:

1) A few years ago I was having problems with one of their on-MCU peripherals. I posted the question to their support forums, and next thing I knew their Engineering staff had scheduled a conference call with me. When they called, there was half a dozen Microchip staff on the call, everything from digital guys to analog guys to MCU guys. Oh yeah, and one sales guy who barely spoke. They spent a solid 30-45 minutes with me grinding through the issue. When it was all over I openly thanked them for the incredible support, especially since we're a rather small customer for them. They asked "how many devices do you buy from us annually?" and I estimated 10K. They responded "Our business is based on smaller customers, 10K is plenty of quantity, and emphasis on smaller customers comes straight from the top of our company". No other company has even hinted at such an attitude, let alone acted on it the way they have.

2) Just a week ago I was helping one of our Contract Manufacturers (CM) search for parts in today's craziness. Turned out they had placed an order with Microchip Direct (MCD) for some PIC18's we use and after the order was accepted, it came back with a change saying the delivery date was pushed out almost a year (!!!). I found an compatible alternative on MCD (different temp range, but still a  different part number so the CM wouldn't substitute without our approval) and started a chat session with MCD to make absolutely certain they wouldn't pull the same trick on this order. The MCD rep was surprised I would ask such a question, which led to me explaining how they'd pulled a bait-and-switch on our CM with the delivery date. It took a few hours but the representative not only guaranteed they'd ship the new order immediately, but also took the time to go back and fix the previous order so it would ship immediately too! In today's market you know they could just ship their parts to the next buyer... but she admitted this was a clerical error and took the time to correct a small order for a small customer (it was only one reel of parts). Again, no other vendor has ever stepped up like that for us.

Nobody's parts nor tools are perfect, but Microchip is a pretty darned good mix of everything backed by great people with an awesome attitude. Speaking of that: I once ran into a guy at a local pizza place who was wearing a Microchip dress shirt. WTH, I live in a rather small town in North Idaho! So I approached him, and he turned out to be head of their Analog division in Arizona. Incredibly nice guy, and despite being there with his wife on vacation he sat and talked with me for quite a while on an array of topics. In other words, yet another example of the great people who work for that company.

As I said, just my two cents. I felt I had to share when the title of the thread started with "Why do people not like Microchip?" Normally all you hear are complaints about companies and people, so I wanted to offset that with my own positive experiences. YMMV.

EDIT: Two more thoughts occurred to me after I wrote this:

1) I've personally found the PIC lineup to have a convenient mix of on-chip peripherals. There are still a couple of combinations they don't offer which would have made MY life a bit easier, but generally speaking for most designs I've been able to avoid implementing separate peripherals connected by SPI/I2C because what I need is already in the package.

2) Their support of us when we were only buying ~10K pieces annually has resulted in us buying a LOT more than that these days. We're still small by most standards but if 10K is important enough to them to be noticed, we're probably in the "middle school" range now! That's the sort of "pay it forward" support that helps the small customers become larger. And we remember who helped us.

[SiliconWizard]

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.

There isn't a GCC for 8-bit targets AFAIK, except one: avr-gcc. It is GCC-based and officially supported by the GCC team. https://gcc.gnu.org/wiki/avr-gcc
So I guess some people used to AVR are probably wondering why the hell Microchip didn't go the same route. Now, I admit not knowing much about avr-gcc, but I'm pretty sure this was hard work and hard to maintain, so I don't blame whoever wouldn't want to go through this same mess. As to architecture, I admit I don't know the AVR architecture enough to judge how much easier it was than with the PIC, but certainly all the oddities of the 8-bit PICs were much more severe.

SDCC is a possible option as a compiler for 8-bit targets. It supports a range of processors, including Microchip PIC ones. Support is still not perfect though, as far as I've seen. I've used it for 8051-based MCUs, and it was fine. But people using 8-bit PICs and absolutely willing to use an open-source compiler can certainly have a look at SDCC.

[SiliconWizard]

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.

Oh, then I see your point. But as you asked for opinions, it was still interesting to see various points of view.

You're right though. Not *all* people have had a perfectly rational reason for not willing to use Microchip MCUs, and for a fraction of them, there seems to be some kind of ideological disdain. I remember, almost 20 years ago (already!), one very experienced engineer in my team was always telling how PIC MCUs were just crap toys for hobbyists and how he would reject using them in any new design. Back then I eventually used one in a project that he was not involved in, and it turned out great. The guy stopped talking about Microchip after this.

So from what I remember, many people tended to consider PIC MCUs like toyish MCUs back in the days, a couple decades ago. It's funny to see that now, many people consider PIC MCUs to be no good for hobbyists.

[DavidAlfa]

Being easy to develop for has nothing to do with the real life performance or capabilities of a mcu. In fact, I wouldn't call it "for hobbists" or toy-like, like I'd do with arduino for example.
To program a pic you had to completeley understand how the hardware worked, the memory mapping, registerss... Although that changed a little in the recent years with Harmony stuff.
And there was no C until Hi-Tech came around. So if a amateur could program them and make useful stuff, an experienced enginner would squeeze them easily.

I still remember a crazy guy who implemented a HID usb protocol in a 16F84, all bit-banged, slightly overclocking it to 24MHz. (Spanish)
https://web.archive.org/web/20130320144542/http://www.telefonica.net/web2/hidlcd

Also this one did something similar with an AtTiny
https://www.modding.kh.ua/a/IgorPlug-USB_(AVR)_eng.htm

So when someone says "8-bits are toys", it looks more like they lazy engineers. There are really smart projects out there.

[Nominal Animal]

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.

There isn't a GCC for 8-bit targets AFAIK, except one: avr-gcc. It is GCC-based and officially supported by the GCC team.

That's exactly why I wrote Atmel knew how to do open source right: it contributed the support to gcc.  There were several Atmel employees contributing to GCC at the time.

Of course, Microchip did buy Atmel in the end, so one could say it did not work out that well for them.  Yet, we probably would not have Arduino without Atmel, as Arduino developers have said that the choice was due to Atmel providing free development tools. 

[Nominal Animal]

I still remember a crazy guy who implemented a HID usb protocol in a 16F84, all bit-banged, slightly overclocking it to 24MHz.

I have a few DigiSpark clones, similar to Adafruit Trinkets.  They have an 8-bit ATtiny85 that bit-bangs the USB 1.1, based on the V-USB (github) USB bit-banging library for AVRs.

There are some USB 3 hosts that don't support USB 1.1 devices anymore, so my advice is to use an USB 2.0 wire hub (the kind with multiple connectors on one end) with these.

[JOEBOBSICLE]

I do hope they discontinue the MIPS products and switch over to cortex m for everything.

[NorthGuy]

I do hope they discontinue the MIPS products and switch over to cortex m for everything.

Both are long-pipelined load-and-store architectures. What difference does it make?

[nctnico]

I do hope they discontinue the MIPS products and switch over to cortex m for everything.

Both are long-pipelined load-and-store architectures. What difference does it make?

For Cortex-M you can use the ARM supported GCC compiler or Clang/llvm and don't have to depend on a Microchip provided compiler. A lot more development is done on ARM compilers compared to MIPS anyway.

[JOEBOBSICLE]

I do hope they discontinue the MIPS products and switch over to cortex m for everything.

Both are long-pipelined load-and-store architectures. What difference does it make?

For Cortex-M you can use the ARM supported GCC compiler or Clang/llvm and don't have to depend on a Microchip provided compiler. A lot more development is done on ARM compilers compared to MIPS anyway.

I have also found compiler bugs with xc32, I trust it a lot less than arm GCC which has a lot more engineers working on it. You can also use Rust very easily.

[NorthGuy]

For Cortex-M you can use the ARM supported GCC compiler or Clang/llvm and don't have to depend on a Microchip provided compiler. A lot more development is done on ARM compilers compared to MIPS anyway.

So what? GCC had support for MIPS since last millenium. Not to mention GCC is hugely overdeveloped already. At any rate, it'll be all RISC-V soon, it's time to forget about ARM, isn't it?

[DavidAlfa]

What? xc32 is based on gcc

Use any compiler, but definitely xc32 is more optimized  for pic32.
Same as  gcc arm and "gnu tools for stm32" (st's patched and optimized gcc-based compiler). The latter produces more compact code using the same optimization.

[JPortici]

I posted the question to their support forums

care to give the link to the thread? just curious.
in the past there were more MHCP engineers active on the forum. The last to leave was george, basically the guy in charge of the simulator (better than most i had to try i have to say) - or the guy resposible to the public for the simulator, which is to me the same thing -

They responded "Our business is based on smaller customers, 10K is plenty of quantity, and emphasis on smaller customers comes straight from the top of our company".

wish i had the same response. the last few years i had a sales droid ask me that BEFORE receiving support. to hell i'm going to answer. i'm reporting issues that exist regardless of the amount of chips that i buy.

Microchip Direct

The only thing i know that remotely resembles microchip direct is TI's store, and they have a long way to climb 

[JPortici]

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.

There isn't a GCC for 8-bit targets AFAIK, except one: avr-gcc. It is GCC-based and officially supported by the GCC team. https://gcc.gnu.org/wiki/avr-gcc
So I guess some people used to AVR are probably wondering why the hell Microchip didn't go the same route. Now, I admit not knowing much about avr-gcc, but I'm pretty sure this was hard work and hard to maintain, so I don't blame whoever wouldn't want to go through this same mess. As to architecture, I admit I don't know the AVR architecture enough to judge how much easier it was than with the PIC, but certainly all the oddities of the 8-bit PICs were much more severe.

SDCC is a possible option as a compiler for 8-bit targets. It supports a range of processors, including Microchip PIC ones. Support is still not perfect though, as far as I've seen. I've used it for 8051-based MCUs, and it was fine. But people using 8-bit PICs and absolutely willing to use an open-source compiler can certainly have a look at SDCC.

borrowing BD139's tone, I only have one finger to give to SDCC. Worst compiler i've ever ever have to deal with. I'd rather write assembly

[JPortici]

Although that changed a little in the recent years with Harmony stuff.

what?
long before MCC/Harmony we had PLIB for peripherals and MLA for USB/Ethernet stacks.
Though "we" never really cared for those, datasheet has always been enough for anything that wasn't PIC32MZ/MK.

[IDEngineer]

I posted the question to their support forums

care to give the link to the thread? just curious.

This was years ago, like perhaps 2016. Doubt I could find the question on the forums anymore. I'm sure things have changed since, but still... that's the best support I've ever received from any chip company except one time back in the 80's when National Semiconductor flew an Applications Engineer to our facility to help debug one of their early video opamps. That was a seriously fun time, our heads down over the breadboard, which was dead-bug style on copper clad laminate, him on the (wired landline!) phone arguing with the chip's designers back in Cupertino(?).

Maybe things have changed with Microchip support since then, but still - credit where it's due. It can't be worse than Bosch Sensortec today, which a while back claimed they were changing their ticket system to "start a thread and we'll respond" to now just the accepted fact that nobody will ever contact you unless you say something disparaging about their company, in which case they accuse of you of "spreading lies" (nevermind the facts you're quoting are visible on the website for all to confirm independently).

[T3sl4co1l]

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.

There isn't a GCC for 8-bit targets AFAIK, except one: avr-gcc. It is GCC-based and officially supported by the GCC team. https://gcc.gnu.org/wiki/avr-gcc
So I guess some people used to AVR are probably wondering why the hell Microchip didn't go the same route. Now, I admit not knowing much about avr-gcc, but I'm pretty sure this was hard work and hard to maintain, so I don't blame whoever wouldn't want to go through this same mess. As to architecture, I admit I don't know the AVR architecture enough to judge how much easier it was than with the PIC, but certainly all the oddities of the 8-bit PICs were much more severe.

AVR is, for the most part: 32 CPU registers, flat address space, memory-mapped IO registers, reasonably orthogonal load-store (RISC) architecture, hardware multiply, and most instructions single cycle.  Stack is traditional (stack pointer into RAM, PUSH and POP instructions).

Oddities include: Harvard architecture (Flash constants accessible by LPM instruction, using PROGMEM and related macros in C); some CPU registers in IO space (flags, stack pointer, some other things); paged memory when extended (effectively, CPU registers have an extra up-to-8 bits section located in IO space, e.g. X pointer (actually r27:r26) extended by RAMPX; this only matters on the larger Flash or RAM devices, or the A-series (fully loaded) devices with external bus interface); interrupts only push address and since flags are in IO there's a whole dance to PUSH it and other important registers (this isn't so unusual really, but different from some that do automatically like x86); and probably more things that aren't immediately coming to mind.  Inorthogonal instructions are mainly the more extended instructions that therefore have fewer operands available, e.g. FMULS and stuff (fixed-point multiply, one for each combination of signs, plus the regular MULs).  Some operands are implicit, e.g. MULs return output in r1:r0, or the DES crypto instruction using r0-r15; there is a 16-bit reg-reg move which only works on even alignments of course; and most immediate operands only work with r16-r31 destinations.  Oh, and instructions are up to 2 arguments, Intel style.

So, overall, pretty easy to compile for.  Most of the quirks are handled by instruction assignment (a less efficient alternative may be used depending on register allocations) and linker scripts (memory spaces, because of course EEPROM, Flash and RAM all start at their own respective zeroes*).

*On XMEGA and AVR0 (new ATmegas), EEPROM can be memory-mapped at a fixed offset.  Though I don't know if the libraries make use of this, or the old method (through the NVM controller).

The main downside is, generated code has gotten worse since GCC 4 or so.  The optimizer seems to be a bit neglected.  I found about a 2x improvement going from -O3 functions to assembler functions on my reverb effect project (at least as of GCC 8.1.0), enough savings that the effect went from a barely usable 2 reverb taps and 1 biquad filter, to 6 taps and 2 filters with about two taps worth of CPU to spare.

But as capability goes, that's a full software DSP effect at 25kS/s, using a simplified mechanism (single delay line with taps, not a proper all-pass), internal 12-bit ADC, external 12-bit DAC, and external RAM (bit-banged).  Not bad for an 8-bit machine running at 32MHz.

Tim

[SiliconWizard]

OK I see. Certainly a lot easier to deal with than the 8-bit PIC architecture, at least when porting an existing compiler.

[NorthGuy]

I have also found compiler bugs with xc32, I trust it a lot less than arm GCC which has a lot more engineers working on it.

XC32 now supports ARM for SAM parts which Microchip renamed to PIC32C. Do you think this makes it bug free?

GCC had support for both ARM and MIPS long before first PIC32 was created. Microchip added very little of PIC32-specific stuff. Both ARM and MIPS appeared long time ago, were meant for PC, but failed. There's no reason to believe that ARM or MIPS implementation in somewhat inferior.

[nctnico]

I have also found compiler bugs with xc32, I trust it a lot less than arm GCC which has a lot more engineers working on it.

XC32 now supports ARM for SAM parts which Microchip renamed to PIC32C. Do you think this makes it bug free?

GCC had support for both ARM and MIPS long before first PIC32 was created. Microchip added very little of PIC32-specific stuff. Both ARM and MIPS appeared long time ago, were meant for PC, but failed. There's no reason to believe that ARM or MIPS implementation in somewhat inferior.

It is not about when support was created, but what has happened in the mean time in terms of improvements & bug fixing.

[NorthGuy]

It is not about when support was created, but what has happened in the mean time in terms of improvements & bug fixing.

I used GCC for various platforms since long time ago. I haven't found any of them particularly buggy.

The recent development may create more bugs than it fixes. Such are times.

[SiliconWizard]

It is not about when support was created, but what has happened in the mean time in terms of improvements & bug fixing.

I used GCC for various platforms since long time ago. I haven't found any of them particularly buggy.

The recent development may create more bugs than it fixes. Such are times.

Well, indeed.

Sure a widely-used  target (such as ARM) will generate a lot more traction. But that doesn't necessarily mean you'll get fewer bugs in the end. Because sure there are more chances bugs will be found and reported, but also a lot more chances target-specific modifications will be made and introduce new bugs. So...

As for me, the last annoying bug I ran into with GCC was an optimization bug on ARM64.

To get an idea, just take a look at the list of regression bugs for GCC for various targets. If you think most are with the least-used targets, you might be wrong.

[Bassman59]

I've also never, EVER had any other company support me like Microchip. Two examples:

When Microchip bought Microsemi, my only thought was "I really hope they improve Microsemi's dreadful FPGA support." So far, no, but I have hope.

[TomS_]

Yes, PIC24 is pretty nice, but higher cost, and no 5V operation.

PIC24FV are 5V.

[eurofox]

For "small" projects I used in the past Pic Basic Pro compiler from Melabs (https://melabs.com) and Microcode Studio Plus (https://www.mecanique.co.uk/shop/index.php?route=product/category&path=20)

Just check it out, easy to learn, powerfull and well documented.