Today has been really busy on the Raspberry Pi front. I’ve gone from a little box I’m not sure what to do with, to a fully working Linux development system. Better than that, it’s already helped me find some bugs in an existing piece of software I was working on.

Things have moved on a lot since I first got my Pi and scrabbled to write a linux “rasbian” SD card to boot it from. One of the first things I did today was to get the latest disk image and burn a new SD card, just to make sure I had the latest version to play with. Then I tried again to connect it to the HDMI port on my 22″ desktop monitor. Switching inputs on this monitor is fiddly and slow – there’s a clumsy sort of soft button, which seems to take a second or more just to think about which input to show next. The long and short of it was no luck. so no screen and keyboard for me.

However, this is not as bad as it seems. In my day job I have been doing a lot of multi-machine development using ssh, and I reckoned I should be able to remotely connect to the Pi from my regular development machine. Looking around the web brought up a lot of pages with worryingly complex descriptions about changing config settings or rebuilding images just to enable ssh in the stock “raspbian wheezy” image. However, it turns out that most of these are obsolete anyway. The current version enables ssh by default. I’m glad, it seems crazy not to do this. Who really wants to be fiddling around with multiple keyboards and screens in this age of virtualization and the cloud.

My current development machine at home, the one I am mostly using over the holidays, is a less-than-modern Windows XP box. Windows does not come with a usable ssh client, so I needed to get one to work remotely on the Pi. In the past I have mostly used cygwin for this. It provides a shell and a bunch of unixy utilities for Windows, including ssh. It’s a bit of a tangle to install, though. Luckily, a few weeks ago, a colleague recommended MobaXterm. This not only provides terminal emulation over a variety of protocols, but also a useful multi-tabbed shell environment. Best of all though, it transparently deals with the messing around to support the running of graphical apps on the Pi, but using the screen, keyboard and mouse of the development machine. The X display system has always been able to do this, but I have never found a tool before which made it this simple. There is also a variety of plugins which you can drop into the directory to support common communication and development activities.

There are a few “gotchas” with MobaXterm, though. The first is that it has an extra non-standard symbol in the window controls (next to minimise, maximise, and close) which super-minimises it to the notification tray on the taskbar. I clicked this by accident and thought the whole app, with multiple sessions open, had just crashed. Don’t be caught out by this! The second gotcha is that, by default, it opens a tab with a shell, a home directory and everything you would expect. However, this home directory is strictly transient. It’s designed for remote working with no impact on the local system and everything in it is discarded when MobaXterm exits. This is fine, unless you do what I did: create an ssh key pair and export the public key to a remote system. A common process which I have done many times. By convention the key pair is stored in a .ssh directory under the user home directory. All worked fine during the initial spot of work. When I came back later though, my connections were cruelly rejected. I had no keys to offer. The solution is simple. In the left panel of the app is a collection of sessions. Simply right-click and create a new “shell” session and you can specify a permanent home directory which will be used every time you run that session. A good answer, just not immediately obvious.

Now that I had a way to get my hands dirty, I wanted to have a go at some C development, I knew I needed a C development toolchain. The obvious choice is gcc, as I am familiar with using that on many linux versions over the years. Luckily the stock OS includes an ARM gcc and development chums such as “make”. Next I feel distinctly uncomfortable trying to do any sort of development without the backup of a good version control system. My current favourite is git, so I wanted to get git on the box as quickly as possible. I opted for the quick and dirty approach sudo apt-get install git-all. This installs not just the core git, but also all the associated tools. Part way through the installation it got in a bit of a pickle, requiring sudo apt-get update and a try again. Eventually it was all installed including, as it turns out, a load more stuff than I really wanted (a whole apache server to run git-web – yikes!). It was comforting to know that the lowly Pi can install and handle all of this baggage, but I doubt that I would do it that way next time.

So having got a toolchain and a version control system installed I was almost ready to rock. But not quite. I am a a big proponent of Test Driven Development (TDD) and would not feel at all comfortable developing software without automated unit tests to back me up. The world of test tools has certainly changed since I last did a major C project. My current favourite is Check. Behind its unassuming sourceforge web page is a powerful and clever unit test framework that brings more unit test concepts to C that I thought were possible. It even runs every test in its own process, with timeouts, so it can give detailed information about successes and failures even if some of the tests have infinite loops or seg faults. Awesome. Installing check on the Pi was as simple as sudo apt-get install check.

Next post, I’ll cover a bit more about what I did with all these C tools, and what I learned from it.