Exploring Edison - SPI |
Written by Harry Fairhead | ||||||
Thursday, 02 June 2016 | ||||||
Page 4 of 5
Implementing The User Mode DriverIn principle the two delays could be different to allow for a difference between a slaves setup and hold time. In practice we generally select a the longest delay. Notice that most SPI devices don't demand that the clock pulses are of the same length so we don't have to worry about being accurate. As long as you are using the latest version 3 of the IoT software you can make use of the same lines as the Edison's SPI bus to implement your own. Before version 3 you couldn't use all of the SPI bus lines as GPIO lines because they were used in the Linux Kernel. To get started first we need to define some global variables.
If you want to tidy things up these could be placed into a stuct and passed as a single parameter. You could then use the stuct to set up any four GPIO lines as an SPI bus. The function that we are going to create is:
it sends byte and returns the byte received. The delay parameter sets the clock frequency. We could have function to initialise the GPIO lines to work as an SPI bus but for the moment let's just put them in the main program: int main() { First we set up the program to run in a FIFO scheduling group. This should make it the only program to run until it gives up control, see Chapter 6 for more information.
Next we initlaize each of the SPI lines in turn:
The only thing that you might wonder about is the final read of the MISO line. Why bother? The answer is that the first read takes longer than subsequent reads because the pin is setup at this point. So a gratuitous read, throwing the result away, speeds up the first byte transfer. It is always a good idea to read an input line when you first set it up. Now we need to implement the function we can return to the main program in a moment. We need two loop variables and a byte variable to read the data in:
Now we are all set to send eight bits one bit at a time. First we set the CS1 line low to select the slave, then we need a short pause to give the slave time, and then we can start the loop that sends each of the bits:
We need to set the data line high or low depending on the most significant bit in byte:
and then we need to shift the entire bit pattern one to the left to get the next bit into the most significant bit position:
Now we busy wait, and this is the only way to wait that doesn't return control to the operating system, for half a clock period and then set the clock high:
Next we need to read the data on MISO. This is the most significant bit and it needs to be shifted one place to the left to ensure it eventually gets to the correct position:
Notice that the first shift doesn't actually do anything but its easier to put up with this waste than to waste even more time trying to test to eliminate it. Next we wait for another half a clock period and then set the clock low.
This ends the loop that processes the eight bits and now all that remains is to deactivate the CS1 line and return the result.
Continuing with the main program from where we left off, we can now make use of the function to send and receive some data:
Assuming that the MISO and MOSI pins are connected together in a loop back, the output AA should equal the input AA. If you run this and measure the clock frequency you will find it is around 666KHz and the data rate is 66K bytes/s. This is the fastest data transfer things can be slowed down by setting other values to delay: Delay Clock Transfer 0 666KHz 66K bytes/s 10 500KHz 62K bytes/s 100 222KHz 26K bytes/s 200 133KHz 16K bytes/s 500 47KHz 7.2K bytes/s 1000 31KHz 3.8K bytes/s Once you get to a delay of 500 or more you will discover that the delay after setting the CS1 line might not be enough. It really needs to be a percentage of the clock frequency. If you want to work down at these frequencies change the delay for CS1 to:
You can easily tidy up this function and program to produce something more like a library function. In addition you can modify it to create a buffer transfer function which works at similar speeds. An example of how to do this is given in the next chapter. Notice that while data is being transferred the function hogs one core of the Edison main CPU and the rest of your program makes no progress. However, if you replace the busy waits by other instructions you do have time to perform some light processing of the input data. The complete program is:
|
||||||
Last Updated ( Thursday, 02 June 2016 ) |