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?
-
@Jeremy-Shubert Assuming you're using this spidev python module:
If you need to write 16 bits, let's say
0xaband0xcdyou can do this:spi.writebytes([0xab, 0xcd])To ready 16 bits (2 bytes):
vals = spi.readbytes(2)To write 2 bytes (let's say
0xaband0xcd) and then immediately read 2 bytes, ie for 16-bit register writes:vals = spi.xfer3([0xab, 0xcd], 2)
-
@Lazar-Demin
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.
-
This full duplex thing is a real bummer. The advantage to this device for me was being able to program in Python and Javascript (via NodeJS). In order to get full duplex SPI communication, which I need for 3 out of 3 chips in my design, it looks like I have to use the kernel driver in a C application and compile this on the Onion. I have no expertise in this. I wish I would have noticed this SPI issue before. Please someone correct me if I'm wrong.
-
Hi,everyone.
I'm working on a project where I need to connect a chip that works over SPI .I used raspberry pi 4 and Ic ad5422 in my project.
now I want to send data throw spidev and xfer that my data is 24 bits.
The input shift register is 24 bits wide. Data is loaded into the
device MSB first as a 24-bit word under the control of a serial
clock input, SCLK. Data is clocked in on the rising edge of SCLK.
The input register consists of eight address bits and 16 data bits.
The 24-bit word is unconditionally latched
on the rising edge of the LATCH pin.Am I using spi.xfer3([0xab, 0xcd,0xef], 3) in my code?
Does anyone know what am I doing?
