May 24, 2007
Developing with Microchip PIC for Mac
For the past six months or so, I’ve been learning the ins and outs of the PIC. It’s a small microprocessor that runs at 4 MIPS. One of the setbacks I’ve had to deal with is the lack of development tools for Mac OS X.
There are many packages for PC, some of them free, many of them commercial. The commercial variety can cost anywhere from $100 – $5000 dollars, depending on how gullible you are. I used the free and trial versions of MPLAB, the IDE that Microchip distributes, in conjunction with HiTech’s PICC Lite.
I began by installing the software that came with my PicKit into Virtual PC and working with the IDE there. As anyone who has actually tried using Virtual PC for any serious work will tell you, it’s very frustrating. I had to jump through a bunch of hoops and set up a few hacks to let me even compile what I needed. Then I would transfer the binary to Mac OS X and use usb_pickit to get the binary into the hardware. It was a slow, tedious process but it worked — which is important.
The second thing I tried was assembly. GNUPic has a package that contains an assembler, disassembler, profiler, and an interesting high-level language called gpal. Unfortunately, various parts of this collection only work with certain PIC models. I learned the asm codes from the datasheet (it wasn’t too hard) and proceeded to write code. I soon learned that complex math should not be attempted in asm. Flow-control was easy enough but beyond simple addition and subtraction, anything like sin(1.5) / 5.3 + 9^3 is heavily obfuscated. Yet this too worked.
GPAL, it seems, is not ready for prime-time. There is very little example code and sparse documentation. If I have some time though, I’ll plow on and see if I can figure things out and perhaps build a repository of code that others can use.
The things that didn’t work? Take a look. Half of these links are dead or broken and the other half lead to incomplete projects. SDCC looks to be the most promising. This isn’t saying much, and I only think that it’s being updated semi-regularly.
Lessons learned? Try Atmel and AVR-GCC. Also, some serious thought should be given to the idea that ANSI C probably isn’t the best language from which to compile code for a MCU that can’t do recursion or even floating-point arithmetic.