MoPi: mobile and flexible powers supply for Raspberry Pi

Over the last few days I have been reading quite a bit about the MoPi: Mobile and 24/7 Power for the Raspberry Pi. I have had an email conversation with Hamish Cunningham and seen it mentioned in several places. The Kickstarter campaign for this clever little board is coming to an end, so I thought I'd add my voice encouraging people to take a look and help reach the next stretch goal before the kickstarter closes. This is, of course, slightly self-interested - as a backer myself, every stretch goal reached adds value to the money I have already pledged ;)

Obviously I have not had a board to look at and play with yet, but it certainly looks interesting "on paper". I'm particularly taken with the ability to hot-swap power sources, to keep it running even while changing batteries, and the fact that it is slim enough to fit inside most ordinary Raspberry Pi cases. I also like the way that it provides easy access to the main GPIO pins, so it can be used relatively easily in conjunction with other boards and connectors. I've certainly moaned about that several times!

Boeeerb MotorPiTX Update

If you read my recent review of the Boeeerb MotorPiTX, you will be aware that I had trouble with powering the Raspberry Pi and the MotorPiTX board from the MotorPiTX power socket, and resorted to ignoring the smart power circuitry and using the usual Raspberry Pi micro-USB power input. I'm happy to report that this was not actually a problem with the MotorPiTX board, but rather with the way I had chosen to power it.

I had been doing some experimentation with battery-powered circuits, particularly using an Arduino Uno, and I had on my desk a 9V PP3 battery pack with an appropriate barrel jack, so it seemed an obvious choice to plug that in to the MotorPiTX power input. The 9V was seemingly enough to power up the MotorPiTX regulator circuit, but I now realise that the battery was not pushing out enough juice to reliably start the Raspberry Pi. This was particularly apparent because, althoiugh the lights were flickering, it never got as far as displaying anything on a monitor, or even attempting to connect to the network. When I replaced the battery pack with a 9V 500mA "wall wart" power supply the Raspberry Pi started with no problems. The Relay does still clatter a little when power is first applied, but after that, the little button works great.

It seems that the system, when powered from the MotorPiTX board, is pretty sensitive to power, though. Flushed with success after getting the Raspberry Pi started and stopped a few times, I tried to run the simple motor control example I used in the previous post. I'm guessing that this drew too much power from the little wall-wart, as it immediately removed power and crashed the Raspberry Pi. A bit discouraging, as the whole point of the smart power-supply circuitry is to help prevent such hard crashes. I'm sure that with a sufficiently powerful energy source this would not be a problem, but it is pretty drastic. Presumably this could happen at any time to a deployed project when a motor happens to ask a bit too much of the available power. In an ideal world the CPU would keep running and be able report an error or try some other fallback if a motor fails or draws too much power.

For a reliable system, I would either want some sort of "ring fenced" power available to the Raspberry Pi which can't be drained by motors, or (probably more likely) two separate power systems, one for motors and one for electronics. If we still want the comfort of a smart power supply, then a separate unit such as a Pi Supply seems a reasonable choice.

Building my own Arduino: shrimp and ArduinoISP

10 low-cost Arduino prototype PCBsA few days ago I wrote about a "learning timer" that I had built using an Arduino Uno. Arduino boards are pretty easy to come by, and also easy to work with, but can be a bit expensive to build in to things (a genuine Arduino Uno from the manufacturer will set you back 20 Euros, for example) Once I had got my circuit and software working on the real Arduino, the next step was to see how cheap and simple a circuit I could make that would also work.

Luckily, some excellent hackers in Morecambe have already done the basics, in a circuit called the shrimp. At its most minimal, this is just an AVR microcontroller, a crystal, a capacitor, a resistor, and a couple of wires. They also have a variety of (slightly) more complex designs which are better at various aspects, but for now, this should be enough for me.

SAM_0202

I started building my shrimp by gathering the components and following the steps in the "blink" example. This takes you all the way through building a shrimp on a breadboard, programming it and running the downloaded program. I had ordered some AVR ATmega328 microcontroller chips and some appropriate capacitors and crystals a few months ago, and had plenty of resistors, LEDs and wires in my parts box, so I followed the steps up until I got to the stage of connecting it to the PC for programming. This is where I hit my first problem.

The shrimp tutorial recommends a CP2102 USB/UART module for programming, and I knew that I had a few of this sort of thing lying around. It turned out that the Arduino is a 5V system, and all the USB serial boards I have are 3.3V ones for use with Raspberry Pi. I crossed my fingers and plugged it in anyway. However, when I came to try and program the board, I got the infamous

avrdude: stk500_getsync(): not in sync: resp=0×00

from the Arduino IDE. This error happens whenever the IDE cannot communicate with the microcontroller, and can be due to many different problems. I went over my wiring very carefully, and did find a mis-placed LED leg, but even after i fixed that, no luck. I even tried adding a 5V power supply to the breadboard to power the chip, but still the same error.

After some more thinking, it finally occurred to me. The microcontroller chips I had ordered were the (slightly cheaper) "raw" version without an Arduino "bootloader". The bootloader is a small program that runs on the microcontroller and is responsible for downloading new application programs. To get past this hurdle I needed a microcontroller with a bootloader. To test my hypothesis I levered the ATmega chip out of an Arduino and plugged it in to my shrimp. To my delight, it worked. Even better, it worked and communicated powered solely by the 3.3V from the serial board.

10 low-cost Arduino prototype PCBs

This was not a permanent solution, though. I had hardly managed a cheaper circuit if I had to cannibalise a working Arduino to build it! I vaguely remembered that I had seen something that looked interesting along these lines, and a bit of searching turned up a clever self-build bootloader programmer at Adafruit called "ArduinoISP".

Months ago, while poking around looking for stripboard I found someone selling a ten pack of bare-board Arduino shields for just a few pounds. As luck would have it, these boards were pretty much identical to the one in the Adafruit kit. All I needed was the ZIF socket which I got for about £2.50 from proto-pic. The wiring instructions were straightforward, and the programming software installed and ran on my Uno. Within a few minutes of completing the build, I had a freshly-bootloadered Atmega328 humming away nicely in my breadboard shrimp.

SAM_0201

SAM_0208


Filled with enthusiasm, I had tp push on and convert the breadboard shrimp to a learning timer. I removed the LED and it's current resistor, and added the "flowing water" LED array, the two buttons and the buzzer. A quick program from the same Arduino sketch that I used on the "real" Arduino Uno and I have a completely self-built learning timer. Here are the two versions for comparison.

The next step is to solder the circuit on some proto-board, add a battery power supply and put it in some sort of enclosure. Then I'll finally have something that anyone can use (if they want to, of course.) For today, though. I'll stop here.

Boeeerb MotorPiTX

Following my review of Ryan Walmsley's RPi MCB, and my previous review of the RasPi Robot board it only made sense to also assemble and review the Boeeerb MotorPiTX which I also received recently.

MotorPiTX components

The MotorPiTX is a multi-function board. It has two A/B motor drivers, two servo controllers, a bunch of headers and most interesting of all an "ATX-style" soft power switch. As with so many boards, this was launched through Kickstarter. The project was successfully funded, and several stretch goals were met, so I also got some handy motors, wheels amd a battery pack included. There seems to have been some sort of mis-calculation with the prices and postage costs, though, which has meant that the kits are being sent out to backers in dribs and drabs. The first ones were delivered last September, but mine only arrived last month.

SAM_0199

The kit is naturally more complex than the single-purpose RPi MCB, and was more fiddly and time-consuming to assemble. Unfortunately I could not find any detailed assembly instructions. The kit came with a diagram, a parts list, and some assembly hints, but not the kind of step-by step instructions that often accompany Raspberry Pi kits. There was also the problem of board versions. The web site and the kickstarter page are full of pictures of earlier versions, but so far I have not been able to find a single picture of an assembled "1.0" board. This makes some things (choosing and placing headers, for example) quite tricky. If It helps anyone else, here's a picture of mine. I have not populated all the headers, but I hope I got the rest right!

The other assembly problem was the surface-mount micro-USB socket. The pads on this are so tiny that I did not feel comfortable trying to solder this in place. Luckily, the instructions suggest to leave it off if it is too tricky!

Eventually I got the board to a point where I was comfortable with powering the board on and trying to test it. My initial attempt was to plug in a 9V PP3 battery to the barrel jack on the board. When I plugged it in the relay clicked alarmingly and the power light flashed, but then the system was quiet again. Pressing the power button on the MotorPiTX switched the Pi on, and it flashed its LEDs pretty much as usual. This was when I hit my first real problem. I don't usually connect a keyboard and screen to my Pis, preferring to work using ssh and remote X windows. However, when I started the Pi powered by the battery connected to the MotorPiTX, for some reason it did not start up the networking. To get a network connection, I had to power the Pi from its own microUSB connection, and forgo the soft power switch. I'll investigate this further some other time.

Having successfully powered up the Pi and the MotorPiTX board, and got a network connection, I now wanted to try the motor control. Wiring the motor was a bit more tricky than the RPi MCB, as the MotorPiTX just provides pin headers rather than screw terminals. If I had had some spare screw terminals I would have soldered them in place instead, as they seem a much better way to connect motors. Eventually, though, I used a small breadboard to connect the bare wires from my test motor to some header wires.

For comparison purposes I wanted to run the same two-second forward and backward test as I did with the RPi MCB. I had that code on the Pi already, so my first attempt was to just change the pin numbers and run that one. Unfortunately, this did not work. My next port of call was the example code. There are examples of using all the board features on GitHub, so I downloaded the motorpitx python library, and knocked together a small python program to use it:

import motorpitx
import time

motorpitx.motor1(100)
time.sleep(2)
motorpitx.motor1(-100)
time.sleep(2)
motorpitx.cleanup()

MotorPiTX uses PWM percentage for speed control, so the example above sets motor 1 to full speed ahead, waits for two seconds, sets motor 1 to full speed reverse, waits for two seconds, then stops and cleans up the outputs. Pretty straight forward really.

In conclusion, this is an interesting board with plenty of features. While I can see the theoretical advantages of the "ATX" power supply circuitry, it does complicate the board, and I could not get it to work properly. If all you want is no-nonsense control of two motors, and you don't feel like wiring your own controller, then the Ryanteck RPi MCB is the obvious choice. If you also need servo control and general purpose I/O, then the Boeeerb MotorPiTX seems a good all-rounder.

Arduino Learning Timer

It's not Raspberry Pi, but I had a hankering to make something of my own design and Arduino just seemed simpler.

This project is a learning countdown timer. In its simplest form it just has two buttons and a buzzer. For Extra bling, though, I have added a "flowing water light" (a board with eight LEDs and a multipack resistor) to show what's going on inside. Although the system will work fine without the LEDs it is much prettier with them!

Making an interval timer is often complicated by problems of calibration and complex input and output just to set the time. So I wondered if I could solve both those problems by entering the interval in its native format - as a duration. This approach works on any microcontroller which runs at a reasonably steady clock speed, regardless of what that clock speed is. I'm hoping it will also be workable with a minimal AVR circuit (such as a shrimp) or maybe even one without the crystal, if I can work out how to program it.

Use is simple. To teach it a duration press the LEARN button once to start and again to stop. During learning the LEDs will show a "walking dot". Once you have taught it a time, press green to count down to that time, then beep.

Code at https://github.com/efficacy/learning-timer.

The whole thing took me a couple of hours to design and build.

RyanTeck RPi MCB motor control board

It's been a while since I did any assembly, but I seem to have built up a pile of bits again, so it's time to break out the soldering iron...

First in the queue is the RPi MCB (Motor Control Board), the first hardware product from Ryan Walmsley (the Rastrack guy).

RPi MCB kit

RPi MCB components


This is an interesting item in many ways - financed through the hybrid-crowdfunding site Tindie, it shows that with a bit of creativity and perseverance, anyone can stand a chance of making and selling electronic stuff. It's a pretty simple circuit, essentially just a SN754410NE chip and some connectors, but it still manages to provide a useful addition to the Raspberry Pi.

RPi MCB almost complete

RPi MCB  populated


Assembly was pretty simple, following the on-line assembly instructions although the screw terminals needed a bit of a wiggle and push to get them fully seated. This is probably a good thing, as it both made them easier to solder, and might even help keep them solid in the face of vibration.

Once I had all the components in place, I thought I'd have a go at doing something with it, but was brought up short by the following comment at the bottom of the assembly instructions

Next why not visit our simple coding tutorials at <Coming soon!>

There are actually a few small hints (GPIO pin numbers and so on) on the RPi MCB product page at Ryanteck, and some more in a Google Document but it is a bit disappointing that the assembly page doesn't even include any way of testing that it has been assembled correctly.

Eventually I did manage to test it out. The example code in the Google document did work (when run using sudo) but as it is an infinite loop it never got to the GPIO cleanup, and thus left the motor running. After a bit of scrabbling with a battery connector I stopped it by removing the power. The lack of a GPIO cleanup also led to a lot of complaints about pins in use. As a more friendly test, I suggest:

##Simple motor script for the RTK-000-001
import RPi.GPIO as GPIO
import time
#Set to broadcom pin numbers
GPIO.setmode(GPIO.BCM)

#Motor 1 = Pins 17 and 18
#Motor 2 = Pins 22 and 23
GPIO.setup(17, GPIO.OUT)
GPIO.setup(18, GPIO.OUT)

#Sleep 1 second then turn 17 on
GPIO.output(18, 0)
time.sleep(1)
GPIO.output(17, 1);
time.sleep(2);
#And now the other way round
GPIO.output(17, 0)
time.sleep(1);
GPIO.output(18, 1);
time.sleep(2);
#And final cleanup
GPIO.cleanup()

which just turns each way once for two seconds, then stops and cleans up.

In conclusion, this is a nice, simple little board which "does what it says on the tin". It could do with a bit more thought on testing the board as part of assembly, but essentially it works.

Well done Ryan, I look forward to more ideas!

Using Raspberry Pi and Chef to set up remote servers (Part 1)

I always have several different projects on the go at any one time, and recently this has meant that I have been setting up and tearing down remote virtual machines frequently in order to try out different system configurations and run experiments. As you might imagine, I got well and truly sick of slogging through a growing list of manual operations to get each fresh remote system installed and set up before I could even start the real work. So I decided to look into the technologies available for remote automated system management.

I started by just gathering my hand-written instructions into an executable script. For some parts of the setup(running apt-get update is hardly rocket science, for example) this was easy, but I quickly found that many of the commands I would type manually required user input, or complex edits to config files, or might only need doing in some situations. I toyed with the idea of pushing forward with my scripting approach and trying to program all these special operations, but decided that this would probably take a lot longer to do than the projects I was supposed to be doing.

Looking a bit further I found a cluster of remote administration tools, including chef, puppet, saltstack, cfengine, ansible and so on. I spent several days trying to get things working using some of these, and following all sorts of different tutorials. In pretty much every case something either did not work, or trying to find out how to accomplish what I wanted took way too long. It didn't help that typical tutorials for these systems make all sorts of assumptions about the system being used to run the tool - particular operating system versions with particular software installed, and so on.

Eventually I did get something working using Chef, but only by abandoning the official chef tutorials (which seem more concerned with getting you to register with the company than actually helping with real tasks), and trying other stuff until I got something working. The most useful tutorial turned out to be Daniel O'Connor's blog post on Managing Raspberry Pi with Chef & Bitbucket. This gave me what I needed: how to get started with an absolute minimum of dependencies.

I had had so many problems and aborted attempts that I could no longer trust the state of my development machine, so I went through the tedious process of setting up a completely clean virtual machine to use. In this case a VirtualBox machine, installed from a CD image of Linux Mint 15. Once I had worked through all the installation screens and could log in to the machine, I was able to install a few things (ruby, bundler, git and so on) and follow Daniel's steps to get the remote machine up and running. Flushed with success I checked stuff into my git repo and went home.

The next day I was somewhat disappointed. I'm guessing that I did not shut down the virtual machine properly, as it would not start up and I had to go back to an earlier snapshot. Luckily I was able to get things back in operation relatively quickly, but it did make me think. Perhaps setting up a development box in a virtual machine on a desktop computer is both overkill for this task, and not very portable. Inspired by the Xtravirt vPi, I decided instead to set up a Raspberry Pi image with the tools I need, so I can manage my remote machines from anywhere with an ethernet cable and some USB power, and without any worries about incompatibilities or missing software.

The installation process is as follows:

Start with a fresh Raspbian image, and write it to an SD card as usual. When it is written, stick it in a Raspberry Pi, plug in an ethernet cable to a nearby router, and apply some power. Don't bother with screen and keyboard etc. This is designed to be a "headless" device controlled from another computer. You will need something which can make an ssh connection. If you don't already have one, then I can highly recommend MobaXterm. Depending on how your local network is configured you can probably ssh to something like pi@raspberrypi.local, but you may have to use the IP address instead. Once you are connected, the real stuff begins.

First, make sure we have the basic software needed:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install ruby1.9.3 ruby1.9.1-dev rubygems bundler rake

Now we can create a skeleton installation. Note that although this is based on Daniel's instructions, it's not quite the same, as in this case we are using the Pi to manage a remote system, rather than using a local machine to manage the Pi.

mkdir skeleton
cd skeleton

# Set up bundler to manage Ruby dependencies
bundle init
echo 'gem "knife-solo"' >> Gemfile
echo 'gem "berkshelf"' >> Gemfile
bundle

# Initialise the Chef tools "Knife" and "Berkshelf"
knife solo init .
berks init (select "y" to overwrite ".gitignore"; select "n" to overwrite "Gemfile")

At this point we now have an empty (but hopefully working) Chef installation. To use it requires a few extra steps, but I have found that putting them into a simple script makes things a lot easier to remember. I saved the following as rebuild.sh:

#!/bin/bash
# usage rebuild.sh <ip address of fresh host>
dest=$1
  
#remove any old key for that ip
ssh-keygen -f "$HOME/.ssh/known_hosts" -R $dest
  
#copy my credentials to allow smooth login
ssh-copy-id root@$dest  # and enter root password, just this once
  
#install chef on target
knife solo prepare root@$dest
  
#run chef to install the configired recipes from nides/$dest.json
bundle exec knife solo cook -VV root@$dest

running this script (with the ip address of the sever to be configured as a parameter) should connect to the remote system, install ssh credentials, then install the server end of Chef. You will probably need to enter the server root password the first time you do this.

That's about it for this post. Next time, I'll explore how to configure the Chef installation on the Raspberry Pi so that it will deploy the set of services you need to the remote machine.

Detective work on PiFace Control and Display

Having wasted all my free time yesterday on trying to find out how the PiFace CAD is interfaced to the Raspberry Pi, I thought I'd take a different approach today. When I was last working with SPI, I used my trusty Saleae Logic analyser to find out what was happening, so I thought I'd connect this up between the Raspberry Pi and the PFCAD, to see what is really going on.

The first problem, as I pointed out in my initial review of the PiFace Control and Display, was that the PFCAD board does not provide easy access to any of the Pi's GPIO pins. I did not want to mess around unsoldering the PFCAD, so my solution was to extend the Pi's GPIO pins with the same kind of "long leg" socket that I use for my own circuit boards.

SAM_0092

SAM_0094


I then ran the "sysinfo" example, which had worked fine yesterday: python3 /usr/share/doc/python3-pifacecad/examples/sysinfo.py. Oddly, it failed, with a very strange complaint.

Traceback (most recent call last):
  File "/usr/share/doc/python3-pifacecad/examples/sysinfo.py", line 5, in <module>
    import pifacecad
  File "/usr/lib/python3/dist-packages/pifacecad/__init__.py", line 19, in <module>
    from pifacecommon.interrupts import (
EOFError: EOF read where not expected

After a bit of poking around, it seems that something has gone wrong with "python3". When I tried the outwardly similar python /usr/share/doc/python3-pifacecad/examples/sysinfo.py it worked without any complaints. I can only assume that this is a result of SD card corruption when the Pi was powered off. Maybe I should use my Pi Supply switch, after all.

My first run of the "sysinfo" example showed some activity on the MOSI and MISO lines, but did not trigger the SPI analyser. It looked like I was monitoring the wrong select line. So I switched to triggering on CS1 and bingo!

pfcad-1

Now we are getting somewhere. The PFCAD is using CS1. Looking at the data being transferred, I see a chain of short groups of bytes:

  1. 0x40 0x0A 0x08
  2. 0x41 0x0A 0x00
  3. 0x40 0x00 0xFF
  4. 0x40 0x0C 0xFF
  5. 0x40 0x13 0x00
  6. 0x40 0x01 0x00
  7. 0x40 0x04 0xFF

Then quite a long gap (around 22ms) before we get to anything else. It seems quite likely that this is some sort of initialisation sequence, so lets try to send it from some other code and see what happens.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#include <wiringPiSPI.h>

#define CHANNEL 1

void send3(uint8_t a, uint8_t b, uint8_t c) {
  uint8_t buf[3];

  buf[0] = a;
  buf[1] = b;
  buf[2] = c;
  wiringPiSPIDataRW(CHANNEL, buf, 3);
}

void main(int argc, char** argv) {
  if (wiringPiSPISetup(CHANNEL, 4000000) < 0) {
    fprintf (stderr, "SPI Setup failed: %s\n", strerror (errno));
    exit(errno);
  }

  printf("start\n");
  send3(0x40, 0x0A, 0x0B);
  send3(0x41, 0x0A, 0x00);
  send3(0x40, 0x00, 0xFF);
  send3(0x40, 0x0C, 0xFF);
  send3(0x40, 0x13, 0x00);
  send3(0x40, 0x01, 0x00);
  send3(0x40, 0x04, 0xFF);
  printf("done\n");
}

This is a fairly simple piece of C code, using Gordon's WiringPi library to do the low-level SPI twiddling, but I was impressed to see that it had some effect. It switched off the back-light on the PFCAD display! This is more than I managed in a day of code autopsy and head scratching.

I could keep on with this approach, and transcribe all the rest of the bytes I saw on the SPI bus, but I would prefer to work at a slightly higher level. So I need to work out what these mean. This means dipping into the MCP23S17 datasheet.

From the documentation, the MCP23S17 expects three-byte sequences of the form OPCODE REGISTER VALUE. OPCODE varies according to which MCP23S17 is being addressed, but in this case 0x40 is WRITE and 0x41 is READ. I'm not sure at the moment what the PFCAD software is doing with its write then read of register 0x0A, but I'm guessing it might be a check to see if the port expander is present and working. The others seem relatively straightforward, though.

Register address Register name this value does
0x00 Bank A IO direction all inputs
0x0C Bank A pull-ups all pull up
0x13 Bank B GPIO data all low
0x01 Bank B IO direction all outputs
0x04 Bank A interrupt enable compare against DEFVAL (reg 0x03)

These seem to appear in a slightly strange order, but the intention is clear. The LCD is connected to bank "B", so the bank is set to output with initially low values. Bank A is set as inputs with pull-up resistors and default interrupt handling, so those are either unused, or connected to the PFCAD buttons.

One of the Bank B data lines is obviously connected to the back-light input on the HD44780, so when they are all set low, the backlight switches off.

I think that's enough detective work for now. I'll see how much further I can get another time!

Programming Raspberry Pi add-ons (a rant and a plea)

I love the Raspberry Pi. Sure it has its warts, but overall it is very well suited to an amazingly large range of uses. What I'm not so keen on, though, is the Python. Not that I have anything against the programming language (or John Cleese, Eric Idle et al., come to that), but it's just not how I want to write software right now.

I have plenty of experience in a load of other programming languages, including C, C++, Java, Ruby, FORTH, APL, BASIC and so on. I'm even getting more familiar with Javascript and node.js. These are all general-purpose programming languages, in one form or another available on the Raspberry Pi, and would be perfectly suitable for writing Raspberry Pi software and controlling Raspberry Pi hardware.

Except that (mostly) you can't easily use these languages to control off-the shelf third-party Raspberry Pi hardware.

This limitation is nothing to do with these programming languages, nor with the Raspberry Pi, nor its operating systems. It's to do with the software and documentation provided with the hardware.

Most recently I have bumped into this with the PiFace Control and Display. I think the board and its features are great, and the supplied example programs do show some of the things it is capable of. But the supplied code is all Python. And, try as I might, I can't find any documentation about the actual hardware which might enable me to use it with anything else. I can tell from examining the board that it has a MCP23s17 port expander on an SPI port with a HD44780 LCD driver and some switches connected to it, but to make sensible use of the hardware using anything other than the supplied Python code I need to know details such as which GPIO pins are connected to what, and whether they are inputs or outputs, which SPI device numbers are used, whether the display is in "4 bit" or "8 bit" mode, and so on. I spent several hours yesterday poking through the PiFace CAD Python code and trying things out in a C program, but so far I have not managed to successfully even clear the LCD display or switch the backlight on or off, let alone write any characters.

I'm really not trying to single out the PFCAD, here. Over the last year or so I have bought a large proportion of the available Raspberry Pi expansion boards, and I think its fair to say that most of them had this problem in one way or another. It almost seems as if the promotion of Python as an introductory Raspberry Pi programming language in schools (a role I'm sure it suits quite well) has obscured the fact that what we actually have is a flexible platform which can and should also be used for everything from for hobbyist tinkering, follow-on education in wider computer topics, product prototyping, and embedded use. And it could so easily be.

Everyone who makes an electronic component provides a datasheet. That datasheet gives enough information, in a mostly standardised form, for anyone with some experience to have a go at using the component. When I tried interfacing an MCP3002 ADC chip to a Raspberry Pi, I made use of such datasheets to understand what I needed to do. If the manufacturer had only produced software examples, I'm pretty sure they would not have made them for my hand-made board plugged into a Raspberry Pi! Without a datasheet, nobody will buy or use your component.

MCP3002 board under construction

My plea is this:

If you produce add-on hardware for a Raspberry Pi, it is vital that you document and make available enough hardware details that anyone with a bit of understanding can use your hardware from any language or operating environment. Let the growing community of skilled developers help you out by writing libraries, drivers, examples and tutorials for languages and uses you don't have time, skills or inclination to do. Don't assume everyone will use only your software!

If you want to also provide some sort of language-independent kernel driver, and/or libraries and examples in multiple languages, good on you, but it's still no substitute for the raw information. As I found out almost a year ago, it can be surprisingly hard to rebuild drivers even on a stock Raspbian Linux system.

My hope is that if everyone tries to do this we will (soon?) begin to see the familiarities between devices and start to standardise on how things are documented. A pool of developers could then form, able to pick up and work with any add-on hardware based on a quick examination of its datasheet. This in turn could help the production of general-purpose software tools which can ease the development of libraries, drivers, examples and tutorials. At the moment everything seems unique and puzzling, the simplest of details are tedious or even impossible to find out, and hardly any extension hardware gains enough momentum to escape the orbit of the original developers. This is crazy, and must be limiting hardware and software sales.

So, am I missing something? is this kind of documentation and developer pool available already? Can someone point me at some sort of datasheet for The PiFace Control and Display board, or for any of the dozens of other add-on boards and devices which have been produced so far?

Pi Face Control and Display Case

In my excitement at ordering the new PiFace Control and Display board, I also ordered a black plastic case to hold both the Raspberry Pi with the add on board fitted.

SAM_0090_small

I can't say that I'm very impressed, though. The case consists of two "U"-shaped halves, which clip together to form a closed case. For many electronic projects this is a tried-and-tested design, but it works best if all the cut-outs for sockets, knobs and stuff are on one half of the case, and there is a bit of room around the board for access and wiring. That way the board can be secured in place, yet the case can be easily opened for modification and maintenance. This combination of a Raspberry Pi with a PiFace Control and Display fitted requires cut-outs on five of the six faces of the case, and almost all of those have protruding sockets or buttons. This means that the case needs to be bent alarmingly out of shape even to get a single board in place.

I just about managed to squeeze my red Chinese Pi into the bottom part of the case, but had no end of trouble trying to fit the delicate-looking protruding buttons of the PiFace Control and Display at the same time. I tried fitting the PFCAD to the Pi first, then put the Pi in first and tried mangling the case to get the board in place and on to the GPIO pins at the same time. Eventually I abandoned both approaches as I was seriously scared of damaging the Pi, the PFCAD, or both.

In conclusion I can't really recommend this case. It's a nice enough idea but it simply does not seem practical, especially for the price of £13.78, almost as much as the PFCAD board itself! I would have been much better with a PFCAD version of the cheap acrylic "jigsaw case", or better still, a new design from the clever people at ModMyPi or Pimoroni