How much has Microchip missed by not having an open source compiler?

[CafeLogic]

That thread expressing discontent at the excessive discussion of Arduino and open source made me think of this.

I look at all this hacker maker stuff which always uses AVRs and I think, "I wonder why that is?". Even discounting the availability problems, PICs are just cheaper. I have a fair amount of experience with both, and I feel like it doesn't make any difference which one you use for your 8-bit project. However, price and availability push me toward Microchip. Of course, with the Arduino, they didn't have any choice. It must have been a choice between avr-gcc and msp430-gcc, which doesn't have near the community support. So, I wonder if Microchip had an open source compiler, would Arduino be based around the PIC18? Looking at this Uno, it uses an ATMega8U for USB, it hard not to think they would rather be paying almost half price for a PIC18F13K50.

I just find the whole thing kind of ironic because Microchip has always been the hobbyist/community friendly MCU. They are the ones who sample chips to anyone, they sell direct to anyone with programming for reasonable prices, they came out with the Pickit, the original 50$ development tool, they have the community support forums. On the other hand, I have always felt like Atmel's attitude has been more on the side of FU little-guy. Look at the response to the Pickit, the Dragon. No enclosure and limited to 32K (not anymore though). But in the end, it seems like the only the only thing that really matters is the availability of an open-source C compiler.

[EEVblog]

Microchip have open source compilers for the 16bit and 32bit series PIC's.
8bit PIC's are supported with the free version of the HiTech compiler, the only limitation is the (lack of) code optimisation.

IMO, no one really cares much about open source, they just want a free compiler that works well, preferably directly supported and developed by the manufacturer. And most companies and big business don't care if they pay for a good compiler, and Microchip know this.
Steve Sanghi (Microchip CEO) told me that they will not run a loss on their development tools, as that will only ruin the company in the long run.
So Microchip are almost there with the free tools, and for Pro use their HiTech compilers beat the shit out of other compilers on the market.

Have Microchip missed anything?, not at all. They aren't the most profitable and close to the #1 microcontroller company for no reason.

Dave.

[CafeLogic]

Well C18, C30, and C32 are free but they aren't open source. There is the open source MIPS compiler but that is for the 32-bit only. And I while I completely agree that I don't give a shit about it, look at it from the perspective of Arduino. For them, it has to be open source because they need to redistribute it and invoke it from their development environment. I haven't read the Microchip compiler license agreements but I really doubt that would be OK. So, it is the third party support that relies on open-source that I am referring to when I say "missed".

As far as Microchip profitability is concerned, I think that comes down to management because Atmel still has higher sales (last I checked).

[John80]

The compilers are not free! They are selling those in Microchip Direct. Only the education version is free, but with some restrictions.

[EEVblog]

Well C18, C30, and C32 are free but they aren't open source.

Yes they are GNU open source.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en536656
I believe there some contention over the full version source up by default for some reason, but I believe you can get it.
I've heard it's possible to (legally) get the full optimising version functionality by tweaking some bits or something.

As far as Microchip profitability is concerned, I think that comes down to management because Atmel still has higher sales (last I checked).

I'm afraid not, in 2009 Microchip had around $800M in microcontroller sales compared to Atmels $450M or so.
Atmel have bigger overall company sales, but only 38% of it is microcontrollers compared to Microchips 80%.

Actual yearly number of micro units I don't know, but Microchip boasted over 6 billion units by 2008, Atmel only 1 billion by 2009.

Dave.

[CafeLogic]

I hate to talk out of my ass so I pulled up the relevant data. It turns out that even though Atmel has higher sales, Microchip has higher MCU sales, and TI is daddy to both of them. However, TI logs revenue under "embedded processing" which could include some of their MPUs and not just MCUs, although I am pretty sure they record the OMAP processors under "wireless" not "embedded processing"

MCU Sales in Thousands

	Microchip	Atmel	Texas Intruments
2007	834,293	458,228	1,588,000
2008	832,921	522,635	1,631,000
2009	731,648	457,797	1,471,000

[EEVblog]

However, TI logs revenue under "embedded processing" which could include some of their MPUs and not just MCUs"

That might include their massively popular DSP line as well?

In any case, Renesas are the #1 microcontroller company in the world by far, with IIRC around 30% market share. I mentioned the actual figure in one of my Renesas videos.

Dave.

[CafeLogic]

Yes they are GNU open source.

Well damn, I had no idea they made the source available. Still no PIC18 though, I wonder why.

[CafeLogic]

That might include their massively popular DSP line as well?

You are correct. According to TI this is the definition of "Embedded Processing"

Embedded Processing – Our Embedded Processing products include our DSPs (other than DSPs specific to our Wireless segment) and microcontrollers. DSPs perform mathematical computations almost instantaneously to process or improve digital data. Microcontrollers are designed to control a set of specific tasks for electronic equipment. We make and sell standard, or catalog, Embedded Processing products used in many different applications and custom Embedded Processing products used in specific applications, such as communications infrastructure equipment and automotive.

Their total sales figure including analog and wireless is over 10 billion, I forgot how massive they were.

In any case, Renesas are the #1 microcontroller company in the world by far, with IIRC around 30% market share. I mentioned the actual figure in one of my Renesas videos.

Not terribly surprising. Anytime I have ever looked inside a microwave or fridge or something, it is always an NEC or Mitsubishi processor. I guess that's why those guys are always pushing their MCUs on white goods.

[Psi]

There are likely quite a few factors that came into play to make AVR take off in the hobby market

Microchip tend to favor the approach of making micro controllers with a reduced number of features in each chip and make up for this by having a very wide range of different model micros each with a different combination of features. This means you can pick a cheaper micro with the features you need and not pay for the features you don't.
Atmel on the other hand tend to put as many features as they can into each chip and produce a much smaller range. The result is of course a chip that's a bit more expensive, but it's also a chip that's more suited for hobby use. You can write some code that requires a chip with 2 timers one week and then write something completely different the next week that uses an ADC and comparator. So this maybe a factor in the avr's success in the hobby field.

The atmel availability problems weren't really an issue for a hobbyist looking for a micro as they were only really after 1 or 2 micros at a time and if one model was out of stock you'd just design for whatever was available. It was only after the arduino became popular that supply problems for micros used in arduinos started to cause problems for hobbyists. So i dont really think the atmel supply issues had much of an effect at the start when hobbyist were moving into AVR over PIC.

The perception of speed.
Most of us know that the 1:1 avr instructions per clock cycle vs the 1:4 for pic doesn't matter at all in the real world. You just run a pic at a higher clock if needed, It's just a design factor and doesn't cost anything to do. The perception of this however is quite different. For a hobbyist who's lived in the era of ever increasing desktop cpu speed its easy to dislike a slow chip. (Some of us will remember those IBM x86 cyrix chips, no one wanted to go there again) So this incorrect assumption may have steered computer geeks away from PICs and resulted in more open source language work being done for AVRs
 

[mikeselectricstuff]

I think a significant issue is that AVR was designed to be compiler friendly, so a run-of-the-mill compiler like GCC can produce reasonable code with a simple code generator, but you need a much cleverer compiler & codegen to work round the PIC's quirks. I think Microchip's move from code-limited to non-optimising for the free versions was a big mistake as it makes the chip performance look bad.

Would be interesting to compare performance between free & non-free on the higher end parts, which are more high-level oriented (although even the non-free PIC24 compiler has a  linker so dumb that it can't even be made to omit unused functions)  - I think the PIC24 is based on GCC.

[CafeLogic]

I think a significant issue is that AVR was designed to be compiler friendly, so a run-of-the-mill compiler like GCC can produce reasonable code with a simple code generator, but you need a much cleverer compiler & codegen to work round the PIC's quirks. I think Microchip's move from code-limited to non-optimising for the free versions was a big mistake as it makes the chip performance look bad.

That's just because Microchip makes lower ends parts. The PIC16 is not optimized for C but I don't think you can get an ATTiny for 48 cents at QTY 1 so it's give and take. The PIC18 is designed with C in mind just like the AVR so I don't know if that is relevant. I don't know a lot about the PIC24s so I cant comment on that. It is 8 or 32 for me.

I completely disagree on the non-optimizing compiler thing. I think its great way to target the people who would actually pay for a compiler. They don't disable all the optimizations just the advanced ones plus you get all the optimizations for 60 days.

I have not gotten the impression that the optimizations make more of an impact on the PIC platform than any other if that is what you are saying.

[apex]

Well, I think the most important thing about avrs is indeed their wide functional range.
All AVRs have the same core structure, but some have extension modules and other don't.
To do many things with just one chip is a big deal! Think of the arduino.
If you would use a PIC to do this work, you would have to use a much bigger footprint or smd to get the same functions.
PICs are more professional.
But in "real life", none of these factors really matter:
You choose the micro that suits best your purpose.
You want a really cheap one? Go for a big supplier.
You want external memory? Use a redesign of the 8051 (or an ARM).
Thats what a parametric search is for!
There is really nothing stopping you.
If you favorize one µC, you miss the others.

apex

[mikeselectricstuff]

I completely disagree on the non-optimizing compiler thing. I think its great way to target the people who would actually pay for a compiler. They don't disable all the optimizations just the advanced ones plus you get all the optimizations for 60 days.

Have you ever looked  at the code the free PIC16 compiler produces? It's not just non-optimised, but actively bloated with completely superfluous code. This may be a by-product of how the optimiser works, but a factor of 2-3x worse size or speed is not at all uncommon.
I've not compared the higher-end ones.

[CafeLogic]

Have you ever looked  at the code the free PIC16 compiler produces? It's not just non-optimised, but actively bloated with completely superfluous code. This may be a by-product of how the optimiser works, but a factor of 2-3x worse size or speed is not at all uncommon.
I've not compared the higher-end ones.

Sample Code

Code: [Select]

#include <htc.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
char buffer[20];
double f = 80.265;
int i;
sprintf(buffer,"%f",f);
for (i=0; i < strlen(buffer); i++)
{
PORTB = buffer[i];
}
}
Target: PIC16F917

Hitech PICC Lite (free compiler): 5113 Bytes

Hitech PICC Standard: 3227 Bytes

Hitech PICC Pro: 3164 Bytes

38% Reduction, exactly in line with what they advertise. I would say that's only slightly higher than typical.

[EEVblog]

I completely disagree on the non-optimizing compiler thing. I think its great way to target the people who would actually pay for a compiler. They don't disable all the optimizations just the advanced ones plus you get all the optimizations for 60 days.

I agree, and was asked by Steve Sanghi about it and said the same thing to him.
IMO it's much more beneficial to have a speed limited compiler that supports ALL the parts, than a full speed compiler that supports only a subset of parts (they used to do this with the free PIC16 Hitech compiler version).
Heck, being optimisation limited means you might actually think about optimising your code a bit more than you usually would. Optimisation starts with the code, not the compiler.

Dave.

[adam1213]

CafeLogic please test the output size of this modified version of your program

#include <htc.h>
#include <stdio.h>

Code: [Select]

int main(void) {
char buffer[20];
double f = 80.265;
char *p;

sprintf(buffer,"%f",f);

p = buffer;
while (*p != '\0') {
PORTB = *p;
p++;
}
}
actually the test isn't fair* as the value of f is known before compiling so a compiler could potentially optimise it (at least depending on how much you value this type of optimisation)

[Psi]

How about this for an interesting possible reason why PIC didn't take off in the hobby areas...
I've heard this from a couple of people so i'm interested to see how many people agree/disagree.

First off, if you can, try to forget everything you know about PIC's and just focus on the word "PIC" itself.
Imagine you've never heard of PIC micros before and it's the first time someone mentions PIC micros to you.

What image do you get from a microcontroller range named "PIC" ?

The name seems to convey an expectation that it's a toy micro. Something you might use at education level to get introduced to the field of mcu programming and not something that's used in industry. Of course this couldn't be further from the truth but if people do get that impression from the word then maybe that influenced the hobbyists to move and/or start with AVR?

Thoughts?  does anyone else feel the word PIC has a toy'ish or not-professional sound to it?

[CafeLogic]

actually the test isn't fair* as the value of f is known before compiling so a compiler could potentially optimise it (at least depending on how much you value this type of optimisation)

I thought of that after I posted and worked it into some phony calculations and the output size barely changed. your code is 5053 on lite and 3133 on Pro.

[CafeLogic]

How about this for an interesting possible reason why PIC didn't take off in the hobby areas...
I've heard this from a couple of people so i'm interested to see how many people agree/disagree.

First off, if you can, try to forget everything you know about PIC's and just focus on the word "PIC" itself.
Imagine you've never heard of PIC micros before and it's the first time someone mentions PIC micros to you.

What image do you get from a microcontroller range named "PIC" ?

The name seems to convey an expectation that it's a toy micro. Something you might use at education level to get introduced to the field of mcu programming and not something that's used in industry. Of course this couldn't be further from the truth but if people do get that impression from the word then maybe that influenced the hobbyists to move and/or start with AVR?

Thoughts?  does anyone else feel the word PIC has a toy'ish or not-professional sound to it?

I kind of agree with that. I don't really like the name of the company either. Whenever I mention to someone not in the field they get all confused. They might say "Wow, that's cool. Is there a mini-computer in there" and I'll say "No, I used an embedded processor from Microchip" then they look at me like I have two heads and I have to explain that Microchip is the name of the company that got spun off from GIs MCU line. Its like if I was going to start a company that made automobiles and I named it "Car".

[mikeselectricstuff]

Have you ever looked  at the code the free PIC16 compiler produces? It's not just non-optimised, but actively bloated with completely superfluous code. This may be a by-product of how the optimiser works, but a factor of 2-3x worse size or speed is not at all uncommon.
I've not compared the higher-end ones.

Sample Code

Code: [Select]

#include <htc.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
char buffer[20];
double f = 80.265;
int i;
sprintf(buffer,"%f",f);
for (i=0; i < strlen(buffer); i++)
{
PORTB = buffer[i];
}
}
Target: PIC16F917

Hitech PICC Lite (free compiler): 5113 Bytes

Hitech PICC Standard: 3227 Bytes

Hitech PICC Pro: 3164 Bytes

38% Reduction, exactly in line with what they advertise. I would say that's only slightly higher than typical.

Short code like that is not really representative as it will be mostly be library code, which may or may not be precompiled.
If you actually look at the code it generates even for simple code segments you see lots of unnecessary stuff.  Looking at the delta when adding small amounts of code would give a better idea.

[mikeselectricstuff]

Heck, being optimisation limited means you might actually think about optimising your code a bit more than you usually would. Optimisation starts with the code, not the compiler.

Absolutely agree that efficiency starts with the code, but when the compiler is pissing away  space for no reason it's frustrating. In the case of the PIC16 compiler, it will usually be more cost-effective to buy the compiler than spend time optimising around its crapness - it's not exactly expensive as commercial compilers go, and members of their developer programme get a 40% discount.
The reason I think it was a bad move was simply that anyone evaluating  PICs against the competition may get a falsely bad impression of  speed and code density.

[Hypernova]

*snip*

I kind of agree with that. I don't really like the name of the company either. Whenever I mention to someone not in the field they get all confused. They might say "Wow, that's cool. Is there a mini-computer in there" and I'll say "No, I used an embedded processor from Microchip" then they look at me like I have two heads and I have to explain that Microchip is the name of the company that got spun off from GIs MCU line. Its like if I was going to start a company that made automobiles and I named it "Car".

+1, I had trouble getting it in my head that a there's a microchip company called microchip. It's just not as classy.

[CafeLogic]

Short code like that is not really representative as it will be mostly be library code, which may or may not be precompiled.
If you actually look at the code it generates even for simple code segments you see lots of unnecessary stuff.  Looking at the delta when adding small amounts of code would give a better idea.

If it was precompiled optimization wouldn't make any difference. Since it does, I think its safe to assume the library is not precompiled.

I pulled up some real code used in a real design that avoids standard libraries.

4744 in lite, 2788 in pro, 41% - same shit.

[Mechatrommer]

4744 in lite, 2788 in pro, 41% - same shit.

size doesnt matter... performance is. run the code in the mcu and record the speed of execution and report here.
unoptimized libraries/functions, whether algorithmitically or post compiled generated machine code, there should be some penalty in speed performance if its called thousands of time from say... in loop, for, while, iteration etc.