SpiDev bits_per_word in Python
Anyone have luck changing this value for SpiDev in Python? I have a device where I need to use 16 bit SPI communication to get all the information I need and can't seem to get this going. When I set this to 8 and communicate via 8 with the device (getting only the basic data) then all communication works well. Setting this value to 16 gives an error.
While not directly affected I had a look and it turns out that this is an underlying problem with the (kernel) driver. To exclude python from the equation I just ran e.g.
spi-config -d /dev/spidev0.1 -b 16which responds with EINVAL for anything but 8 bit word size
Does anyone know where I can find the source for the driver?
If you need to write 16 bits, let's say
0xcdyou can do this:
To ready 16 bits (2 bytes):
vals = spi.readbytes(2)
To write 2 bytes (let's say
0xcd) and then immediately read 2 bytes, ie for 16-bit register writes:
vals = spi.xfer3([0xab, 0xcd], 2)
How to read the specified ( address ) SPI device
@Landon-Lin not sure what you mean, can you give me an example?
Thanks for the response all. Before I saw these responses, I connected an inexpensive logic analyzer from Amazon and I was able to view the SPI communication. I was able to confirm that bits_per_word should always be 8 and that using writebytes([0xab,0xcd]) does write two bytes without toggling the CS pin in between, the number of clock cycles was correct. Same thing with the xfer3...if you send 2 bytes and ask to read 2 bytes then you will get 32 clock pulses.
I'm having some other challenges with the SPI, the chip doesn't always seem to respond to the SPI signal, even though the logic analyzer confirms the data. I'll respond back here because it seems others are having challenges with the SPI comm.
@Landon-Lin There are no addresses in SPI (addresses in I2C), you must use a different CS pin for each chip on the SPI bus. If you would like to use a non-standard CS pin. Then set no_cs to True and manually toggle the bit you are using before and after the write/read/xfer3 instruction.
##Assuming Pin 11 for CS gpio11 = onionGpio.OnionGpio(11) status = gpio11.setOutputDirection(1) status = gpio11.setValue(1) status = gpio11.setValue(0) ##assuming CS active low vals = spi.xfer3([0xab, 0xcd], 2) status = gpio11.setValue(1)
I had a wiring error causing the inconsistencies. Now I have traced the problem back to duplex communication. The chip I am using expects to send while receiving. If I perform a readbytes, then the chip interprets the data in as 0. If I use an xfer3 function to try to write 2 bytes then read 2 bytes, then the first 2bytes are immediately overwritten with during the read clock pulses. I've seen some other threads with duplex issues, I'll look at how others have worked around this.