# Understanding a SPI command sheet

I am interested in learning more about how SPI works in general, but with the raspberry pi and py-spidev library in mind. I am very technically savvy, although not so much on the EE side of things.

I am attempting to communicate to a piece of equipment via SPI and have been given only a spreadsheet with some information regarding the byte commands and timing. I have already determined that the SPI mode is 1, clock speed should be 300kHz, and word length is 8 bits. A snapshot of the command sheet is seen below. They should be joined end-on-end.

I have attempted to communicate using the py-spidev library and have seen some hopeful numbers (I think). Example:

import spidev
spi = spidev.SpiDev()
spi.open(0, 0)
spi.mode = 1
spi.max_speed_hz = 500000

spi.xfer2([0x03, 0x00])


I am under the impression that this should turn ON the digital pot, which it does not. However, I do see the values [3, 0] returned, which leads me to believe that something is happening.

What is the difference between Bytes(s) out and Byte(s) in? I am under the assumption that if I send the command xfer2([0x03, 0x00], 500000, 9000) I should receive the bytes 0xF3 and 0x03. Is that correct?

I am really at a loss for how to proceed and would love references to good tutorials/descriptions.

After finally receiving my Saleae Logic Analyzer, I have an update. It appears the chip select pin isn't working? Does anyone have tips for debugging this on a Pi specifically?

• Your spreadsheet insert is unreadable. Also, a link to the datasheet for the pot would be useful. – tcrosley Feb 25 '15 at 17:32
• Sorry about that, I have updated them. – David Hagan Feb 25 '15 at 17:35
• Slightly better, but pretty much still unreadable, at least with Firefox. The text is so small I'm just barely able to make anything out. Looks like it was inserted as an image (perhaps jpg) so the text is anti-aliased giving it fuzzy edges. The right half of the bottom part is overflowing to the right; the forum software may be trying to reduce the image to fit. Trying cutting that off and making three sections. – tcrosley Feb 25 '15 at 17:43
• The image looks ok, but a link to the datasheet is still best. At minimum you should identify this mystery equipment. Have you made sure you're using the CS line properly? Is it active-high or active-low? – Samuel Feb 25 '15 at 17:47
• Unfortunately, there is no datasheet. This is the only thing that exists as of now and the equipment is an optical particle counter. I believe the CS line is being used properly: when I switch it to cshigh = True, the data that is returned is [0, 0] as opposed to [3, 0]. – David Hagan Feb 25 '15 at 19:18

With spi devices, you need to shift something out in order to get something back.

Normally that means sending a command, then shifting some zeros to all the device to respond. If you are sending a command, the device doesn't know how to react until it has received it.

So here is a possible solution, shift the command byte, then the 'bytes out' then some zeroes equal to the number of bytes you want back. Here is the example array to send:

0x03 0x03 0x00 0x00 0x00

Try that, and try it also without the first one. After the transfer the array should have 0xf3 and 0x03 in the last two bytes

• Thanks for the suggestion. When I run the following command xfer2([0x03, 0x03, 0x00, 0x00, 0x00], 500000, 9000) I get [3, 3, 0, 0, 0] in return. Similarly, when I send the bytes [0x03, 0x00, 0x00, 0x00] I receive [3, 0, 0, 0]. Somethings going on, but I don't know what :/ – David Hagan Mar 2 '15 at 14:36
• Normally the device will return undefined (or 0x00) bytes before it has fully shifted in the instruction. If it is returning the instruction as you send it, i would look for a short between MISO and MOSI! – Joel Mar 2 '15 at 23:39
• Gahh.. I tested it pretty thoroughly and there doesn't appear to be a short between MOSI and MISO, although of course I could be wrong. I have a logic analyzer on the way, so hopefully that will solve all of my problems. – David Hagan Mar 4 '15 at 15:56