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.