search

doceme / py-spidev

MIT License
459 stars 205 forks source link

xfer2 deassert the csline after transfer #25

Open ghost opened 9 years ago

ghost commented 9 years ago

hello xfer and xfer2 have the same behaviour i needed to transfer two block while keeping the csline low between them doing so i used xfer2 for first block then xfer for second block, but the csline goes high between

thanks for supporting py-spidev AM

obtitus commented 8 years ago

I belive you might have mis-interpreted the documentation. To transfer without the csline going low, use spi.xfer2([0x12, 0x34])

If you do spi.xfer2([0x12]); spi.xfer([0x34]) then the csline will go high after the call to xfer2.

ghost commented 6 years ago

hi i use raspbian+python+spidev to send commands to an MCU target i installed the last release today 1> xfer2 is still not working as expected. xfer2 asserts and deasserts CS just as well as xfer do 2> the no_cs parameter seems to have no effect at all. for debugging purpose i need fine control on the CS behaviour. will spidev CS control be fixed ? thanks AM

softweyr commented 6 years ago

How do you manage to do a 'read after write?' Apparently xfer2() followed by readbytes() also triggers CS. I'm trying to read a register on an MCP23S17 DIO chip; you write the read command and register address, then read the (8-bit) register value, and I can't for the life of me figure out how to do that with this library. I guess it's back to C++ for now.

ghost commented 6 years ago

hi here is an example of the code i use, it runs on a raspberry pi ... import spidev ... spi = spidev.SpiDev(0,0)
spi.max_speed_hz = 8000000 spi.mode = 0 # mode = [CPOL | CPHA] spi.cshigh = False ... w = [0,0,0x1d] + 9 [0x00] # send a command spi.writebytes(w)
r = spi.xfer(16[0]) # read response ... here i use the built in /CS line that is asserted by spidev in an automated way you can use a GPIO instead and assert the /CS line by hand if you want to comply with the MCP23S17 SPI interface

daniel214 commented 5 years ago

Having this behavior regarding this issue on Raspberry Pi Zero W:

xfer and xfer2 have identical CS behavior, such that it's not possible to have multiple transactions without the CS line toggling. This makes it difficult or impossible to adhere to certain IC SPI access protocols.

pi@taskcontroller:~ $ uname -a
Linux taskcontroller 4.14.98+ #2 Thu Apr 4 11:35:35 PDT 2019 armv6l GNU/Linux

This is a custom compiled kernel, but the SPI system should be Raspberry Pi stock.

I believe this problem is also identical to this now closed issue, https://github.com/doceme/py-spidev/issues/51