Talking with Steve Sanghi, CEO of Microchip for 31 years

[JPortici]

And yet, i have a friend that works with STM32 and making good money on it. He uses Keil and doesn't want to touch anything anymore that has eclipse or GCC.
i sort of agree with him. Free stuff is nice for your personal projects because it's your hobby, or when you want to get your feet wet with new things.

Somehow the interesting part is missing from this comment, isn't it? I.e., *why* he doesn't want to touch anything that has eclipse or GCC, and *why* you agree with him.

The fact that free stuff is nice for hobby use and the like ... doesn't say anything about whether it isn't nice for professional use, does it? And the mere fact of having to pay money obviously can't be the advantage, can it?

we both have a complete dislike of the eclipse+gcc combo. It comes from when we started out about 10 years ago when setting up STM32 toolchains on windows was either pay a lot for Keil and have a working setup out of the box, or fiddle with guides you find on blogs and somewhere else, do this and do that without explanations. Guides were always outdated because every month something changed in eclipse and broke the whole process, you had to guess what to change because when asking for guidance the answer was in the tone of figure it out yourself.
GUI itself for creating projects, register view and so on changed at least three times in the meantime, and you had to do a bunch of manual setup every single time you created a new projects.
We like installers and "just works", we don't like it when setting up projects and toolchains become a job on itself.

Also OpenOCD. I don't understand how people can mock the pickit3 and then praise openocd probes. I've used it very little but had far more problems, hangs and time wasted.

It doesn't help that we both absolutely hate the GUI of eclipse, their UI choices and many little things you have to configure every time you install or update it. It's not a surprise that Qt Creator is an IDE i absolutely love, and while it's actually eclipse under the hood, it looks nothing like it

From time to time i install eclipse again, while it's far more stable in both the installation process and the program itself, i still find it atrocious. Luckily i can do vanilla C/C++ in Qt Creator as well (and before that i was using vanilla netbeans, because i like it so much more)
Obviously i use MinGw as a compiler so it's not a dislike of GCC per se

The only open-source compiler that has been half-maintained is SDCC, and AFAIK, while it works great for other targets, it's never been all that great for the 8-bit PICs.

One thing that has become really annoying to me is Microchip's stubbornness about using their own ICSP interfaces on most of their MCUs instead of a standard JTAG (or SWD) that would allow using standard JTAG/SWD adapters and tools. I think only their PIC32 series have a JTAG interface, but I'm not even sure that MPLAB supports any JTAG adapter. So you're basically stuck with their ICDx/PICkit stuff. But that may be part of their overall strategy, so.

you can say it's complete garbage for PIC16. It may be okay on trivial software, but the quality of XC8 when you start writing some serious software using clean and concise code (and not trying to be too "smart" and trick the compiler in producing a specific assembly pattern for which you should really link an assembly module, or combining several statements in one) is astounding.

Re: JTAG, yeah All new 16bit parts (since 2018 i think) and most dsPIC33E, all 32bit parts and i think also the new 8bit, at least the PIC18 Qxx series have JTAG, but i don't think any of those besides the PIC32 can be programmed using it (ICSP over JTAG). There was the possibility mentioned in old docs, but also erratas that said that programming through JTAG is not functional. I don't know why.

re: Sources for the compilers
https://www.microchip.com/en-us/tools-resources/archives/mplab-ecosystem
this has been the link for some years, now it's easy to reach from within the website, in the past it was really buried. Or you google "microchip download archive".
Notice how microchip provides EVERY version of their tools, even the old PLIB and MLA. MCC, you can also have all versions of the components to download/mix and match.

[nctnico]

OTOH, Microchip has been acquiring quite a few companies that server either a high-end niche market (Microsemi), Atmel as a well established maker of cost effective flash chips and the likes of SMSC (low quality networking chips) that gives Microchip a rather diverse & broad portfolio. They might not even need the PIC microcontroller line in order to be profitable.

I doubt that. Like he said, practically every medical device has a PIC in it,

But for how long? Connectivity is a big thing nowadays and none of the Microchip products I'm aware of really caters to that market. One of my current projects could do with a super simple microcontroller IF the customer didn't want connectivity... 99.9% of the firmware is dealing with connectivity, 0.1% is for the functionality.

[mikeselectricstuff]

One thing that has become really annoying to me is Microchip's stubbornness about using their own ICSP interfaces on most of their MCUs instead of a standard JTAG (or SWD) that would allow using standard JTAG/SWD adapters and tools. I think only their PIC32 series have a JTAG interface, but I'm not even sure that MPLAB supports any JTAG adapter. So you're basically stuck with their ICDx/PICkit stuff. But that may be part of their overall strategy, so.

Pretty much all low-end MCUs use their own protocol. Microchip's is documented, and there are plenty of third-party and clone programmers so not a big deal.
Flash programming via JTAG is hardly standardised

[hans]

Not just that, but the source code is provided (XC16 and XC32). Granted they don't make it particularly easy neither to find the downloads, nor to build the compilers (I've done it before and it's a bit messy), but it's open. For XC8, as they bought the compiler, I don't know to what extent they could have open-sourced it anyway. Sure for XC16 and XC32, you may argue that they didn't have a choice due to GCC licensing.

For a number of people, the concern is not the cost of the tools per se (for commercial dev), but the possibility that said tools could become unavailable or unusable in some way in the future.
But again, the source code is available. Even if the compilers are not trivial to build, it's not impossible at all. So if/when the need is really there, a lot of people will just do that.

There is a XC16++ project on Github that goes along this route. It pulls the source files from microchip, builds it but with g++ executable enabled, and then needs some extra bootstrap code in order to make class initializers work properly. I'm not sure if the last step is included in that project.

It's not rocket science as it's mostly standard GCC stuff. But in a commercial environment, I think most companies would only dare such a journey if they really need to. I'm not actually sure about the licensing terms. Like, can you download Microchip's GCC code, remove XLCM, and then put those EXE's and alike on Github for people? Hmm..

One thing that has become really annoying to me is Microchip's stubbornness about using their own ICSP interfaces on most of their MCUs instead of a standard JTAG (or SWD) that would allow using standard JTAG/SWD adapters and tools. I think only their PIC32 series have a JTAG interface, but I'm not even sure that MPLAB supports any JTAG adapter. So you're basically stuck with their ICDx/PICkit stuff. But that may be part of their overall strategy, so.

I'm not too fussed with the ICSP interface. JTAG, SWD, ICSP, AVR PDI interface, etc. -- these are all just buses that can read/write memory on the target micro, and control some registers to handle code debug. SWD is proprietary from ARM, so I'd rather have only 2 lines from ICSP even it's non-standardized. If you need a dongle, I think the newer J-Link devices support ICSP for PIC32.

I'm much more interested what happens at the other end. It's not hard to use Microchip's compiler outside of MPLAB X. This makes usage within CMake and other command line environments possible. But if I need to debug code, what options do I have? AFAIK, only MPLAB X. But that uses it's own build/project system, so I can't exactly transplant program images between them.

Most GCC IDE's expect that there is some GDB server available. But Microchip doesn't have one. I think JLink has one, but until recently I had an older JLink Edu that didn't have ICSP.
Expanding to other targets requires a driver for the FLASH controller and CPU core debugging registers. As mike says, these are documented to some degree for PICs,  so it would be feasible. Many moons ago, someone wrote a GDB bridge for PICKIT2/3/et al. and PIC32MX series. But I never got it too reliably work back then. I think this is already over 10 years ago. I've been contemplating this idea from time to time, but then again, I don't often use Microchip PICs nowadays to warrant (probably) weeks of dev time to figure this stuff out.

The last project I did with Microchip PIC32 was developed in CLion, and then used their proprietary commandline debugger that could atleast give me a PC location whenever a program failed due to some kind of assertion check. The rest was just guessing. It worked for that particular project, but it was not particularly complex stuff (and 95%+ unit test coverage also helps).

[zilp]

It's not rocket science as it's mostly standard GCC stuff. But in a commercial environment, I think most companies would only dare such a journey if they really need to. I'm not actually sure about the licensing terms. Like, can you download Microchip's GCC code, remove XLCM, and then put those EXE's and alike on Github for people? Hmm..

Yeah, that's the point of the GPL, that your freedom to modify and distribute the software can not be limited by distributors.

[zilp]

we both have a complete dislike of the eclipse+gcc combo. It comes from when we started out about 10 years ago when setting up STM32 toolchains on windows was either pay a lot for Keil and have a working setup out of the box, or fiddle with guides you find on blogs and somewhere else, do this and do that without explanations. Guides were always outdated because every month something changed in eclipse and broke the whole process, you had to guess what to change because when asking for guidance the answer was in the tone of figure it out yourself.
GUI itself for creating projects, register view and so on changed at least three times in the meantime, and you had to do a bunch of manual setup every single time you created a new projects.
We like installers and "just works", we don't like it when setting up projects and toolchains become a job on itself.

I mean, nothing against easy setup ... but at the same time, at least if you are serious about developing a project, it seems like a rather minor thing, given that set up of the environment isn't really something that you'd need to repeat all the time?

It doesn't help that we both absolutely hate the GUI of eclipse, their UI choices and many little things you have to configure every time you install or update it. It's not a surprise that Qt Creator is an IDE i absolutely love, and while it's actually eclipse under the hood, it looks nothing like it

Well, I am not a fan of eclipse either, or big IDEs in general, really, so ...

Obviously i use MinGw as a compiler so it's not a dislike of GCC per se

Really, that was the part that I was wondering about most, as I'd think that GCC is a pretty good compiler, so I was surprised that someone would want to avoid GCC in particular ...

Though I would say that really it's just a bad idea in general to bundle the device toolchain and the development environment, or more precisely, the "device tooling" and the "user interface". Like, I write code in a bunch of languages, and some, like C,. for a whole bunch of targets, from Linux servers to 8051 embedded stuff, and I have my editing environment set up for my needs, I am familiar with it, and it's just annoying when some µC vendor thinks that I'd want to use their preferred user interface to edit code for their processor, rather than what I am familiar with, and what's already set up for my needs. And all of that even moreso, of course, when you are sharing code for multiple targets ...

[JPortici]

we both have a complete dislike of the eclipse+gcc combo. It comes from when we started out about 10 years ago when setting up STM32 toolchains on windows was either pay a lot for Keil and have a working setup out of the box, or fiddle with guides you find on blogs and somewhere else, do this and do that without explanations. Guides were always outdated because every month something changed in eclipse and broke the whole process, you had to guess what to change because when asking for guidance the answer was in the tone of figure it out yourself.
GUI itself for creating projects, register view and so on changed at least three times in the meantime, and you had to do a bunch of manual setup every single time you created a new projects.
We like installers and "just works", we don't like it when setting up projects and toolchains become a job on itself.

I mean, nothing against easy setup ... but at the same time, at least if you are serious about developing a project, it seems like a rather minor thing, given that set up of the environment isn't really something that you'd need to repeat all the time?

One point that maybe didn't come across was repeteability of the whole operation, and support whenever there was a problem.
In the past (but also in the present from what i can see) most assistance in eclipse+gcc comes from "the community" which isn't always great to use an euphemism. It's good when you happen to have the same problem as someone else, but when it's something a little more obscure... let me say that keil support is there (because there are people paid for it) and microchip support is there (because there are people paid for it).

[zilp]

One point that maybe didn't come across was repeteability of the whole operation,

As in, the same version behaved indeterministically? Or just that stuff changed between versions (which is how I understood your before)? The former would be pretty bad--the latter, well, really depends, I guess, there might have been good reasons for that, though it's still annoying, of course.

and support whenever there was a problem.
In the past (but also in the present from what i can see) most assistance in eclipse+gcc comes from "the community" which isn't always great to use an euphemism. It's good when you happen to have the same problem as someone else, but when it's something a little more obscure... let me say that keil support is there (because there are people paid for it) and microchip support is there (because there are people paid for it).

Well, but did you try paying for support for eclipse? As otherwise this seems like a pretty apples to oranges comparison?! Like, why would you hold it against eclipse that good support costs money when the good support for Keil wasn't exactly free either/when Keil's free community support presumably isn't significantly better than the free community support you get for eclipse, if it exists at all?! And as for the free tools from Microchip, you obviously pay for the support, too, when you purchase the parts.

After all, the point of Free Software isn't that people shouldn't be paid for their work, the point is to avoid lock-in ... which you still get if you pay for support.

[nctnico]

One point that maybe didn't come across was repeteability of the whole operation,

As in, the same version behaved indeterministically? Or just that stuff changed between versions (which is how I understood your before)? The former would be pretty bad--the latter, well, really depends, I guess, there might have been good reasons for that, though it's still annoying, of course.

Eclipse workspaces are not 100% compatible between versions (although newer versions can convert the older versions). However, you can easely install several Eclipse versions on the same computer as each version has it's own directory with plugins & settings. So all you need is to specify which version you are developing with. But the same goes for the compiler. When working with others, I always make it a point we all use the same compiler so at least we won't run into the situation where something doesn't work because it is compiled differently. This applies to any set of tools (either commercial, free or open source).