I enabled Google Analytics on this site a little over a month ago to try and get a feel for what pages people were reading and which (if any) other pages that led them to. I've now got enough data collected to get a reasonable overview and some of the results surprised me. It seems a lot of people are coming here to read my PIC related posts even though I haven't published a new one for over a year.

I've migrated away from using the PIC over that period and (judging by what shows up on the web) a lot of other people have as well. This led me to wonder why people have moved on from the chip - I figured the best way to find out was to examine the reasons I don't use it that much anymore (it certainly wasn't a planned migration in my case, it just sort of happened over time).

This post examines those reasons and I've done some investigation into how things have changed since then (I also have another years worth of experience with other processors under my belt so I might view things a bit differently now). It is by no means meant to be an 'architecture XYZ is better because ...' argument so please don't take it as such.

Some Context

When I first started using the PIC (well before I started this blog) the general purpose go to device from the PIC family was the PIC 16F84A which was a pretty basic chip - no ADC's, no UART, very limited RAM and only a small amount of flash. This was superseded by the PIC 16F628A which added a lot more internal peripherals (still no ADC but at least you got a couple of comparators).

I'm coming from the hobby perspective so I'm going to limit my comparisons to devices in this family with similar specs - general purpose rather than task oriented, 18 pin DIP format and readily available in small orders.

Things are a bit different in a commercial environment - Microchip have a wide range of chips available with various built in functions to support specific tasks (the company I work for uses the PIC family in almost all of their products and it is very cost effective to pick a chip specifically suited to your requirements). Your average hobbyist is not going to want to learn and use a different chip for each project though, they want a drawer full of the same device that will cover a wide range of applications.

Looking through the Microchip web site it seems that the devices available now that fall into that category are shown in the table below. I also did a quick Google search on each of the part numbers to see if they were being used by hobbyists - they are.

Model |Flash|RAM|Clk (Int)|Clk (Max)|Price -------|-----|---|---------|---------|-------- 16F628A|2K |224|4 MHz |20 MHz |$AU 2.81 16F648A|4K |256|4 MHz |20 MHz |$AU 3.19 16F88 |4K |368|4 MHz |20 MHz |$AU 4.21 16F1827|8K |384|32 MHz |32 MHz |$AU 2.70

The price figure was pulled from the Australia Mouser site (not the cheapest option I know, but I wanted to get price comparisons from a single source). The ATMega8 and ATMega168 (some commonly used alternatives) are $AU 3.02 and $AU 3.43 respectively from the same source. With the exception of the 16F88 the pricing is pretty close so that (and availability) should not have a big impact on deciding whether to use the PIC or not.

Bootloaders

For me, the availability of a serial bootloader on the ATMega family (the normal Arduino bootloader and it's compatible cousins) was a big benefit. Reprogramming the flash on a PIC chip was generally a frustrating exercise - remove the chip from the circuit, plug it into the programmer, load the new code on and reinsert the chip. It is possible to build an ICSP interface into your circuit but you had to take care that the rest of your circuit wasn't interfering with it - with a serial bootloader all you need to do is make sure that the TX and RX pins from the UART were available.

The availability of a boot loader that you could use through a simple FTDI cable meant a much better turn around time when developing and testing the firmware to go on the chip - when your time is limited this is a massively important feature. Of the four chips I listed above only two (the 16F88 and 16F1827) even support rewriting their own flash and can have a bootloader, the others require all reprogramming to be done through the ICSP interface.

The development of the Arduino created a sort of de-facto bootloader standard for the AVR family - something that never really coalesced around the PIC. There are bootloaders available (like this one) but no real single standard that is supported across platforms and IDE's.

NXP have taken this to the next step - their LPC series of ARM Cortex M0 processors have a serial bootloader built into the ROM on the chips so you don't need a special programmer at all - a simple FTDI cable will do the trick.

Internal Peripherals

For a long time the PIC processors (the 16F84 and 16F628) had a very limited set of special functions built in. There was no ADC, support for communications protocols like SPI and I2C was limited if it existed at all. Some of this was addressed with the 16F628 but compared to the AVR it still seemed limited.

The downside of course was that the ATmega required a 28 pin package to make all the multi-function pins available while the PIC had a smaller 18 pin footprint resulting in more compact and efficient PCB layouts. In my case at least the flexibility trumped the layout problems - even if I didn't use half of the peripherals it was easy to stick with a single chip that could be used in a range of projects rather than have to find workarounds for the lack of peripherals.

The LPC series of chips have another solution - the pin matrix. This allows you to map almost any internal peripheral pin to any external pin giving you a full range of peripherals while still keeping the pin count down - the LPC810 ($AU 1.61) comes in an 8 pin package while the LPC1114 ($AU 3.44) comes in a 28 pin package like the ATmega.

Development Tools

The main development environment for the PIC was Microchips own MPLAB IDE which was only available for Windows, this has since been replaced with MPLAB/X which is based on the open source NetBeans IDE from Oracle. This at least makes it cross platform (not a big deal for a lot of people but I tend to use OS/X or Linux rather than Windows so it was an annoyance for me).

In terms of open source support for PIC there is the gputils (this provides an assembler, a linker and a librarian). For an alternative C compiler there is the Small Device C Compiler (SDCC) project which supports a range of 8 bit CPU's including the PIC family.

For both the AVR and LPC processors the compilers are based on the widely used (and well documented) GCC compiler suite (including support for C++). The Arduino IDE and the LPCXpresso environments are simply wrappers around the underlying GCC compiler - you are free to use your own editor and a set of makefiles to build your project.

I tended to use raw assembly for most of my PIC projects so I don't have a lot of experience with the C compiler on that platform. The few times I did use it I found it a bit limiting - I had to revert to assembly enough times to negate the benefit of using a high level language.

The register bank memory model used by the PIC was another common source of frustration. Coming from a background that included the 8080, Z80 and 6809 series of chips it was a bit odd to encounter - it took me a while to get used to it. It certainly doesn't lend itself to large or complex data structures and added a lot of friction to the development process if you had to change your memory layout part way through the design.

Community Support

There was a large and active community of people using the PIC (and still is if my site activity is anything to go by) but there was a lack of coherency and limited availability of compatible libraries - there is nothing like Wiring (and the large number of extension libraries) for the PIC. There is plenty of sample source available but getting things working together could be a challenge (it was a lot of fun as well). This could be a great learning experience but it wasn't really conducive to achieving the goal of a completed project.

Part of this, I think, is due to the memory limitations of the PIC (both program memory and RAM). There really wasn't enough space that you could waste some of it on parts of a library that you may not use. The ATmega8 was fairly limited in that arena as well but had just enough wriggle room for it not to matter a great deal.

The LPC chips are relatively new and don't really have a large community around them yet but NXP seem to have pre-empted this by including a simple support library in the on-chip ROM allowing all users to perform common operations in a consistent way. It has the additional benefit of not using up valuable flash memory as well.

Conclusion

It seems like I've been neglecting the PIC family for too long. The 18 pin devices fill the gap between the 8 pin processors (ATtiny and LPC810) and 28 pin processors (ATmega and LPC1114) that have been my choices over the past year. Both the 16F88 and 16F1827 support the use of bootloaders and there is already source available that I can use or modify. I will probably tend to use them as peripheral chips, using them as I2C or SPI slaves to replace something like the MCP23008. I can easily see a PIC controlling a HD44780 LCD and exporting a simple memory mapped interface to it over I2C and avoiding the complexity of controlling individual pins through a plain IO expander. I still don't see myself using them as the main processor for a project though (unless it is a very simple project). The combination of GCC and extra RAM still makes the alternatives more attractive (to me at least).

So if you've come to this site looking for PIC projects in the past, stick around - you might be pleasantly surprised in the future. I've ordered some 16F88 and 16F1827 parts to play around with and I'm looking forward to doing some projects with them.