MPLAB X a PIC inhibitor! Alternatives ?

[cv007]

It is odd that the byte offsets of interest are exactly the same on all 3 files as v2.05- not sure how that happens with different code. I guess when the source becomes available I can check it out, although not terribly important.

Actually the source is available (via simple deduction), they just don't show it on the the web page (yet). XC32 v2.10 looks like it basically just removed all C++ license references and now just uses PRO (2). So the 6 (Full C++) becomes a 2 (PRO). Which is why I was failing. I should have noticed when I was viewing the objdump, as I saw that 2 being used (for the mafrlcsj test) but glanced over it as I thought 2 was referring to some form of the free version. I guess they now think c++ is mainstream and no longer special

Anyway, just use the simple way as my previous post suggests. The binary mod should be faster as it skips checking with xclm, but its hardly worth the trouble for most people (maybe for projects with many many files to compile, but it still probably only adds time measured in ms).

[peterson]

While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.

[Karel]

Here's the download link to the source of the new compiler:

http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.10-src.zip

I can confirm that the "old" method still works when you change the return value from 6 to 2 as described here:

https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1621915/#msg1621915

Here's the content of an header file: XC32 source v2.10/xc32-v2.10-src/pic32c-gcc-binutils/pic32c-source/XC32-arm-gcc/gcc/gcc/config/mchp-cci/xclm_public.h

Code: [Select]

/* General XCLM return values */
#define MCHP_XCLM_NORMAL_EXIT            0x0

/* Original options used for C translation units */
#define MCHP_XCLM_FREE_LICENSE           0x0
#define MCHP_XCLM_VALID_STANDARD_LICENSE 0x1
#define MCHP_XCLM_VALID_PRO_LICENSE      0x2

#define MCHP_XCLM_DONOTUSE               0x3

/* New options used for C++ translation units */
#define MCHP_XCLM_NO_CPP_LICENSE         0x4
#define MCHP_XCLM_VALID_CPP_FREE         0x5
#define MCHP_XCLM_VALID_CPP_FULL         0x6

/* diagnose problems */
#define MCHP_XCLM_OPTION_ERROR 0x10 /* something bad in supplied options - refer to stderr for details */
#define MCHP_XCLM_INTERNAL_ERROR 0x11 /* internal error - memory, filesystem, network, ? */
#define MCHP_XCLM_LICENSE_ERROR 0x12 /* no license available, or license expired */


/* -liccheck */
#define MCHP_XCLM_NO_VALID_LICENSE 0x1
#define MCHP_XCLM_SUBSCRIP_RENEWED 0x2
#define MCHP_XCLM_LICENSE_EXPIRED 0x3
#define MCHP_XCLM_LICENSE_RENEWED 0x4
#define MCHP_XCLM_DONGLE_LICENSE 0x5


[Howardlong]

cv007: xc32 v2.10, looks like there may be a couple of errors in the cc1/cc1plus Windows offsets in https://raw.githubusercontent.com/cv007/XC3216/master/xc32xc16-info-rev5.txt

May I suggest:

xc32 version 2.10 | - notice now uses 2 instead of 6
----------------------------------------------------------------------Windows--
 Dir: C:\Program Files\Microchip\xc32\v2.10\bin\bin\gcc\pic32mx\4.8.3\
File: cc1plus   Offset: 0x774510  Change: FFFFFFFFFFFFFFFF to 0200000000000000
File: cc1       Offset: 0x6c3410  Change: FFFFFFFFFFFFFFFF to 0200000000000000

Furthermore, for XC16 v1.35, things seemed to have changed in this regard. I've found where the relevant code appears to be (Windows at offset 0x16220C). The jump is now a short jump, and of the opposite sense. I switched it around (0x74 -> 0x75) but it doesn't open the optimisations up.

[Howardlong]

While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.

Many of us do exactly that, pretty much on almost a daily basis in my case!

[NorthGuy]

While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.

Many of us do exactly that, pretty much on almost a daily basis in my case!

I like DIP parts. Very easy to connect, very easy to probe. I don't need any more soldering in my life.

And when you need it, you can get the exact same part in QFN. Perfect.

[cv007]

May I suggest:

I corrected the Windows numbers for xc32 2.10, added xc16 1.35 info.

for XC16 v1.35, things seemed to have changed in this regard

Same as before, v1.35 offset is 0x161FEB. Tested.

I would suggest using-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev6.txt
one simple file, when a new version rolls out, simply copy the file to the new version folder. Works for xc16 and xc32, every os.

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.

[Howardlong]

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.

I may well have misunderstood, but with the new method, switching between optimised and not optimised requires you to add or remove spec files. I quite often switch between optimised and non optimised particularly while debugging, and it's not uncommon to switch off optimisation at an individual source file level. How well does the new method work with this?

[cv007]

switching between optimised and not optimised requires you to add or remove spec files

Read the file I posted. Its too simple, I guess. Just create a file, put it in a folder, done. You have no restrictions. Change optimizations as wanted.

[Howardlong]

switching between optimised and not optimised requires you to add or remove spec files

Read the file I posted. Its too simple, I guess. Just create a file, put it in a folder, done. You have no restrictions. Change optimizations as wanted.

OK, I had misunderstood, the way I thought it worked was as a global "always on". It does indeed seem to just work with that file.

Regarding the XC16 location, I'm not sure how I managed to get fixated on the wrong part a few bytes down, anyway, no need for it now!

[Howardlong]

May I suggest:

I corrected the Windows numbers for xc32 2.10, added xc16 1.35 info.

for XC16 v1.35, things seemed to have changed in this regard

Same as before, v1.35 offset is 0x161FEB. Tested.

I would suggest using-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev6.txt
one simple file, when a new version rolls out, simply copy the file to the new version folder. Works for xc16 and xc32, every os.

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.

Aplogies for necroposting, now that XC32 includes ARM, the above seems to break the ARM compilation. If I remove the specs file, I can compile ARM targets.

Code: [Select]

cc1.exe: error: target CPU does not support ARM mode
c:\program files\microchip\xc32\v2.41\bin\bin\..\..\lib\gcc\pic32c\6.2.1\..\..\..\..\bin\bin/pic32c-ld.exe: cannot open linker script file ATSAMC21N18A.ld.00003098.00: No such file or directory
collect2.exe: error: ld returned 255 exit status

Are there any GCC aficionados out there who can explain this specs file to a GCC noob so I can figure this out? I've looked at the docs but I'm none the wiser to be honest.

Code: [Select]

*cc1:+ -mafrlcsj


[hans]

Have you tried adding the argument -mthumb? It tells the compiler to generate 16-bit thumb instructions instead of 32-bit ARM instructions.

IME older GCC versions does not default to generating thumb instructions for Cortex-m0, which does not support any 32-bit ARM instructions.

[cv007]

It appears you can rename (or remove) the specs file so it no longer gets used, and simply add the -mafrlcsj option to the project Global options/Additional options. They appear to no longer try to 'block' the use of -mafrlcsj when they move you from the bin executable to the bin/bin executable like they did previously (before adding in arm compiler). The specs file was a way to bypass the removal of the option by adding the option after they were done looking for it. A specs file could probably still be used instead of adding the option to each project, but not sure how at the moment as it appears the mips side is happy with the cc1 addition but the arm side is not (and the specs file could be moved to a more compiler specific folder so the mips version could be different than the arm version).

I hardly touch the pic32mm anymore, and for the samd10 I have I added the arm gcc compiler (downloaded from arm) as another toolchain option, but then requires some extra work to get it to work (replacing xc.h to the mcu specific include, or something). I would tend to want the arm supplied version of the gcc compiler as its a newer version and is used by everyone else, but I'm sure there can be good reasons to stick to the xc32 version.

[Howardlong]

It appears you can rename (or remove) the specs file so it no longer gets used, and simply add the -mafrlcsj option to the project Global options/Additional options. They appear to no longer try to 'block' the use of -mafrlcsj when they move you from the bin executable to the bin/bin executable like they did previously (before adding in arm compiler). The specs file was a way to bypass the removal of the option by adding the option after they were done looking for it. A specs file could probably still be used instead of adding the option to each project, but not sure how at the moment as it appears the mips side is happy with the cc1 addition but the arm side is not (and the specs file could be moved to a more compiler specific folder so the mips version could be different than the arm version).

I hardly touch the pic32mm anymore, and for the samd10 I have I added the arm gcc compiler (downloaded from arm) as another toolchain option, but then requires some extra work to get it to work (replacing xc.h to the mcu specific include, or something). I would tend to want the arm supplied version of the gcc compiler as its a newer version and is used by everyone else, but I'm sure there can be good reasons to stick to the xc32 version.

Yes, thanks. Coincidentally I just figured out that I could move it to the project specific options rather than in the specs file.

What threw me was the option itself, particularly not being a GCC guru other than as a dumb user for many years, I couldn't find its purpose explicitly documented anywhere, so I was thinking there was some clever shenanigans going on with a combination of flags somehow. Presumably it's simply an undocumented option outside of Microchip.

[cv007]

> Presumably it's simply an undocumented option outside of Microchip

Its an undocumented 'inside' option, and in the source code- mchp.opt (and used in mchp.c). Looks to me like someone at mchp wanted easy access to 'pro' without all the hoops everyone else has to go through (they don't like their own cooking). With a little imagination, its not hard to figure out what the option is saying, and who most likely created it (although there a two j's to choose from).