Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xfer modifies its input list #61

Open
vpatron opened this issue Aug 9, 2017 · 4 comments
Open

xfer modifies its input list #61

vpatron opened this issue Aug 9, 2017 · 4 comments

Comments

@vpatron
Copy link

vpatron commented Aug 9, 2017

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
Copy link

alexyr commented Dec 4, 2017

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
Copy link

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
Copy link

me21 commented Feb 4, 2020

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
Copy link

Fox682 commented Jul 10, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants