I occasionally use GeSHi on this site (via the GeSHi Filter Drupal module) to add syntax highlighting to code snippets, but usually not PIC assembler. Even though it lists MPASM among its supported formats, GeSHi highlighting has always been uneven and incomplete, at least when applied to my PIC18F242-based code. For example:
;; ---------------------------------------------- ;; void restart() ;; ;; Reset the countdown period for the millisecond timer. ;; restart: ; Set up the basic timer operation. movlw b'00001000' ; 0------- TMR0ON ; turn off timer ; -0------ T08BIT ; use 16-bit counter ; --0----- T0CS ; use internal instruction clock ; ---X---- TOSE ; [not used with internal instruction clock] ; ----1--- PSA ; do not prescale timer output ; -----XXX T0PSx ; [not used when prescaler inactive] movwf T0CON ; Establish the countdown based on calculated MIPS. movlw kTickDelay >> 8 movwf TMR0H movlw kTickDelay & 0xff movwf TMR0L ; Clear the timer interrupt flag. bcf INTCON, TMR0IF btfsc INTCON, TMR0IF ; is the flag clear now? bra $-2 ; no, wait for it to change ; Unmask the timer interrupt and turn on the countdown timer. bsf INTCON, TMR0IE bsf T0CON, TMR0ON return
Now that I’ve switched to GPUTILS from MPLAB, makefiles have re-entered my life. I’ve always hated writing them, the last time being five or six years ago for BREW projects, an atavism not unlike my recent return to assembler. As I sat down to write three new ones (and they’re about as straightforward as makefiles get), all the unpleasantness came flooding back to me. Forgettable macros, single stems, arcane completion rules—I thought about documenting my innumerable complaints, but found someone had already summarized them perfectly.
Up to now I’ve been controlling my Ifos slaves with a simple Modbus master I wrote in Ruby. In preparation for the move to TINI, though, I thought I’d better investigate Modbus master code actually capable of running there. jamod is the logical first choice, since it’s Java-based and fairly mature. TINI runs Java, and if jamod complies with the Modbus application protocol specification, everything should just work.
My Mac OS X development tool chain for PIC is now complete. I successfully assembled my Ifos project (and by extension, my Modbus and Framework projects) on the Mac using GPUTILS, then programmed it over ICSP using pp and a K150 programmer. This was not a painless process.
For the projects I work on these days, switching to a Mac OS X-based development environment has been mostly painless. Eagle works, Java and Ruby are essentially cross-platform, and there’s always Unix just under the covers. It’s the hardware tools that have been difficult to migrate, mostly related to PIC assembly and programming.
On the PC, I’ve been using MPLAB for PIC code development and simulation, but that program isn’t available on the Macintosh. Luckily, GPUTILS is a stellar alternative that runs on Mac OS X. I ran into only a couple of issues in switching over.
As I suspected, the in-circuit serial programming problem I was having with the new Ifos prototypes was due to a lack of isolation between the ICSP interface and the rest of the Ifos circuit. Not sure how the breadboard prototypes work in spite of this, but the circuit-board-based versions are definitely affected. Here's the original circuit:

I just started building the second Ifos prototype from scratch, and already I've discovered an issue that problably contributed to the DOA-ness of assembly attempt #1. It turns out the land pattern for the voltage regulator's heatsink doesn't quite match the heatsink I'm actually using. When installed, the heatsink just barely clears the solder pads, and the mounting nut allows enough play that the pads may actually be shorted together.
After assembling the first Ifos prototype based on the new circuit board design, I crossed my fingers and applied power.
My PIC programmer has a 6-pin ICSP header that I've been using to program the breadboard prototypes of my Ifos controller. Each prototype has a matching header and I simply connect it to the programmer with a straight-through ribbon cable. For the "real" version (or at least the real prototype version), I decided an RJ25 jack would be more convenient, wired for compatibility with Microchip's MPLAB ICD 2.
I solved my timing issue, but I have to admit, I’m still confused as to exactly what caused it.
My basic timing functions rely on an asynchronous wallclock with millisecond resolution. I implement this using Timer 0 in 16-bit mode, setting its initial value then incrementing a tick count during the interrupt it generates on roll-over from 0xffff to 0×0000. Since Timer 0 is incremented every instruction cycle, the correct initial value is simply 0xffff – (the # of instructions that can be executed in 1ms).