xfer2 deassert the csline after transfer about py-spidev

[obtitus]

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.

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]

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.

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]

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, #51