May 24, 2007

Developing with Microchip PIC for Mac

The Microchip PIC Chip

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.


  1. I am partial to Motorola HC11 and HC12, I use boards from Technological Arts ( ) such as the NanoCore12, pretty affordable. I have scripts that can build the GCC toolchain on OSX [see note], I use these to write HC12 progs in C, works for me. A serial BDM is recommended suuch as the MicroBDM12-SX on the TechArts site.

    Note: gdb isn’t building but I haven’t pursued it, I just use ‘gcc’ ‘ld’ ‘make’ and binutils, and do downloads with ZTerm.

    Email me if you are interested in the GCC/HC12 connection.

  2. G├╝ran Stigler wrote in to mention the following:


    (I tried this out and didn’t care much for the way it worked. Granted I didn’t spend a lot of time with it, but gpasm seemed to do a better job.)

    A Mac editor for Basic Stamp:

  3. Someone has posted an AVR ISP Programmer on AVRfreaks that has a USB interface. He built it so he could use it on his Mac ! He has the postscript files for the PCB layout available for download too.

    Also, here is a beginner’s tutorial to learn assembly on the AVR.

  4. Very interesting, I also would like tools on the Mac so I could do embedded work on the box. I do this for a living (test equipment for telecom) and would like to work using my favorite OS instead of Windows. The next problems you will hit after you find a tool to build the code (as you did with AVR-GCC and GNUPic) are (1) programming the part and (2) debugging the code.

    Almost all the tools for small processor programming/debugging assume a parallel port connection or some funky use of hardware serial ports. There a very few USB or ETHERNET devices out there but they are VERY expensive (why I don’t know). My hope is that as Window’s laptops leave the legacy ports behind that manufacturers will finally build USB hardware for embedded work and then the Mac can compete on equal footing. Also as the Linux folk use these tools we can benefit also.