-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.
I wouldn't go quite that far. Yes, the CPU is awful compared to AVR, and the almost-requirement to use a proprietary compiler that is focused more on commercial profit than on hobbyist accessibility (it never was GCC-compatible and probably never will be), makes it even worse. But they seem to have a lot more peripherals for the price than AVR, even for the bog-standard stuff. So if I can make the peripherals do all the work and keep the CPU as just a supervisor with only a small amount of less-critical "glue logic", then that makes a PIC the better choice.
But for data-processing kinda stuff, AVR wins by a mile in the 8-bit world! It was wonderful, having learned on PIC, to use an AVR for the first time to make a DMX lighting controller. A little bit of peripheral work just to move data in and out, and TONS of memory and number-crunching. Just to declare a single, 2-dimensional array (scenes x channels) to occupy several kB would be a tall order on a PIC, but the AVR was like, "Yeah, sure! What else ya want?" Not to mention working through all of that data within one refresh cycle.
(PIC's do tend to have higher maximum clock rates, but not *that* much higher. 32MHz/4=8MIPS for PIC, vs 20MHz=20MIPS for AVR. Plus, AVR likes to include a single-cycle multiplier more than PIC does.)
-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.
Good to know that. I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path. (most libraries use a block size of 64 samples or so, but I need single samples) I'm guessing that's not it.
-all parts had frequent read/modify/write problems
Never had a problem with that myself. Maybe because I learned on them and treated that oddity and its workaround as "normal"? I'm not even sure what it is.
-silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.
That's good! I wouldn't put it past them though. Too much marketing pressure to get it out NOW!???
- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.
The official explanation is that all versions initially output the "free" assembly by concatenating prefab entries from a lookup table that each have enough wrapper code around them to guarantee that they all work in every context as-is, and then the paid versions go back and clean that mess up according to how much you paid for it. In that sense, it's not artificially stuffing the output with dummy instructions, but yeah, the completely uncleaned code that you get from the free version is pretty bad.
But the chip does end up doing what the source tells it to do. In that sense, it's a "good" compiler, but ONLY in that sense.