Carson Baker

For the past six months or so, I’ve been learn­ing the ins and outs of the PIC. It’s a small micro­proces­sor that runs at 4 MIPS. One of the set­backs I’ve had to deal with is the lack of devel­op­ment tools for Mac OS X.

There are many pack­ages for PC, some of them free, many of them com­mer­cial. The com­mer­cial vari­ety can cost any­where from $100 - $5000 dol­lars, depend­ing on how gullible you are. I used the free and trial ver­sions of MPLAB, the IDE that Microchip dis­trib­utes, in con­junc­tion with HiTech’s PICC Lite.

I began by installing the soft­ware that came with my PicKit into Vir­tual PC and work­ing with the IDE there. As anyone who has actu­ally tried using Vir­tual PC for any seri­ous work will tell you, it’s very frus­trat­ing. I had to jump through a bunch of hoops and set up a few hacks to let me even com­pile what I needed. Then I would trans­fer the binary to Mac OS X and use usb_​pickit to get the binary into the hard­ware. It was a slow, tedious process but it worked—which is important.

The second thing I tried was assem­bly. GNUPic has a pack­age that con­tains an assem­bler, dis­as­sem­bler, pro­filer, and an inter­est­ing high-​level lan­guage called gpal. Unfor­tu­nately, var­i­ous parts of this col­lec­tion only work with cer­tain PIC models. I learned the asm codes from the datasheet (it wasn’t too hard) and pro­ceeded to write code. I soon learned that com­plex math should not be attempted in asm. Flow-​control was easy enough but beyond simple addi­tion and sub­trac­tion, any­thing like sin(1.5) / 5.3 + 9^3 is heav­ily obfus­cated. Yet this too worked.

GPAL, it seems, is not ready for prime-​time. There is very little exam­ple code and sparse doc­u­men­ta­tion. If I have some time though, I’ll plow on and see if I can figure things out and per­haps build a repos­i­tory 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 incom­plete projects. SDCC looks to be the most promis­ing. 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 seri­ous thought should be given to the idea that ANSI C prob­a­bly isn’t the best lan­guage from which to com­pile code for a MCU that can’t do recur­sion or even floating-​point arithmetic.

Perhaps this is obvi­ous to most, but I thought I’d share my trick with C++ enums. Consider:

enum Face {ACE=1, TWO, THREE, ... , QUEEN, KING};

If you want to step through this datatype you can’t just do:

Face f; f++;

No, you must do some kind of con­di­tional check­ing or integer-to-enum cast­ing which becomes unsightly and dif­fi­cult. Instead, simply over­load the ++ oper­a­tor for the enum type:

Face operator++(Face& f, int) { // int denotes postfix++
    if (f == KING) return f = ACE; //rollover
    int temp = f;
    return f = static_cast<face> (++temp);
}

Now f++ works prop­erly and you can enu­mer­ate away.