Is it worth using these PIC32?

[westfw]

The pragma configs are basically a shorthand notation for a bitfield that are written to a specific memory address.

the XC32 "pragma config" statements essentially set what would have been called the "fuse bits" on an 8bit chip.Many ARM chips have similar "config bits" somewhere, and I've never particularly seen complaints that ARM gcc doesn't support each particular chips' bits.  Usually that's handled outside of the source code (as part of the "project config" of a vendor-specific IDE, but ... still not insistent that the compiler do anything.)

Whether config bits SHOULD be in the source code is subject to debate.  My current complaint has been that "config" has expanded to include both things that are dependent on the hardware (and therefore shouldn't be in the C source) AND software-like things that it does make sense to include in the source, but have no way of separating them.

[nigelwright7557]

MPLAB X and Harmony are free to use unless you want top level optimisation.
But you will need a PICKIT programmer. I wouldn't recommend a Chinese copy.

Anyone who has bins with dozens of PIC32 parts on hand is likely to already have the tools needed to program them. I would not recommend a PICkit for a PIC32--it's ungodly slow. An ICD4 is much faster and will save a lot of frustration.

A Snap programmer is a fast and cheap option if you power pcb externally. PICKIT 4 is quite fast too.
ICD4 is a lot more expensive.

[Sal Ammoniac]

MPLAB X and Harmony are free to use unless you want top level optimisation.
But you will need a PICKIT programmer. I wouldn't recommend a Chinese copy.

Anyone who has bins with dozens of PIC32 parts on hand is likely to already have the tools needed to program them. I would not recommend a PICkit for a PIC32--it's ungodly slow. An ICD4 is much faster and will save a lot of frustration.

A Snap programmer is a fast and cheap option if you power pcb externally. PICKIT 4 is quite fast too.
ICD4 is a lot more expensive.

I haven’t tried a PICKIT 4. It might be fast enough for use with a PIC32. I found the PICKIT 3 so frustratingly slow that I Widlarized mine, may it rest in peace.

[nigelwright7557]

Anyone who has bins with dozens of PIC32 parts on hand is likely to already have the tools needed to program them. I would not recommend a PICkit for a PIC32--it's ungodly slow. An ICD4 is much faster and will save a lot of frustration.

The el cheapo Snap programmer is much faster than pk3.
I have done dozens of PIC32 projects without paying for the optimising compiler.
The free compiler can do a couple of levels of optimising anyway.

[Doctorandus_P]

For me it's quite simple. I have no interest with fiddling with eula's, license keys, crippled software and arbitrary whims of manufacturers, and if a chip does not support GCC out of the box I am simply not interested. I may make an exception for for example SDCC.

[tepalia02]

There is a free version of MikroC Pro for PIC. I think you can use that.

[DonKu]

For me it's quite simple. I have no interest with fiddling with eula's, license keys, crippled software and arbitrary whims of manufacturers, and if a chip does not support GCC out of the box I am simply not interested. I may make an exception for for example SDCC.

Yes. SDCC also became too much work in the middle of a IIC project.

[JPortici]

There is a free version of MikroC Pro for PIC. I think you can use that.

why? XC32 can optimize, no stupid code size limit, actual support is only on XC32, software libraries are not closed source black boxes
(besides that i checked, only a few parts are supported by the compiler. PIC32MK not among them)