search

doceme / py-spidev

MIT License
461 stars 203 forks source link

xfer modifies its input list #61

Open vpatron opened 7 years ago

vpatron commented 7 years ago

xfer() function modifies the list of values that you give it as input. This was totally unexpected and a bit annoying.

>>> a = [0, 1, 2, 3] >>>spi.xfer(a) [0, 0, 0, 0] >>> a [0, 0, 0, 0]

So basically, it sends the 4 bytes (0, 1, 2, 3) and the host reply was 4 zeros. The problem is that it also modifies the input parameter, list a, with the SPI data that was read in. And the function also returns the same data.

Either it should return the data read in over SPI and not modify the input, or it should modify the input list and not return anything, but it should not do both.

If it had no return, then it is more obvious that the SPI data read in would be in the input list, basically a buffer exchange, which is what SPI is. But because it also returns the SPI read data, it makes one think it is a regular function.

A simple way to get around this is to convert the data to a tuple first so it cannot be modified:

spi.xfer(tuple(a))

Anyway, behavior should be clearly documented.

alexyr commented 6 years ago

xfer2 also...

May be add optional rx_buffer to arguments and not reuse tx/create new if supplied?

Like: xfer(list of values[, speed_hz, delay_usec, bits_per_word, rx_buffer])

transistorgrab commented 5 years ago

I stumpled across this today during converting a script from 2.7 to 3.7. The behaviour differs between Python 2.7 and 3.7. in 2.7 the original list is not altered. in 3.7 the list is cleared after xfer2.

me21 commented 4 years ago

I confirm, this is annoying. Spent a day banging my head on the table till I figured out what was happening. Only in my case it happens on Python 2.7.13 too.

Fox682 commented 2 years ago

I can confirm this behavior for Python3 is still an issue. I can also say that I banged my head against the table for this issue too... this is the only significant roadblock that prevented me from making progress with this. I think the behavior in general is ok (I'm not sure of a good alternative method at this moment).

But this issue REALLY needs to be documented in the main page for visibility. The convert to a Tuple ( tuple() ) and back to a List ( list() ) when needed is a good work around for this issue.