You are viewing jjpmcd

McD's Musings

(and rants)


March 17th, 2014

MPLAB-X -- SDCC -- Fedora @ 10:05 am


I frequently use MPLAB-X (sadly, not entirely free) for PIC projects.  It works quite well even though it required me to go out and buy a new programmer.  Actually, I got two, both an ICD-3 and a PICkit 3.

Recently I needed to do an 8-bit project, and decided to use SDCC.  It isn't the most efficient compiler in the world, but it is free and I kind of like it.  Since I've recently been doing a lot of 16 and 32 bit stuff, I haven't gotten piklab set up in ages, and besides, it doesn't work with the newer programmers.  And MPLAB-X does have an SDCC plugin.

Unfortunately, MPLAB-X apparently expects an older version of SDCC and it includes a couple of compiler switches that no longer exist.  Although this doesn't cause the build to fail, it does lead to annoying messages which might disguise warnings which I care about.

MPLAB-X-warnings

Although MPLAB-X allows you to add switches, it has no provision for removing switches, and I could not find a way to easily modify the defaults.

I did find that I could edit nbproject/Makefile-default.mk, but as soon as I added any files to the project, MPLAB wrote over the edits.

However, MPLAB provides a Makefile that doesn't get written over, and it has targets to be executed at various times during the build.  By using the .build-pre target, I could edit the other Makefile just prior to the build:

MPLABX-Makefile

But there is yet another (small) fly in the ointment. Because I have multiple programmers, I often create configurations for each programmer.  Now there is no longer a Makefile-default.mk but instead a Makefile-Red.mk and Makefile-Blue.mk (for the PICkit and ICD).  Fortunately, MPLAB provides a variable, CONF, with the name of the configuration, hence the ${CONF} in the edit.

Now by simply adding a line to the Makefile, my SDCC project builds cleanly and there is no concern about missing important warnings.
 

May 28th, 2013

Adventures in JNOS/ARM @ 08:29 am

Sorry, this is long.  More of a tome than a posting.  Originally I hadn't posted this to Planet, but on re-reading it for the thirtieth time I realized it is as much about Fedora as it is about radio.

I thought it worthwhile to document some of my recent trials and tribulations around JNOS.

But for background, it is becoming more and more obvious that digital comms is a key, if not THE key, component of emergency communications.  What is perhaps a bit less obvious is that, while NBEMS modes offer simplicity and much wider acceptance than packet, they are often not up to the task.  Even less obvious is that we need a broader based connection to WinLink.

Many of you may be aware that my personal JNOS is running on a BeagleBoard xM, a small, ARM-based PC, somewhat more powerful than a Raspberry Pi, but available for much longer.  My JNOS is running on Fedora 17.  It works quite well, although is is something of a kludge.
Beagle
You see, my Beagle's Ethernet port is broken, so it is connected to my LAN via a wireless dongle.  I never got the headless JNOS working on F17, but it didn't matter all that much anyway - WiFi takes a relatively long time to make a connection, so automatically starting JNOS on boot is pretty darned messy.  As a result, I start JNOS manually on the serial port through gtkterm.  The nice part about this is that JNOS doesn't know whether there is actually anything connected to the serial port, so unlike a virtual terminal, it doesn't need to stay connected.

Power to the Beagle is supplied through a little board containing a 7805 and a couple of caps, and a cobbled together coaxial jack connected to the station supply.  The TNC-X is connected via USB.
Supply
It took me a while to get the TNC connected over USB; I had long since lost the documentation and there are a number of jumpers to switch.  I was able to write off and get a schematic and eventually get it to work.

OK, that much is ancient history.  The Beagle has worked quite well.  The only real maintenance is restarting JNOS whenever I loose power, and dusting the thing off every few months (I really should get some sort of case).

I do use the mail server on the Beagle/JNOS, and I do all my packet traffic with Evolution (ugly I know, but it is the default).  If you send packet traffic to wb8rcr@wb8rcr.ampr.org it appears in my email inbox, just like it should.

Somewhat out of sequence here, for a long time I have been wanting to get soundmodem working.  I recently found the trick (it turns out to be pretty simple), and soundmodem is WAY COOL.  On Linux, soundmodem automatically grabs the AX.25 stack, so all the normal Internet stuff works over packet whenever an ampr.org address is presented.

My first reaction was soundmodem/Raspberry Pi would make an amazingly cheap JNOS, and since the Pi image is on an SD card, it would be easy to make a JNOS image cheap and easy to configure. Hmmmm....

But then I said, HEY, what about soundmodem on Windows.  It is available for that platform, and might have an even greater impact than a cheap JNOS.  Unfortunately, while soundmodem is available for Windows, Windows doesn't have a AX.25 stack, so it is no more than a cheap TNC. It really doesn't address the complexity, which, IMO, is the major problem.

So, on to JNOS/Raspberry Pi.

An off-topic word about the Raspberry Pi.  This thing truly is a game changer.  You see, when you have a very capable PC that is SO cheap, it becomes realistic to dedicate it to pretty simple applications.  And dedicating a computer to a single application greatly simplifies everything.

I am on my third Pi, and I can see a need for at least two more:

  • Pi #1 is in the Salvation Army vehicle for use in logging during Search and Rescue operations. (MySQL/PHP)

  • Pi #2 is destined to be installed in a local contractor's shop as an electronic sign-out board. (MySQL/PHP)

  • Pi #3 will probably become my JNOS

  • Pi #4 wants to become a media center (MythTV)

  • Pi #5 needed for experimentation on the next new thing


I was able to build JNOS on the Pi, and better yet, I was able to build the headless version and run it as a service.  Very nice. OK, there were some flaky things around running JNOS as a service that I'm not so sure I completely understand, but I can say

   systemctl start jnos.service

   systemctl status jnos.service

   systemctl stop jnos.service

and it all seems to work.  I haven't always been successful with

   systemctl enable jnos.service

but I think that will succumb with a little more beating my head against the wall. (Fedora is just about complete with the systemd conversion, so although the service jnos start stuff still works, it is the old thing, and probably will disappear at some point.)

One hiccup I observed.  In making it headless, I wanted to deconfigure as many options as possible.  I had trouble on F17 making the headless version work, but I had configured in everything I thought I might some day like to play with.  On the Pi I took the alternate approach of configuring out everything I didn't absolutely need.

The problem here is Maiko has a bit of a bug.  At the end of config.h he makes sure that if, for example, you select NETROM off, anything that depends on NETROM is also off.  But he missed something (and of course now I forget what it was!)  Fortunately, this caused JNOS not to build instead of occasionally hanging later, so finding what I missed wasn't too much of an issue.

So, on to running JNOS on the Pi.  Well, first thing I ran into an uh-oh.  The minute I started JNOS the OS hung.  Eventually, I concluded that the system hung as soon as I tried to attach the TNC-X.  I got the same result with the normal Fedora 18 as well as with the new Pidora.

Wondering whether the problem was in JNOS or lower in the stack, I connected the TNC and tried to poke it with gtkterm.  As soon as I selected ttyUSB0 the Pi hung!

The USB chip in the TNC-X is basically a USB to Serial converter, so I tried a couple of others, and no problem with them.  Unfortunately, all the USB to Serial converters I had, all two of them, used the same chip, so I can't be sure, but it looks as if the issue is related to the chip in the TNC-X.

Since this worked on Fedora 17, perhaps I could make it work on some other Rasperry Pi operating system.  I had both Wheezy and Arch Linux for the Pi, so I decided to try them.

Unfortunately, I am sufficiently immersed in Fedora that these other distros are just weird, particularly their package managers.  Wheezy's apt-get wasn't too strange, but I couldn't figure out how to search the repos, and it is clear that the packages have different names than I'm used to, so I couldn't install a package that messes with the serial port, nor could I install enough stuff to build JNOS.  Arch Linux was even worse.  While I could browse their repos on the web and see what was there, Pacman didn't seem to do anything useful.

So, I posted a bug around the USB to serial converter and on to the next idea.

Actually, there are two potential courses here.  JNOS won't use the native AX.25 stack since it has its own, but soundmodem could be a nice, cheap approach. Unfortunately, the Raspberry Pi only has sound out, so it would require a soundcard dongle and some sort of transmit/receive circuitry, so not as simple as I would like.  Still, a transistor and a sound or modem chip might be put on a daughter card pretty cheaply, so that idea isn't totally scratched off the list.

The other approach, somewhat simpler but more expensive, is to use a normal USB to serial converter with a TNC-X.  Along the same lines, the newer TNC-X's use a different USB chip, so they might well work.

I tried converting my TNC-X back to serial, but the result was weird.  When JNOS said to transmit, the transmit light came on but no audio came out.  Evidently, there is some jumper or another that I missed, so the next thing is probably to track that down.

But it looks like I need to order another TNC-X and maybe another Raspberry Pi or two while I'm at it, perhaps even a sound chip.  An even more interesting possibility is to convert the TNC-X code to the dsPIC, which has enough gas to generate and detect the tones itself, making for a single-chip daughter card.  The newer TNC-X code, as far as I know, hasn't been published, but the original has, and I suspect a lot of the stuff in the newer code has to do with his GPS and APRS addons so probably not interesting anyway.

And going back to the top, I really need to find someone to take point on a project to construct a few gateways between our packet network and the NTSD/WinLink network.  Supposedly doable, but not yet demonstrated, and then of course there is the issue of supporting something permanent.

Ahh, so much fun to be had, so little time.

73 de WB8RCR
 

May 16th, 2013

When it rains it pours @ 09:06 am

Current Mood: satisfied satisfied

What a wild few weeks.  Lately I haven't been able to spend the time I would like with Fedora, although I did manage to get some release notes work done on some of more geeky beats.  Good thing (really good thing) that others have stood up for the past few releases.  My life shows no signs of getting any more sane.

MiMapOK, the past month or so has been a bit unusual.  We have some nuke drills coming up, well, actually already started, and the State has a new critical incident management system which all the state agencies have been getting familiar with.  We had a "dry run" in the middle of April to familiarize ourselves with the new system, a scheduled meeting of the state agency emergency management coordinators the following day, and the day after that, the State Emergency Operations Center activated in response to flooding across the state.

Although we (amateur radio) didn't have a huge role, still, it took an amazing amount of my time to stay on top of what was happening, participate in SEOC briefings, keep our status updated in the state system, etc.  And the thing about a flood is that it goes on and on and on.  It has now been almost a month and still we are in monitoring mode as the various counties understand the extent of the damage, sort out how they are going to repair it, and who is going to pay for it.

When the government is involved, the who is going to pay for it gets to be a pretty big deal.  There are all sorts of statutes that provide relief for this, that or the other thing, but each has its own set of conditions.  County, State and Federal owned roads are all treated differently, many types of aid are conditioned on having a certain level of damage in a particular city/county/state, etc. etc. etc.  I suppose it shouldn't be a surprise, but it amazes me how many statutes are on the fingertips of State Police lieutenants (the State Police are Michigan's Emergency Management Agency).

Flood4One of the interesting things I noticed was that the damage in the various counties had at least as much to do with the experience and skill of the emergency management coordinator (EMC) for the county as the actual extent of the flooding.  My own county had very extensive flooding, but experienced very little dollar impact compared to counties who saw less extensive flooding.  I see three main reasons for this:

1) Perhaps most significantly, the county experienced a very bad flood about 20 years ago.  Since then construction within the 100 year flood plain was stopped.  As a result, most of the flooding occurred in parks and golf courses.
2) Floods, even flash floods, tend to come with warning.  Our EMC, an experienced and highly skilled guy, was very proactive in preparing, notifying homeowners, getting the right resources in place, etc.
3) We had an exercise around a flood about a year ago, so all the responders knew what to expect.

I find it unfortunate that in Michigan at least, few counties can afford the kind of emergency management skill they need.  That is aggrivated by a culture in much of Michigan that is decidedly anti-government.  There are a number of counties where half the official positions are held by the same person, and the other half by his brother in law, simply because nobody else is willing to take the job.

Of course, the flood isn't the only thing consuming my time lately.  I had a laptop issue that caused me to re-install Fedora, and of course, there are dozens of things not yet whole.  Add to that my main server is in similar shape, and it seems like every time I turn around there is some new bit of software that no longer works, or something I forgot to install.

Plus, in the midst of all this we had a meeting of all the amateur radio Emergency Coordinators.  Since I was the instigator, almost all the preparation was on me.  And the same thing with an exercise we had last weekend.  And of course the release notes coming due.  Yeah, mostly I do it to myself, but a lot of things were on the books for April/May and getting consumed by a flood was the last thing I needed.

And I'm not sure why, but a lot of things are suddenly falling out that in more sane times would have been welcome.  Just before all this started I met with the Public Service Commission to talk about communications in the event of a widespread critical infrastructure outage. The State Police are wanting to get their database of communications assets updated with amateur radio assets,  we are about to put our training data into the State's database, the State is asking if we can perhaps provide video from their aircraft, and I was tasked with lining up some training for a FEMA official in Washington.  On top of that the Emergency Communications Advisory Committee of the ARRL is now meeting frequently to get some of our work wrapped up, and I've just been appointed to a committee that develops public safety communications policy for the state.

I guess it is true when they say there is no rest for the wicked.
 

January 18th, 2013

A teeny web server for Search and Rescue @ 03:12 pm


For a while now I have been working with Midland County Search and Rescue, operating as net control on the radio net we use to keep track of the teams in the field.  This turns out to not be quite normal amateur radio logging; the key issue is accountability - making sure we know where everyone is and that they get back safely.

SAR-loggingAfter doing this for a while, I realized the job could be made easier with the help of a bit of PHP, so I built an application that helps me keep track of the teams, and also prepares a PDF of the log after the search.  Often on a search there are law enforcement issues, and it is important to have proper records.

I generally run Apache/MySQL on my laptop, so this works quite well, and easily.  But when someone else is net control I either have to let them use my laptop, or have it become a server.  The group has a number of laptops, but they all run Windows, and I wasn't interested in dealing with the complexity of SQL Server and all the weird Microsoft server page things.

Raspberry Pi in Bud boxBut, the Raspberry Pi provides a really beautiful answer.  I installed the necessary software on my Pi and it is surprisingly snappy, even running MySQL under the web server.  Since it is a simple matter to make the database and web server come up on boot, I realized that this thing could be made incredibly simple.  So, I put the Pi in a Bud box with holes for the USB, ethernet and power.  The USB sticks out so to make the RJ45 reachable I had to expose it, requiring the third hole.

USB connector covered with tapeSetting up for a search is kind of a messy business, with all sorts of things going on, and most of the folks are not at all technical.  So I wanted to be sure it was as simple as possible.  With the Pi in a box and very little exposed, all that is required is to plug it into power and a router and it's done.  I had to expose the USB connector, which is unnecessary for this application, so I taped over the USB port, leaving no room for error.  The RJ45 cable won't fit into the hole for the power, and the little micro-USB will just rattle around inside the RJ45 jack, so there isn't any opportunity for someone to make a mistake.

This also allows some additional features.  Since we will now always put it on our local, scene WiFi, search operations will be able to view the log live.  I plan in the future to come up with another page which shows an expanded team status.  Currently I have a little snapshot of the team status on the upper right of the logging screen, but I have additional data which would be interesting to SAROPS so I plan to add that as well.

The Raspberry Pi, of course, is running Beefy Miracle. 
 

September 25th, 2012

Wah hoppen to jjmcd? @ 01:36 pm

OK, this is long overdue.  As many of you are aware, I am not leading the charge on the Release Notes this release.  And although I've been hanging around on IRC quite a bit, I rarely have much to say these days.

It ain't that I don't still love ya.

This fall a number of things have colluded to make it impossible for me to spend as much time as I would like on Docs.  I do anticipate things will get a lot better after October.

Many of you know that I am the Section Emergency Coordinator for Michigan.  That has me spending a lot of time in Lansing with the State Police.  This is nothing really new, *BUT* ...

This year the State of Michigan is rolling out a new Critical Incident Management System.  I have been quite involved in the development of that system, seizing the opportunity to ensure that features are included which are useful to amateur radio.  This, of course, takes time, and a lot of that time is surrounded by two hour drives each way.

Perhaps instigated by this rollout, my responsibilities with the Michigan State Police have increased.  Instead of simply coordinating amateur radio activities, I now have responsibility for all auxiliary communications for emergency response.

Also on the government front, every eight years each nuclear power plant is required to run what is called an "ingestion pathway" exercise.  Since Fukishima, the NRC has really ratcheted up these exercises.  This is the first that Michigan will be doing since that event.  When we do any of these nuclear plant exercises, we do two drills and then the actual exercise.  During the drills there is less going on out in the field, but from my perspective in the State Emergency Operations Center, they are all the same.

Except in this case, the final exercise will be multiple days instead of one. In the past, even when we had an ingestion pathway exercise, I wasn't involved in the second day anyway.  This time I'm not so sure.  In fact, we have little insight into what to expect except a LOT more Federal participation than we are used to.  I was at a "Federal Outreach" a couple of months ago, and it sounded ominous.

The first drill is tomorrow.

Saturday I am speaking at the Ohio Linux Fest.  Of course, getting ready for that takes time, and me being me, probably takes more time than it needs to.  The good news is that next week that will be behind me.

Speaking of OLF, where are the Fedorans?  I don't see any familiar names on the speaker list where in previous years it looked like a FUDcon. I don't think I even know of anyone else who is going.

But the big time eater is SET.  Every year amateurs across the nation hold what is called a Simulated Emergency Test.  Typically, this is a pretty low impact event, but in Michigan, we have chosen to use this as an exercise to help us improve our skills.

Over the past couple of years, we have begun using FEMA's Homeland Security Exercise Evaluation Program (HSEEP) for our exercises.  As you might imagine, this adds a huge amount of work to preparing for and evaluating an exercise.  However, the results are more than worth the effort.

Most times, I have an assistant who does much of the heavy lifting.  However, this year he has a number of personal demands on his time, so he hasn't been able to assist much.  The task takes a fair bit of training, including a number of FEMA courses, so is isn't something I can quickly grow someone into.

Once I get past October, things should look a little more normal.  But I don't know, I need to keep doing it to myself.

Back in 2003 I did an online course on PIC microcontrollers.  The course was amazingly well received; thousands of folks took it.  When we were first talking about it, I was thinking we might get a dozen.  One of the QRP clubs kitted a board to go with the course, and after a few months they cried uncle; they just couldn't keep up.  Eventually the board was commercialized, and it is still available and still selling.

PICs have changed a lot, and I am toying with doing a course on the newer dsPICs.  These have way more capability, are a lot easier to use, and cost barely more than the old ones.  With the help of a couple of other folks, I've been working through what a board would look like if I were to do this.  And then there's the whole deal of what will it cost to manufacture, is there enough of a market, etc. etc. etc.

The good news is that after October, the SCHEDULED items die down, and hopefully things will return to their normal level of chaos.

Meanwhile, many thanks to all the folks who have stepped up to be sure the Release Notes are the best ever.

 

April 25th, 2012

March 14th, 2012

February 17th, 2012

MPLAB-X Review @ 02:23 pm


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

 

February 4th, 2012

January 26th, 2012

Hacking on an IR Remote @ 08:36 pm


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.


 

McD's Musings

(and rants)