The Danger of Day-Tight Compartments
Last week I mentioned the old Dale Carnegie quote about living in day-tight compartments. I may need to get out of my compartment a bit and get updated on a few things. If you recall, I had mentioned how I switch back and forth between processor families, and lately I was programming some PIC 16F-series chips. Although Microchip (the maker of the PIC) has some chips that handle C nicely, I mentioned I prefer assembly for that particular family, because the architecture was poorly suited for C.
Microchip nicely mentioned to me that I had not been paying attention to their press releases. The "Enhanced mid-range" family (like the 16F193X, for example) has the same basic architecture as the "traditional" 16F family, but also has some features that help C compilers.
In particular, the devices have:
- A 16-level call and return stack and better interrupt stack handling
- Two FSR registers so you can use one as a software stack pointer (for example) and another for pointer dereferencing
- You can use the FSR to read (but not write) to program memory in a linear fashion, which makes storing constants and tables in flash easier
The chips have some other nice features, but those are the main ones that apply to C programming. Microchip also pointed out that some C compilers do strenuous optimization, and I did mention it was possible to overcome some of the banking inefficiency with optimization. On the other hand, I have not seen a plain vanilla GCC that does that type of optimization. True, you can get somewhat limited licenses for many of the compilers for free, but if you want the full blown thing, there is a cost.
But still, the new architecture sounds like it would be a boon to compiler writers and (when I get a few devices in) I'll look at how the compiler generates some code.
I appreciated Microchip pointing out these relatively new chips, and as I mentioned last week, I'm a fan of the PIC for a lot of different reasons. Having a workable C compiler for these inexpensive and widely-available chips just makes it even better.
What I was really happy about, however, was the Microchip MPLAB X, which runs nicely under my OS of choice, Linux. I promised that this week I'd show you a little bit about MPLAB X under Linux, and I'm as good as my word.
The IDE is based on Netbeans (see the Figure) which is, of course, a Java program so it isn't too surprising that it runs well under Linux. Netbeans is on par with other modern development environments — it interfaces with bug trackers, version control, and additional tools you expect to use while writing software.
Probably the most interesting thing, however, is that MPLAB can also operate with several different debugging back ends. For example, I have it connected to an inexpensive (under US $40) PICKit 3, which lets MPLAB debug code live on the chip. There are also more expensive options that have correspondingly more sophisticated features. If you just want to experiment, MPLAB can also use a software simulator so you don't have to have any hardware at all. Just beware. There are a few things that don't work right in the simulator on certain parts (and this is typically documented). It can be frustrating to debug code for a few hours only to discover the simulator doesn't simulate the I/O device you are trying to control.
I could go on about MPLAB, but I decided that if a picture is worth a thousand words, a video should be good for a million or so. That's why I did a little project walk through that you can find on DDJ TV.
I'll be looking at the PIC more in the near future, including some techniques that apply to many types of processors in the same category. Got a favorite PIC trick or tool? Put it in a comment and maybe it will show up in a future blog.