Is it worth using these PIC32?

[luiHS]

Today reviewing the components that I have I have found these PIC32 (MX795, MX460), there are quite a few as can be seen in the attached photos. Many years ago I stopped using PIC microcontrollers, to use ARM.

But now given the scarcity of components, and having found all these PIC32's around the house, I wonder if it's worth trying to use them for some projects.

The last thing I remember about the PIC32 is that the C compiler was not free, and it cost quite a lot, I think I remember around 1200 Euros, and the alternative to using the demo is that you don't have optimization enabled, which results in a code object that is twice the size and for certain parts of the program it may not work well if it is not optimized.

[alexanderbrevig]

Ouch! You need some JEDEC trays my friend 

Either use for project, or try and score some $ on ebay?

[luiHS]

Ouch! You need some JEDEC trays my friend 

Either use for project, or try and score some $ on ebay?

Those PIC32 that I show in the photos are from many years ago, when I was dedicated to electronics as a hobby.

Now I work professionally, I have my own Pick and Place machine with custom trays and the ARM microcontrollers I buy always come in trays from the manufacturer, although I don't use them in my P&P machine, I use the custom trays in these photos attached.

[alexanderbrevig]

Well played! Awesome setup 

[uer166]

The last thing I remember about the PIC32 is that the C compiler was not free, and it cost quite a lot, I think I remember around 1200 Euros, and the alternative to using the demo is that you don't have optimization enabled

That is not true, optimization is enabled up to -O1 or -O2 (I forget which), which results in code almost as fast as -O3 or -Os, perfectly serviceable. I also prefer MplabX to any Eclipse-derived thing so it's a little more pleasant to work with.

[Ian.M]

XC32 (and XC16 and AVR XC8) are GCC based so there's nothing to stop you bypassing the license check.  In fact, the check is less effective than the worst electronic lock the Lockpicking Lawyer has ever picked, and is trivial to bypass.  See our fellow member cv007's plain text specs file hack for details: https://github.com/cv007/XC3216/
Development history in the forum thread here: https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1618555/#msg1618555

[JPortici]

For those wondering, the specs.txt method is still working on XC16 and XC32, but on my code -O2 is enough
maybe you were using them in the dark times of MPLAB v8 and C32 in which only -O0 was available?

I don't see a reason why you shouldn't use those PIC32, in fact if i really NEED 32bit (and it actually never happened other than on prototypes) i still reach to the PIC32MX, you can't really beat that if you need usb, can and lots of ADC/PWM/timers (though in the end i always scrap usb or can so i can reach out to a cheaper PIC24 or a cheaper and more powerful dsPIC) Well you can but it's like twice the price from other microchip or any other vendors arm parts.

[hans]

I've recently done a few toy projects with PIC32, and although not perfect, it's also not that bad IMO.

XC32 works up to O2, which is good enough for most applications. I believe XC32 was updated to GCC 6.x branch a little while ago, so it is atleast possible to use some of the newer language features in C++14, if that is of interest to you.
But unless you're doing something fancy in C++ with complicated constructions for virtual method devirtualization, you'll unlikely observe massive speed/size improvements going beyond O2. The compiler will (under the hood) compile your code twice for -Os as well, and advertize the binary size in that case (so you buy a license )... It's slightly annoying and makes compilation a bit slower, but not unusable by any means.
Oh and the specs modification still works, but I only tried it on my office machine, as I can't be bothered to put it on my lab machine. Like, honestly, for my projects I didn't have code size or speed problems (even though I know some code will alot run faster on O3), so I don't see why bother.

As in terms of actual silicon, the MX series are not bad chips. Their Coremark/MHz score gets close to 3-3.5/MHz, where a Cortex-m3/m4 will score similar. The documentation and programming of peripherals is rather straight forward.

There are perhaps 1 or 2 things that I find lacking somewhat. First is the quantity of peripherals. It's easy to get used to having 3.6MSPS 12-bit ADCs, 6 SPIs and 8 UARTs on a 100-pin STM32F4 chip. But if you can fit the I/O layout, it's doesn't have to be a problem.
The energy efficiency of the MX chips, to todays standards, is not great.

Personally the reason for me that stopped using PICs a while ago was their IDE. I don't like Netbeans and the glitchyness, how slow it is, while using plenty of resources on a fast machine (12-core AMD 3900X). For my ARM projects I've switched over to CLion, so I expanded my CMake scripts to support the XC32 compiler. However, I have not been able to get debugging to work so far from CLion. I would need a XC32 gdb executable (probably), but more importantly a GDB <> PICKIT bridge. There were some opensource alternatives for that, but it didn't work out yet for me. I may try openocd + JLink on JTAG pins one day.. but unfortunately I've only broken out the ICSP pins on my boards.

However, there is the mdb command line simulator/debugger in MPLAB, that can be used independently from the IDE. It's not interactive, but it can aid a little bit in debugging. I've used that to upload debug code, run the program till a fault occurs, and then halt the program to inspect the PC (which using a custom assert() can hint which one failed). Also printf() debugging. Both methods are rather primitive.. but also sufficient if you test application level code on PC first, and only need to debug hardware related stuff on the device.

[iMo]

I spent some time with pic32MX795 (and MZ) chips mainly because of their 128kB of on-chip sram (perhaps the first chip with 128kB sram on the market). For example we ran 2.11bsd unix on it (the "retrobsd" project). It was 10+ years back, however. The pic32MZ(EF) got double precision FPU (and 512kB of sram at 200MHz clock). Pretty capable chips, indeed, MX comparable with 72+MHz CM4, MZ with CM4F @168+MHz, the power consumption/MHz a bit higher than with the stm32 chips.
Except the MCHP tools there is for example the arduino-like UECIDE dev environment
https://uecide.org/about
supporting the pic32 as well.
PS: there is an USB bootloader/programmer available as well
https://github.com/sergev/pic32prog

[Sal Ammoniac]

The PIC32MX series is still a very viable MCU for projects, even today. The line is mature, and relatively errata-free (at least compared to the newer MZ parts). I consider the MX series to be equivalent to a Cortex-M3 in nearly every way. The only thing I miss is hardware floating point (which is available on the MZ), but Cortex-M3 doesn't have an FPU either--you need to go to Cortex-M4 for that.

XC32 is free if you don't care about high optimization levels. I've found that going from -O0 to -O1 gives me 90% of the optimizations of higher levels, so I don't consider this to be a real issue. If it is, you have two options: pay Microchip for a license, or disable the license check (their compiler is based on GCC, which is open source and the source code is available on Microchip's website).

EDIT: I've found the Microchip documentation for the PIC32 to be better than what most ARM vendors supply for their Cortex-M parts. Some people are turned off by the fact that Microchip puts each major subsystem (CPU, I2C, SPI, UART, etc.) in a separate document, but that doesn't bother me.

[SiliconWizard]

PIC32MX MCUs are nice and perfectly usable. The compiler is no issue really - the free version is perfectly usable too, contrary to what you seem to be implying. But there are ways of using the full version for free, and as I remember was discussed earlier, it's probably perfectly legit due to the fact that xc32 is GCC and is open source.

One thing to keep in mind though compared to at least recent ARM-based MCUs is power draw, which is a bit on the high side. It's approx. 0.5 mA/MHz, while many ARM-based MCUs these days are half or 1/4 of that, or even lower for the ultra-low power ones. But if power draw is no real concern to you, no problem.

I also found them easier to work with 100% baremetal than many ARM-based MCUs.

[nctnico]

Ouch! You need some JEDEC trays my friend 

Either use for project, or try and score some $ on ebay?

Those PIC32 that I show in the photos are from many years ago, when I was dedicated to electronics as a hobby.

Now I work professionally, I have my own Pick and Place machine with custom trays and the ARM microcontrollers I buy always come in trays from the manufacturer, although I don't use them in my P&P machine, I use the custom trays in these photos attached.

Is that material even ESD safe (as in slightly conductive)?? The same for your parts in plastic bins. I'd throw them out; dealing with potentially ESD damaged components is too much of a hassle.

[mikeselectricstuff]

EDIT: I've found the Microchip documentation for the PIC32 to be better than what most ARM vendors supply for their Cortex-M parts. Some people are turned off by the fact that Microchip puts each major subsystem (CPU, I2C, SPI, UART, etc.) in a separate document, but that doesn't bother me.

The part datasheets include enough basic info on most peripherals, and all the register details - there are seperate datasheets that go into more detail on each peripheral, but IME these are rarely needed.

[westfw]

I've always been a bit puzzled that there isn't more discussion of using a generic MIPS GCC compiler to develop for PIC32.  I mean, gcc was the major MIPS compiler, and in common use, long before PIC32 existed, and the Microchip XC32 for MIPS is just a somewhat customized build of gcc, anyway.  And a generic ARM gcc is "frequently" used for ARM microcontrollers...

[nctnico]

I've always been a bit puzzled that there isn't more discussion of using a generic MIPS GCC compiler to develop for PIC32.  I mean, gcc was the major MIPS compiler, and in common use, long before PIC32 existed, and the Microchip XC32 for MIPS is just a somewhat customized build of gcc, anyway.  And a generic ARM gcc is "frequently" used for ARM microcontrollers...

Same here. Maybe people are too tied into the Microchip ecosystem (and blinded) to see the compiler as a freestanding tool that can be replaced.

[Sal Ammoniac]

I've always been a bit puzzled that there isn't more discussion of using a generic MIPS GCC compiler to develop for PIC32.  I mean, gcc was the major MIPS compiler, and in common use, long before PIC32 existed, and the Microchip XC32 for MIPS is just a somewhat customized build of gcc, anyway.  And a generic ARM gcc is "frequently" used for ARM microcontrollers...

I wonder if a generic MIPS GCC would support the configuration settings for the PIC32? These look like this:

Code: [Select]

#pragma config DEBUG = OFF              // Background Debugger Enable (Debugger is disabled)
#pragma config JTAGEN = OFF             // JTAG Enable (JTAG Disabled)
#pragma config ICESEL = ICS_PGx2        // ICE/ICD Comm Channel Select (Communicate on PGEC2/PGED2)
#pragma config TRCEN = ON               // Trace Enable (Trace features in the CPU are enabled)
#pragma config BOOTISA = MIPS32         // Boot ISA Selection (Boot code and Exception code is MIPS32)
#pragma config FECCCON = OFF_UNLOCKED   // Dynamic Flash ECC Configuration (ECC and Dynamic ECC are disabled (ECCCON bits are writable))
#pragma config FSLEEP = OFF             // Flash Sleep Mode (Flash is powered down when the device is in Sleep mode)
#pragma config DBGPER = PG_ALL          // Debug Mode CPU Access Permission (Allow CPU access to all permission regions)
#pragma config SMCLR = MCLR_NORM        // Soft Master Clear Enable bit (MCLR pin generates a normal system Reset)
#pragma config SOSCGAIN = GAIN_2X       // Secondary Oscillator Gain Control bits (2x gain setting)
#pragma config SOSCBOOST = ON           // Secondary Oscillator Boost Kick Start Enable bit (Boost the kick start of the oscillator)
#pragma config POSCGAIN = GAIN_2X       // Primary Oscillator Gain Control bits (2x gain setting)
#pragma config POSCBOOST = ON           // Primary Oscillator Boost Kick Start Enable bit (Boost the kick start of the oscillator)
#pragma config EJTAGBEN = NORMAL        // EJTAG Boot (Normal EJTAG functionality)

[ataradov]

I wonder if a generic MIPS GCC would support the configuration settings for the PIC32? These look like this:

Not out of the box, but those pragmas just put values into a reserved address in the ELF file. You can imitate this with a simple constant that is placed at the same address by a linker script. You can #define all the possible values and build the final value the same way as you prepare register fields before writing into a register.

I have not tried this with MISP, but I've done that for ARM. I'm personally not a fan of this, but some people like it.

[mikeselectricstuff]

I've always been a bit puzzled that there isn't more discussion of using a generic MIPS GCC compiler to develop for PIC32.  I mean, gcc was the major MIPS compiler, and in common use, long before PIC32 existed, and the Microchip XC32 for MIPS is just a somewhat customized build of gcc, anyway.  And a generic ARM gcc is "frequently" used for ARM microcontrollers...

Same here. Maybe people are too tied into the Microchip ecosystem (and blinded) to see the compiler as a freestanding tool that can be replaced.

Or maybe people just like the convenience of being able to just install the toolchain with a couple of clicks and be writing code and programming parts  in a few minutes without any dicking around....

[JPortici]

Or maybe people just like the convenience of being able to just install the toolchain with a couple of clicks and be writing code and programming parts  in a few minutes without any dicking around....

And like the parts too much

[Ian.M]

Historically Microchip weren't at all FOSS friendly until they started paying lip service to the concept circa 2010 when MPLAB X was in the pipeline, and prior to that had no official cross-platform support, so I strongly suspect that most of their historic DOS/Windows user base regarded GCC as the domain of Linux neckbeards, best avoided  as a bottomless time sink by sane engineers with the usual project time pressures. 

[woofy]

Or maybe people just like the convenience of being able to just install the toolchain with a couple of clicks and be writing code and programming parts  in a few minutes without any dicking around....

Exactly so.

[nctnico]

I've always been a bit puzzled that there isn't more discussion of using a generic MIPS GCC compiler to develop for PIC32.  I mean, gcc was the major MIPS compiler, and in common use, long before PIC32 existed, and the Microchip XC32 for MIPS is just a somewhat customized build of gcc, anyway.  And a generic ARM gcc is "frequently" used for ARM microcontrollers...

Same here. Maybe people are too tied into the Microchip ecosystem (and blinded) to see the compiler as a freestanding tool that can be replaced.

Or maybe people just like the convenience of being able to just install the toolchain with a couple of clicks and be writing code and programming parts  in a few minutes without any dicking around....

That may offer a quick start but at some point you might not want a crippled compiler, for which a fully working version can be obtained for free, or want to update to a newer version that has features / bug fixes that you need. In the long run having a compiler seperately does have its advantages.

[hans]

Use this along with MIPS GCC (?) :

https://gitlab.com/spicastack/pic32-parts-free/-/tree/master/

The pragma configs are basically a shorthand notation for a bitfield that are written to a specific memory address. The memory structure of binaries for PIC32 is a bit of a mess, since it has a boot memory (with interrupt vector table), program memory, and configuration bits. See the ld script(s):
https://gitlab.com/spicastack/pic32-parts-free/-/blob/master/proc/32MX250F128B/procdefs.ld
https://gitlab.com/spicastack/pic32-parts-free/-/blob/master/ldscripts/elf32pic32mx.ld

The config0-3 are the configuration bits are set by pragma. kseg0 contains your code. kseg1 contains stuff for booting the PIC. The IVT is located at 9D01F200h for the linked PIC32.

In my Cmake script I typically output all forms of build images and outputs you may want to use or look at (.bin .hex .elf .nm .nmsz .lst .lstsrc, etc). The problem with PIC32 is that the program memory spans such a large range of addresses, so dumping to .hex to .bin will fill intermediate regions with zeros, and therefore yield a 0.5 GB bin file (BFC00BFCh-9D000000h = 556MiB). Whoops! Guess will need to disable that for XC32..
There is also a custom elf to hex converter in XC32 (bin2hex executable). All of this memory segmentation makes the PIC32 perhaps a bit more complicated than was absolutely necessary.. I also believe the PICKIT firmware isn't really clever in reprogramming devices. IIRC it always rewrites the whole device memory..., and at 5-10kB/s it takes up to half a minute for a 128K chip. Perhaps because the IVT is at last 4K of FLASH?

But if you use the vendor tools, or are writing a bootloader, then all of this isn't really much of an issue..

The only reason why you perhaps would want to use a custom (cutting edge) GCC, is if (you dare to) use code that is written for the C++17 or C++20 standard. Or you want optimizations without the 'hack'. Otherwise IMO there is really little reason to not use vanilla XC32 builds.

[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.
I have used PIC32's for all sorts of projects over the years.
Cheap enough.
You can still get through hole versions of some too if your SMD shy.

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

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