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 ...

This post, rather long and geeky, is more of an attempt to record a little project for myself, but I am copying it to the Planet, even though it has little Fedora content, because my fellow Fedorans deserve an occasional peek at just how weird I am!

For Christmas, Santa brought me a PIC24FJ256DA210 Development Board.  This is quite a cool board, with an especially cool PIC.  The board includes the obligatory buttons and LEDs, along with a PICtail socket, Host, Device and OTG USB ports, a serial port, parallel and SPI Flash, SRAM, mTouch pads, and a display connector.  Plugged into the display connector is a 3.2" TFT display with a resistive touch panel.

The PIC24FJ256DA210 itself is quite interesting, including not only USB and PMP, and gobs and gobs of Flash and RAM (by PIC standards), but also a graphics controller.  I had done some graphics a while back on a 24F on the Explorer 16 Development Board.  I was interested in seeing how things changed with the controller on the PIC.

The demo app was pretty neat, one of the (many) things it did was to read JPGs off a thumb drive and display them.  On a PIC this is kind of a big deal since few PICs even have a USB stack, let alone the capability to interpret the FAT filesystem and decode JPGs in finite time.

In looking for a project to get my head around this thing, it turned out that a friend (N8ERO) was working on decoding the output from a TV remote. He was trying to draw the output graphically on a little black and white LCD.  It occurred to me that this was a sort of interesting project and would exercise the PIC.

I began by coming up with a scrolling graph on the Explorer 16 since I was already familiar with the older version of the Microchip Graphics Library, and I thought a speed comparison would be interesting.  Since I didn't need the touch screen for this application, but did need speed, I stuck to the graphics primitives portion of the library and avoided the Graphics Object Layer (GOL).  Although the scrolling wasn't terribly fast, handled by redrawing rather than memory copying, it was still pretty tolerable on the PIC24FJ128GA010, so now off to the the PIC24FJ256DA210 to see what the graphics controller could do with a pretty simple case.

(For the pathologically curious, the code for all these little exercises is on gitorious at https://gitorious.org/pic16/graphtest/trees - there's actually nothing in the master branch; each of these experiments is in its own branch.  The GA010 display is in graphAD branch.)

Microchip has some pretty slick hardware, but their software has never been anything to write home about.  The older Graphics Library had a mess of directories and files that made little sense.  I was hopeful that the new library would be an improvement.

Well, it was worse.  "Back in the day", you could download the Graphics Library.  Now, you need to download the "Microchip Application Library", which includes not just the Graphics Library, but all sorts of other things.  It isn't that the download is so burdensome, or the disk space is unmanageable, but the addition of all the other features, even if they are pretty neat, gives Microchip the opportunity to make it even more of a mess than it was before.

And it gets worse.  over the past few years Microchip has added a number of experimenter boards to their stable, including quite a collection of displays and a few graphics controllers.  When you dig down into the source, every line of code is preceded by about a half page of #ifdefs to select the appropriate PIC, board, controller, display panel and touch controller combination.  In some cases there are choices between serial and USB interfaces and SPI or parallel external flash. It is totally unreadable.

There are no actual "libraries" in the Graphics Library, something I thought a little odd.  Their sample projects include lots of source files into the project.  Well, of course, you need to set all those various #defines before compiling the code.  In many cases it isn't at all clear how you get some symbol or another defined without editing the Microchip code, but with a lot of digging you can get around it with our old friend -D.  (Would have been nice if the documentation provided a clue, tho.)

Speaking of documentation, there is quite a bit.  Most of it .chm files.  Now, .chm files in general tend to be trash.  The templates that Visual Studio provides lead the developer down the path of useless help files.  But to Microchip's credit, the MPLAB help files are among the best I've seen.

Unfortunately, the files provided with the application library are a newer version than can be handled by anything I could find in Fedora, newer even than could be read on the XP image I have on a VM.  Fortunately, the critical (to me) stuff was also available as .pdf.  There's a lot of stuff there I would like to explore that is only in .chm files, tho.

Sadly, the documentation is mostly disjointed.  They do have a pretty nice function reference for the Graphics Library, but it doesn't give you any help as to what the dependencies are, what symbols need to be defined for what purposes, etc.  There are other documents that help you figure out how to set the two dozen jumpers on the board, but those documents are scattered.  The best bet seems to be reading the schematics.  Those are annoying because they are spread out over umpteen pages.  I would rather deal with a humongous fold-out like Icom does.  A bit unweildy but at least you can trace lines with some degree of confidence.

After a bit of a struggle I managed to get my GA010 code working on the DA210, and the speed improvement was startling.  Even without using features of the controller the display was almost 20 times faster, although it felt faster than that. (graphAD-DA branch).

Earl provided me with an IR sensor he had ripped out of an old VCR or something.  I tacked it onto a PICtail prototyping board I had been using for various experiments, and when supplied with 5 volts, it seemed to be able to see my remote.  Unfortunately, it was totally blind when powered with 3.3 volts.  This is a problem.  The PIC24's are 3.3 volt parts.  Although the DA210 isn't a horribly expensive part, it is a TQFP100.  I've been able to deal with parts like that before, and although possible, it isn't any fun at all.  I really wanted to avoid damaging the PIC. But I'm also a big fan of simple, so rather than some elaborate voltage conversion scheme, I simply put a 10K between the sensor and the PIC on the theory that the sensor wouldn't be able to drive damaging current into the PIC through the 10K.

So, now we have the IR sensor connected to the PIC, but the PIC didn't seem to be able to detct anything.  Most of the PIC lines are used for the graphics controller.  Even tho the DA210 has 100 pins, the board has enough different functions that every pin has multiple uses.  The pins connected to the buttons, which are shared by mTouch pads and LEDs, seemed to be the best bet, and I could convince myself that I had the right pin by putting my meter on the PICtail and pushing the button, but still the PIC couldn't see anything.

After spending way too much time, I realized that the pull ups for the pushbuttons couldn't be overpowered through the 10K by the sensor.  But another blatantly obvious thing I should have seen; the pushbutton was enabled by a jumper!  Simply removing the jumper allowed the PIC to see the sensor.

Up to this point the slugging had been pretty slow.  Every step became a battle.  But from here on, once I had my head around the graphics so-called library and the board, things went surprisingly well.  From here on the vast majority of time was spent, well, tinkering.  I can really get wrapped up in making this or that look just right.  Foolish, really, since I have absolutely no eye for making things look right!

As I looked at the data from the sensor it became obvious that a scrolling display wasn't going to be much help.  Ultimately, the point is to be able to decode the pulses from the remote.  There were a LOT of pulses going by very fast.  If the data were scrolling by there would be no opportunity to examine it to look for patterns.

So, the scrolling display went out the window, in preference to a static graph. (readIR).  The approach I used, since I didn't know the speed, was to sample the data and put it in an array, then plot the data after the fact.  The PIC24FJ256DA210 has a lot of RAM, so a fairly large array wasn't out of the question.  I could then adjust the sampling time without messing with the graphing code until I could see the relative length of the pulses.

But, it turns out there are a LOT of pulses.  Given the 320x240 resolution of the little display I couldn't display even a significant fraction on them, and even if I could, the display wouldn't make much sense.

So, the next optimization was to make the array very large, and display the data a page at a time.  This was effective, and made for a nice display, but still it was difficult to make sense out of what I was seeing.

At this point I started digging around on the web to see if I could come up with the codes for my remote.  Unfortunately, not only did I not find my particular remote, but different sites seemed to have entirely different opinions of how to interpret the data stream.

It seemed to me that a less pretty approach might be more enlightening.  So the next approach was to display a string of characters, green for a low and white for high.  This evolved to displaying underbars for low and a digit, increasing as the pulse persisted, for high.  This made it quickly obvious that, other than the start pulse, there were only two pulse lengths.  Short pulses were either 1 or 2 samples, long 7 or 8 (after adjusting the sampling time to optimize the display).  (listIR commit 58bfdd2)

Once it became evident I only had two states, it seemed obvious to convert the pulse train into a number, using 0 for a short pulse and 1 for a long pulse.  Now I could easily see whether I had the timing right and understood the signal; if the same button resulted in the same number, and a different button gave a different number, I was close to having it decoded.

So initially I was pretty timid; get the number, look for one of a few hits in a case statement.  Of course, the case statement became immediately annoying as I added codes, so it went out the window in favor of a table lookup, which was not only shorter, but much easier for adding codes. I also quickly dispensed with the string display, and pretty soon my fancy graphics display was pretty boring.  All I really needed was the hex code (for adding new buttons) and the result.

So at this point, I'm kind of at the end of this experiment. I did notice that, although there are all sorts of claims of standards, the pulse lengths vary widely between different remotes.  But honestly, I don't have a burning application for this capability anyway, so I doubt I'll be motivated to expand to other remotes.

Another good day, in a surprising way.

Last night the roads were pretty poor, but this morning, in spite of a little more snow last night, were good.  Apparently they have salt in Virginia.

The main event planned today was the Docs hackfest.  We never did find the agenda, but we did get one thing done; all the Beats are ready to start on F17. This isn't a huge job, but it is really tedious and annoying.  With multiple hands it was done in no time.  So now everything is in place to get started on the Fedora 17 Release Notes.

After lunch they wanted to move us to another floor, and lots of folks were headed back home, so I headed back to my hotel room.  It had warmed up considerably; so much so that I decided to seize the top-down opportunity for the short drive back to the hotel, interrupted by a quick stop at Starbuck's.  (I may not have mentioned, there was NO COFFEE at FUDcon.)

I needed to get out my monthly report for my day job(?).  I was missing two reports, sent out a request for one and got it back almost immediately.  The second one might not make it; only about an hour now before I have to just send the report.

I plan to meet my godson later today.  He is on the way back to VT as I write this.  He is in Civil Engineering at VT, so it will be nice to have a chance to see him.

Tomorrow we will try to get out as early as possible and head back north.  I don't much like the way the weather reports look back in Michigan, so we want to get as many miles behind us as possible before we hit the weather.

I don't know how it went for others, but for me, this was a very productive trip.

Day 2 is the main deal at FUDcon.  Most of the presentations and such are on Saturday.  After the FPL's State of Fedora address and voting on the BarCamps, I had back to back Docs things.  First, I needed to be in the Introduction to Docs so I could harass Sparks.  Then, after lunch, I was on the hot seat for the XML/Publican presentation, with Jared doing the harassing.  Both went well.  There were only a handful of attendees, but they were well engaged.

Probably one of the high points was a presentation from suehle's daughter explaining how Princess P's power was spelling, something us Docs folks could use.

I also picked up the Raspberry Pi presentation.  There wasn't a lot there that was really new to me as I had followed the product for a while, but I hadn't really "internalized" just how serious they are about producing millions of these things.  I did also manage to get a cupon from Red Hat for a Raspberry Pi and power supply as soon as they become available.

Saturday is also FUDpub.  This time held at the "Break Zone" in the student center.  I was a bit surprised at how elaborate the facilities are these days at school.  Perhaps because of a misspent youth dozens of pool tables seemed out of place at an engineering school.  Don't know why, saw the same thing at Annapolis decades ago.  Perhaps the bowling alleys felt a bit over the top.  The food was good, the talk was good.  I left a bit early when Jared and Mark started having a snowball fight; I was pretty concerned about how southerners would react to snow on the road.

So yet another good day.  Sunday should be a bit more laid back, with a Docs hackfest all that is on deck.

Got over to the school early to find a parking place - that turned out to be much harder than I expected. In the end I lucked out, but although I expected it to be a problem, the pickings were a lot slimmer than I expected.


Day 1 started out as they always seem to - disorganized. The first thing I did was to take in the first of the ARM sessions. There was another session planned for Saturday that looked as it might be better (for me), but it conflicted with stuff I really needed to be at. Well, this one turned out to be perfect.

And there was no coffee!

It was a surprise to me that ARM intended to be a primary arch, but once I thought about it, it makes sense. And that alone answered lots of questions I had. I was also surprised to learn that putting SSDs on some of the servers significantly improved performance, but also that the life was so short, and predictable. I guess I was aware of the limitations of FLASH, but hadn't considered what that means in heavy use applications.

Did I mention there was NO COFFEE?

So, we walked over to Jimmie John's for lunch, and it was FREEZING.

After lunch on to mw-render. Ian Weller discovered that upstream had released a new version of mw-render just a day ago. He downloaded it and it seemingly no time had it running. But once we tried it out, it complained about a "writer". A little exploration revealed that in an earlier release they had removed exactly the part we need.

So Ian, Eric and myself noodled on what we might do, and I think we have a good strategy.

I also managed to drop in on a session Tatica was leading on dealing with people needing help, especially the very demanding users. Good session with a lot of good thoughts passed around.

So all in all, a very productive day.

Well, I'm here, and it is good.

I left Michigan Tuesday afternoon.  I wanted to leave plenty of time in case of snow.  Tuesday was beautiful, corner to corner blue sky, made it to Columbus where we stayed in one of our favorite places.  Unfortunately, we didn't get to Columbus in time to enjoy the Turkish restaurant, but you can't have everything.

Wednesday wasn't so nice.  The weather deteriorated as the day went on, and by the time we hit West Virginia, we had very heavy rain, lots of standing water on the Interstate, and very dense fog.  Still, we made it to Blacksburg fairly early.  The Predicted snow kept getting later, and it didn't show until Thursday night, and even then, not more than a dusting.

Thursday late morning I called Jared, went over to the Inn to chat a bit.  Didn't seem like a lot was getting organized yet, so I went back to the hotel (I'm staying in a different place) and started tickling the keys.

I'm the guy Dave Barry described when he talked about spending days building tools to help a five minute project.  Every release I take Robyn's schedule and put the release notes part on the wiki with a little more description.  The descriptions in the schedule are often misleading, and some tasks require a lot more prose than is reasonable in the schedule.

Also, I'm a visual sort of a guy, so I also make calendars with the schedule on them.  I got it in my head that I needed a program (my knee-jerk is still C instead of bash) that would take Robyn's schedule and make the calendar pictures directly.

It turns out that the Taskjuggler csv's are hideous, with an obnoxious date format.  So I need to convert those dates into something useful if I am going to calculate where they are on the picture.  I had some ideas about how I would organize the schedule in memory so I could make calendar images a little nicer than the ones I have now.  I thought I would import the taskjuggler csv's into a spreadsheet, and sort out dependencies so when the schedule inevitably changes, I could change one or two tasks and the rest would fall into place, instead of changing dozens of dates.

Of course, oocalc can't make sense of the taskjuggler dates, so the first step was to write a program to convert the dates.  That took more than I thought because oocalc seemed to want everything to be text.  After a lot of diddling around I discovered all I actually had to do was to tell oocalc what columns were dates when I imported the csv.  Oh well.

Once the schedule was in oocalc I realized that if I put the comments and extended descriptions into the spreadsheet, I could then write a program that would output the ugly wiki table, and I could also easily then mark external milestones etc.  So a second C program.  That one went very quickly.

By now it was afternoon and other trouble makers and ne'er do wells had started to arrive so I ran back over to the Inn, hung out with Robyn, Eric, Ian, etc. etc. etc.

After dinner I decided to turn to the calendar, my initial intent, and by then concluded with with everything else in place, that was going to be quicker just doing it manually.

As I was finishing that up, Ian asked on IRC whether it was OK to move the mw-render session, which was fine with me.  In fact, a positive since it would allow me to at least catch the first part of the ARM sessions.  Those ARM things showed up late, and were pretty much all scheduled in conflict with some Docs thing, in spite of the calendar being mostly empty at this point.

OK, so now it is cold outside, getting time to head over the the campus and see what's up at McBryde.

https://github.com/jjmcd/Elmer160/tree/16F628A/ChristmasDoodle

Click on doodleAll.zip then right-click on "raw" and select SaveAs... to get the entire project in a zip, or if you just want to look at the code, click on doodle.asm instead.

Can you figure out what it does? (It is deliberately sparse on comments.)

Even after you run it can you figure out what it's doing?