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

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