Help! I want my PORT PINS BACK!

[Howardlong]

jnz. I see where you are coming from... Purely from a hobbyist perspective, the PIC24  families, more than fit my purpose, May seem strange but I don't use libraries , but build my own drivers relying on code examples and the www . I have found MPLABX and PICkit 3 ( all be it sometimes frustrating ) all that i need.  buying one or two devices cost is not a factor ,  I have followed the mcu wars posted here , but not seen any reason  to experiment with other devices, I did start my controller story with a diy board with a  RCA1702 back in the 1970's       

One of the joys and frustrations as you go across the vast range of PICs is the array of peripherlas. Joy in that there are similarities, frustration in that, even between devices in the same family, they are not the same. Things like I2C and SPI implementations differ markedly, with some devices going the dedicated peripheral route and others using the more generic MSSP route. UARTS and PWMs too, I've lost count of the number of implementations.

Largely because of this, the provision of peripheral libraries can be patchy across the full device range to say the least.

Apart from complex peripherals like USB and Ethernet, irrespective of whether or not there's a PLIB for a given device's peripheral, almost certainly you'll need to get out the device's and peripheral's datasheets plus the errata and have at least some understanding of the device at the register and hardware implementation level. While the PLIB provides maintainability from a readability standpoint, it doesn't allow you carte blanche to drop your code onto another device without some prior investigation.

I tend to agree regarding having your own "utility belt" of code ready to cut and paste though. All too often when there is a PLIB formyour device's peripheral, it doesn't quite do what you want it to without coercing it which in itself makes it nasty.

I don't think there's a right or wrong answer as to whether to use the PLIBs, at the end of the day if they can't support the peripheral you're going to have to do it your own way anyway. The downside is that you need to spend time documenting more closely what you're doing to avoid too much unnecessary cross referencing with datasheets when it comes to maintainance.

My own journey in micros started with the General Instrument LP8000 in the mid 70s. That was the precursor to CP1600 which I also used which coincidentally spawned the PIC in the first place. I'm sure like you I've lost count of the different devices I've dealt with in the meantime!

[andersm]

I wonder why the 16bit PIC’s do not seem to be in favour.

I think 16-bit MCUs in general are a dying breed. In my opinion, if you've outgrown an 8-bitter you've simultaneously outgrown the 16-bitters too. Unless there's some specific feature you need, you'll just end up paying more for less. You'll also have to deal with the architectural kludges used to extend the address space, that invariably break C in some way.

In the olden days, when every transistor counted, 16-bitters were a reasonable compromise between performance (esp. compared to the 8-bitters of the day) and cost. These days, they don't really serve a purpose.

[BloodyCactus]

I'll add that the pic32mx 170 variant in soic/dip is a sweet sweet chip!