Hardware Reference
In-Depth Information
void receiveEvent(int size) {
if (size == 2) {
int header = Wire.read();
int dataRead = Wire.read();
if (header == 0xC9) {
// Do something
}
}
}
The equivalent, but more rare, code to send data from the Raspberry Pi back to the Arduino is left as an exercise
for the reader!
With SPI
As a de facto standard, the Serial Peripheral Interface Bus is a method of communicating between a single master
(the Raspberry Pi in our case), and an arbitrary number of slave peripherals. Although it is only possible to control,
or query, one slave at a time, its high speed of operation along with full duplex operation makes this a useful approach
for many microcontrollers and other such projects.
The hardware necessary involves just five pins of the Raspberry Pi's connector, SCLK (the clock), MOSI (master
out), MISO (master in), and CE0/CE1 (both select which slave to use.) The MOSI/MISO pair provides the transmit/
receive pairing for the full-duplex communication channel, while the SCLK is used to keep all the slaves in sync with
the master. As a consequence of this, there is no need to run separate clocks on the slave machines, which makes
it easier to find suitable oscillators and they don't need to be precise. This effort of simplifying the circuitry is also
demonstrable by the fact that, unlike I 2 C, no pull-up or pull-down resistors are needed to you can simply connect the
MOSI on the master to the MOSI on the slave (repeat for OISO and SCLK) and you're nearly ready!
The slave select indicates to which of the slave devices the master is talking. The Raspberry Pi hardware provides
two of these, CE0 and CE1, which utilize /dev/spidev-0.0 and /dev/spidev-0.1 . As a protocol however, SPI allows
you to control as many slaves as you like. Therefore, it is possible (and indeed, suggested) that you use the other GPIO
pins to select the necessary slave, using a low logic 0 to indicate the slave in question. Since you can't use the standard
SPI library, you must manually handle the slave selection by writing to the GPIO as we saw earlier. Timing between
the GPIO and SPI is a question of ordering it correctly-first take all the GPIO pins used in slave selection high to logic 1,
wait, and then take the appropriate pin low.
N If you write your own slave select driver, then you should always begin by sending the selection pins high, and
then low, since some slaves are only awoken by the falling edge.
Tip
The projects possible with SPI are much the same as if you were using GPIO or I 2 C. What you gain in the simplified
electronics, you lose on the software, so you need to write your own error handling and hand-shaking code since there
is no way of knowing if the slave received the messages sent to it, nor is there any error checking in the protocol itself.
If your project is to be in an electrically noisy environment (maybe the utility room, with the powerful motors of a
washing machine and tumbler dryer) then this is a valid concern, since SPI is more susceptible to noise. If you have no
SPI slaves with which to experiment then you're probably wrong (!) because anything capable of communicating on
four different pins can be pressed into service . . . the Arduino is a suitable candidate for this. A proof of concept can be
found at http://hackaday.com/2013/01/06/hardware-spi-with-python-on-a-raspberry-pi .
 
Search WWH ::




Custom Search