Why do people not like Microchip?

[Wilksey]

I have used PIC MCUs for years, they have so many options, and the part I used 10 years ago I can still get, I have used AVR but I guess the whole Microchip vs Atmel is dead in the water now as Microchip own them, I find them quite easy to interchange, just different registers and such.

I use it in a commercial capacity and we have equipment all across the world that uses PIC controllers with a lot of different uses.

If I had to pick one thing that I do find a tad frustrating is the new debugger and programmer tools (ICD/PICKIT 4), the 3 was much more reliable in my experience, I find it quite irritating that it has to download new firmware to the ICD before it will program a different chip, so I end up with an ICD3 for each project that has a different uC, we have used about 8 different PICs in our projects so not too bad.

I have no reason not to continue using them they work, I am very familiar with them and their quirks, yes the errata can be a face palm moment.  I have started using STM32 and ESP processors of late for more tasking things, but these are overkill for most of what we produce.

PIC controllers were the go to IC when I was starting out, everything was PIC and a sprinkling of AVR and the "new kid" the Parallax Propeller, but 9 times out of 10 if I was an article (as is the case still) it almost always used a PIC.

[rcbuck]

I have an ICD3 but haven't used it in several years as I have a Real ICE programmer/debugger. It also has to download new firmware if I change chips. I don't see that as a problem since it only takes a minute or so to load the new firmware. The Real ICE is much faster than the ICD3 was. Unfortunately it is no longer available and it appears they did not release a follow-up product. Microchip does say to consider purchasing the ICD4 as a replacement.

Their notice killing off the Real Ice said no new device support would be added after June 1, 2019. I haven't found a device yet that it doesn't support. I guess I haven't used any of their newer devices (whatever those are). If I find one it doesn't support I will just not be using that device. There are other MCU manufacturers out there.

[Howardlong]

I have an ICD3 but haven't used it in several years as I have a Real ICE programmer/debugger. It also has to download new firmware if I change chips. I don't see that as a problem since it only takes a minute or so to load the new firmware. The Real ICE is much faster than the ICD3 was. Unfortunately it is no longer available and it appears they did not release a follow-up product. Microchip does say to consider purchasing the ICD4 as a replacement.

Their notice killing off the Real Ice said no new device support would be added after June 1, 2019. I haven't found a device yet that it doesn't support. I guess I haven't used any of their newer devices (whatever those are). If I find one it doesn't support I will just not be using that device. There are other MCU manufacturers out there.

Quite a few of the newer devices aren't supported by third generation PICkit3, RealICE & ICD3, eg PIC16F152xx, PIC18FxxQ4x, PIC18FxxQ8x.

I find the need to upload new firmware every time I switch a target device family to be inconvenient (and sometimes unreliable - more often than not you have to do one or more physical removal/reinsertion cycles) but not a show stopper.

Worse thing about the ICD4 & PICkit4 are their propensity to either not work, or even worse, brick older devices with 12V Vpp due to overshoot in the boost regulator. This has been corrected in recent hardware revisions. To be safe, put a 100 ohm in series with the device's MCLR.

As a result, I end up using both the third and fourth generation programmer/debuggers.

I found I only very rarely used some of the features of the RealICE, although I do have some of the add-ons such as the Performance Pak high speed adapter (which isn't high speed, it just extends the distance between DUT and debugger), and the Power Monitor. The ICD3 and PICkit3, both having the ability to power the DUT, I found to be a more useful use case.

[Sal Ammoniac]

Segger claims to support the PIC32 with their J-Link products. They claim a major speed improvement over the ICD3/4. I've never tried this, so I don't know how viable this is, but it might be worth a try for someone who has issues with the ICDs.

https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/microchip-pic32-support/

[SiliconWizard]

Segger claims to support the PIC32 with their J-Link products. They claim a major speed improvement over the ICD3/4. I've never tried this, so I don't know how viable this is, but it might be worth a try for someone who has issues with the ICDs.

https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/microchip-pic32-support/

Interestingly: from your link, Segger uses JTAG for the PIC32.

The PIC32 MCUs have been supporting JTAG from the first PIC32 IIRC. But they also support Microchip ICSP. I admit I don't know much how ICSP is implemented on those, and how close it is to JTAG - it may also depend on which PIC32 line we're talking about.

But, don't Microchip programmers only support ICSP? Do they actually support JTAG?
Point is: isn't JTAG access on PIC32 just faster than ICSP? Which would be ironic.
If you know more about this on PIC32 though, don't hesitate to correct me or add information.

[Sal Ammoniac]

Here's the Microchip help page for using J-Links with MPLAB X: https://microchipdeveloper.com/mplabx:segger-jlink-plugin

From the page: "As of MPLAB® X IDE v5.25, the plugin for SEGGER J-Link debug probe support will no longer be necessary. Native IDE support is available as of this release."

[Rudolph Riedel]

What I do not like is that Microchip made the new ATSAM includes for MPLAB-X incompatible to the existing ones for Atmel Studio.
And I really like what they have with Harmony, I would have apreciated it more though without breaking the includes for no apparent reason.

[westfw]

What I do not like is that Microchip made the new ATSAM includes for MPLAB-X incompatible to the existing ones for Atmel Studio.

That was a bit of a shock, wasn't it?
I guess the theory is that the new "style" yields more unity with other chip families?
and it's not like the Atmel style was particularly compatible with CMSIS standards, or without its problems.  the whole ".bits.xxx" vs ".reg" was ... not pretty.

[Rudolph Riedel]

That was a bit of a shock, wasn't it?

More of a showstopper, the last straw to prevent me from switching over to MPLAB-X.

I guess the theory is that the new "style" yields more unity with other chip families?

I just checked the PIC32M examples in harmony and the includes are totally different.
There are not even structures defined per peripheral unit, every register is identified by name,
like "IEC4CLR" or "TRISBCLR".

So no, that is not it, if anything these need a major overhaul.

and it's not like the Atmel style was particularly compatible with CMSIS standards, or without its problems.  the whole ".bits.xxx" vs ".reg" was ... not pretty.

While I never had an issue with this .bits stuff I accept that issues might be a reason to change already established includes.
But in this case we went from for example this:
SERCOM6->SPI.DATA.reg

to this:
SERCOM6_REGS->SPIM.SERCOM_DATA

While a fix would have been this:
SERCOM6->SPI.DATA

To me this looks like an attempt to maximise the damage from changing the includes, active sabotage.
And guess what, it works, I am looking into switching over to a controller family from a different manufacturer.

[Microdoser]

Personally, I tried a couple of chip types before deciding on the chips to use in my project. I bought 4 of each type, and the corresponding kit needed to program them. These days, there is hardly any difference in speed, reliability, features etc (at least ones relevant to my project), so I would be choosing on which was easiest and most reliable to flash, as that is where most of my time would be spent after the project was finalized and production started and so ease and reliability of flashing is where I would make the most long term gains.

I then downloaded example code from well known sources to use as a test and tried to flash the chips.

The PIC chips (using MPlab and PicKit 4 direct from the company, no chinese ripoff) failed at the first hurdle as none of them would flash. They claimed to have flashed, but the most simple test showed they had not, also there was no error message letting me know what had, or had not happened.

I don't want to have to dive deep into technical manuals simply to flash a chip, arguably the most common process, and what should just work 'out of the box' even when attempted by the most novice user. I will be avoiding PIC chips wherever possible in the future unless I have the time and energy to find workarounds for issues that should have been addressed at the factory.

The other chips worked straight away with no issues and I have now selected a suitable chip which I luckily bought a years worth of stock of just before ChipaGeddon. I only hope that in a year, we may see stock levels return slightly to normal.

[Howardlong]

I then downloaded example code from well known sources to use as a test and tried to flash the chips.

The PIC chips (using MPlab and PicKit 4 direct from the company, no chinese ripoff) failed at the first hurdle as none of them would flash. They claimed to have flashed, but the most simple test showed they had not, also there was no error message letting me know what had, or had not happened.

I don't want to have to dive deep into technical manuals simply to flash a chip, arguably the most common process, and what should just work 'out of the box' even when attempted by the most novice user. I will be avoiding PIC chips wherever possible in the future unless I have the time and energy to find workarounds for issues that should have been addressed at the factory.

I do agree that Microchip's interface between its MPLAB X IDE and the debuggers themselves isn't improving, if anything it's getting worse, and I use them on a daily basis.

I also agree that having to debug the debuggers is a terrible introduction.

I'm not sure that Microchip is alone in this, I have seen similar issues with both NXP andr Atmel (before Microchip) for example, but Microchip has had increasing difficulties in its toolchain QA for many years now, releasing half-finished products that aren't completed before they throw in the towel and start again with another half finished solution.

[DavidAlfa]

Wasn't hating them so much, but now I'm starting to do so!
If I remove the Pickit3 while MPLABX is opened, on reconnect it will hang for 10-20 seconds and drop a power error message, having nothing connected to it, or just freeze forever.
Hadn't this isue las time I heavily used it, maybe 1 year ago. I have to restart the IDE everytime !

[Rudolph Riedel]

This reminds me of an issue I had with MPLAB-X 5.15 and an Atmel ICE as well as a C21 xplained.
As soon as I connected either the Atmel ICE or the C21 xplained MPLAB-X IDE or IPE would just terminate
with no error message. Just connect -> gone.
And neither MPLAB-X IDE or IPE would start with an Atmel ICE or C21 xplained connected.

I am not sure why this happened or if this still is happening but I found a way around this:
Do not connect the Atmel ICE or C21 xplained using a hub, plug it directly in the computer.

And of course this was with the USB driver Microchip provided with MPLAB-X.
Also there was no issue with Atmel Studio.

[mikeselectricstuff]

Pretty much every devtool I've used, Microchip & others, has had issues with flakiness when the target connection, or power is interrupted unexpectedly.
I find pickit 3 (which I only use on 8 bit devices) to be reasonably OK most of the time, but ICD4 always falls over if target power is shorted, requiring an exit/restart of MPLABX

[DavidAlfa]

Well, it might have been some gremlins inside the pickit.
Changed to other pic model, mplabx updated the fw and completely bricked it.
Flashing it with another pickit slightly worked, but neither mplab, mplabX or pickit 3 utility was able to connect to it. They saw it, but they freezed forever trying to connect.
After a lot of fiddling around I found a workaround: Inmediately after flashing, I had to inmediately connect it to pickit3 utility and switch to mplab mode.
If any other program connected to it before switching to mplab mode, it would brick it again.
After that, I could ran the firmware update in MplabX. No issues with power, hanging, crashing, everythign like it should be.

[AaronD]

Long thread that I didn't read entirely, but here's my experience:

PIC has always had the best hardware features for the cost, but an awful CPU architecture as far as a C compiler is concerned.  C was not the original design goal, and it seems like they're stuck with what they already had and won't change.  So to use it well requires a proprietary compiler that is quite expensive for the full version.  There is a free one, but it produces assembly so bad that it's been accused of purposely sandbagging to make the paid versions look even better.  (actually, if you really know how a compiler works, you'll understand that the free version really is just the translation stage as-is with nothing after it, and that the optimizer really is that good)  There are also community-supported compilers, but they don't get a lot of attention, and so they're still not as good as the proprietary one.  It's too far different from a "standard" architecture for GCC to be modified to work.
So PIC is excellent in value for hardware, but bad for development.  Not really a problem if you develop once and then dump the same binary into millions of chips.

AVR (both before and after MCP bought it) is exactly what GCC expects, so there's no reason to use MCP's version of it.  Just get the free AVR-GCC and move on.  It also runs 1 instruction per clock instead of PIC's 1 instruction per 4 clocks, but it requires more instructions to do some common things, so the benefit isn't quite as much as you might think.  Most of the practical benefit is a boatload of RAM, and a NOP is 1/4 the time on AVR as it is on a PIC, so you can busy-wait more precisely.  But it doesn't have as much on-chip hardware as a similarly-priced PIC.  I see no reason why they can't put a PIC's peripherals around an AVR core for the best of both worlds...except that they wouldn't be able to sell their expensive compiler anymore.
So AVR has a better CPU, which makes it easier to use as your first microcontroller, but so far isn't paired with as much hardware for the price.

---

Ultimately, Microchip is out to make a profit.  They can't operate as a charity, or they'd go bankrupt and cease to exist.  Can they make all of their profit on hardware and let hobbyists use their full-version software for free?  Perhaps, but I don't think they're focused so much on hobbyists.  Hobbyists are too low-volume to be profitable to a chip manufacturer, and if you offer something to them for free, then the large corporate customers can get it for free too.  (a "non-commercial" clause in the license isn't as effective as you might think)

It'll be interesting to see what the next generation does.  The idea that those who learn on a given system will later decide to use it in production is very real, and those who are just starting to learn will choose the one that's most accessible to zero knowledge and almost zero budget in single quantities.  So a manufacturer can't just ignore those people.  Sure they're not profitable now, but they certainly will be if they're not driven away!

---

One more note:
I see people complaining about the PicKit.  I have one, and haven't had any issues so far, but I also found a free programmer that uses the GPIO pins of a Raspberry Pi:
https://wiki.kewl.org/dokuwiki/projects:pickle
I've only used that for one project so far, which is a permanent connection between a Pi and a fairly new PIC, but it works perfectly!  Together with SDCC in Code::Blocks, I have a completely free toolchain that runs entirely on the Pi.  Nothing at all from MCP except the chip itself.  (SDCC still has some significant shortcomings, but it's a lot better than MCP's free thing!)

[DavidAlfa]

I think they'll always have their place.
They won't be super powerful, but they're so damn easy to configure and run, you can make a small project in less than 10 minutes... Reseting peripherals is a childs game, everything is so damn simple!

For example, I made an astable timer for the reverse camera of a friend's car, the rear bulb signal has nasty pulses from the detection circuitry, messing with the camera power.
It took me less than 10 lines to configure a 18F1330: INTOSC, x4 PLL, ADC, Timer0 and GPIO.
Another 40 lines of code to read the potentiometer with the adc, adjusting the timer and making the state machine.

It's just like a toy, a digital lego you can play with and get results in no time.
Stuff gets extremely complex really fast when you with a modern arm cores and such.

[Feynman]

The only thing I don't like about Microchip are the shitty dev-tools for their micros.

[Howardlong]

PIC has always had the best hardware features for the cost, but an awful CPU architecture as far as a C compiler is concerned. 

That's a fairly reasonable take, if discussing the 8 bit architecture, although functionally it's very well hidden from the end user in XC8, particularly the RAM banking: some other PIC 8 bit compilers it's a lot more obvious. You have to accept the the 4x clock is just that, and read through the marketing blurb with that in mind. The peripherals they cram in are impressive, some of which can relieve the CPU from tasks. In my line of work the low power aspects often come into play also, particularly sleep and MIPS/MHz performance.

The 16 bit architecture is far more attuned to C, with a proper stack and frame pointer for example. It's far less prone to banking, on many of the lower end devices no banking's needed at all.

One thing Microchip have taken their eye off the ball recently is power consumption across the range: older devices were much better in this regard. This is particularly since they have introduced the PIC18FxxQ and PIC16F152xx series, which no longer have specific low power 'LF' variants.

One other thing that's taken a turn for the worse over the past couple of years is the datasheet format, where they've switched to a single column format from their traditional two column format. As a result the information is presented in a far less efficient way for both on screen and printed reading. One thing I always liked was that I could find the pinouts after scrolling past the first couple of pages, usually it starts by page 4, sometimes it's page 2 or 3. Now there's several extra pages of cruft, due to single column presentation, a couple of pages of double spaced ToC, and a frankly almost useless block diagram. The most common part of a datasheet anyone will refer to during development is the pinout.

[AaronD]

...functionally it's very well hidden from the end user in XC8, particularly the RAM banking: some other PIC 8 bit compilers it's a lot more obvious.

I had a project at work with a PIC16F1454.  (the smallest and cheapest I believe with a USB peripheral)  By the time the application code was done, it was significantly over 1/2 of the code space.  And it still needed a USB bootloader for field updates.  So I had to be creative in how I did that, including the ability to bootload a new bootloader, while absolutely minimizing the chance of bricking it from the end-user's perspective without a programmer.  (requiring a second attempt to download is okay, as long as that's always possible at *every* step of the process)  That's where I learned that the XC8 linker is absolutely awful, even in the full pro version.  It eventually worked like I wanted, and passed all the tests, but it was not fun at all.

Our 8051 toolchain was much better at that...or maybe it was explained better.  The on-site support guy that we got from Microchip left some to be desired as well; older guy that didn't really seem to know much more than we did, but that might have been a fluke.  Nice guy, but technically useless.

If you don't care where anything goes as long as it works, then you won't see any of that.  But you probably *will* need to use the external programmer interface for any updates.  (depending on what you're doing, that requirement might be a feature)  Even a pre-fab bootloader needs to not be overwritten, which requires at least a little bit of linker code to not try to put stuff there, even if that bit of flash is protected otherwise.  (hardware fuses, and the bootloader itself checking addresses)

One thing I always liked was that I could find the pinouts after scrolling past the first couple of pages, usually it starts by page 4, sometimes it's page 2 or 3. Now there's several extra pages of cruft, due to single column presentation, a couple of pages of double spaced ToC, and a frankly almost useless block diagram. The most common part of a datasheet anyone will refer to during development is the pinout.

Maybe they're relying on the flexible configuration to make the pinout mostly irrelevant???  That's not a very strong argument though, because that configuration has defaults, and you can't really move the power pins.

[DavidAlfa]

What I can't understand is the PIC18 extended instruction set. It's meant for high level languages like C.
The old mplab C18 did support it, but HiTech's PICC never did.
Microchip bought HiTech, renamed it to XC8, and abandoned C18.
Since then, Microchip gave zero f*** to improve that.
So, the situation is that their own compiler can't use all the capabilities of their own devices. It's like a bad joke!
I've read it was a try to compete against PICC. Since PICC was more efficient that C18 without using extended instructions they just remainded there, unused.

Anyways, modern mid-range (Like 16F18323) have a better, new architecture that mixes a bit of everything. I guess these pic18 are just old.
The new ones are impressive, the available peripherals is crazy. The 16F18323 packs a lot of them, costing barely 1€.

[nctnico]

If you don't care where anything goes as long as it works, then you won't see any of that.  But you probably *will* need to use the external programmer interface for any updates.  (depending on what you're doing, that requirement might be a feature)  Even a pre-fab bootloader needs to not be overwritten, which requires at least a little bit of linker code to not try to put stuff there, even if that bit of flash is protected otherwise.  (hardware fuses, and the bootloader itself checking addresses)

This is where many LPC series microncontrollers from NXP really shine; most of them have well designed serial port bootloaders so you don't need any fancy programming hardware to do field updates.

[Davor]

I guess these pic18 are just old.
The new ones are impressive, the available peripherals is crazy. The 16F18323 packs a lot of them, costing barely 1€.

There are new PIC18 series (Q40, Q41, Q43...).
Price of 18F04Q40 is similar to 16F18323, but with 4x more RAM and flash, 2x speed and EEProm, 8x more stack, 12-bit ADC, 8-bit DAC, +-1% RC oscillator. Even errata is OK.

[DavidAlfa]

They must be very new. Last time I searched for 14-pin tssop pics (few months ago) they didn't show up!
Only the PIC18F06Q41 appears in RS Spain. 0.90€ +VAT.
That's Microchip getting serious, DMA in a pic18!
If they make a single-cycle instruction core like pic24/dspics... ouch!

[SiliconWizard]

What I can't understand is the PIC18 extended instruction set. It's meant for high level languages like C.
The old mplab C18 did support it, but HiTech's PICC never did.
Microchip bought HiTech, renamed it to XC8, and abandoned C18.

I have used mcc18 with PIC18 MCUs, and it was fine AFAIR, but never used XC8. (Have used XC16 and XC32 on other PICs since then.)

Are you sure XC8 never got updated by Microchip for better support of the PIC18? I admit I've never bothered to check.
Why did they abandon mcc18? No clue. They probably wanted to redirect resources to XC16 instead. Maintaining a compiler is always costly. Dunno.