Friday, February 17, 2012

MPLAB-X Review


I first tinkered with MPLAB-X during beta.  Although it was promising, it seemed flaky enough that I didn't want to move to it yet, plus, I wasn't doing a lot of PIC stuff anyway.

More recently I've been doing a bit more with the PIC.  I had installed the release version but had quite a few problems so I put it on the back burner.  I thought maybe it was time to go back and see whether it was going to be a good thing.  All of this is based on MPLAB-X version 1.00 on Fedora 16.

For whatever reason, perhaps updated libraries, perhaps the last time I played with it I had got the configuration right, whatever, but it worked quite well for me.  Mostly I used the C30 toolchain, although I did tinker with the C18 toolchain.

One of the first things you notice is that the buttons are all different.  Nicer looking to be sure, but since they don't look like the old version, confusing.
One of the very nice features is that there is a build, program and run button.  That is a departure from MPLAB 8 where they are all separate steps.  Also, instead of having production and debug configurations and targets, you can simply click "Debug this project" and the project gets rebuilt for debugging, programmed and started.  As in earlier versions, the debug buttons don't show up until you start the debugger.
Another big change is that the window is tiled.  You could set MPLAB 8 up that way if you wished, but when debugging you need so many windows that it is pretty unwieldy.  On MPLAB-X, though, everything is tabbed, so the tiled model is actually pretty nice.  Once you get the idea of where things are, you aren't always hunting for hidden windows like in earlier versions.


The left hand area has a number of surprising choices.  The most obvious, perhaps, is the dashboard.  This seems to take a page from Piklab, but there are a couple of nice features, like bars showing memory used and a section showing the status of the programmer.

You can have multiple projects open at once, and the "Projects" tab shows all the open projects, and allows you to navigate for files in those projects.  the "Files" tab is similar, but also allows navigating the various project subdirectories for object files, executables, etc.  Yes, MPLAB-X makes a number of subdirectories so your main project directory doesn't get cluttered with all the odd MPLAB created files.

The services tab allows you to add team servers like java.net to your project,  also issue trackers such as bugzilla.  I tried adding a local instance of bugzilla with no joy.  Not sure if it's broken or something lacking from my bugzilla instance.  the only other issue tracker available is JIRA.  Whether Trac or similar trackers could be added reasonably I have no idea.

But to a degree that fits.  There is also a "Team" menu that allows connecting with CVS, Mercurial or Subversion.  Where is git?  Who knows.  Seems odd to have all these old RCSs and not the most popular.  But it appears that perhaps the Pony Express doesn't make it out to Arizona with news more than once a decade.  Still a step up from the time when the only choice was SourceSafe.

On the bottom is a tabbed area very similar to the "Output" window in earlier versions, but with a lot more capability.  Besides showing you the compiler output and the status of the programmer/debugger, it also has a very cool "variables" tab when debugging.  If you halt in a function, this tab shows the values of all the automatic variables in the function, as well as any watches you have defined.  This really cuts the need for the various debugging windows, and automatically shows you the exact things you probably want to see.

There is also a tab showing all the breakpoints you have defined, along with checkboxes allowing you to disable them without having to track down the source line.  But wait, there's more.  When debugging, hovering over a variable will show you its current value (if it is in scope, of course), and if it is a structure, will even show you the bits and pieces -- especially handy for special function registers.

For your static variables, it also shows the address of each element.  Very, very handy.

MPLAB-X starts very slowly, being a huge Java app I suppose that isn't much of a surprise, but once started, it seems to be quite speedy.  It seems especially quick for compiling and programming, odd, since it apparently uses the same compilers as MPLAB 8.  The build, program and run button, one of the most common things to do during development, seems especially quick.

But there are some things that seem to take an inordinate amount of time.  When a program is running, placing into reset seems to take forever.  A simple task like that shouldn't take visible time, but it is at least 3 seconds on a very fast computer.  Releasing from reset also seems slow, but nothing like holding the target in reset.

Probably the biggest win, though, is the editor.  It seems to make a lot more sense than the old one, especially with tabs.    It automatically puts in closing parentheses and braces, but unlike most other editors, if you habitually type that closing paren, yours simply writes over the provided one, unlike other editors where you may find yourself constantly erasing extra parens.

If you click on a variable or function, it highlights all other occurrences of that variable or function on screen, and places little tic marks to the right of anywhere else that function appears within the file, so you can even track down off screen occurrences easily.


The right-click menu lets you go straight to the declaration (or header or implementation in C++),  find other occurrences, etc.  It will even generate a call graph.

With all these features, though, I am still left with the feeling that there are important features from earlier versions of MPLAB missing.  The more I use MPLAB-X, though, the less I feel that, and the more it does seem like a significant step up.

Now if I can just figure out how to make a git plugin ...

Thursday, February 16, 2012

Weird PIC stuff

So, a week or so ago I got it in my head that I wanted to compare the performance of various LCD display modules.  Yeah, I know, weird.  I wrote a little app for the PIC-EL using a PIC16F648A to see how long a few operations took to become un-busy.  Looked promising, but there was considerable variation within a single LCD, and since the only actual I/O on the PIC-EL is the LCD itself, taking a lot of readings to get a decent read on the variation was frustrating.
So, I need to get the data out of the PIC, probably to the PC.  My knee jerk was to go to the Explorer-16 board which has a serial port. I even had a spare PICtail prototyping board I could mount a socket for the LCD on.  I didn't get very far down that path before I realized that the only PIMs I had for the Explorer 16 were 3.3 volt parts, and all my LCDs were 5 volt LCDs.  Conditioning all those LCD lines, most of which are bidirectional, looked like no fun at all.
So, the next plan was to use the 28 pin 16 bit starter board.  I will take a dsPIC30F, a 5 volt part, it has no serial, but it does have USB.  I had a few different 28 pin 30F's on hand; chose the dsPIC30F4012 simply because it had the most memory which meant I could be fairly reckless in my code.
The 28 pin board also has a PIC18F2450 on board programmed to look like a USB to Serial converter.  Years ago I made it work on Windows by using a Microchip provided .inf file, but I have never been able to make it work on Linux, and have long since lost track of that .inf file.
I few weeks ago I had chased down that USB rabbit hole again, learning far more about USB on Linux than I ever wanted to know, but not enough to make the board work.  So, I would have to be a little more persistent.
Well, it turned out that Linux had figured out the board all by itself; I was making it far harder than it needed to be.  Instead of showing up as ttyUSBx like a normal USB to serial converter, the 28 pin board was showing as ttyACM0.  GTKterm didn't show that in its port list, but by poking it in, I was able to capture output from the 4012.
So, I wrote the little PIC program to send SQL INSERT statements to the PC so I could just poke them into MySQL and then slice and dice how I wanted with R.  The results were confusing at best.
My code was something of a hack at best, I needed to re-compile every time I changed LCDs.  PICs aren't the most user friendly thing in the world, and that seemed easier than trying to figure out how to code some user query when the only input device I had on the board was a single pushbutton and a pot.
Also, the LCD code I had written was far from optimum.  I wanted to make it as lean and straightforward as possible to be sure there were no surprises, especially since some of the measurements looked suspicious.  So, I went to work on a separate app, using essentially the same LCD code, but this time aimed at exercising all the LCD functions and making sure that there were no little hacks and workarounds in the code that might be causing me some confusion.  That went surprisingly well.
Well, I found yet another LCD, and a friend had a few more to add to the mix, and it hit me that while there were few I/O devices on the board itself, I was now connected to GTKterm, which can write as well as read.  So the next step was to code a simple menu of LCDs.  Again kind of a hack, but I could now select the LCD from a list instead of recompiling every time I changed.  Sure, I still had to compile to add a new model, but I still had tons of free memory.

Another little detail.  I've been programming the PIC from a Windows VM.  I've been using an ICD2LE redirected to the Windows VM.  It is fairly convenient to compile and build within MPLAB.  I get around some of the Windows frustration by using a drive on a Linux VM for the projects, shared via Samba with the Windows VM and via sshfs with the Linux host.  Not the simplest thing in the world, but it works.
Microchip had dropped support for the ICD2 in the production release of their Linux IDE, which seemed to have a zillion problems anyway.  Santa brought me an ICD3, but I had never actually gotten it working.  Since the USB emulation on the 28 pin board had gone so well, maybe a little persistence could make the ICD3 work.  Well, once again, there really wasn't much to it.  It simply worked.  But, as i used the new, fancy, MPLAB-X it became apparent that there are plenty of regressions compared to the old MPLAB-8 on Windows.  It is darned convenient not have to deal with Windows, but whether I can get used to the lack of a lot of features remains to be seen.
So, now it is time to test that additional LCD, get with my buddy and test a few more, and perhaps merge the "good" LCD code into the measuring app and rerun all the tests, probably with some additional conditions.
But then I made a BIG mistake. There was one of those annoying little gear things at the bottom of the screen, so I decided it was time to get rid of it with a yum update. After rebooting, my /dev/ttyACM0 was gone.  After a couple of time plugging and unplugging, I realized that the starter board was causing TWO /dev/ttyUSBx's to appear.  Of course, neither of them had my data.
So, a little searching of yum.log showed a few possible culprits.  One was the kernel, he could be the bad actor.  There were also two USB-related packages updated; usb_modeswitch and usbredir.  Neither looked particularly promising.  One has to do with the virtual machine and the other with network cards, but they do both mess with USB.
The easiest thing to test is the kernel; I could simply reboot and choose the previous version, so that is what I did.  Voila!  My /dev/ttyACM0 was back.  Unfortunately, it still doesn't get any data. And yum downgrade doesn't seem to be able to unravel the dependencies in the other packages.
So now I'm sitting here grumbling, scratching my head, wondering what my next move is.