-
Notifications
You must be signed in to change notification settings - Fork 203
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
Comments
xfer2 also... May be add optional rx_buffer to arguments and not reuse tx/create new if supplied? Like: |
I stumpled across this today during converting a script from 2.7 to 3.7. |
I confirm, this is annoying. Spent a day banging my head on the table till I figured out what was happening. |
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. |
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:
Anyway, behavior should be clearly documented.
The text was updated successfully, but these errors were encountered: