My Experience with PIC

About 15 years ago a friend gave be a pile of PIC datasheets. I looked into them, read a few bits and decided PICs are not for me. Not much later another friend bought an AVR development kit and gave it to me to find out how it works. It wasn’t hard to get everything up and running. So I used AVRs since then, and if I need something bigger I take an STM32. But now I have a project which uses PIC18 and I was forced to bite the bullet. So here is my experience with the PIC hardware and software.

IDE and Compiler

Microchip offers a free IDE called MPLAB X IDE which is written in Java to make it able to run on different platform. I downloaded that 540MB file and installed it on Linux. After installing it it tried to ‘download’ more software. Actually it just tried to open an URL in Firefox and failed. Firefox just showed an error message. So the result was an IDE without C compiler.

I then had to search for a C compiler for this IDE and found Microchips XC8. I downloaded this ~100MB file and installed it. After installing the compiler runs only in “demo-mode”, that means without any optimizations. The produced code is inefficient and slow. So I had to organize a license for that compiler. There are 3 options: Full license ($995), subscription license ($29.95/month) and trial license (60 days free).

I also recommend to install MPLAB Harmony Framework (MHC) and MPLAB Configurator (MCC). I forgot what the HarmonyFramework is good for. But the Configurator saved my life. For me it was the only way to get I2C running. It can generate working C code for various peripherals. Though it forces a certain code structure on the program, Arduino-style.

The compiler is outdated compared to other compilers. Its warnings and errors are often misleading and some are plain wrong. For example I used function pointers in const structures and this lead to the follwing warnings for each of the functions:
display.c:600: warning: (1090) variable "display@entry" is not used
display.c:600: warning: (1090) variable "display@init_entry" is not used

These warnings littered the compiler output and made other warnings less visible. So I had to changed the code to use an integer ID instead of a function pointer and use it in a big switch/case statement to call the functions.

I also saw the following warning which sounds suspicious and there is no way to get rid of it:
main.c:260: advisory: (1510) non-reentrant function "_msg_clear" appears in multiple call graphs and has been duplicated by the compiler

While debugging PICKIT3 sometimes loses connection and then the IDE crashes.

After a while the IDE showed me that there is an update. Ofcourse I wanted that update installed until I found out that I have to download the whole 540MB file again. Obviously they haven’t heard of patches or incremental updates…

PICKIT3 Programmer

Programming using PICKIT3 is very very slow. For my PIC18 it takes 18 seconds to program no matter how big the application is. After power up PICKIT3 often pulls reset low and I have to tell it to do a reset by clicking a button in the IDE. PICKIT3 sometimes hangs and then its reset button has to be pressed to get going again. All in all it makes an unreliable impression. I expect programmers to just work, even the cheapest chinese AVR programmers do not need a reset button.

Dave is also not happy with PICKIT3.

The PIC18 Hardware

Many things are pretty easy to use and work out of the box. Where I had big problems is the I2C hardware, I wasn’t able to get it running. The I2C hardware interface is very complicated and the documentation is lacking and confusing. After wasting a day I tried the code generator and got some working code, but it also seems to not be 100% reliable. As a comparision I got the AVR I2C hardware running in about 2 hours including debugging a chip which didn’t want to send back any ACKs. The PIC I2C hardware seems to also have a bug since after programming the PIC I have to to a power cycle to get I2C running again.

The PIC core is pretty slow, it needs 4 clock cycles per instruction, sounds like some other very very old CPUs nobody uses anymore. But when enabling the integrated PLL it runs at 64MHz which compensates for that. Another thing is that it doesn’t have a stack, it only has a call stack which is hidden and more or less inaccessible. The advantage is that code can’t accidently overwrite the stack (though it will probably overwrite something else). The disadvantage is that writing compilers for it is more difficult. And that is probably the reason that there is no GCC port for PIC.


The IDE is funny, the compiler is lacking and hopeless overpriced, the programmer is slow and unreliable, the hardware also has its problems and the documentation is often confusing and incomplete. All in all I can just say: Stay away from PIC, there are many better options.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>