Safe, simple connection to your Raspberry Pi
Here's the pinout for our SPI connectors.
The CS line is connected to CS 0 for the connector on the left and CS 1 for the connector on the right of the Interface Board, as seen from above. Int can be connected to an interrupt for those chips that support it, such as the MCP23S17 SPI Port Extender.
One of the themes that came out of yesterday's excellent Raspberry Jam at Milton Keynes was the very positive overlap between the Arduino and Raspberry Pi communities.
A lot of us Pi enthusiasts also have Arduinos and use them for projects. We're beginning to investigate what the two can do together, and we're seeing a number of projects (like Gordon Henderson's wiringPi) which let people use their Arduino skills and code to drive hardware attached to the Pi.
Some of us are also currently evaluating a Pi shield from Cooking Hacks which allows you to plug in Arduino shields and control them from the Pi.
Of course, not everyone has both computers. If you're trying to decide which one to use Andrew back has written a great comparison on DesignSpark.
If you do have both, there are several ways in which the Pi and Arduino can be connected.
You can use the serial ports. You need to remember to insert a level shifter to convert between the Pi's 3.3 volts and the Arduino's 5 volts, and you need to write programs to send and parse text at each end of the wire.
For most applications I prefer using I2C or SPI. You still need a level shifter, but the software is pretty straightforward. The standard Arduino examples include a sketch that makes the Arduino act as an I2C slave device, which you can then control from the Pi.
Since you decide on the address the Arduino uses on the I2C bus, you can (in theory) control over a hundred Arduinos from a single Pi! I2C is fairly slow, and if you need to send a lot of information to or from the Arduino then SPI might be a better solution.
One combination that I want to explore when I have time (ha!) links the Pi and the Teensy 3. If you haven't come across one before, the Teensy is an Arduino-compatible computer with a very small form factor, and the Teensy 3 has a powerful ARM processor while maintaining a high degree of Arduino library compatibility.
It has 16K of RAM - not much by Pi standards, but eight times the memory of a standard Arduino - and it has a much more powerful processor. Together the Pi and the Teensy 3.0 should form an awesome combination.
I've been tearing my hair out for the last couple of days trying to work out why our automated SPI test was failing on the Raspberry Pi I use for testing.
I was pretty sure it wasn't a problem with the interface board. I'd done a manual continuity check and was as sure as I could be that the Pi's expansion header was connected to the right pins of our SPI bus.
I didn't think it was a problem with our software. We've done quite a bit of testing with SPI, and that part of our library hadn't changed since the last time the test was passing.
The original tests were run on a rev 1.0 Raspberry Pi, and we're now using a rev 2.0 board. I doubted that was the cause. Although GPIO has changed slightly, and the Rev 2.0 uses a different I2C bus, the SPI pins are unchanged.
I was mystified, and decided to bring out the big guns. I don't have an oscilloscope these days (though it is on my shopping list for next year). Instead, when I need to debug I2C or SPI, I use the Open Workbench Logic Sniffer from Seeed studios.
The OWLS is an amazing piece of hardware. It's about $50 from Seeed studios, and you need to buy one or two probe cables to go with it, but it has most of the features of bus analysers costing several times more.
Here it is connected to the board under test. The OWLS is the red board at the bottom of the picture.
Open Logic Workbench Sniffer debugging an SPI board
The board uses the SUMP protocol, and there is a great SUMP client called OLS. A few minutes of debugging found the source of the problem - I'd got the SI and SO wires reversed when I plugged jump leads from our header to the prototype circuit. I had checked and rechecked, but I guess my brain was seeing what I expected to see, not what was actually there.
Once I'd got that corrected, the SPI test passed with flying colours. Here's a screenshot from the OLS client showing the SPI bus traffic when the software is sending data to the board.
I'm taking a couple of lessons away from this.
The story has a happy ending, too: here's the output from our loop-back test:
Passing SPI test
While we’re waiting for the first interface boards to arrive we’ve been checking out our libraries against the new Raspbian distro.
The latest Raspbian kernel supports I2C and SPI, and today we got all our loopback tests passing. This means we have working Python libraries on Raspbian for GPIO, I2C and SPI.
Raspbian is now the official recommended kernel, so we’re fast approaching the point where a new Pi user can plug in our hardware, install our libraries, run an example and expect everything to work.
At the moment the Python GPIO library needs our gpio-admin library as well as the Python code. Soon we’ll package the two together as a .deb file, which will make things even easier. The gpio-admin and Quick2Wire Python libraries are on github so if you feel like experimenting, clone away and let us know how you get on! The libraries have examples and test code included.
If you want to try out the SPI code, you’ll need to upgrade to the latest Raspbian firmware. The kernel in the current Raspbian image (2012-07-15-wheezy-raspbian) supports I2C but not SPI; you can use Hexxeh’s firmware updater to get a later kernel, which supports both.
There are a couple of other things you’ll need to do: uncomment the two lines in /etc/modprobe.d/raspi-blacklist.conf which stop needed modules from loading, and add a line i2c-dev to /etc/modules to ensure that the relevant i2c module is loaded on boot-up.
Your raspi-blacklist.conf should then look like this:
# don't blacklist spi and i2c by default
# blacklist spi-bcm2708 # blacklist i2c-bcm2708
and /etc/modules should look like this:
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. # Parameters can be specified after the module name.
snd-bcm2835 i2c-dev
PS Things are moving fast. If you want to keep up-to-date with what’s happening here at Quick2Wire, sign up for our free newsletter. Just fill in your email at the top of the page and click sign up. We won’t spam you, and you can unsubscribe at any time.
We’ve got an experimental version of our SPI library working. Like our I2C library, it’s written in Python and uses Python ctypes to drive the low-level interface provided by the kernel.
You can see our usual exciting binary counter demo
We’re driving an MCP23S17 16-bit SPI port extender, and sending the PORTA outputs to a Bar LED display.
There’s still lots of work to do but we’ll be releasing the current code on GitHub shortly.