How to Pick and Program a PIC, Part 2

In Part 1 of this soon-to-be-legendary mini-mega-series, I made mention of the fact that—a couple of years ago as I pen these words—I foolishly agreed to take over the maintenance of a company’s library of code targeted at 8-bit PIC microcontrollers from Microchip.

Sad to relate, this code was in PIC assembly language, which—if the truth be told—is a bit of a beast, not least because the internal architecture of PICs is … let’s say “interesting” and leave it at that.

I’m sorry, I can’t leave it at that because of what’s to come. As one small example, the memory in the 8-bit PICs that are the focus of these columns isn’t presented as a single contiguous whole. Rather, it’s split up into 128-byte banks, which means you often need to use special assembly instructions to switch banks to access whatever it is you wish to access. Also, PICs contain an inordinate number of Control and Status Registers (CSRs) whose bits you typically must tweak to realize whatever effect you are hoping to achieve.

To be honest, once I fully comprehended the complexity of the problem I started to despair. Seriously, I was waking up in the middle of the night thinking, “how on Earth am I going to pull this one off?” Happily, I remembered that my friend Joe Farr, who hails from a beautiful village outside London, England, is a master of the mystic arts when it comes to PICs. I can’t tell you how many times we’ve bounced ideas back and forth about some project on a Friday, only to find that Joe has a fully functional PIC-based prototype up-and-running by Monday morning (and this includes fabricating his own printed circuit boards).

Related:How to Pick and Program a PIC, Part 1

Thus it was that I called Joe and inquired how to address my assembly language problem. Joe responded that the solution was clear … that I should forget the idea of programming in PIC assembly language. Obviously, this was only the first step in the solution, otherwise I’d be up the coding creek without a metaphorical paddle. Joe informed me that—in his humble opinion—my best option was to recode everything from the ground up in a higher-level language that would be easier to understand and to maintain.

My knee-jerk reaction was that Joe was going to suggest I program my PICs using C or C++, so you can only imagine my surprise when he recommended using BASIC (if you are interested in the history of computers, you really should watch The Birth of BASIC video).

I must admit to being a tad surprised (“BASIC is so 20th Century, my dear!”), but Joe proceeded to explain that a guy called Les Johnson has created some awesome Positron PIC BASIC Compilers. The reason for the plural (“compilers” instead of “compiler”) is that Les supplies different compilers for 8-bit and 16-bit PICs. The associated integrated design environment (IDE) automatically selects the appropriate compiler when you tell it which PIC you want to program using a special statement in your BASIC source code. The whole kit and caboodle (the compilers and IDE), along with all future upgrades and enhancements, can be yours for a one-time payment of £39.99 (which equates to ~$50 in the USA). All I can say is that this was one of the best $50 investments I ever made.

Related:The Times They Are A-Changin'

As an aside, a lot of older programmers claim they can create better code in assembly than others can achieve using higher-level languages like BASIC or C (by “better” they meant using less memory and/or fewer clock cycles). This was possibly true in the early days when interpreters and compilers were in their infancy, but these tools have evolved dramatically over the years, including their ability to apply optimizations many human programmers wouldn’t even think of. But the real advantage of using higher-level languages is that they let you explore multiple scenarios in the solution space, which isn’t something you want to try doing if you are capturing your code in assembly language. However, we digress…

Related:Reincarnated Return of the HRRG 4-Bit Computer (Part 3)

As soon as I’d downloaded and installed my Positron PIC BASIC Compilers, I used the context-sensitive editor in the IDE to take one of the smaller programs I’d undertaken to support, replicate it in BASIC, and compile it into machine code. The results, which are stored in .hex files (i.e., text files in hexadecimal format) are shown below.

Hex file size comparison: original (left) vs. new (right). CLIVE "MAX" MAXFIELD

I blurred this image to protect the innocent (i.e., me). As we see, my version on the right is significantly more concise than the original version on the left, even though that version had been painstakingly handcrafted by an assembly language guru. The great thing is that if you look at the .asm (assembly) files generated by the Positron Compiler in addition to the .hex files, you’ll see that the compiler has taken care of all necessary memory bank switching and control register bit flipping for you.

In my previous column I introduced the PICkit programmer. This currently comes in four flavors: PICkit2, PICKit3, PICKit4, and PICKit5. I originally opted to use the PICKit3 because it was a fraction of the price of a PICkit4, and it’s still cheaper than the recently announced PICKit5. However, as we’ll see in my next column, for reasons that will be revealed, I’ve now moved to using a PICkit2.

The folks at Microchip offer the MPLAB X IDE, which offers awesome functions and features for professional programmers. Sadly, it makes my head hurt. Happily, they also have something called MPLAB X IPE, where IPE stands for integrated programming environment, which is focused on programming and provides a much simpler interface than the IDE.

I can no longer remember the reasoning, but I was told by someone that the version I needed to use was MPLAB X IPE v6.00. The great thing is that the folks at Microchip provide all the earlier versions of their tools for free download.

As I mentioned in my previous column, using the PICkit of your choice, you can program a PIC directly on a breadboard. However, one weekend when he had some spare time on his hands, Joe designed a special development and test board for me as shown below.

My super-duper PIC programming board. CLIVE "MAX" MAXFIELD

The cable on the right-hand side plugs into my PICkit programmer. The cyan-colored zero insertion force (ZIF) socket in the middle helps speed things if I’m programming a bunch of parts. The power supply section in the lower right-hand corner can be fed from a 7 V to 15 V AC or DC source, and I can select between 5 V and 3.3 V to power the board depending on the PIC parts I’m working with. There are a bunch of other features, but those are all related to my own special requirements.

All we need remember for the moment is that we can capture our PIC source code using the Positron BASIC Compilers, which generate both .asm and .hex output files. And we can use the free MPLAB X IPE v6.00 in conjunction with one of the PICKits to upload hex files into our PICs, irrespective of whether these devices are on a cheap and cheerful breadboard or a special development and test board like the one shown above.

In my next column, we will consider the programming of PICs in a little more detail. Also, we will take our PIC development environment to the next level by means of… but no, you’ll just have to wait. Until that frabjous day, I welcome your comments, questions, and suggestions.

And be sure to read Part 1.