microchip studio and the free XC8 compiler

[snarkysparky]

Microchip studio now comes with the XC8 compiler for AVR microcontrollers.   However you can purchase the PRO version.

Old ATMEL studio supported AVR.  Does this mean Microchip studio now has a crippled version of XC8.

Might this be the path for all the AVR and SAM parts.   Free is crippled ,  you pay for the optimization that you use to get for free in ATMEL studio?

[oPossum]

The free version of XC8 for AVR is has limited optimization and will also throw in some MULS instructions to slow things down even more.

[cv007]

> Does this mean Microchip studio now has a crippled version of XC8.

It always has been that way- all XC compilers have restrictions. All XC compilers except XC8-pic are based on gcc so the restrictions can be removed as the gpl license allows. XC8-avr was restricted from day 1.

I would just extract the latest gcc-avr compiler (7.3.0) from arduino and use that instead (any ide can easily change to another compiler). You get a compiler that can do C++ (with -std=c++17), and there is no downside. The same applies to their Arm mcu's, and I would use the latest gcc version from Arm (I use the same compiler for samD, nRF52, and stm32).

If you want to use XC8-avr for some reason, you can change a few binaries to remove the restrictions-
https://github.com/cv007/XC3216/blob/master/xc8-avr-info.txt

The above was for 2.20 so don't know if they changed anything, but GPL means they release the source code, so can easily see what needs to be changed- go download the source and check it out if needed. The restriction removal for xc32/xc16 is even easier (no file modifications needed).

[Jan Audio]

I did not know you can hack XC8 ?, also for PIC target chips ?

[cv007]

>also for PIC target chips

There is XC8-avr and XC8-pic and the pic compiler is not using gpl licensed code. They use llvm/clang for XC8-pic (and separate binaries), which has a license which allows them to do mostly whatever they want with that code. Doesn't mean its any harder to figure out how to enable all optimizations (5 minutes work), it just means you are no longer on solid ground in doing so (if you are concerned about what ground you are standing on).

[DavidAlfa]

There's a xclm patch since a long time ago, works even on latest releases. Saves about 50% of code space.
Usually you can live with the non-optimized code.
Xc8 aint't cheap (900€), however, you know what can happen using pirated software in professional enviroments, you might pay several times that and get a lot of trouble!
Better avoid the lawyers... The Pro version will pay itself in no time if you really need it.
I think there're some ethics here. For learning purposes I think it's aceptable, like AutoCAD or solidWorks.
Paying thousands just to train yourself at home, to not lose practice? You're not making a single cent out of that...

[nctnico]

But you have to ask yourself how many products you need to sell before the 900 euro pays itself back versus using a different microcontroller which comes with free tools. With GCC being available for so many microcontrollers nowadays it is not much of an issue but back in the days I'd tell every sales rep that a microcontroller must come with tools at no extra cost otherwise I won't use it. I'm surprised Microchip still charges for the compiler 

[DavidAlfa]

As I said, 99% of the time you can live with no optimizations.
And you can say thanks, others limit the code size in the free version.
You have alternatives like sdcc and others...
For real quick ISRs, you can always use some asm.
With the free version, maybe you'll need a pic with more flash to fit the code, but that's all.
900€? Well, that's easy. You have a xc8 compiler and hundreds of Pic 12/16/18 that you can use in your projects. It's another tool, like a power supply, computers, oscilloscope. It pays itself over time.

But yes, it's strange that gcc supports AVR and not PIC, being similar architectures.
http://gcc.gnu.org/backends.html

[Jan Audio]

For 32 and 16 bit i had to search for some 256 byte hash, and replace with another, that was easy.
I dont know what to look for and replace with in the XC8 version.

Forum member Karel explained it is illegal for XC8, so he did not tell i guess.

[cv007]

But yes, it's strange that gcc supports AVR and not PIC, being similar architectures.

? ? ?  similar in that they are both 8bit? There is a reason gcc compiler writers didn't even pick up the ten foot pole for the pic mcu.

Saves about 50% of code space.

That is quite optimistic, and that number probably comes from the brochure. They probably got that number years ago when it was probably true and are still using it (early days of banksel every other instruction -> banksel when needed, probably got them the 50% they still claim).

This compiled with v2.31-
https://github.com/cv007/3DigitLed

opt flash/ram
0 5633/321
1 5200/321
2 5080/319
3 5194/319
s 5080/319

For 32 and 16 bit i had to search for some 256 byte hash, and replace with another, that was easy.
I dont know what to look for and replace with in the XC8 version.

Forum member Karel explained it is illegal for XC8, so he did not tell i guess

For their 32 and 16 bit versions, all you have to do is add a tiny text file to a folder, and there is no modification to any files (my earlier link for xc8-avr is in the same repository that describes the xc16/32 versions).

The xc8-pic compiler takes about 5 minutes with objdump, a calculator, and a hex editor, if you know what you are looking for (basically 2 bytes to change, not that I have done it). When you study the gpl source code for the others, you can figure out a shorter path than dealing with the hashes/xclm which was the long way to get to the destination. When you understand what they are doing in the gpl code, its doesn't take a rocket scientist to understand whats going on the pic version which is not that much different in this area. Not really worth the trouble, though.


The better solution to all of this is pick your toolchain before you pick your mcu. In the end the restrictions are more of an annoyance than a problem, but they still annoy. One of the best things the arm cortex series has going for it, is you get a compiler that is up to date (not stuck at version 5), is used by everyone, and you can go to arm to download it any time you want without restrictions/registration/or any other hassles (or get it via a hundred other ways).  Now that you picked a good compiler, you can choose your flavor of mcu to match, and you will have a good selection to choose from.

[DavidAlfa]

Optimistic? I tested a program, with no optimizations flash usage was 15%, while optimized 10%, so yes, 50% less.

I'm not sure about posting an external link. For learning purposes only, I don't support piracy in any way.
I found this. Not my file, not uploaded by me, I just found it somewhere.
If it breaks any rules, sorry, proceed to deletion.
If you get money from the compiler, then buy it.
If you only want to touch and see, it won't harm them.
That's my way of thinking.

Also, instead buying the whole thing, you can now get a suscription, I think it was $29/month. If you only want to use the compiler for one project, it's a nice solution.

[Howardlong]

For their 32 and 16 bit versions, all you have to do is add a tiny text file to a folder, and there is no modification to any files (my earlier link for xc8-avr is in the same repository that describes the xc16/32 versions).

Be aware that this method breaks ARM XC32. To avoid that, add the -m.... switch at the project level for PIC32 MIPS builds in compiler command line options, rather than in the compiler specs file.

[cv007]

Optimistic? I tested a program, with no optimizations flash usage was 15%, while optimized 10%, so yes, 50% less.

I'm sure there are discussions somewhere on the internet about less vs reduce/reduced/reduction, so you probably got 33% 'less' and a 50% reduction. Its more helpful to specify what the free (-O2) vs paid (-O3,-Os) is getting you, rather than compare with no optimization. In any case, the advantage from free to pro happens when the flash usage is high, and the numbers on that end are going to be the ones that are important. In the example I gave previously, there is ~10% difference from -O0 to -Os, and none from -O2 to -Os.

Our free MPLAB XC C Compiler comes with the majority of the optimizations you need to reduce your code by up to 70%

It seems we are behind the times. You can reduce your code by up to 70% even with the free optimizations. Not sure why they feel the need to sling these numbers around as they have little or no meaning, but advertisers advertise, and Advertisement-101 teaches you need to throw out these kind of numbers to dazzle the audience.

If they start out with -O0 on the avr, they can probably claim a 300% reduction in code size as anything you produce on the avr in -O0 will be 3 times the size of anything with optimizations enabled at any level.

Be aware that this method breaks ARM XC32. To avoid that, add the -m.... switch at the project level for PIC32 MIPS builds in compiler command line options, rather than in the compiler specs file.

I also figured that out when they started to include an arm compiler in xc32, and there is probably an easy solution as to why it seems you lose an include directory in the process of adding to the cc1 specs, but not that interested in figuring it out as I no longer use their compilers.

I'll probably just remove that repository rather than let it get old and outdated. It was initially a problem to solve when they required a license to use c++, and I had a pic32mm which I wanted to use c++. Haven't touched the pic32mm in a long time. I also now use c++17 features which none of their compilers can do as far as I know. Just sell me an mcu, provide a datasheet, if you have an mcu header, that's fine. I'll take care of the rest.

[JOEBOBSICLE]

Not sure if I'll ever buy microchip again unless they sort out the compiler and debugger situation.

 I'm more likely to go for a cortex m0 because I can get a painless debugger for $40 from multiple vendors whereas with microchip I need to pray to the gods that the ICD works

[Jan Audio]

If you use 0 optimizing it will also calculate all your macros, it can get to the 50% easy i guess.

#define MYVALUE ( 1 + 1 )

It will calculate the 1 + 1 every time,
i dont understand why 0 is the default setting and not 1, the best you can get for free.

[cv007]

>i dont understand why 0 is the default setting and not 1, the best you can get for free.

They give you to -O2 for free, which changed some time ago.

[Howardlong]

i dont understand why 0 is the default setting and not 1, the best you can get for free.

It makes debugging painful unless it’s set to zero.

[DavidAlfa]

Well, you can't just use 2 lines of code and  take that as the optimizing benchmark.
My program is about 2000, so that's more like real-world scenario.
If you want to try yourself , just try the patch from the link...

I repeated the tests with all modes:

Flash bytes
O0: 2389
O1: 2039
O2: 1975
O3: 1914
Os: 1686

Also never use their latest debugging tools. They always need years of polishing, same happens with the new StLink v3.
The Pickit3/4 works pretty nice, not the best for huge projects, but does the job. When I was at this professionally I preferred the Pickit3 over ICD3.
Slower but way less trouble maker!

Also it will  depend a lot on the architecture. Pic18 and newer pic16 have more instructions, made for optimizing high level languages like C.
So the code size will be lower in the pic18 and newer pic16 vs the old pic10/12/16.

[Jan Audio]

I would love to hack the XC8 for windows, anyone know how ?

[cv007]

>I would love to hack the XC8 for windows, anyone know how ?

The link in #2 shows what you need. You need to find the file location of the 2 symbols in each of the 3 files and change their values. You will need objdump, but its possible they stripped the symbols so would then take more work to find where they are located in the files (symbols not stripped in Linux version, but not sure about the others- they have stripped them in Windows versions before so maybe still do).

I wouldn't bother as there is something better- gcc-avr version 7.3.0 which you can get from arduino- download the arduino zip file, extract just the compiler, done. Add the toolchain to your ide if you use an ide. Its better as its not restricted, does not require a call to xclm when used (so is faster), can use C++, and you will not have to 're-hack' on every new release of xc8-avr.

[DavidAlfa]

Read carefully #10. Theres's a link with the patch file.
I won't put it in BRIGHT RED for obvious reasons.

[Jan Audio]

I am certainly not downloading a .exe file hack.

I like to know how i can edit the file myself.

[cv007]

>I like to know how i can edit the file myself.

They stripped all the symbols from the Windows version, but the Linux version still has some info that can help. The Linux version can help find what code to look for, and once this code is found the global symbol addresses can be found, once the symbol addresses are found the file offset address can be found via the file section header info and a calculator, once the file offset is found it can be verified it is correct (will be -1 in u64), then the knowledge of what code to look for that uses the global symbols is used to locate these in the other 2 files. Since Windows and Linux will compile basically the same, this code knowledge transfers to the Windows version also, and the symbol addresses can be located using something like mingw64 for objdump (meaning its the same process but now know what to look for to locate symbol addresses).

The link in reply 2 now has the Windows numbers for v2.31. Still recommend avr-gcc 7.3.0.

Also, fyi, these files that are modified are all gpl licensed code and xclm is not touched or bypassed.

[Svuppe]

It makes debugging painful unless it’s set to zero.

I strongly prefer -Og for debugging with avr-gcc. I don't know if XC8 supports it though.