Update -> Microchip C Compilers-which free complier do you use ? (from 2011)

[ez24]

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

[Howardlong]

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.

[westfw]

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.)

[Ian.M]

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.

[nctnico]

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.

[Howardlong]

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.

[AndyC_772]

+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?

[BloodyCactus]

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?).

[Delta]

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...

[andersm]

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.

[bson]

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.

[Ian.M]

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.

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 . . . .

[kony]

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?

[AndyC_772]

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.

[hans]

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).

[neslekkim]

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?

[Delta]

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!)

[Howardlong]

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.

[richardman]

...
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.

[Howardlong]

...
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.

[nctnico]

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.

[Howardlong]

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!

[nctnico]

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.

[richardman]

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.

[nctnico]

Actually I have my own boards. It is good to get some hands-on experience with putting a certain microcontroller on a circuit board.

[richardman]

Well, again, not for super-users, but for mere mortals :-)

[Howardlong]

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.

For those, I just add them on: I have a small drawer with common parts that I only use for breadboarding including Rs and Cs, LDOs crystals etc. There are also ready made LCD, USB and debugger breakouts for example, but admittedly the USB breakouts are only for up to full speed. Inevitably at some point you're going to need to have something more exacting, such as for high speed USB, when I use a ready made board or I make up my own PCB. But there's a whole lot of unit testing and proof of concept work at can be done on breadboards for MCUs without even turning on a hot pointy thing, as long as your chip is DIP!

[andersm]

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 unoptimized code is bad, no-one's saying differently, but it is a very different thing to claim that it deliberately makes it worse. It's a dumb claim that doesn't even pass the simplest bullshit test (one, it would just be a possible source of bugs, second, you can imagine what would happen if someone took apart the code generator and found this code). You can go to Microchip's forum and read the explanation straight from the compiler engineers, but IIRC the issue is that during the initial code generation pass, the compiler doesn't yet know the memory layout of the data, and must assume that every variable lives on a different memory page. Later optimization passes removes the code that turned out to be unnecessary.

The claim that the compiler would somehow naturally produce perfect code (on a C-hostile architecture like PICs, no less) and would then deliberately make it worse unless you pay is ludicrous.

[Delta]

Fair enough Anders, I did some testing with XC8 v1.34, and it didn't do any of the redundant double MOVing malarkey.  In free mode it did however use

Code: [Select]

MOVLW   0
MOVWF   the_varinstead of a simple

Code: [Select]

CLRF   the_varas it does in Pro mode.

Is that an "optimisation"?  I'm not sure, but admittedly I don't know anything.  (I would say no it's not, based on the fact that even as a self-taught ASM programmer, I was using CLRF right from the start)

My comments were based on this bit of code (taken from http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/) where the author was using XC8 v1.21 with a PIC18.  I can't see how the unknown banking explanation could fit here...?

Code: [Select]

71:                            maxDev = CCPR1L>>1;
001E  3611     LSRF CCPR1L, W
001F  00F2     MOVWF 0x72
0020  0872     MOVF 0x72, W
0021  00A2     MOVWF maxDev
 
72:                            maxDev= maxDev>>1;
0022  3622     LSRF maxDev, W
0023  00F2     MOVWF 0x72
0024  0872     MOVF 0x72, W
0025  00A2     MOVWF maxDev
 
73:                            maxDev= maxDev>>1;
0026  3622     LSRF maxDev, W
0027  00F2     MOVWF 0x72
0028  0872     MOVF 0x72, W
0029  00A2     MOVWF maxDev
 
74:                            maxDev= maxDev>>1;
002A  3622     LSRF maxDev, W
002B  00F2     MOVWF 0x72
002C  0872     MOVF 0x72, W
002D  00A2     MOVWF maxDev


[nctnico]

What would be interesting is to see the difference between no optimisation in the paid compiler and the free compiler.

[Ian.M]

Any *NEW* user can test that as there is a option for a 60 day free trial of PRO mode and STD mode.  (only applies if there's never been XC8 on the pc previously.  The trial does NOT reset on version upgrade)

[neslekkim]

What would be interesting is to see the difference between no optimisation in the paid compiler and the free compiler.

the article referred do exactly that.. but yes, an older version.

[hans]

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?

In my opinion XC8 is the best bet for 8-bit PIC, but from software point of view it falls short (for me). It is OK if I have something very simple that can be done via hardware registers directly without any need to have portable code.

There may still be reasons to use a 8-bit PIC from hardware perspective, but as this topic is not discussing the hardware features it's unfair to not recommended 8-bit PICs in general. You may need to use a 8-bit PIC to reach a pricepoint, simplify hardware by using a CLC or 16-bit PWM DC/DC module, etc.

What would be interesting is to see the difference between no optimisation in the paid compiler and the free compiler.

You need to select the compiler mode as in Free, Std and Pro. The license just unlocks each tier and will turn on some (safe?) optimizations in the compiler. Some of which are really necessary, like tidying up the output of the assembler code generator. GCC at -O0 also produces crap code. In XC16/32 you do get -O1 for free which makes it livable IMO. But it often breaks debugging.

However I think there are 2 additional flags, like debug and speed which will likely finetune the assembler output slightly. I am not sure how aggressive these are at each compiler mode. This would be worth testing at some point.

[MT]

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.

PIC32MX250 in DIP for instantaneous use early Saturday morning naked out of bed with an idea to test on plastic veroboard is nice
but that practice is no more for me since ST etc makes do LQFP32 (some devices) it is then a small stretch to make DIP board for it
in 30 minutes.The problem is PicKit 3 who cant supply current enough to run a small standalone setups + off board faff and it's often
a hassle to setup from zero compared to Nucleos, Discoveries who always have some extra bananas able to supply this additional off
board faff to do these early Saturday morning tests without having to fire up the entire laboratory! All my old PIC and MSP code i have
ported to ARM and that was easier then to actually set up ST peripherals. just my 5 cent!

[nctnico]

What would be interesting is to see the difference between no optimisation in the paid compiler and the free compiler.

the article referred do exactly that.. but yes, an older version.

I scanned through the article but I can't find where the author tries to compare 'pro mode' with no optimisation versus 'free mode'. If 'free mode' produces crappier code than 'pro mode' without optimisation than the author has a point stating the code generated by the free mode is deliberatly made longer.

[Howardlong]

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.

PIC32MX250 in DIP for instantaneous use early Saturday morning naked out of bed with an idea to test on plastic veroboard is nice
but that practice is no more for me since ST etc makes do LQFP32 (some devices) it is then a small stretch to make DIP board for it
in 30 minutes.

But that 30 minutes is three times longer than I take to get a PIC32 up and running 

The problem is PicKit 3 who cant supply current enough to run a small standalone setups + off board faff and it's often
a hassle to setup from zero compared to Nucleos, Discoveries who always have some extra bananas able to supply this additional off
board faff to do these early Saturday morning tests without having to fire up the entire laboratory!

I can't say I've had much problem with a PK3 supplying power, I have though had an enormous amount of difficulty in getting it working at all on occasion on MPLAB X, the USB debugger interface is truly flakey, but I can say exactly the same frustrations for NXP with their LPCLink 2/LPCxpresso and TI with their LaunchPads/CCS for different reasons. The NXP problem is the use of using too loosely integrated components that don't recover from faults without restarting most of the dev setup. With TI it turned out to be to do with the change of USB descriptor requirements from initial bootloader mode to operational mode: the device is recognised fine in its initial power up bootloader mode, but when used in CCS it attempts to re-enumerate with different USB parameters which in some heavily subscribed USB scenarios will fail. All of these scenarios take hours if not days to figure out. Hardware debuggers seem to be a continual weak link in pretty much all development environments as long as I can remember, indeed I'm always surprised when they work consistently well!

All my old PIC and MSP code i have ported to ARM and that was easier then to actually set up ST peripherals. just my 5 cent!

But that will be to just one ARM family or subset from one vendor: that is why I cringe about the generic use of "ARM" as if it is some kind of universal panacea. While the same cores may be the same between vendors, everything else is different. The memory layout and interfaces, boot options, peripherals etc. And CMSIS isn't the answer, that ends up being such a compromise that it's usually not worth considering except for the most trivial of tasks like a blinky.

In the big scheme of things whether you're running a core from ARM, MIPS or a proprietary one, that is of less relevance than hard considerations such as pricing, availability, reliability, speed, power consumption, integration level and functionality, together with soft considerations such as available skill sets, familiarity and existing investment in development tools.

As an example I have a battery powered project I'm working on the uses a triple core ARM for the main processing and a PIC24 for the power control including regulation of three power domains, plus charging and on/off. The reason for the PIC24? It will run directly from 5V or a LiIon battery without regulation, plus it has a sub microamp standby. In short, couldn't find a better device for the specifications I had.

[MT]

Howardlong

But that 30 minutes is three times longer than I take to get a PIC32 up and running 

Exactly,that's why i prefer the Microsticks over Pickit3. I can be naked while coding!
Hmm, it is peculiar in some way as ones get older one have less time to faff and learn yet another toolset,
yet another MCU, yet another peripheral etc. Time is everything.

I can't say I've had much problem with a PK3 supplying power, I have though had an enormous amount of difficulty in getting it working at all on occasion on MPLAB X, the USB debugger interface is truly flakey, but I can say exactly the same frustrations for NXP with their LPCLink 2/LPCxpresso and TI with their LaunchPads/CCS for different reasons.

Well, its an awful long time ago we used dsPIC's ,PIC24 and PIC32 but i recall PICkit3 had very little current to deliver out of the box. Hmm, i clearly read somewhere.....ah here the note, i might be entirely wrong as VDD_Target is delivered from USB but from Pickit3 user guide page 70 quote:
Note: The PICkit 3 programmer/debugger is powered through its USB connection. The target board is powered
from its own supply. Alternatively, the PICkit 3 can power it only if the target consumes less than 30 mA.

30mA is strangely low considering it's sourced from USB.
MPLABX, aaaah well, that brings back awful memories! Did they ever fix it?

The NXP problem is the use of using too loosely integrated components that don't recover from faults without restarting most of the dev setup. With TI it turned out to be to do with the change of USB descriptor requirements from initial bootloader mode to operational mode: the device is recognised fine in its initial power up bootloader mode, but when used in CCS it attempts to re-enumerate with different USB parameters which in some heavily subscribed USB scenarios will fail. All of these scenarios take hours if not days to figure out. Hardware debuggers seem to be a continual weak link in pretty much all development environments as long as I can remember, indeed I'm always surprised when they work consistently well!

That i had no idea about! Thanks for info! In contrast ST-link works surprisingly well.

But that will be to just one ARM family or subset from one vendor: that is why I cringe about the generic use of "ARM" as if it is some kind of universal panacea. While the same cores may be the same between vendors, everything else is different. The memory layout and interfaces, boot options, peripherals etc. And CMSIS isn't the answer, that ends up being such a compromise that it's usually not worth considering except for the most trivial of tasks like a blinky.

Yes but i didn't say it was a universal panacea just that it was easy to port code in those particularly cases and that includes , suprice some of the peripherals, for example MSP430 Timers is quite similarly to ST even uses same wording for reg bits. But ofcourse it depends how complicated, convoluted ones code ,peripheral are, it also might be very difficult, we was lucky i suppose.

In the big scheme of things whether you're running a core from ARM, MIPS or a proprietary one, that is of less relevance than hard considerations such as pricing, availability, reliability, speed, power consumption, integration level and functionality, together with soft considerations such as available skill sets, familiarity and existing investment in development tools.

In general yes but many things these days can be reconsidered, development tools for instance in the same way as the absolute need for
latest Altium one can get away with P99se or ANY other depending on what the requirements is for your product or in which market segment your company/you operates in.

As an example I have a battery powered project I'm working on the uses a triple core ARM for the main processing and a PIC24 for the power control including regulation of three power domains, plus charging and on/off. The reason for the PIC24? It will run directly from 5V or a LiIon battery without regulation, plus it has a sub microamp standby. In short, couldn't find a better device for the specifications I had.

Who makes triple ARM core MCU's?

[Howardlong]

Who makes triple ARM core MCU's?

NXP, LPC4370.

[ale500]

In all seriousness, did someone here actually got microchip's xc32 compiled from sources ? Yes, I read it multiple times, I have yet to find someone who did it. (I found it described in a website...).
I tried 3 times in cygwin, mingw and linux 32 bit. It doesn't compile in any of them and it aborts at different times....

[andersm]

In all seriousness, did someone here actually got microchip's xc32 compiled from sources ?

There was just a thread on Microchip's forums where someone did it.

[Howardlong]

In all seriousness, did someone here actually got microchip's xc32 compiled from sources ? Yes, I read it multiple times, I have yet to find someone who did it. (I found it described in a website...).
I tried 3 times in cygwin, mingw and linux 32 bit. It doesn't compile in any of them and it aborts at different times....

Most of the work appeared to be around fooling the licensing wrapper interface which itself is continually evolving.

[andersm]

Most of the work appeared to be around fooling the licensing wrapper interface which itself is continually evolving.

IIRC the license checks are not enabled by default.

[BloodyCactus]

Ive compiled x32 from microchips sources zip files multiple times. On linux its a cakewalk, run 'make' and done..

[Sal Ammoniac]

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.

Why not consider a PIC32? I realize that ARM is the current media and fanboi darling, but they're no better than PIC32 when it really comes down to it. Sure, the PIC32 uses a MIPS core, but MIPS is just as capable as ARM. There are differences, of course, but nothing that makes an ARM core intrinsically better than a MIPS core.

The PIC32 has a lot going for it. There's a broad lineup of parts, including parts available in DIP packages, from low-end to high-end. Microchip has a free IDE (MPLAB X) which is quite capable, a free C compiler (which is restricted to lower levels of optimization, but since it's based on GCC you can always download the source and compile it to bypass the restrictions), and inexpensive debug tools (PICKit3, ICD3).

Microchip's datasheets and user's guides tend to be better than their competitors, especially non-US based competitors. Microchip also tends to support their MCUs for long periods, which is very handy if you design long-lived products.

Micicrochip's latest PIC32, the PIC32MZ, certainly gives the Cortex-M7 a run for its money with a clock speed of 200 MHz, up to 2MB of FLASH and 512K of RAM, a double precision FPU (the only Cortex-M7 I've seen so far is the STM32F7, which only has a single precision FPU). The MZ did have teething problems when Microchip released it too early with too many errata, but they've recently released a new revision that cleans up most of the issues.

So, if you want to hang with the popular kids on the block, by all means go the ARM route, but if you want a 32-bit MCU that works, has good documentation and tools, and don't mind marching to the beat of a different drummer, don't dismiss the PIC32.

[nctnico]

Good tools??? Why would I bother with a crippled compiler when I can get a fully working GCC for ARM which is maintained by ARM for free?
And why would I bother with a broken chip in which most of the problems are solved? I use NXP's ARM devices and in those you rarely find show stopping problems.

Besides that going the ARM route provides a lot of community support and many vendors support ARM fully. If you need some cutting edge digital signal processing routines in highly optimised assembly code you are much likely to find them for ARM than for MIPS. I have been down the MIPS road before and it was like being cast away on a deserted island.

[Howardlong]

Good tools??? Why would I bother with a crippled compiler when I can get a fully working GCC for ARM which is maintained by ARM for free?
And why would I bother with a broken chip in which most of the problems are solved? I use NXP's ARM devices and in those you rarely find show stopping problems.

Besides that going the ARM route provides a lot of community support and many vendors support ARM fully. If you need some cutting edge digital signal processing routines in highly optimised assembly code you are much likely to find them for ARM than for MIPS. I have been down the MIPS road before and it was like being cast away on a deserted island.

The recently released PIC32MZ EF devices are an order of magnitude better than the EC devices released with its pants down by its ankles eighteen months earlier. I can't imagine many projects have made it to production with the older EC chips. The EFs are another kettle of fish entirely. More concerning is the frikkin' Harmony Framework that you pretty much have to use to do anything more than a blinky, forget forking out a kilo dollar for a compiler, the Harmony Framework is by far the biggest barrier to getting anything production ready, although it's a lot better than it was a year or so ago. Almost every time I use it I find another bug!

Every time in my life I've come across software frameworks it's been painful because you have to fundamentally change your programming design and style around somebody else's supposed "best practice". It's like getting into a car and the foot pedals are switched around. I just wish they'd forget forcing us to use frameworks and just give us simple consistent, full function, performant, light weight and working peripheral APIs to use instead, plus USB and IP stacks done in a similar manner.

[westfw]

More concerning is the Harmony Framework that you pretty much have to use to do anything more than a blinky

why do you "have" to use it?  Surely the peripherals aren't so complex and poorly documented that you can't use them without the vendor middleware?

[Howardlong]

More concerning is the Harmony Framework that you pretty much have to use to do anything more than a blinky

why do you "have" to use it?  Surely the peripherals aren't so complex and poorly documented that you can't use them without the vendor middleware?

As soon as you want to use USB or Ethernet, you have to use their framework... Unless you fancy writing your own drivers and stacks that is.

[Throy]

I'm forced to work with the Microchip tools everyday since we're not allowed to use anything other than Microchip.    And I have to say I often get really annoyed and frustrated with their debugging tools. 

I have here sitting on my desk a RealICE and a Pickit3.  The RealICE will lose its communications with MPLABX in the middle of debugging many times a day and I'm forced to unplug and plug it back in to the USB. The Pickit3 is just way too slow for me since I mainly work with the PIC32MX series.  It takes quite a long time to program the target.  Another lovely bug that I ran into yesterday with both debuggers was I'd set a breakpoint in the code, the device itself would stop, but in MPLABX it showed the device as still running! 

[Howardlong]

I'm forced to work with the Microchip tools everyday since we're not allowed to use anything other than Microchip.    And I have to say I often get really annoyed and frustrated with their debugging tools. 

I have here sitting on my desk a RealICE and a Pickit3.  The RealICE will lose its communications with MPLABX in the middle of debugging many times a day and I'm forced to unplug and plug it back in to the USB. The Pickit3 is just way too slow for me since I mainly work with the PIC32MX series.  It takes quite a long time to program the target.  Another lovely bug that I ran into yesterday with both debuggers was I'd set a breakpoint in the code, the device itself would stop, but in MPLABX it showed the device as still running! 

I feel your pain. This won't help much but the ICD3 is as fast as the RealICE and suffers fewer bugs.

[nctnico]

I have here sitting on my desk a RealICE and a Pickit3.  The RealICE will lose its communications with MPLABX in the middle of debugging many times a day and I'm forced to unplug and plug it back in to the USB. The Pickit3 is just way too slow for me since I mainly work with the PIC32MX series.  It takes quite a long time to program the target.  Another lovely bug that I ran into yesterday with both debuggers was I'd set a breakpoint in the code, the device itself would stop, but in MPLABX it showed the device as still running! 

This is exactly why I have given up on on-target debugging a long time ago. It just never works reliable which is frustrating like hell. I use a command interpreter & terminal  and other tools (edit: testing/debugging code on a PC) to debug code instead.

[dannyf]

Microchip C Compilers - which free compiler do you use?

I have been the biggest fan there is of Hi-tech pic compilers, up til 9.61 (I think), just before they introduced the ocg compilers. The pro and non-pro compilers (9.61 and earlier) produce tight and robust code.

Now, I am the biggest fan of their XC8 compilers: my tests suggest that the free XC8 compilers are on par or slightly ahead of the non-pro / standard PICC compilers, and the pro XC8 compilers are way ahead of the pro PICC compilers.

I was never a fan of C18.

XC16 is a copy of the old C30 - very good.

Now, I use mostly XC8 and C30.

[boz]

Gosh Guys, Lots of Doom and gloom here!

I do all my projects, even commercial ones using the free versions of XC32 and XC8, the latest versions are both fine compilers and work well with the IDE and debuggers .

Crippled is probably a bit strong a word, adding 10-20% percent to the memory requirements is annoying at worst but the only time I remember this affecting me was having to move from an 18F23K22 to a 18F24K22 which put my BOM up $0.20

If I do the math on my last project which used an AT90USB646 (https://easyeda.com/editor#id=S0UNjdvpjd), Yes I got a free fully optimised compiler (woohoo!) but had to pay US$9.30 for the chip 

[ez24]

If I do the math on my last project which used an AT90USB646 (https://easyeda.com/editor#id=S0UNjdvpjd),

Is this suppose to bring something special up?   

[boz]

Just Another Arduino Clone I made for a friend a few weeks ago, as its open source I thought I'd include the link to the board, feel free to ignore.

[BloodyCactus]

Just Another Arduino Clone I made for a friend a few weeks ago, as its open source I thought I'd include the link to the board, feel free to ignore.

just loads a blank eda schematic page for me

[westfw]

just loads a blank eda schematic page

I see a pcb layout, with traces outlined for CNC milling (?)

Crippled is probably a bit strong a word, adding 10-20% percent to the memory requirements is annoying at worst

It used to be MUCH worse than that.   Like I said earlier, I'd heard rumors that the "less optimization level" had been improved, but I've seen surprisingly little info on exactly when or how much...

[Delta]

Crippled is probably a bit strong a word, adding 10-20% percent to the memory requirements is annoying at worst

It used to be MUCH worse than that.   Like I said earlier, I'd heard rumors that the "less optimization level" had been improved, but I've seen surprisingly little info on exactly when or how much...

I've done some testing with XC8 v1.34, and the free mode doesn't seem too bad at all now to be fair. However earlier versions DID generate pointless MOV instructions, and if you google around you will find ASM snippets generated by Hi Tech C that were littered with NOPs!    However fair play, they seem to have sorted that out now...

[boz]

just loads a blank eda schematic page

Apologies for that, me not reading the share link. try https://easyeda.com/rodyne gets you my public domain stuff