About half the team at Quick2wire are professional software developers, and several are very well known in the Agile software development movement.
It’s not surprising that we put a strong emphasis on automated testing.
We write automated tests for all the production software that we write, and that can pose a challenge when the software is controlling hardware that interacts with the physical world.
We normally use one of two techniques:
- Use the test platform (typically a Pi, an Arduino or a Beaglebone) to monitor the outputs from the System Under Test (SUT) as well as stimulating the inputs.
- Feed some of the outputs from the SUT back into the SUT. This is sometimes called a loopback test.
Would you like 64 more GPIOs? 128?
Testing the MCP23008
Let’s start by looking at one of the I2C interface boards we are developing. It’s based on the MCP23008 port extender from Microchip, which sits on the I2C bus and adds 8 GPIO pins. These can be individually configured and controlled over I2C. Since you can have up to eight MCP23008s at different addresses on the I2C bus, this means you can add 64 GPIOs to your Pi. If that’s not enough, you can use the MCP23008′s big brother, the MCP23017. Each of those adds 16 GPIO ports, and you can have up to eight of them on the I2C bus, giving a magnificent extra 128 GPIOs. Sadly, you can’t combine the two as their I2C addresses overlap, but 128 GPIO pins is probably enough for most applications.
We’ll be offering interface boards based on both chips, but we started with the MCP23008. The photo on the right shows the chip connected to its test harness. Since we had no Pi at that time, we used an Arduino as our test platform; as soon as we have I2C working on the Pi we’ll test in that environment as well.
The testing strategy is simple. We’ve connected the eight GPIO pins on the SUT to eight digital IO pins on the Arduino. We start by setting each chip pin to be an input, and then verify that it returns the correct value when reading an Ardruino pin that is set LOW and then HIGH. Then we reverse the process, checking that the Arduino sees the expected outputs from the SUT when the GPIOs on the chip are configured as outputs.
The chip has quite a lot of additional features, and we’re in the process of writing tests to verify that our library works with all of those as well.
Loopback testing
PCF8591 ADC/DAC
The next I2C board we’ll be testing is based on the PCF8591 from nxp (formerly Phillips). This useful workhorse has four Analog-to-digital converters (ADCs) and one Digital-to-Analog converter (DAC), all controllable via I2C. In other words, it can measure four different voltage inputs and control one voltage output. That’s enough to do some really useful work: you could use the chip, with a few extra components, to keep track of sunlight, temperature, pressure and humidity – a weather station on a board. Connect it to your Pi and you have a weather station on the web!
So how do we test our software library?
We use a loopback test. We drive the DAC to generate a known output voltage, and then use a set of resistors in series to divide that voltage. We connect the ADC inputs to the correct points of the voltage divider, and check that the voltages as measured at the inputs are what we’d expect, given the output.
The full repertoire of the chip is a bit more extensive, so some additional tests are needed. The four inputs can be combined in several different modes of operation, but the test harness described above makes it easy to verify that the software is configuring each mode correctly.
Permaproto boards
The sharper-eyed among you may have noticed that both the port extender and the PCF8591 board look rather similar. Both are bases on Adafruit’s permaproto boards – PC boards which mimic the layout of a breadboard. They make it really easy to transfer a working breadboarded design to a more permanent home, while en route to a custom board design.
Once our shop is open we hope to sell these boards, which we’ve found incredibly useful; you can buy them right now at the adafruit store in the USA, or from ProtoPIC in the UK.
Coming next
In the next part, we’ll take a look at loopback tests for the GPIO code we’re writing for the Pi.