Archive for April, 2014

Notes To Myself: Migrating legacy Microchip C18 projects to MPLAB X + XC8 toolchain, Windows 7

First note to myself: NEVER USE MICROCHIP AGAIN. If I didn’t just need to make “a couple tiny updates” to an already selling, on-the-shelf project I’d just scrap the PIC18 for an EFM32TGxxx part, gcc (shaft of light from the sky, harps playing melodically) and be done with this entire shit-show. Insert whining about the month+ long circlejerk with Microchip Support about the bug in the PICKit3 programmer that is now corrupting the config bits on said product here. Of course, if the code from 5 years ago, even with no changes, still compiled and fit onto the chip it was written for and used to fit on 5 years’ worth of versions ago, and current MCC18 did not insist on dragging in the gargantuan (>4KByte) ‘.code_vfprintf.o’ even if it is not used or referenced anywhere in the code, I wouldn’t even have to bother trying it with the new compiler in the first place….

Soooo…. Install MPLAB X (make tea, a sandwich, possibly a baby or two while waiting for the crunching sounds from your harddrive to finish) and XC8. NB: Licensing is done via a Windows batchfile, completely outside any of the devtools OR their installers. If you have the license file, ignore absolutely anything to do with licensing and install as if you want the “free” version.

License: Run said batchfile. Voodoo happens and it should “Just Work”. (It did. Quite surprised.)

Make XC8 “C18 Compatibility Mode” findable:

The fake “C18” that currently serves as the compatibility layer must first be manually setup in MPLAB X (apparently no autodetect). But first-first, you need to workaround a stupid MPLAB X bug that has been unfixed going on two years now. The bug is you are arbitrarily forbidden from having two toolchains set up whose executables are in the same directory. Unfortunately this is EXACTLY WHAT MICROCHIP’S OWN XC8 COMPILER DOES (of course that directory is already used for XC8 itself, which IS autodetected somehow). So you have to create a fake instance of this directory (symlink or hardlink) with a different name to fool MPLAB X.

NB: The below workaround only works if your filesystem is NTFS. If not, you could also try just copypasta-ing the entire contents somewhere else, and hope this doesn’t break a path dependency somewhere or whatever. I haven’t tried this, but worth a shot.

To do this, you have to first-first-first somehow get a Windows console with Administrator privileges. The way I found that works is to create a batchfile with the contents “cmd <carriage return> pause”, then right-click and “Run As Administrator”. (Using the ‘runas’ command, Windows 7’s answer to sudo, apparently does not work for this as it forces you to know the actual administrator password, and will not accept your user password even if you have administrator privileges.

At the console, cd into the XC8 directory directly above the binaries directory (e.g. “C:\Progra~1(X86)\Microchip\xc8\v1.31\”) and type:

mklink /D _c18bin_ bin

This should result in a message indicating a symbolic link named “_c18bin_” was created.

Now you can actually set up the devtool. Ignore anything on the splash page and go to Tools -> Options -> Embedded -> Build Tools tab. Press “Add…” and enter the fake directory you just created. Specify the location of each build tool (if it exists). NB: For some reason the individual devtool settings ‘disappear’ after specifying them (close and re-open this dialog and “C Compiler” is blank again!). Does this mean it doesn’t need to be specified, or this is another MPLAB X bug and your dev tool will never, ever work? Will soon find out…

Now, try to build project (it will fail).

In “Output -> Configuration Loading Error” tab: “Could not generate makefiles for configuration default.” “XMLBaseMakefileWriter::createRuntimeObjectForMakeRule: null”

In “projectname (Build, Load)” tab: make[1]: *** No rule to make target ‘.build-conf’. Stop.

FIXME: Fix this error…

The Internet, things, and you

Ha ha, apparently proselytizing about the “Internet of Things” is trendy again. Don’t hold your breath kids; until IPv6 is a thing that’s really a thing, enjoy your “small home network of things”, where your game console, thermostat and toaster have 192.168.x.x IP addresses dangling from your cablemodem, and require a 3rd-party cloud service to mediate contact with your neighbor’s toaster*.

Seriously though… if anybody but major datamining companies are going to get remotely enthusiastic about this IoT business, two things need to happen: IPv6 and dirt-cheap low-bandwidth wireless uplinks (think cellphone plan with pay-by-the-byte or 512kb/month dataplans and low/no monthly maintenance fees) so that all the applications (smart stoplights, weather/pollution sensors, whatever) that would benefit from not dangling off someone’s cell plan or cablemodem don’t have to do so. Maybe on the 3rd revival of the IoT hype, about 10 years from now, it’ll really catch on and be actually kind of useful. (See also: “M2M”.)

* The latter shit-uation is due in equal parts to headaches around NAT traversal, service/peer discovery, and the fact that nobody serious (read: businesses) wants to throw in for an open platform when there’s a snowflake’s chance they could parlay their own proprietary stuff into the One True IoT Service. Even with IPv6 and cheap-as-free radio/cell/satellite pipes, the “IoT ecosystem” (I cringe just saying that) won’t be completely free of the need for a centralish service/peer discovery mechanism and (for power-limited systems) somebody acting as mailbox/aggregator/push notifier/whatchamacallit so that the low-power endnodes can talk to one another despite randomly popping onto the network for just a few seconds at a time. Still, a backend you can download and drop on your own cheapo web hosting account if you didn’t want to be tied to said 3rd-party cloud service would be huge in making this, well, A Thing.