| Embedded Microcontroller |
|
Raspberry PI SPI interface
Some timing and waveform pictures on the Raspberry PI SPI interface.
spi.xfer2([data1,data2])
The Raspberry PI SPI interface uses 4 signal lines, MISO, MOSI, CLK, and CS (Chip Select). The SPI interface is full-duplex, meaning that it transmits and receives data at the same time. Each SPI interface also requires a dedicated CS (Chip Select) line to enable it. I sent the following command in python:
spi.xfer2([0x0F,0x55])
The results show the two bytes being transmitted on the MOSI line (most significant bit sent first). The waveform also shows two bytes coming back from a A/D interface that I have connected on the SPI lines. You can easily see how bytes are transmitted and received simultaneously on the two separate data lines.
spi.xfer2([0x0F,0x55])
The results show the two bytes being transmitted on the MOSI line (most significant bit sent first). The waveform also shows two bytes coming back from a A/D interface that I have connected on the SPI lines. You can easily see how bytes are transmitted and received simultaneously on the two separate data lines.
Raspberry PI SPI interface waveform and timing
The Raspberry SPI timing is much faster than the i2c interface. The SPI clock is 2us or 500 KHz. In the waveform below it is 2 us between the x and y cursors. This makes the SPI interface 5 times faster than the stock i2c interface. The spi.xfer2 command also allows you to vary the nominal SPI speed. A second argument can be added which is used as frequency. I tried spi.xfer2([0x0F,0x55],100000) and got 16.4us or approx. 61 KHz. Next I tried 500,000 and got 2 us, right on the money for the default speed. A 250,000 setting gave me 4.1us or 244 KHz. There is some offset happening in the speed setting, so don't try and use the SPI clock for super accurate timing, unless you figure out the slowing offset effect ahead of time.
Raspberry PI SPI timing waveform
spi.xfer([data1,data2])
The documentation that I read says that xfer2 holds the SPI chip enable low for the entire transaction of bytes, while xfer should raise and lower the SPI chip enable for each byte transmitted. This is not what I see when I send "spi.xfer([0x0F,0x55]). Not sure if I am doing something wrong or if there is a bug with the spi.xfer command.
Raspberry PI "spi.xfer" not disabling SPI chip select
SPI chip enable glitch?
For some reason the Raspberry PI enables the SPI chip enable for a brief period (8us) some short time (54us) after I would expect the transaction to be complete. This happens on every transaction. No actual data is transmitted or received during this period. Just be aware of this, so you don't use the SPI chip enable to count transactions for instance, or you will have problems.
Raspberry PI SPI chip enable glitch?
spi.xfer2([list],speed_hz,delay_usecs)
What does the 3rd parameter "delay" do? Well it extends the SPI chip select signal. I sent spi.xfer2([list],500000,1000) and got the following waveform. The time between the x and y cursors was roughly 1ms or 1000us.
spi.readbytes(len)
Sent the "spi.readbytes(2)" python command. The resulting waveform is as expected. Beware that any SPI device connected would still be receiving an equal number of zero bytes, even though you are not explicitly sending them. The SPI device will see a valid clock and chip select, so even though the transmit line is not driven, it will appear to be driven low, meaning that a bunch of zero's are sent. You are probably safer using the spi.xfer command.
