PIC32 evolution

[asgard20032]

First, I assume the PIC32MX work fine right? I don't remember to read anything bad about the PIC32MX. Also, yeah, I agree that going arm cortex is a better choice because to the ecosystem. So not the time to start to talk about arm, I already embrace the arm idea. But it can happen some project where I am forced to go with PIC because of the other people on the project knowing nothing else, and don't wanna switch.

But well, lets get back on the main topic. I am trying to figure out how the PIC32 evolved, and when it became stable. For example, wikipedia say : "In September 2015, Microchip updated the MIPS core of the PIC32MZ to the MIPS M5150 Warrior M-class processor." When did that happen (which generation of PIC32MZ)? When I go to the microchip website, I see many different generation of PIC32MZ : PIC32MZ....EFE, PIC32MZ....EFK, PIC32MZ....EFF, PIC32MZ....ECG, PIC32MZ....ECM, PIC32MZ....ECE, PIC32MZ....EFH, PIC32MZ....EFM...

In which order  they came, then did they correct X bug? which one is considered the stable one? Is the most stable/bugfree PIC32MZ hold up against PIC32MX?

[JPortici]

Each family has its peculiarities so you should aim to choose the one you need

check the errata and see if that line of chips can work for you or if it's a no-no
check the errata to see if this or that bug is corrected. it doesn't have to have anything to do with age

[Sal Ammoniac]

The PIC32MX has errata, but nothing too significant at this point. It's a mature line.

The MX line came first, followed by the MZ line. The MZ first appeared about two years ago and was a very flawed chip with an errata sheet as long as your arm (no pun intended). Microchip chipped away at these errata and the EF iteration came out about a year ago which not only fixed many of the errata that plagued the earlier EC part, but added functionality such as a floating point unit. The EF still has some significant errata, but at least it's usable in its current form.

At this point I'd say that the MZ parts are not as stable as the MX parts, The MX parts have been around longer and Microchip has had more time to fix the errata.

[hans]

There are only 2 generations of PIC32MZ: EC and EF. Third letter are expansions to include CAN bus and crypto on the top of my head.
I also believe the DA is unofficially announced which will be a chip targeted for high RAM applications or running embedded linux, because it will contain embedded SDRAM.

EC was the first PIC32MZ series, which plagued by errata bugs above average. Now that doesn't necessarily have to be a showstopper, as all micro's will have some errata to varying degree. Some bugs can have decent workarounds or be of no importance at all. I would recommended not assuming the application of errata's across multiple families, heck.. maybe not within a particular family of chips (e.g. different package). I've seen stuff like "Ethernet: on 64-pin devices, pins used with MII cannot be used even when controller is set to RMII mode", which is trap when you think the project turned out to use less GPIO's than assumed and the package is shrunk. Therefore I would always recommended looking up the errata for your specific chip if you are contemplating on using/switching it.

The CPU core in the PIC32MZ is a bit different to PIC32MX, because of the higher clock. Similar to ARM Cortex m7; these CPU's have instruction and data caches to allow these high clock speeds.
Similarly, I believe you can also use an external SQI chip to integrate into memory space and run large images (e.g. Linux) from it. I'm not sure of the penalty hit when you do so, but I imagine it wouldn't be as high because of the caches.

[JPortici]

http://www.microchip.com/design-centers/32-bit

bottom of the page, click on documents tab. you have the datasheets of each family, the errata etc

[mikeselectricstuff]

The new 32MM looks interesting - very low cost, and a different approach to I/O pin mapping :

PIC24F : any peripheral to any RP pin

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

PIC32MM : One of typically 2 instances of a peripheral (UART SPI etc.) has fixed pin mapping, one is mappable to any RP pin. Probably a more flexible approach.

A quick skim of the errata didn't show much of any concern, but it's early days. Pinout, at least of the 28 pin one I looked at today,  is reasonably compatible with the 32MX1xx, so you can design in a 32MX1xx as a fallback, if you don't need all peripherals and all pins.
 It's a while since I read the data, but ISTR reading they'd included an interrupt shadow register bank, which was an annoying omisison on the 32MX1xx as it increased interrupt latency significantly. 

[Sal Ammoniac]

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

The PIC32MX5XX/6XX/7XX series do not support Peripheral Pin Select.

[mikeselectricstuff]

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

The PIC32MX5XX/6XX/7XX series do not support Peripheral Pin Select.

Sorry I was referring to the 32MX1xx/2xx which are the only ones I know.

[hans]

The PIC32MX3x0 and PIC32MX4x0 where x is an uneven number (e.g. PIC32MX470F512H) also contain PPS. They also contain a 120MHz MIPS CPU on 0-70C, which is faster than the PIC32MX5xx, 6xx and 7xx series. Unfortunately though, these MCU's do not contain any ethernet MAC which 5xx and up series do.

I believe these series micro's were released before PIC32MZ, maybe Microchip had plans to also "upgrade" the higher tiers of PIC32MX, but I am just completely speculating here.

[andersm]

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

[mikeselectricstuff]

I've got a very basic and related question coming from someone who has never used a PIC32 and very rarely uses older PICs.

From a "let's play with this technology just because it is different in nicer ways than something else" standpoint,
* Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size?  Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32?  I'm aware they may not be exactly code / function compatible, but a UART is a UART, a timer is a timer, I2C is I2C, etc.  So unless some of the old PICs have something that is wonderfully BETTER than the PIC32 I might as well not do much more personally with the old parts.

There are still reasons to use 8 & 16 bit parts. Small size, 5V operation, lowest power ( active and sleep),  simplicity and wider availability in DIP ( 40 pin in particular - 16/32 bit parts only have 28 pin in DIP).
Also depends what you mean by "invest". The programmers and IDE are the same and there is a lot of commmonality in the peripherals, so moving between parts is much easier than most other manufacturers.
If you can use PIC32, the others are pretty trivial to get running with.
[/quote]
* Similarly other than the obviously more capable 32 bit MIPS CPU core with modern capabilities what are the great reasons to care about PIC32 when the world is a sea of ARM CORTEX-M4F/M4/M3/M0+ parts with all kinds of CPU capabilities and peripherals.  Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?  Not higher speed.  I assume not lower power.  I assume not lower cost.  So.... what's compelling if not cost and code / tool / architecture familiarity & compatibility reasons?
[/quote]
The core just doesn't matter. It's all about the peripherals.

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?  I've always recalled that PIC had "special" tools (SW, programmer) that weren't compatible with basically anything else.

The free compilers for PIC24 and PIC32 with -o1 optimisation are perfectly useable and unless you're really trying to squeeze  size or speed to the absolute maximum I don't think you'd need to buy the paid-for version.
The free version of XC8 is pretty sucky in terms of size and speed, but still useable on all but the tiniest parts.
PICkit3 is a cheap and reliable programmer/debugger for all devices, and there are plenty of cheap clones out there which IME work just fine. An advantage of using this is that new parts are guaranteed to be supported as soon as they are available.

Seems like I've even heard that the new PIC toolchain/environment might be widely hated ()

This is probably the Harmony stuff - this is not the IDE but a framework of libraries for higher level stuff like USB, Ethernet, Graphics, filesystem etc. I've not used it so can't comment, but it's been around a while now so may well be better than it was when it was initially released. You don't need to use it unless you want to use this functionality. If you _just_ want USB, or graphics, or SD filesystem, there is still the old "library for applications" which are more standalone and supplied with full source code, but messier if you want to use more than one library.

I only recently started with MPLABX when I needed to use a new 32MZ part, & it seems perfectly OK - ISTR it had a lot of issues early on.  I still use MPLAB 8.91 for older stuff just because I'm more familiar with it - the only issue is that you need to switch drivers for programmers, but they provide a utility to do this fairly painlessly.
 

[jesuscf]

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

Microchip charges a lot for the optimizing compiler for PIC32s (XC32) which is a derivative work from the MIPS port of GCC.   Lots of people, which whom I agree, had questioned the morality of such charges.  Granted, Microchip releases XC32's source code for each version, most  probably to comply with the GCC's license.  Unfortunately, Microchip doesn't release the information with the required options/settings to build the compiler successfully.  Nevertheless, several people had managed to build XC32 from sources, at least to the point of re-enabling optimizations.  The optimizing compiler, in particular option -mips16, makes a huge difference in code size.

[westfw]

So why do you even need the microchip compiler?  Isn't there a vanilla gcc that supports MIPS that should work fine when combined with the includes and linker maps and such from the microchip free version?

[SteveyG]

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

Microchip charges a lot for the optimizing compiler for PIC32s (XC32) which is a derivative work from the MIPS port of GCC.   Lots of people, which whom I agree, had questioned the morality of such charges.  Granted, Microchip releases XC32's source code for each version, most  probably to comply with the GCC's license.  Unfortunately, Microchip doesn't release the information with the required options/settings to build the compiler successfully.  Nevertheless, several people had managed to build XC32 from sources, at least to the point of re-enabling optimizations.  The optimizing compiler, in particular option -mips16, makes a huge difference in code size.

It might depend on your usage, but I've had no issues getting free licences from our FAE.

Responding to a question earlier on, PIC24/dsPIC33's are a good compromise between performance and complexity if you're only doing hobby stuff. The learning curve is a little steep on the PIC32s purely because configuration of the devices can be a little complex and the example code is extremely minimal.

I still regularly use devices from all the families though - they all have their place. The price point of the PIC10/12/16's is attractive if you're making something which needs lots of them and you can design some pretty complex stuff on these devices. There does seem to be a trend to be lazy and use powerful MCUs for the simplest tasks. 

[dannyf]

 'Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size? '

I still use a lot if low end oics because I have an inventory of then, mostly 12f675, 16f684, and 16f886.

Given the choices out there now, it makes no sense to start on the pic.

' Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32'

Generally no. There is a high degree of similarity between peripherals for the pic24 and pic32 but the low end pics are simply weird.

[dannyf]

'Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?'

To me, the answer is none, other than learning. I tend tobthink the pic32 is on borrowed time, and investing in it is a mistake.

[dannyf]

'What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days? '

My main environment for pic24 is  emblocks plus c30, the prior version of xc16. Extremely happy with that setup.

Sometimes I use mplab but hate its 1980s interface. Not a fan of mplab x.

Not yet supporting puc24 and pic32, mplab xpress is pretty good as well.

[dannyf]

'Lots of people, which whom I agree, had questioned the morality of such charges. '

What's morally questionable to charge for ones labor? I hope none of the people above are working for free.

Philosophically, I think it is morally questionable for people to project their morality onto others.

[dannyf]

You didn't ask this but the recent versions of xc8 compiler do a very good job.

I did extensive benchmarking between the free xc8 (1.12 and later) vs. Picc 9,63 STD and pro. The picc is the last non OCG compiler.

The xc8 in free mode is about somewhere between the STD and pro. So people can whine about it, but end of the day it is as good as a paid commercial grade compiler.

[andersm]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

[mikeselectricstuff]

You didn't ask this but the recent versions of xc8 compiler do a very good job.

I did extensive benchmarking between the free xc8 (1.12 and later) vs. Picc 9,63 STD and pro. The picc is the last non OCG compiler.

The xc8 in free mode is about somewhere between the STD and pro. So people can whine about it, but end of the day it is as good as a paid commercial grade compiler.

Not looked recently as I have the full version, but could be one of those things that sucked badly at first ( and it really did), and nobody has noticed any improvements tat have happenned since.

[SteveyG]

'Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?'

To me, the answer is none, other than learning. I tend tobthink the pic32 is on borrowed time, and investing in it is a mistake.

Not a mistake if you ever end up working with them commercially. Microchip's stock control and silicon availability is a huge advantage over just about everyone else and is often enough to sway clients who need long term availability and bonded stock.

[SteveyG]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

I agree with Mike, the core rarely makes any difference. Choice comes down to availability, supply chain and peripherals.

[Howardlong]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

I agree with Mike, the core rarely makes any difference. Choice comes down to availability, supply chain and peripherals.

I'd agree with that too. Strongly biasing your decision to use ARM rather than MIPS because ARM has a significantly larger number of vendors doesn't hold a lot of water. If you think there's much portability between ARMs from different vendors you're in for a rude awakening, the way vendors differentiate themselves is by what value they add on to the part, and that should usually be the primary decision maker, far more so than whether it's MIPS or ARM.

However, if you are looking to use an MZ part, you may well be wanting to use one of the complex peripherals like Eth, USB etc., which pretty much forces you into using Harmony, which is a software framework (aka straitjacket) that demands a very significant amount of effort to become proficient enough to write production code, is not very efficient, and is proprietary to Microchip's PIC32 family only. It also pretty much forces you to use MHC, a code generator that generates buggy code, is very difficult to maintain (yes, you have to edit code that it generates), and breaks its own generated code between releases. Other than that it's great 

The lower end PIC32MX1xx and MX2xx are pretty useful, I've used them a lot, and they're available in DIP if you like prototyping on solderless breadboard.

[hans]

My take on this:

I've got a very basic and related question coming from someone who has never used a PIC32 and very rarely uses older PICs.

From a "let's play with this technology just because it is different in nicer ways than something else" standpoint,
* Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size?  Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32?  I'm aware they may not be exactly code / function compatible, but a UART is a UART, a timer is a timer, I2C is I2C, etc.  So unless some of the old PICs have something that is wonderfully BETTER than the PIC32 I might as well not do much more personally with the old parts.

For hobby I wouldn't consider them. 8-bit PIC core is still usable for a push-a-button-and-then-light-this-LED kind of boards, because PIC12s are in 8-pin packages and those programs may end up with a few hundred lines of code. However at the 14 or 20-pin package size I will grab a PIC24F32KA301 (DIP) or even a 32-bit chip because laziness. Also, more MHz, more memory, more I/O, less frustration about platform limits, better debugging features, etc. The 3 euro I spent extra in the chip, I save in the hours coding and debugging the project.

In terms of peripherals; PIC32MX and PIC24 share very similar peripherals. PIC24 XLP chips are better suitable for low power designs, PIC32 power consumption is fairly high, dsPIC also quite high.

There is some caveats to be expected from a 32-bit architecture, like interrupt latency because of software stack, and for example non-atomic I/O operations.
However, compared to 8-bit PICs the higher clock usually greatly offset the remedies for these problems, so I would expect a 8-bit PIC to be beaten in almost any case by a PIC24 or PIC32.

* Similarly other than the obviously more capable 32 bit MIPS CPU core with modern capabilities what are the great reasons to care about PIC32 when the world is a sea of ARM CORTEX-M4F/M4/M3/M0+ parts with all kinds of CPU capabilities and peripherals.  Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?  Not higher speed.  I assume not lower power.  I assume not lower cost.  So.... what's compelling if not cost and code / tool / architecture familiarity & compatibility reasons?

I can't say too much abuot the 32-bit MIPS core. It's a CPU, and it runs code. I write my programs in C, so all I get to see is registers of peripherals, and the platform specific definitions for interrupts and the like.

The peripherals on PIC32MX are wonderfully simple and straight forward to program. Most ARM Cortex chips are beasts with half a dozens of registers to set up clocks and peripheral power. Although programmatically all of these operations are simple to program, the amount and depth raises the complexity in using these chips. This is usually only a problem if you tend to write a lot of driver code. After that; a UART is a UART from the code's perspective, and advantages or disadvantages start to disappear.

I don't have much experience with Microchip's vendor-supplied driver/code library Harmony, but I heard it's unbelievably bloated and a can of worms.
I think I tried it like 2 years ago and I didn't like it.

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?  I've always recalled that PIC had "special" tools (SW, programmer) that weren't compatible with basically anything else.  Seems like I've even heard that the new PIC toolchain/environment might be widely hated () and a good version of it isn't necessarily even free now?  What's the story as to what I should look for to program and develop for PIC32 or PIC24 today if I had low cost and ease (and preferably works under LINUX not MS Windows) as my desiderata?
I don't necessarily want to get "expensive" dev boards just to get a free built in programmer/debugger but if like ARM boards there's lots of good $15 or less MCU + integrated debugger boards for PIC32 / PIC24 I'd consider it.  If so, I haven't seen them, though.

I think people are quite harsh on it. Here's my view on it:

- IDE: MPLAB X. Free. Native builds for Windows, Mac and Linux. Just run the installer and it installs on any modern Ubuntu or derived system. I haven't had any troubles with Java JDK's or whatever, those must be distro specific issues. I am fairly happy with MPLABX , except it's maybe a bit buggy compared to programs like Visual Studio.
- Compiler: XC8 / XC16 / XC32. Free versions, but also paid ones. Native builds for Win/Mac/Lin. Just install and integrates seamlessly into MPLAB X.
Another reason why I don't recommended 8-bit PICs is XC8. The paid optimizations are desperately needed on this already slow platform. The compiler lacks in many modern C features, like C99, and overall the only reason I keep this is installed is for one of those PIC12F609 projects.
XC16 and XC32 are modified versions of GCC. The free version allows optimizations up to level 1. This is sufficient for almost all projects. Well, ideally you may want to use O2 for release, but usually the gains are only a few % code size/speed. Only in very specific use cases you may want to use optimize for size or speed, like lots of code or ultra low-power respectively. Note that the gains are once again only a few % compared to -O1.

- Hardware: PICKIT3. Not free, but quite affordable considering it can program almost every PIC out there. I think it's reasonable to get started with this, but take note that any programmer/debugger on ARM evaluation boards (like Silabs with JLINK onboard, ST discovery with STLink, etc. etc) will beat the crap out of a PICKIT3. PICKIT3 takes like 5-10 seconds to start a debug session, code stepping is slow, sometimes downright buggy (EEVblog did a rant about it half a year ago or something), etc. This for me is personally becoming more and more of a dealbreaker though, considering that I only use 16-bit and 32-bit PICs; both of which are increasingly less interesting considering so many ARM chips these days.

However, I must admit Microchip's toolchain is turnkey across 3 platforms. Only a few ARM vendors can match or beat this. The only one which I had good experiences with on Linux is SiLabs. Most other vendors will recommended using something like Keil or IAR, which is either limited, very expensive, and above all Windows only.
Alternatively, for ARM you can roll your own toolchain in any GCC/GDB compatible IDE, which is ultimately what I did for STM32 on Linux using ARM GCC, GDB and OpenOCD.