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 16 which responds with EINVAL for anything but 8 bit word size :(

    Does anyone know where I can find the source for the driver?


  • administrators

    @Jeremy-Shubert Assuming you're using this spidev python module:

    If you need to write 16 bits, let's say 0xab and 0xcd you can do this:

    spi.writebytes([0xab, 0xcd])
    

    To ready 16 bits (2 bytes):

    vals = spi.readbytes(2)
    

    To write 2 bytes (let's say 0xab and 0xcd) 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


  • administrators

    @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.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.