I suppose I should know better than to announce what I plan to do the next day. In yesterday's post I made a lot of progress with the HotPi board and was looking forward to having fun with colour LED control and IR sensing. Unfortunately I made hardly any progress, and ended the evening not really any further ahead than I was.

As far as I can tell, it's not really a problem with the hardware, it's just that the combination of work-in-progress documentation and trying to use the board on a system different from the one used by its creator led to a lot of frustration.

The documentation begins with instructions on rebuilding the kernel. I know from past experience that this can be a lengthy process on the Raspberry Pi. Given that the documentation is not very clear on why this might be required, and also has some pretty big gaps in what to enter, I decided to skip this bit and head straight on to building the "userspace" tools.

Just like yesterday's playing with the RTC, this also had its share of quirks. It started well, cloning the source code from the git repository and changing directory into it worked fine. Unfortunately that's when things started to be a bit more difficult. the next instruction was ./build.sh. This refused to run, as it was not marked as executable. However, passing it directly to the shell using . build.sh did seem to do the right kind of stuff. The compilation failed, though, because it could not find the wiringPi library. I have installed that before on a different SD card, so I knew the drill git clone git://git.drogon.net/wiringPi followed by cd wiringPi; ./build. That completed OK, and installed wiringPi n the expected location. Now I could change back to the HotPi directory and run . build.sh again. This time it finished.

The next step in the documentation was to run ./install.sh This was also not executable, but this time it seemed to need a bit more effort. It wanted to install files to system locations and needed elevated privileges to do so. Eventually I found that sudo sh < install.sh seemed to do the trick.

When it came to trying out the examples to switch the LED colour, I hit a brick wall. After digging a bit, and some courteous but eventually unfulfilling help on the HotPi facebook page, I came to the conclusion that there are some significant differences between the OS version I am using for these tests (a recent stock Raspbian Wheezy) and the OS version used by Karl Lattimer (a Media Centre version, probably XBMC). In particular, the installation of the drivers for the HotPi relies on something called "upstart" which examines and manages a directory of service startup scripts.

When I ran apt-get install upstart to see If I had this software I got the following scary message:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libjson0 libudev0 udev
Suggested packages:
  graphviz
The following packages will be REMOVED:
  sysvinit
The following NEW packages will be installed:
  upstart
The following packages will be upgraded:
  libjson0 libudev0 udev
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  sysvinit
3 upgraded, 1 newly installed, 1 to remove and 87 not upgraded.
Need to get 1,009 kB of archives.
After this operation, 950 kB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]

That was enough for me this evening. I think if I am to get the rest of the features of the HotPi working, I will need to either wait for more comprehensive documentation, or bypass the supplied software and write something to talk directly to the hardware. So far, though I have not found anything which explains what is connected to what (no circuit schematic or port connection list for example), but presumably the details are in the driver source code somewhere.

That's for another day, though.