Dale Carnegie said you should live in day-tight compartments (well, actually I guess he was quoting Sir William Osler but I have no idea who he was; and yes, I'll apologize to the Johns Hopkins alumni in advance). I have found that my development cycles tend to break into compartments even though I don't plan it that way. I will work on Power PC for a few weeks and then an Atmel AVR for a while. Then I'll switch to an Arm processor.

The last few weeks I have been back working on a Microchip PIC device. I like the PIC, not so much for the technology, but because they are cheap, readily available, and when they upgrade devices the new device is usually mostly compatible. You might need a software tweak or two, but they nearly always fit the same socket and you get a better part at a lower price with very little fuss (usually).

Back in April, I mentioned that Microchip and other vendors ignore us Linux users. I doubt my blog had anything to do with it, but Microchip now has version 1.0 of MPLAB-X, which is a modern toolset (based on NetBeans) that can run on Linux or the Mac. Oh, or even Windows.

I was very happy to see official support for many devices without having to resort to wine or virtual machines. Of course, it uses Java so it isn't that amazing. But still, very nice. I was a little sad, however, to see that my old PicStart programmer or my ICD2 won't work with the new software. Granted, it does support the inexpensive PICKIT3 and the newer ICD3. But it would have been nice to not have to buy hardware.

Like previous versions of MPLAB, this version lets you use assembler or many third-party compilers including C compilers. I mostly use the 16F family and as much as I like C, it isn't a good fit for the 16F architecture. Mind you, some of the Microchip CPU offerings accommodate C very nicely. But the 16F is an old architecture artfully stretched to meet modern demands and doesn't lend itself to C for a variety of reasons.

For one thing the processor lacks a true stack for program use. You can use the FSR register, but you need that for doing pointers. You can make it work, but it is messy. Another problem is the way these devices use code pages and register banks.

The original PIC chips had small address spaces. As the family grew, the designers added more program space by using pages. The idea is simple. Suppose a device has 4k of instructions (that is, 12 bits of address). To make an 8k device without adding bits, you can use two 4k pages. Any jump has to get an extra bit from somewhere else (a page register).