-
Update -> Microchip C Compilers-which free complier do you use ? (from 2011)
Posted by ez24 on 15 Nov, 2015 23:54 -
Re: Microchip C Compilers - which free compiler do you use? (from July 04, 2011)
https://www.eevblog.com/forum/microcontrollers/microchip-c-compilers-which-free-compiler-do-you-use/
What has happened in the last 4 years in regards to free compilers for PICs?
Better or worse ? Also there were comments on ARM and AVR compliers, so any updates on them (free compilers) would be appreciated.
thanks
-
XC8 is the replacement for C18, but it covers PIC10F thru PIC18. It is based on the Hitech C I believe who Microchip bought out. It is a bit buggy, but it hides the programmer from a lot of the nasties such as banked memory.
XC16 replaces C30 and is a direct descendent of C30.
XC32 replaces C32 and is a direct descendent of C32.
The free versions lack much optimisation, but are not size limited. If you want to spend, there are standard and pro versions of each compiler. Costs are high in particular if you work across all families, although as XC16 and XC32 are based on GCC it is possible to work around that, or at least it was. There is chatter about XC8 being fiddled to liberated options too.
There is an entry cost to each level (standard or pro) and then there's a software assurance type annual licence. You only have to pay the software assurance if you need, say, support for new chips. I haven't updated any of mine since June as I have no need for any new functionality yet, but they all still work with the versions I have installed. A year's software assurance is included with the first purchase.
There is also a C++ for PIC32, it's not something I've bothered with myself.
I find XC16 and XC32 pretty robust, XC8 less so, it sometimes generates errors from nowhere and you have to deliberately reorganise your code to stop it failing. -
I have heard that the "brainless translation of intermediate code" non-optimization that the freeware 8bit PIC compiler used to do has actually been replaced by something that isn't as obnoxious and embarrassing. But it was sorta too late for me, so I haven't looked at it closely, and I don't remember whether that happened before or after the previous discussion...
For PIC32, you can consider using the toolset that comes with MPIDE (the Arduino-clone for ChipKit boards.)
-
XC8 free mode is generally getting better. Microchip has also introduced device support updates that can be applied to earlier versions if your support licence has expired. Also, unlike many competitors, the free mode licence does NOT prohibit commercial use, so if you haven't got funding yet for your project you can still go ahead with a clear concience.
However, anyone who plugs XC8 as a drop-in replacement for C18 is talking out their arse. Existing code that's more complex than basic pin wiggling usually requires major work to port to XC8. -
IMHO the price for the PIC compiler kinda negates the cost savings for using a PIC compared to the free GCC compilers availabled for other platforms.
-
IMHO the price for the PIC compiler kinda negates the cost savings for using a PIC compared to the free GCC compilers availabled for other platforms.
I agree, Microchip need to get much more competitive in this respect. -
+1.
I use PICs for simple stuff, or occasionally if I happen to need specific peripherals. For analogue stuff, they're quite good, and generally not too demanding in terms of the code they need to run.
However, if I need anything faster or more capable than a PIC18 running code from the free XC8 compiler, I jump straight to an ARM processor.
Seriously, Microchip, a crippled compiler in this day and age? You do know that Cortex-M0 exists and that gcc is free... right?
-
and that gcc is free... right?
sigh.
the full optmizing xc32 is free, you just have to compile it. (its gcc. you know that gcc is free... right?). -
The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces. Often as blatant as using additional MOV instructions to move a value out of the W register into a temp location, then immediately back again.
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
There are ways for unscrupulous users to enable the pro mode without buying the licence... -
The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces.
That is a lie, and you should stop spreading it. -
However, if I need anything faster or more capable than a PIC18 running code from the free XC8 compiler, I jump straight to an ARM processor.
Yeah, if the code is too big or requires any optimization whatsoever, then PIC18 isn't the right platform to begin with. It excels where all the C code does is set up hardware peripherals and the WDT and does pretty much nothing else. It's never going to be a good software target. An MSP430 at 1/4 the clock will run circles around a PIC18 for anything non-trivial; USB, chained buffers, rendering to a panel, etc. Doesn't matter how heavily optimized the code generation is, or even if it's carefully handcrafted, it will never be a computational platform. It does have excellent peripherals (like PWM outputs capable of operating in bridge mode without any external components), very fast interrupt service, and very low power consumption at low clocks (which precludes the software doing any significant lifting).
For everything else, there is MSP430 and ARM.
-
It depends on the definition of "deliberately". The HiTech/XC8 compiler team did have a tradition of leaving the optimiser rather a lot to do . . . .The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces.
That is a lie, and you should stop spreading it. -
Ever looked at disassembly of what it produces in free mode?The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces.
That is a lie, and you should stop spreading it. -
sigh.
the full optmizing xc32 is free, you just have to compile it. (its gcc. you know that gcc is free... right?).
XC32 is for PIC32, though, and I can't think of one single, solitary reason to ever consider using PIC32 over an ARM based device. Happy to take suggestions.
-
I would NOT recommended XC8. Simply because it does not fully support C99, which is 15+ years old by now and can be very useful (snprintf)/less frustrating. Will it ever fully support C99? Not sure.. the architecture has it constraints which likely impose a limit on this (e.g. variable length arrays).
The XC8 compiler relies heavily on the optimizer as shown, and in the free version you don't get all bells and whistles. And don't think the PRO will save you; I could not get an expanding macro's to collapse back to bit set/clr instructions (bit set/clr a to a dereferenced const I/O ptr). This which works fine on XC16/XC32 with -O1 optimizations (which is still free).
XC16/XC32 are fine, I have little issues with them. Yeah the -O2, 3 and s are missing for free, but -O1 is often more than good enough. It usually shrinks the code by the biggest step, -O2 and -Os adds very little IMHO.
What XC16 could very well use is C++ support (there are plenty of capable 16-bit uCs around with 32kB of RAM, DMA, USB, CAN, LCD, etc.). The AVR and ARM GCC compilers don't have this 'problem' (and are also free). -
I would NOT recommended XC8. Simply because it does not fully support C99, which is 15+ years old by now and can be very useful (snprintf)/less frustrating. Will it ever fully support C99? Not sure.. the architecture has it constraints which likely impose a limit on this (e.g. variable length arrays).
And the alternative for xc8 is? -
The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces.
That is a lie, and you should stop spreading it.
Did you read the link I posted? That guy gives clear code examples. Admittedly, he's using v1.21 rather than the latest version. I've got v1.34, so I'll do some testing and report back. (Always happy to be proved wrong!) -
sigh.
the full optmizing xc32 is free, you just have to compile it. (its gcc. you know that gcc is free... right?).
XC32 is for PIC32, though, and I can't think of one single, solitary reason to ever consider using PIC32 over an ARM based device. Happy to take suggestions.
I do the entire PIC range as well as ARM, mostly Cortex M4(F) but some M0 and M3 from NXP and TI. You may think it's trivial, but being able to prototype something in ten minutes in DIP is a key reason for me to continue to use PIC extensively. The other reason, perhaps more telling, is that I've been using PICs, and their predecessors, since the late 70s. Like it or not I have an awful lot of boilerplate code and experience for PICs sitting there ready to go, but not as much as with NXP or TI ARM.
The single biggest failure of Microchip has been their awful silicon and development framework since 2013 targeted at the the high end PIC32MZ, although this has improved of late significantly with their floating point PIC32MZ. I guess they were desperate to get something out of the door silicon-wise to compete with M4, but it was a car crash. The framework which you pretty much have to use on the latest PIC32MZs was and still is complete overkill. It was revealed recently it was written by some Linux kernel folks. It shows, it's hugely over abstracted and the newer PIC32MZ chips, with double the processor speed of the PIC32MX, run applications written for the MX without the framework significantly slower.
I am not sure why this needs to be a PIC vs ARM in the same way you could have the same argument about TI ARM vs NXP ARM, to me although there are similarities in the cores, that's generally a minor consideration for most of the time: beyond that they're very different from the peripherals to the vendor libraries to the free IDEs, I could go on, but knowing one ARM Cortex chip from one manufacturer doesn't mean you automatically know all the others, far from it in fact.
Having said all that, I do think Microchip made a marketing blunder going for MIPS rather than ARM, because like it or not that is where everyone thinks they should be, for now at least. -
...
Having said all that, I do think Microchip made a marketing blunder going for MIPS rather than ARM, because like it or not that is where everyone thinks they should be, for now at least.
They are stuck - if they go with ARM, then they have to compete with everyone else. By going with MIPS, they only have to compete with, oh wait, everyone else
But it's a tough situation for Microchip. Back in 2000s, BEFORE ARM really took over the 32-bit embedded / phone world, a BIG semiconductor company thought that they could dethrone the ARM7 with their own 32-bit architecture, and ... after even their own phone division would not use their chip but went with ARM, they had to cancel the whole product line. I am speaking of the mCore of course.
And then of course we still have Atmel AVR32. How many people use that?
So Microchip is stuck either way. -
...
Having said all that, I do think Microchip made a marketing blunder going for MIPS rather than ARM, because like it or not that is where everyone thinks they should be, for now at least.
They are stuck - if they go with ARM, then they have to compete with everyone else. By going with MIPS, they only have to compete with, oh wait, everyone else
But it's a tough situation for Microchip. Back in 2000s, BEFORE ARM really took over the 32-bit embedded / phone world, a BIG semiconductor company thought that they could dethrone the ARM7 with their own 32-bit architecture, and ... after even their own phone division would not use their chip but went with ARM, they had to cancel the whole product line. I am speaking of the mCore of course.
And then of course we still have Atmel AVR32. How many people use that?
So Microchip is stuck either way.
FWIW, I remember a number of folks (including me!) questioning the decision to go MIPS when the PIC32 was announced ISTR in 2007 or so. However it didn't seem quite such a big deal then, although ARM was already a key player. I guess it depended who was playing golf with who. -
You may think it's trivial, but being able to prototype something in ten minutes in DIP is a key reason for me to continue to use PIC extensively.
I have solved that by having some boards lying around to which I can solder an ARM controller bolt that to a PCB or breadboard. -
You may think it's trivial, but being able to prototype something in ten minutes in DIP is a key reason for me to continue to use PIC extensively.
I have solved that by having some boards lying around to which I can solder an ARM controller bolt that to a PCB or breadboard.
I do the same, but for BGA devices it's a lot more effort. Either way, having to solder up something when I don't need to is one less step. I found a few weeks ago that one of the newer 28 pin dsPIC33Es was only available in SOIC or smaller, not a big deal, like you I popped it on a breakout board and got on with it. So the end is nigh for DIP at Microchip too it would seem! -
It is nice to have a board which already has a regulator, some decoupling caps, maybe a USB connector, programming header etc. It can also be used in more permanent one-of solutions.
-
It is nice to have a board which already has a regulator, some decoupling caps, maybe a USB connector, programming header etc. It can also be used in more permanent one-of solutions.
That's pretty much what Teensy/ST-Nucleo-32 (the new ones) are right?
We have thought about making "C-Stamp" but just cannot compete with ST on prices when they are practically giving them away. -
Actually I have my own boards. It is good to get some hands-on experience with putting a certain microcontroller on a circuit board.