Talking with Steve Sanghi, CEO of Microchip for 31 years

[AndyC_772]

To play devil's advocate, if I'm building 10,000,000 of something and a compiler that's 1% better than GCC lets me ship with a PIC that costs 10 cents less, that compiler license is worth up to $1 million.
Of course, there are likely to be any number of ways to shave 1% from the code size without paying a six-figure sum for a compiler.  I guess he's assuming that a lot of customers don't have the time or talent needed to find another way.

It's $44/month.

That's precisely the problem, though.

True story... last year one of my customers contacted me to say he couldn't get hold of a certain PIC, but we were able to find stock of a lesser device with only half the Flash. At the time, the original part was indeed only about 50% full, so I made the changes, compiled with -O2, and we were back in production.

Then, as always happens, a requirement came in to add a new feature that allows the product to be used in a new application. Do I:

a) Rent the fully optimising compiler, or
b) Split the code into different builds for different applications, so we now have multiple binaries for different operating modes?

The answer is (b), because even though it's a pain to manage, I have to be able to support every piece of code I release on an ongoing basis.

Option (a) would mean renting the compiler not only to complete the code on day one, but also each and every time a change is needed. By choosing this option I'm making a costly commitment, to maintain the ability to fix and upgrade that code for its entire commercial lifetime.

This is why the whole concept of renting dev tools sucks - especially where development isn't carried out by the same company that mass produces the end product.

[chris_leyson]

PIC1655 was a General Instrument part originally. Remember seeing a GI PIC1655 in a musical doorbell maybe 35 years ago. Datasheet attached.

[mikeselectricstuff]

I've used 8,16 and 32 bit PICs for hundreds of projects since the 16C54, and C since the 16c74
I have licenses  for the full versions of the first 2, and the hack for the latter
 Whenever I've experimented with the optimisation options, I don't think I've ever seen a situation where the highest option made a make-or-break difference to speed, and even then, tweaking my code made at least as much improvement.
As regards codespace, this is rarely an issue for me as my code is usually small, and has only been a limitation on tiny 8-bit devices - I usually only see a few % difference on larger devices.

Given the "need" for a paid version, Microchip's strategy of limiting optimisation (and not trying too hard to protect it) is greatly preferable to approaches taken by other manufacturers - limiting code size, device support or time-limitations.

[woofy]

Yes, there was no "C" in the original parts, they were all NMOS devices. The PIC16C55 was the first with the CMOS process.
One version of the 1650 (GI TV1650) was used used in teletext/viewdata chipsets.
Back in those days EMM-semi (USA) and Intermetall (GMBH) were second sources.

[woofy]

I've used 8,16 and 32 bit PICs for hundreds of projects since the 16C54, and C since the 16c74
I have licenses  for the full versions of the first 2, and the hack for the latter
 Whenever I've experimented with the optimisation options, I don't think I've ever seen a situation where the highest option made a make-or-break difference to speed, and even then, tweaking my code made at least as much improvement.
As regards codespace, this is rarely an issue for me as my code is usually small, and has only been a limitation on tiny 8-bit devices - I usually only see a few % difference on larger devices.

Given the "need" for a paid version, Microchip's strategy of limiting optimisation (and not trying too hard to protect it) is greatly preferable to approaches taken by other manufacturers - limiting code size, device support or time-limitations.

I also had licenses for the compilers, now dropped. I never had a situation where the speed or size difference beyond -O2 made it anywhere near a deal breaker. So now I set -O2 and forget about it.

[EEVblog]

They might be "out of touch" when it comes to small time users, but name a microcontroller maker more consistently profitable than Microchip. Also name another microcontroller manufacturer that still makes and supports ancient parts as ell as Microchip. Perhaps beig "out of touch" is the price paid for profitability and longevity?

Uh ... or maybe the long-term availability is part of what makes them successful, and they'd be more so if they had a different approach to dev tool licensing?

Impossible to know long term, but it's worked for them for 30 years, so who's to argue.

[EEVblog]

It's $44/month.

That's precisely the problem, though.

Why? $44 for a month doesn't even cover an hours of an engineers time.

True story... last year one of my customers contacted me to say he couldn't get hold of a certain PIC, but we were able to find stock of a lesser device with only half the Flash. At the time, the original part was indeed only about 50% full, so I made the changes, compiled with -O2, and we were back in production.

Then, as always happens, a requirement came in to add a new feature that allows the product to be used in a new application. Do I:

a) Rent the fully optimising compiler, or
b) Split the code into different builds for different applications, so we now have multiple binaries for different operating modes?

a) obviously, it's only $44, again, way less than an hour of your time.

This is why the whole concept of renting dev tools sucks - especially where development isn't carried out by the same company that mass produces the end product.

Just pass the cost on to the client.

[EEVblog]

Given the "need" for a paid version, Microchip's strategy of limiting optimisation (and not trying too hard to protect it) is greatly preferable to approaches taken by other manufacturers - limiting code size, device support or time-limitations.

Agreed, hugely preferable. And in most cases you don't need the extra optimisation. And you can rent for one month for $44 if you absoutely must have it. Again, less than hour of what an engineers time is worth.
There are also third party compilers that support PIC if you like their pricing and performance better.

[zilp]

Uh ... or maybe the long-term availability is part of what makes them successful, and they'd be more so if they had a different approach to dev tool licensing?

Impossible to know long term, but it's worked for them for 30 years, so who's to argue.

Well, if it's impossible to know long term, then they don't know either. Which is probably true, strictly speaking, but at the same time, if I take that to mean that it's impossible to have any idea at all as to whether a given business decision is a good idea or not, if only the business has been doing the same thing for 30 years, that seems to be obviously incorrect, don't you think?

One obvious reason to argue with that is that the market has changed significantly in 30 years, free software compilers are very mature, and much of the market has shifted and continues to shift to architectures well supported by those, ARM in particular, and increasingly RISC-V, of course, not in a small part because the economic realities of semiconductor manufacturing nowadays make 32 bit processors a perfectly reasonable choice for many applications where an 8-bitter would have been the obvious choice 30 years ago, and that's what those compilers were built for (Hurd/Linux/Free/Open/NetBSD on x86/SPARC/MIPS/ARM/whatever with all the application software on top of it).

Still agree, though, that it's much better than code size limits and that sort of thing ... but then, I wonder whether that isn't actually acknowledging exactly that it's not a winning strategy to erect barriers to using their actual core product? To the point where I wonder whether this doesn't undermine the supposed goal of making dev tools "not a cost center", when the limitation is so little of a limitation that noone buys the license anyway ... except for the 10 big customers who have determined that using a 3 ct cheaper part in their 10 million pieces per year product is worth it, gaining their dev tools department 5280 USD of revenue per year to pay their engineers? I mean, I am obviously making up the numbers, but it just doesn't seem like they think they have much price setting power there (that wouldn't cut into their revenue elsewhere).

[hans]

Many limitations age poorly. I think TheAmpHour discussed Keil's (or was IAR?) 32K C/C++ compiler for ARM. "When are you ever going to write more than 32K of code?"
Like, every day? If a printf() takes 10kB of FLASH, bolt a SD card driver and some magic sauce, and you're over 32K. ESP32 Arduino executables start at 250KB IIRC, as it can include RTOS, WiFI, ethernet, audio, USB, etc.

I agree with Steve that in-house supported tools means more control over product life cycle is good. It is excellent to exactly know what tools and compilers you need from day 1. On ARM this is much more a mess or "DIY". But the reason why tools "must" cost money sounds more like an internal managerial side-effect that's exposed to the outside world. If the compilers were made free and a new manager is going to cut "costs" in a core aspect of product support, then that manager should be fired. Delivering "support" costs money, until it generates new sales in the future if you do it well.

Microchip seems to do very well despite their closed eco-system because its well documented and supported. But it also sounds like a risk judging by some of the answers. A hobbyist or small business could get a bigger/faster part if necessary. But if products need to excel in certain areas, then that is not always the solution. Optimization O3 is not only for higher Coremark scores, but also longer battery life (race to sleep). Optimization Os could mean more features and a longer product support cycle, which is also part of Microchip's focus on not obsoleting products. It's not always about the cheaper devices when boards get assembled.

Now the impact of these optimization levels is core part of the compiler marketing. I've found Microchip's compiler to be very slow, since so far as I can tell, it's compiling the program twice internally to give an accurate figure of how big the executable would be if you paid for optimization -Os. A compile with XC32 can take literally a minute for a project I did the other day, while it was completed within 5s using MIPS GCC. The newer MIPS GCC also delivered smaller and faster code. And supports the latest and greatest language features of e.g. C or C++ (like constexpr). This closed ecosystem also reflects a closed-mind approach on e.g. a lack of C++ for PIC24 devices (which are more than capable of utilizing it, see AVR/Arduino). Likewise, there is also no MPLAB X IDE or compiler builds for non-x86 machines, even though Apple seems to be selling tons of M1/M2 Macs and ARM PC's are emerging more and more. I firmly believe that if Microchip had a more open approach to their hardware tools and software toolchains, that their popularity amongst hobbyists would pick up greatly, which would then design in a chip into a product when they land their first job. Because [in general] on silicon level and documentation quality is at least as competitive as e.g. ST's.

[JPortici]

If the compilers were made free and a new manager is going to cut "costs" in a core aspect of product support, then that manager should be fired. Delivering "support" costs money, until it generates new sales in the future if you do it well.

Of course they should be fired. However, how many times new management / bean counter focus on immediate gain to appear good to investors?

[SiliconWizard]

Oh well, some people have no problem shelling out $8k or more for an Altium license but will whine about a couple hundreds for some other tool, implying that some tools are not worth even paying a dime for, even though they are every bit as necessary. Making CAD software is certainly more profitable than making compilers.

As some have said, with a license you don't just get more optimizations, you also get support, which can be invaluable.
Otherwise you can also turn to ARM stuff and use plain GCC as some other vendors provide and spend days or weeks on issues that you'll flood forums with.
Not sure the latter is more efficient or costs less in the end, but it's an approach that's all the rage now.

Obviously there are other reasons than cost for preferring free/open-source tools, but heck, apart from XC8 (I think), Microchip's compilers are open-source.

[peter-h]

Does anyone remember the original General Instrument?

They made a chip called AY-something which had the most weird instruction set. 4 bit, IIRC.

[woofy]

I don't know of any 4-bitters, but they did the AY-3-8910 sound generator which was very popular. The only dead-end processor I'm aware of was the CP1600, a 16-bit PDP11 clone.

[EEVblog]

If the compilers were made free and a new manager is going to cut "costs" in a core aspect of product support, then that manager should be fired. Delivering "support" costs money, until it generates new sales in the future if you do it well.

Of course they should be fired. However, how many times new management / bean counter focus on immediate gain to appear good to investors?

A new manager/CEO's job is not to think long term, it's to immediately correct problems that the previous manager/CEO was booted for. So short term thinking is guaranteed.
e.g. if a CEO got the boot because the company's financies are in the toilet, cutting non-functioning cost-centres is their first priority. Everything else be damned.

[EEVblog]

Well, if it's impossible to know long term, then they don't know either. Which is probably true, strictly speaking, but at the same time, if I take that to mean that it's impossible to have any idea at all as to whether a given business decision is a good idea or not, if only the business has been doing the same thing for 30 years, that seems to be obviously incorrect, don't you think?

If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to join a race to the bottom.

[peter-h]

I don't know of any 4-bitters, but they did the AY-3-8910 sound generator which was very popular.

I suspect it was a mask programmed micro, as they all were in the old days. I remember reading the DS and wondering HTF do you program this thing In the end we did nothing with micros and after a few years went for a Z80...

Microchip bought a compiler from Hitech Software in Australia. They took over the company. They were selling it (or giving it away?) until quite recently. I still sell a couple of user programmable protocol converters which use that compiler (Z80 and H8/300) written by Clyde Smith-Stubbs; I bought a license for a large number of copies. I wonder if he's still around.

[zilp]

If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to join a race to the bottom.

If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to ignore changes in the market.

I mean, that's just a truism, isn't it? *Perhaps* it's not a smart move to do the same ... *perhaps* it is.

Other than that, any logic of the form "if the most profitable company in business X is doing Y, then not doing Y would be less profitable" is just obviously fallacious? For one, even Microchip in particular has changed how they were doing things, at times when they were the most profitable µC company--by that logic, those changes made them less profitable. Which might well be true for some of them, obviously, but chances are that they simply recognized at some point that they were moving in the wrong direction, and so they corrected course *in order to stay profitable*.

Also, it's not really a race to the bottom if all you are doing is reducing a price that makes presumably negligible contributions to the bottom line in order to reduce friction for your (potential) customers using your (core) product. After all, the point isn't to reduce the price on dev tools in order to outcompete others in the dev tools market, it's to remove friction that potentially costs the customer much more than the licensing costs, therefore creating a disincentive that isn't worth it.

[JPortici]

Re: PlatformIO

https://www.microchip.com/forums/m1221852.aspx

It requires the experimental XC16 recompile to enable C++ (man i whish i could use C++ with dsPICs sometimes)
this guy also figured out how to bypass MPLABX IPE (you still need to install it to get the script files though)

[peter-h]

Also, it's not really a race to the bottom if all you are doing is reducing a price that makes presumably negligible contributions to the bottom line in order to reduce friction for your (potential) customers using your (core) product. After all, the point isn't to reduce the price on dev tools in order to outcompete others in the dev tools market, it's to remove friction that potentially costs the customer much more than the licensing costs, therefore creating a disincentive that isn't worth it.

I agree.

Things have changed over say the last 20 years. Back then people paid £450 for a C compiler. I sold loads of them. Today they tell you that is a ripoff and they want it either for free or for £50 or something like that. People also resist floating licenses and such like.

[hans]

@others. All fair and good points. I'm not daring to complain too harshly about the pricing scheme. It's still affordable if need be.

However, in a world of free GCC/Clang compilers that is used for absolutely everything, a paywall is a bit of a standout.
Now it is still a "good" paywall as it ages well. In retrospect, if someone is making their money with the product features I listed (battery life, limitless feature creep for customers), then its fair that they can also afford a compiler license. Indeed Altium is much more expensive and seems to sell like hot cakes in the hardware design world.

However, I'm most fearful that this limits the speed at which innovation occurs. For XC16, they could upstream their modifications specific to the PIC24 core, so we could enjoy a C++ compiler that is up-to-date with GCC 12 etc. As JPoritici says, that could allow PlatformIO to be integrated which opens up the world for all the Arduino libraries (if they don't do anything too crazy with non-portable code) to be used on those microcontrollers. Some of those dsPICs are dual-core at 100MHz, so would give the average Cortex-m3 a run for its money.

For XC32, as far as I can tell they took MIPS GCC which already supports e.g. MIPS4K and added their sauce on top which includes start up scripts, a bootloader for their dual FLASH region structure, and all the necessary interrupt prologue. It's actually a benefit they used MIPS GCC, as there are also Linux builds made by MCP for PIC32MZ DA, and using GCC to compile Linux is almost a must. The bootstrapping for their parts is absolutely more effort than for the average ARM core, but less than for a RISC-V core. And in a market where RISC-V cores are exposed to the user as CPUs that can run code, we'll have to see how things evolve over time.

Perhaps I'm not knowledgeable at these (business) things at all. But personally I'm a bit surprised that charging money for compiler licenses is worth the hassle. The argument of a compiler license being worth up to 1M$ if a customer can save 10cts/each on 10M parts --- they still charge them only several k$ (multiple licenses) as far as I can tell. Say those PIC parts costs anywhere between 80ct and 90ct, then that's say 10k$ licensing fees on a MCU order of 8M$+. Is it really worth to penny pinch <1% in licensing fees if a customer is already buying millions of $ of PIC parts? Maybe these customers don't care at all and that's why they do it. But it does hurt the middle or bottom of the market.

[JPortici]

Today they tell you that is a ripoff and they want it either for free or for £50 or something like that.

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.

[peter-h]

If he has a license-free tool which works, and he is up to speed on it, then it makes sense to continue using it. For example I have a 1995 PCB design program (Protel PCB 2.8 ) and need it because I run products for a long time, and often need to generate updates and new gerbers etc. It used to have a dongle (I bought it for > 1k) but it has been patched out.

The problem starts when a tool has some kind of lock on it, and you need to run it for many years, or after many years. Almost certainly, that will break. Whereas a free unlocked tool can just be archived with the project, in a VM if necessary.

This is off topic for Microchip however; it is a general thing

[AndyC_772]

The problem starts when a tool has some kind of lock on it, and you need to run it for many years, or after many years. Almost certainly, that will break.

Exactly. If I send a binary to a customer that requires software I no longer have the use of a month later, that's a risk.

Dave's right to some extent; I could, in the near future, just rent it again for each update, and add the cost to my bill. But that assumes that the same month-by-month licensing terms are still available when the code needs updating a couple of years later. I don't want to risk discovering that a couple of hours' worth of software tweak also needs a four figure sum spending on a compiler, because <insert excuse about middle managers at Microchip here>.

I won't risk putting my customers in that position.

The irony here is I do use paid-for tools for STM32; I use CrossWorks which is absolutely excellent, probably the best £1000 or so I ever spent on tools and equipment, and the difference in speed, features, usability and reliability over MPLAB X is absolutely comical. Moreover, since it's a one-off payment for a perpetual licence, I know for certain that I'll still have it available to me for the entire commercial lifetime of my code.

[nctnico]

Given the "need" for a paid version, Microchip's strategy of limiting optimisation (and not trying too hard to protect it) is greatly preferable to approaches taken by other manufacturers - limiting code size, device support or time-limitations.

Agreed, hugely preferable. And in most cases you don't need the extra optimisation. And you can rent for one month for $44 if you absoutely must have it. Again, less than hour of what an engineers time is worth.
There are also third party compilers that support PIC if you like their pricing and performance better.

Try that for a project that needs to be supported for 10 years. Then the extra cost adds up to 5k dollar. For many projects I do that is a significant extra cost which adds no value to the customer and hence they won't pay for it. I prefer to put that 5k into my pension fund. I have never used a paid compiler ever in my entire career. Whatever tool which does not have to be bought , allows me to end up with more money in my pocket.

For other cpus GCC id free and works well so why even bother? The comparison with the datasheet department making no money is very on point. It is a nonsense argument.