PIC Versus AVR
As a general purpose microcontroller board I was always a bit disappointed with the Arduino. When in Arduino appeared in 2005 the 8bit AVRs were already pretty old school microcontrollers and cheap 32bit microcontrollers were already available. These days when you can pick up a cheap STM32 for under a dollar it seems kind fo crazy to use 8bit mid-90s technology…
The reason we do of course is because the Arduino has great support and a large active community.
For a recent project I wanted a small microcontroller. All it had to do was send a few very simple serial commands. For this, I really didn’t need anything more than an 8bit microcontroller, which for me comes down to PIC versus AVR.
I cut my teeth on PICs in the 90s using MPLAB under windows 3.11. PICs have a kind of nasty architecture. They’re Harvard architecture. Which means code and data sit in separate memory spaces, and that takes a little getting used to.
One of the nice things about PICs is that very have very very low power, cheap versions. The PIC12F629 has ~2KB of flash and 64 bytes of RAM. It’s about 1USD on digikey and about 10 cents on taobao. It also looks like there might be cheaper clones down to about 1 cent.
So I went with the PIC12F629 and it was a nightmare. Firstly, I thought I’d try using a C compiler, inefficient for sure but hopefully quicker than writing assembler. So I installed the debian package sdcc, which is the only compiler I know that supports PICs on Linux.
Debian sdcc doesn’t have PIC support.
sdcc uses the microchip header files which have a non-free license. It look me a while to figure this out but I then downloaded sdcc for their sourceforge site.
It’s a sourceforge site. I should probably have stopped right there. Binaries are available, but they are 32bit only. I checked out the source from their svn.
./configure;make;make install
Looks good. Could at least start to compile code, lots of issues. Size issues due to 32bit in library requirements (removed 32bit ints) etc. etc. Finally code looks like it should fit in the flash, but it’s failing to link with libsdcc.
Building sdcc doesn’t build libsdcc. Googling… digging around in random directories, and try and configure;make it. Fails. Missing instructions in the floating point library. Hack the floating point library until it builds…
Finally get a binary from sdcc.
I’m using a minipro to flash the controller. Fails.. the hex file is the wrong size.
The hex file contains a single word way off the end of the flash memory. This was actually the configuration bit, but the Linux minipro software doesn’t know how to flash this correctly. However with this removed the devices would flash and verify.
PIC does nothing when powered. Can’t even get an LED to blink.
I try reference hex files which should just blink LEDs… they don’t work.
I figure maybe the Linux minipro client doesn’t work well. So I try the Windows client. Many people have reported successes with minipro and the PIC (including the PIC12F629) so it should be an issue.
Fails.
Spend hours fiddling with config bits. Decoupling.. Power supplies..
Fails.
Give up, and buy a Digispark with a ATTINY85. Works within 5 minutes.
I’d literally spent hours with the PIC. I’m guess one possibility is that I’d overwritten the OSCVAL config in the PICs (which stores internal oscillator calibration) and the PIC was hosed because of this. But the conclusion is basically the same.
The AVR has a clean, open toolchain and a larger community, it’s just easier to get things done. At some point I’ll likely migrate my code to the ATTINY10 which are about the same price as the cheapest PICs (
RSS