Microchip XC8 (v2.00) Compiler

[MarkF]

I have just installed the latest XC8 compiler and running in "free" mode. 
Two of my old programs no longer fit in their targeted MCUs (a 16F877A and a 18F2550).
Maybe it's no longer doing any optimizing or just adding bloat???
The compiler also outputs many more warnings then the older version.

Switching back to version 1.45 for now.

[HB9EVI]

This is actually the pain with the Microchip compilers. Instead of focusing on their hardware business, they have to deal with shabby software they were actually not even able to develop on their own; they had to buy it and integrate the whole company in theirs. That was for me the reason to leave the Pics behind me very fast and use just the AVR platform as 8bit mcus.

short: the binaries from the free compiler is just garbage; it's completly bloated.
and to say it clearly: because of the banking, the PIC16F are barely useable for high language programming while at the same time the pic asm is a total pain to use. Although the PIC18 are quite neat mcus

[JPortici]

I have just installed the latest XC8 compiler and running in "free" mode. 
Two of my old programs no longer fit in their targeted MCUs (a 16F877A and a 18F2550).
Maybe it's no longer doing any optimizing or just adding bloat???
The compiler also outputs many more warnings then the older version.

Switching back to version 1.45 for now.

no warnings for me.
I did notice an increase of 5% the PIC18 projects i tried to upgrade. I compared the assembly and it seems that the standard library functions are way less optimized, in C99 mode.
in C90 mode, however, i had either a 5% reduction or essentially the same size.
note that if for any reason you are using floating point, in 2.00 C99 mode the floating point size is changed from 24bit to 32bit

[Bruce Abbott]

I have just installed the latest XC8 compiler

Why?

[AndyC_772]

I found that with 2.00, the IDE underlines in red everything that's defined in the standard headers (eg. <xc.h>), like it can't find them. Switch back to an earlier compiler and all the highlights go away.

TBH I only tend to use PICs now when there's a really compelling reason, like a custom peripheral that's not available elsewhere (eg. the CTMU), or a particularly high temperature spec. Otherwise it's ARM all the way.

Can't believe they're still peddling a paid-for "PRO" compiler in a world where Cortex-M0 exists...

[firstcolle]

I try it for a little bit and I found that it's not only an upgrade but it's a whole new compiler that uses C99 standard for a new project and a new parser. I don't know if this is only for AVR MCUs. But also the settings in the compiler options are different.

If you convert a project from 1.xx version the program ask for change the params at the nearest value in the new compiler. In this new compiler, there is no option for the license as we seen it before (free/pro) and there are no settable warning levels. There is only an optimization level and in free mode we can select only 2 of those. try to modify this param and it should reduce the code dimension.

but whit no settable warning levels I have an infinite row of warning during compiling (i always set the level on 0 or -1).. anyone knows how can I set this param?
otherwise, I should live with the old 1.45

[JPortici]

really? i only used to get the stupid and obvious

Code: [Select]

(398) implicit signed to unsigned conversionwhen doing bitwise operations. And that was because at version 1.42 or whatever the default warning threshold level was changed to -3.

Now the default level is 0 (refer to the compiler manual) and I only have two warnings, as i used to have before

Code: [Select]

(520) function "xxx" is never called
(1498) pointer (xxx@yyy) in expression may have no targets
and 1498 is a bogus warning generated by the ""omniscent compiler"" because the unused function is removed later by the linker.

I think you have two options
- Fixing your code to get rid of the warnings
- Reading the compiler manual, chapter 3.6.4.1 Disabling messages at page 55. The related command line options has to be added in "XC8 Global Options", additional options. You can, as before, change the warning level, disable all warnings, disable specific warnings.

@AndyC, i also noticed that problem happening from time to time, i think it's the stupid netbeans parser breaking whenever it feels like it, as apparently it can't find any of the <*> includes and yet it still compiles.

[firstcolle]

the most warnings I have are

Code: [Select]

(520) function "xxx" is never called
(398) implicit signed to unsigned conversion

never seen with the warning level set to 0 with the previous version.

thanks for the advice on chapter 3.6.4.1 Disabling messages at page 55.

[MarkF]

Since my initial post, I have been so confused.  Some where in the process of installing/uninstalling the XC8 compiler versions and correcting the most egregious warnings, I'm no longer able to reproduce my initial findings. Things I've found while comparing the different versions (v1.45 vs v2.0) are:

• The C89 and C90 standards are producing the same warnings
• The C89 and C90 standards are producing the same binary sizes when using optamization level #1
• The C99 binaries are about 5% larger
• The old interrupt service specification ,"void interrupt isr(void)", has been replaced with "void __interrupt() isr(void)"

Is there a way to have the compiler default to the v90 standard when creating new projects?

I have just installed the latest XC8 compiler

Why?

Although I'm retired now, I try to remain current and use the newest versions of tools when able and affordable.  The only real issue I have with MPLAB X is that I can't disable the auto-formatting.  I can't understand why it's so hard to have an OFF button.  As for the XC8 compilier, an older (free mode) version's output seemed pretty clean without bloat and met my personal needs. My first MCU was from DLP Designs, DLP-2232PB-G, which has a pic16f877a.  The PICs have been my goto MCUs for tiny projects that don't require a lot of processing power.

[TomS_]

I found that with 2.00, the IDE underlines in red everything that's defined in the standard headers (eg. <xc.h>), like it can't find them.

I used to get this, and it was when you had multiple projects listed in the projects window at the same time. If you got rid of all of the projects you werent working on, the red squiggly lines would no longer be an issue.

[AndyC_772]

It was definitely compiler related; switching from 2.00 to 1.40 made them go away immediately, with no other change required.

Since then I've installed the new IDE 5.00 and it seems OK. Time will tell what other gremlins leap out when my next PCB design is ready, but since it uses a PIC which is only supported in the very latest versions of the IDE and compiler, I didn't have a great deal of choice.

[JPortici]

dsPIC33C ?

[AndyC_772]

The only reason I've ever used a dsPIC of any kind is because there are a few that'll run at 150 deg C, and that's not a quality you'll find in most alternatives. (If anyone knows of a relatively affordable 150+ rated ARM chip - say, a Cortex M0 or M3 - then I'd love to know about it!)

The part I'm using this time is just a simple, cheap 8 bit PIC (16Fsomething) that happens to be a good fit for a little lab tool I'm throwing together. It doesn't need to be anything special, and I could have used any one of a hundred other parts, but it was the one that came up in MAPS when I selected the features I need and sorted by price.

[JPortici]

Ah, i see. i thought it was the dsPIC because it actually needs new features introduced in MPLABX 5.00, for dual core project management!
(Besides the 150 °C, they were on par or outperformed any cortex M0 and M3 i used in latency, dsp (doy!) and peripherals. and we are going CRAZY for this new core. can FD and 100+90 MIPS rated at 125°C but i won't go on further on this subject, this was enought OT for this thread)

[jpmkm]

I made the same mistake a few days ago too.  I was on 1.45 and it said there was a new version available, so I let it install 2.00.  Started getting warnings all over the place that I didn't have before.  Changed everything to C99, changed my float and double sizes to 32bits like it wanted, and kept getting warnings.  I had no specific reason to need xc8 2.00, so I switched back to 1.45, which thankfully is easy enough to do.  Not sure what kind of code size difference there was since I didn't even get to that point.  Using a pic18f46j50(not what I would use if I had to pick one, but I've got several of them that I hate to not use).