Maplin's Touch LCD Shield for Arduino

I've been playing around with Maplin's Touch LCD Shield. It's not a bad device (it does seem to be a little slow, but I suspect that's mostly down to the library being used to drive it. That said, I did take a while to get it working since there's not a lot of documentation for it and I notice that I'm not the only one who had problems. So partially as a reminder to myself (and partially to make this visible to search engines) there's what I had to do.

Download the correct library from linkshield's wiki. I eventually downloaded the v2 library.
Copy the example program (again from the wiki).
Fix up the compile errors in that example program - I guess the library was updated AFTER the example:
1. Remove the declaration of TS_MINX, TS_MAXX, TS_MINY, TS_MAXY (the library has these as #define's and the compiler gets quite confused.)
2. Changed the test p.z > ts.pressureThreshold to ts.isTouching() (The library doesn't have a pressThreshold field and the point class doesn't have a z field. On the other hand, the library does have the isTouching method!)
3. Changed the initTouchScreenParameters method to initialise a touchscreen via TouchScreen(XP, YP, XM, YM) and deleted the setting of TS_MINX, TS_MAXX, TS_MINY, TS_MAXY (again the compiler gets quite confused).

I was then able to run the demo, although the touch output seemed to be completely reversed, so I edited my library header file to switch the values of TS_MIN* with TS_MAX*. This seemed to fix the problem.

I've, for the time being at least, used it to act as a monitor for my Thinkpad that runs my linux server (that is, I got the linux server to talk to it!)

Recovering from an Oops! Backup rollback error

After a problem with coretemp that hard crashed my CPU (at least that's what the symptom looked it), on the subsequent reboot, Oops! Backup reported that it attempted to rollback the backup that was in progress at the time. Sadly the rollback failed and left sufficient damage to prevent backups from proceeding. To be fair to Oops! Backup, to fully prevent this would require write-ahead buffering to be disabled (it's enabled by default on windows systems as for most consumer system the lost of performance is considered too expensive.

I recovered from the problem with the aid of a luckily quite recent 2nd backup. My steps were:

Exit the existing Oops! Backup instance
Move the existing backup to a safer place (I should have used the windows "robocopy" command from the beginning rather than the GUI. Robocopy can cope with long path names and deep directory structures and is faster than the GUI.
Copy the 2nd backup to where the existing backup had been
Start Oops! Backup and run a backup. This correctly recognised that plenty of files needed to be backed up.

This does mean that I've lost a couple of days of history - but, for me, the only ones that mattered are the changes to my wordpress plugins and those are already under change management via fossil.

running popfile as a daemon process

This is just a note to myself in case I need it 🙂

To run popfile as a daemon process on Ubuntu. I did the following:

Created a popfile user and home directory and gave it a copy of the popfile executables and copied across its data into /var/popfile.
Created a /etc/init.d/popfile file
Issued
```
sudo /etc/init.d/popfile start
```

It's worth noting that popfile has data in /var/lib/popfile when it comes to backing it up. When restoring/transferring these files I also needed to ensure that the popfile userid owns these files.

running fossil as a daemon process

This is just a note to myself in case I need it 🙂

To run fossil as a daemon process on Ubuntu. I did the following:

Created a fossil user and home directory and gave it a copy of the fossil executable and the website fossil file
Created a fossil/etc/init.d/fossil file
Issued
```
sudo /etc/init.d/fossil start
```
Run sudo update-rc.d fossil defaults to get the init.d script run at system start.

This /etc/init.d/fossil runs multiple fossils.