Well Screw you Microchip...

[CJay]

Digging out an old project for a nixie clock I find it'll no longer compile under MPLABX/XC8 because PLIB is no longer provided.

OK, so I'll modernise it and use the MCC plugin.

Except, well the bloody chip I used (18F2550) is no longer supported.

So, my options are to either find a copy of PLIB.H (shoould be fairly easy as I tend to archive old dev tools) and crowbar it into MPLAB 3.45/XC8 1.38 or what?

Am I just supposed to ditch all my old code because their preferred method of supporting chips is limited to a tiny handful of parts?

[JPortici]

lol
everything should still be available in the archive section i think? an older version of XC8? from a fast google search XC8 v1.28 was the last one to provide them

[mikeselectricstuff]

MPLAB8 is still available, and a driver switcher is available to flip programmers between MPLAB8 and MPLABX

Of just pull the bits you need out of out of PLIB

[andersm]

PLIB is available as a separate installer right on the compiler download page ("Legacy Peripheral Libraries").

[Ian.M]

This is not a MPLAB 8 vs X issue.  When it was decided to freeze the XC8 PIC18 PLIB, it was re-packaged as a separate download, which can be found on the download tab of the XC compilers page.  Simply scroll down to 'Legacy Peripheral Libraries' 'PIC18F' and pick the installer for your OS.  Run it and tell it where your XC8 folder is.

Unfortunately there are a few devices that have had changes to the headers that break compatibility with the prebuilt library for that device, so if you get build errors referring to incompatible definitions of SFR bits that don't occur under XC8 v1.34 or earlier, you have to rebuild PLIB for the device you are using under your current XC8 version, or disable linking with the prebuilt PLIB, and copy the PLIB sources for the functions you are using to your project.  You may also need to fixup the offending bit names in the library source.

[Bud]

If one wants to torture a man, he should make him learn Microchip Harmony.

[CJay]

Sorry, my bad, should have said MPLABX 3.45.

All sorted now and fortunately I archive old copies of dev tools myself (been burned before) so I had the relevant XC8 installer already and a lesson learned (again) which is to include the IDE/compiler version numbers in the comments.

Bit of a non issue really I suppose but for a company with such a rich portfolio of legacy parts you could end up with a very bloated computer by installing the files to support one's old designs unless you're willing to maintain and constantly update old projects to meet current compiler setup.

[dmills]

That is what a TB hard drive full of virtual machine images is for....

We literally create a new VM image for every project with everything needed to build it included, that way tools vendors playing silly buggers is less of an issue.

Costs some disk space, but that is cheap.

Regards, Dan.

[aandrew]

We literally create a new VM image for every project with everything needed to build it included, that way tools vendors playing silly buggers is less of an issue.

This is *exactly* what I do as well. To hell with trying to keep a machine in working state without Windows updates breaking things or hardware dying; spin up the VM on any machine (even a server in a server room) and your dev environment is always there and *exactly* in the state you left it in. Snapshots are also great for testing whether an update breaks something or not.

+1 more people need to know about this method of (embedded) development.

[CJay]

It's a damn good idea to archive VMs, I like it.

[Jeroen3]

A VM per project is a bit excessive for me. You'll still need to be able to attach the debugger or dongles. Which don't work.
I know the ulink works, but never could get tasking and silabs to compile and debug. Maybe it's better now?

However, I do keep versioned backups of ALL SOFTWARE I install. That's 100 GB and counting today, for home use. With parity files! You'll see that when you need them, they're bitrot.

I also started the habit of putting documentation and appnotes inside git. They make large blobs, but I don't care. Try finding a datasheet for obsolete parts.

[chickenHeadKnob]

I also started the habit of putting documentation and appnotes inside git. They make large blobs, but I don't care. Try finding a datasheet for obsolete parts.

You are a genius, why didn't I think of this. I have a shit pile of random and lost documentation that I was man handling in no consistent way as I don't really know how to organize it.

[brainwash]

Debuggers can be attached to VMs, most USB devices can be redirected to the VM, at least Oracle VBox and VMWare (the ones I'm using).
I'm also pushing datasheets to my git repositories, as well as all measurements, notes, prototype photos, everything.

As an extra step, for all my Arduino and Javascript project,s I'm pushing the small 3rd party libraries as well. Sometimes they have bugs or unperformant code that needs to be modified, other times you cannot just rely on free hosting to be available 3 years from now.
For Java (offtopic, but a bit related) you have the choice of using Maven repositories - which is nice when it works - and the libraries are usually more mature. However, after some years I find that some library updates break existing projects or the needed dependencies cannot be found. This is why I'm advocating that, for a project which you don't want to constantly maintain, you keep a local copy of all the dependencies.

Back to the topic of VMs: I use them a lot for my personal projects but I find that in large companies they are seldom used. Probably because they don't want to deal with the hassle of securing, storing and transferring gigabytes on the slow corporate network. For example my last big client had the USB ports blocked on all computers but they were accessible through the VM.

One VM per project is a bit overkill, a better approach is to build a new VM every few years or so when the tools and OSs change significantly. An example: I cannot maintain an old Windows Phone 7 project because the MS tools require me to build for the latest WP iteration and the new tools only run on windows 10. While this is pretty specific it can be indicative of the things to come.
Also, what about using devices with unsigned drivers? For old unmaintained devices the logical thing is to dedicate an XP machine for those.

Another issue is site availability. Google code went down a few years ago, not sure if anyone predicted that. Github looks strong now but can you really rely on it to be there 5 years from now? Are you relying on the archive section of Microchip or archive.org to resolve dependencies? I think it's obvious that we need several backups in different physical locations.
Offline storage is pretty cheap, 100$ for 4TB, it can probably hold at least 100 projects with all the VMs and repositories.

That was a long rant, I'm going to stop now.

TL;DR: create VMs for each generation of projects, commit datasheets and project notes into version control, commit used library versions to avoid breaking updates or future lack of availability, keep offline backups of everything.

[KL27x]

Bit of a non issue really I suppose but for a company with such a rich portfolio of legacy parts you could end up with a very bloated computer by installing the files to support one's old designs unless you're willing to maintain and constantly update old projects to meet current compiler setup.

+1. And glad to see you got it sorted. I like your idea of including compiler revision to my project text file, just in case.

[CJay]

Microchip doing you a favor for still supplying this chip. Superceded a long time ago. If doing any new design or any volume, you probably should consider to replace chip with new one that has superior features and performance at 1/2 the price. BTW, if you insist on using this chip and need some, pm me. I have a small stock of these (QFP) leftover from a project.

I agree and I thank them for it too, I do like their products (I know, they're not the best, easiest, elegant, whatever brickbat people throw at them but...) and it makes it easier for me if I can buy old parts easily

 This isn't for a commercial project so there's no ongoing supply need, I do use more modern chips, the main reason I was digging through old code was that I had answered another post here about using an RTC with nixies and wanted to show some of my code.

I think it'd retarget really easily as it's not using any specific or unique feature of the chip I chose and it's nowhere near approaching the memory or performance limits of the chip either, it was just a chip I had at the time.

[KL27x]

Kewl. I edited my post because I didn't want to be pedantic. But not fast enough. Glad you did not take it the wrong way. Cheers.

[hans]

I think more people should realize they are their own librarian. No one else can fix that for them. Archive as much as you can in a way that makes it manageable for you to find it.

At home I keep a folder of datasheets and stuff around whenever my internet goes down. I've had this happen several times at work, and seeing productivity drop to 0 because of that is not fun.
For work I probably keep datasheets per project because I want to know which datasheet revision I worked from. At home I'm often not that fussed about that kind of stuff.

GIT/SVN are a must for projects. For open source there is github, for closed source there is bitbucket, and moreover there are several other selfhosted GIT servers like gitlab so you don't push anything out of your firewall at all.

VM's work fine for USB stuff nowadays in my experience. VBox also can clone and link VM images, potentially saving some storage if you archive 1 base image and branch projects from there.

However not entirely sure how reliable it will work for archival purposes. It limits you upgrade path of VBox because you should upgrade the VBox guest extensions for every VM, which basically makes this a throw-away solution. If you don't do this you could see random crashes and hangups of VBox.

Nevertheless I use this setup on my laptop for day to day activities. It also nice to care less about health of installations if you know you can just roll back Windows a minute or reinstall an environment from a fresh image in like 15 minutes.

[CJay]

I think more people should realize they are their own librarian. No one else can fix that for them. Archive as much as you can in a way that makes it manageable for you to find it.

Indeed, I keep datasheets, manuals, schematics, anything I search out on local storage, changing filenames to suit where necessary and to make them more obvious, app notes become ANxxx-whatever function-manufacturer for instance.

The main problem I had was that I'd not expected support for a still available part to have been 'removed', it was fairly trivial to reinstate it once I'd worked out which versions of the compiler had it.

GIT/SVN are a must for projects. For open source there is github, for closed source there is bitbucket, and moreover there are several other selfhosted GIT servers like gitlab so you don't push anything out of your firewall at all.

I found GIT/SVN a pain it the backside for my needs (I may have fundamentally misunderstood the various options/methodologies though and will probably revisit them again in the future), I tend to sync my projects to online and local storage daily when I'm working on them and am self disciplined enough to version things in comments, I've added one extra line to indicate compiler/IDE version so I don't have to spend time working out which versions might compile projects.

[brainwash]

The main advantage to VCS is that it gives you a log of everything. Even if you are disciplined and put comments everywhere you might miss an important one. You can then go back to a previous working version and see what changes broke the functionality. The other scenario is someone else working on your code (design) or if you publish it somewhere.

GIT shines compared to SVN because you can move your working folder to any location and continue working, you always see the full history and you can sync online and offline in multiple locations. Working with bare folders does not make a lot of sense if you can set up git. Ok, you can work with bare folders AND use git, but as a local repository, it will then act as a basic work log.

However not entirely sure how reliable it will work for archival purposes. It limits you upgrade path of VBox because you should upgrade the VBox guest extensions for every VM, which basically makes this a throw-away solution. If you don't do this you could see random crashes and hangups of VBox.

I'm not sure I understand, I never had that issue. But I don't use branching (I assume you are referring to snapshots), I just copy a base image to create a new one. There might be the issue of duplicate HDD IDs, but that can be solved with some fumbling in the command line.

[hans]

The issue is that if the guest drivers and host Vbox software version differ, it could result in instability performing certain tasks. For me in particular this includes shared folder access and video acceleration.

It's a possible to use it but they recommended not mixing versions up. But if you need to update the software for every install you may fire up one day, that's a lot of work.
However I guess you could also update it at the moment you plan to use it.

In my case I have linked VM images for throwaway environments, and just keep them up to date manually whenever needed. It aren't that many VM's, only like 5 or so. However unfortunately this software up does duplicate 5 times over the drive, instead of a single time which is the thing so advantageous about linked images.

I found GIT/SVN a pain it the backside for my needs (I may have fundamentally misunderstood the various options/methodologies though and will probably revisit them again in the future), I tend to sync my projects to online and local storage daily when I'm working on them and am self disciplined enough to version things in comments, I've added one extra line to indicate compiler/IDE version so I don't have to spend time working out which versions might compile projects.

I guess you should, but I can't make that call for you obviously.

I like git because it allows me to continue having version control even without internet. Commits are first made local and can be pushed across multiple servers. Pull requests are nice to merge software tickets into the main line code, allowing a point of software review when the pull request is accepted/denied.

GIT is not as powerful for binary stuff because you can't view a diff of the commit (you just see the file has changed). Something like rsync, owncloud or dropbox will probably work just as well, although automatic tools wont allow you to add a revision message easily.
Also for me I think it's crucial that you have some revision history so you can recover old revisions and deleted files, not just as a backup utility.

[Bassman59]

GIT shines compared to SVN because you can move your working folder to any location and continue working, you always see the full history

That's true with Subversion, too. On several occasions it was more convenient to copy a working copy from my main machine to my laptop. Remember that hidden in the working copy is the .svn folder, which contains the "pristine" copy of what you checked out (so that diffs don't need to hit the server).

[andersm]

There are tools, like Vagrant, that aim to provide scriptable and easily versioned virtual environments.

[Howardlong]

Regarding the use of VMs, which I think is absolutely essential for medium to long term project maintenance, please be aware that some compilers such is Microchip's XC series are not supported under a VM unless you purchase a VM licence (a further $1k or so) on top of the server-distributed licence. VM installation is not "supported" at all on node locked licences as far as I know.

In reality node-locked versions seem to work with a caveat. Make sure the MAC address of the VM NIC remains constant wherever you deploy it.

Another trick to allow portability is to add an additional dummy NIC to the VM which you don't connect to anything, give it the registered fixed MAC address that you have a licence for, install the licence(s), and then you can run as many copies as you like where ever you like.

Any long term VM you have should be on a host-only network to avoid suffering hours of irritating updates that will likely break your environment anyway.

[Karel]

Regarding the use of VMs, which I think is absolutely essential for medium to long term project maintenance, please be aware that some compilers such is Microchip's XC series are not supported under a VM unless you purchase a VM licence (a further $1k or so) on top of the server-distributed licence.

Apart from real support from Microchip techs, there's no need for a licence for Microchip compilers because they are using GCC which is free.
So, if it's only for the sake of unlocking the optimizations of the compiler, you can perfectly legally patch them yourself without the need of a licence.
Patching takes only 5 minutes.

[JPortici]

Regarding the use of VMs, which I think is absolutely essential for medium to long term project maintenance, please be aware that some compilers such is Microchip's XC series are not supported under a VM unless you purchase a VM licence (a further $1k or so) on top of the server-distributed licence.

Apart from real support from Microchip techs, there's no need for a licence for Microchip compilers because they are using GCC which is free.
So, if it's only for the sake of unlocking the optimizations of the compiler, you can perfectly legally patch them yourself without the need of a licence.
Patching takes only 5 minutes.

not xc8 i believe and that's the one that really need optimizations

[Karel]

Regarding the use of VMs, which I think is absolutely essential for medium to long term project maintenance, please be aware that some compilers such is Microchip's XC series are not supported under a VM unless you purchase a VM licence (a further $1k or so) on top of the server-distributed licence.

Apart from real support from Microchip techs, there's no need for a licence for Microchip compilers because they are using GCC which is free.
So, if it's only for the sake of unlocking the optimizations of the compiler, you can perfectly legally patch them yourself without the need of a licence.
Patching takes only 5 minutes.

not xc8 i believe and that's the one that really need optimizations

You are right. I forgot that because I stopped using 8-bit mcu's long time ago.

[Howardlong]

Regarding the use of VMs, which I think is absolutely essential for medium to long term project maintenance, please be aware that some compilers such is Microchip's XC series are not supported under a VM unless you purchase a VM licence (a further $1k or so) on top of the server-distributed licence.

Apart from real support from Microchip techs, there's no need for a licence for Microchip compilers because they are using GCC which is free.
So, if it's only for the sake of unlocking the optimizations of the compiler, you can perfectly legally patch them yourself without the need of a licence.
Patching takes only 5 minutes.

It took a lot longer than 5 minutes to find all the right information the last time I tried a couple of years ago. In addition, Microchip histroically have fiddled with the way they do things meaning that any process that might've worked in the past sometimes doesn't work in newer releases. In the end I considered it not worth the effort to fanny about and renew my compiler licences when I need to. I've renewed them all this year, but this was the first time for over two years I've needed to.

I'm not excusing the compiler pricing and licensing model they use, just that sometimes life is too short. I simply found that the cost of renewing the compiler license was less than the cost of time lost to build my own, so it was a simple commercial decision.

[Karel]

It took a lot longer than 5 minutes to find all the right information the last time I tried a couple of years ago.

Try this: https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099

[aandrew]

A VM per project is a bit excessive for me. You'll still need to be able to attach the debugger or dongles. Which don't work.

I have only ever found ONE debugger that didn't work in a VM, and it was pretty unstable outside of the VM as well. VMWare and VirtualBox both have excellent USB1.x/2.x passthrough support, and I've had some limited success with USB 3.0 passthrough with VMWare Fusion.

You're correct that for "real" VM (where your image is on a server somewhere) and you're using RDP to connect, USB-over-LAN is a fair bit trickier, but running a local VBox or VMWare VM it pretty much just works every time.