The SPI bus is often a real headache because of the lack of a definitive standard but in most cases you can make it work. The first problem is in discovering the characteristics of the slave device you want to work with. In general this is solved by a careful reading of the data sheet or perhaps some trial and error - see the next chapter for an example.
If you are working with a single slave then generally things work once you have the SPI bus configuration set correctly. Where things are more difficult is if you have multiple devices on the same bus. The Pi can only directly support two devices but this is enough to make the task more difficult. Typically you will find SPI devices that don't switch off properly when they are not being addressed. In principle all SPI devices should present high impedance outputs (i.e. tristate buffers) when not being addressed but some don't. If you encounter a problem you need to check that the selected slave is able to control the MISO line properly.
A better solution is to multiplex the CS0/1 lines to create additional chip selects. For example you can use standard GPIO lines as chip selects and connect more than two SPI slaves.
The SPI bus is often problematic because there is no SPI standard.
Unlike other serial buses it makes use of unidirectional connections.
The data lines are MOSI master output slave input and MISO master input slave output.
In addition there is a clock line - output from master and an unspecified number of select lines - two in the case of the Edison.
Data is transferred from the master to the slave and from the slave to the master on each clock pulse in arranged as a circular buffer.
The mraa library provides all the functions you need to set up the SPI bus and transfer data one byte or multiple bytes at a time.
You can test the SPI bus using a simple loopback connection.
Working with a single slave is usually fairly easy, working with multiple slaves can be more of a problem.
In single byte transfers cannot achieve a high data rate because of the overheads involved in the mraa calls. In this case 5Kbytes/s is about as fast as you can achieve.
Multiple byte transfers can achieve higher data rates because the latest system software uses DMA but this only works with clock rates of 1MHz and higher. You can achieve data rates of 3Mbytes/s.
Multiple byte transfers are limited to blocks of around 5Kbytes.
You can achieve transfer rates of up to 65K byte/s using your own software implementation of the SPI protocol.
The starting point for finding out about all Intel's Internet of Things resources, including Edison, is the Intel IoT Developer Zone.
Now On Sale!
You can now buy a print edition of Exploring Intel Edison.
Meet Edison In this chapter we consider the Edison's pros and cons and get an overview of its structure and the ways in which you can make use of it. If you have ever wondered if you need an Edison or an Arduino or even a Raspberry Pi then this is the place to start.
First Contact When you are prototyping with the Edison you are going to need to use one of the two main breakout boards - the Arduino or the mini. This chapter explains how to set up the Edison for both configurations.
Mraa GPIO Using the mraa library is the direct way to work with the GPIO lines and you have to master it. Output is easy but you do need to be aware of how long everything takes. Input is also easy but using it can be more difficult. You can use polling or the Edison interrupt system which might not work exactly as you would expect.
Fast Memory Mapped I/O There is a faster way to work with GPIO lines - memory mapped I/O. Using this it is possible to generate pulses as short at 0.25 microsecond and read pulse widths of 5 microseconds. However getting things right can be tricky. We look at how to generate fast accurate pulses of a given width and how to measure pulse widths.
Near Realtime Linux You need to be aware how running your programs under a non-realtime operating system like Yocto Linux effects timings and how accurately you can create pulse trains and react to the outside world. In this chapter we look the realtime facilities in every version of Linux.
I2C - Measuring Temperature After looking at the theory of using I2C here is a complete case study using the SparkFun HTU21D hardware and software.
Life At 1.8V How to convert a 1.8V input or output to work with 5V or 3.3V including how to deal with bidirectional pull-up buses.
Using the DHT11/22 Temperature Humidity Sensor at 1.8V In this chapter we make use of all of the ideas introduced in earlier chapters to create a raw interface with the low cost DHT11/22 temperature and humidity sensor. It is an exercise in interfacing two logic families and implementing a protocol directly in C.
The DS18B20 1-Wire Temperature The Edison doesn't have built in support for the Maxim 1-Wire bus and this means you can't use the very popular DS18B20 temperature sensor. However with a little careful planning you can and you can do it from user rather than kernel space.
Using the SPI Bus The SPI bus can be something of a problem because it doesn't have a well defined standard that every device conforms to. Even so, if you only want to work with one specific device it is usually easy to find a configuration that works - as long as you understand what the possibilities are.
SPI in Practice The MCP3008 AtoD The SPI bus can be difficult to make work at first, but once you know what to look for about how the slave claims to work it gets easier. To demonstrate how its done let's add eight channels of 12-bit AtoD using the MCP3008.
Beyond mraa - Controlling the features mraa doesn't. There is a Linux-based approach to working with GPIO lines and serial buses that is worth knowing about because it provides an alternative to using the mraa library. Sometimes you need this because you are working in a language for which mraa isn't available. It also lets you access features that mraa doesn't make available.