Proposal: deprecate xfer2
Gadgetoid opened this issue · comments
This library has suffered somewhat from function creep caused by useful features being added in conjunction with a fear of breaking the existing API.
I think it's worth reviewing what functionality an SPI library should constitute- taking into account #83 and the possibility of reading/writing bytearrays. But before we dive into what could be a time consuming nightmare it migh tbe worth reviewing the current functionality and attempting to whittle the codebase down to a maintainable core.
Right now as near as I can tell from code-review xfer and xfer2 are functionality identical unless the library is compiled with -DSPIDEV_SINGLE. I'm unaware of how this library is packaged for RPi (I have asked who I believe to be the relevant individual) but this flag is not referenced or set anywhere in the packaging visible in this repository. The library is shipped on PyPi without this flag set. The lack of any functional difference between xfer and xfer2 was noticed in #35 and #25 and has remained unchanged since.
I don't believe there's any reason to have a first-class method that handles re-asserting chip-select between "blocks" (in this case, we mean bytes).
- Nobody has asked for it (#35 notwithstanding)
- nobody has discovered or mentioned
-DSPIDEV_SINGLE - anyone who desires this behaviour can simply invoke xfer byte-by-byte from Python (or ask for it)
I propose we quietly roll xfer and xfer2 into a single function and drop the -DSPIDEV_SINGLE code path altogether. Along with dropping some of the Python version checks this constitutes a significant reduction in code that needs maintained and testing in future.
Right now there are also inexplicable minor differences (allowing/disallowing threads) between xfer and xfer2 that should be ironed out, so this would be a good opportunity to reconcile those.
Have confirmation that -DSPIDEV_SINGLE is never set- at least in the Raspberry Pi distribution.
Are there any other binary distributions that might set this flag and suffer from that code being removed?
I supose at the very least if the bugfixes are rolled out a release before this code is killed, then it will always be possible for anyone who needs this functionality to rely on a previous release (everyone pins their dependencies right, right!?).
Hi,
I tried to use xfer because I have a chip that needs a CE spike between any 8bit transaction. With my Logic analyzer I can see that this is not working with the function. Is there any easy way to get the "old" xfer function as described on the main page?
(PS: sending xfer byte-by-byte is no option for me, because I need a fast transaction without delay)
Best wishes
I am sending RGB data to a display, so I need a fast transmission.
Here is my test code
import spidev
import time
spi = spidev.SpiDev()
spi.open(0, 0)
spi.xfer([0xFF, 0xFF, 0xFF],1000000, 0, 8)
spi.xfer([0xFF],1000000, 0, 8)
spi.xfer([0xFF],1000000, 0, 8)
spi.xfer([0xFF],1000000, 0, 8)
spi.close()
As you can see the first trasmission is a lot faster.
You can also see a bug that the CE is dropped twice which is mentioned here:
https://www.raspberrypi.org/forums/viewtopic.php?t=73323
but sadly it wasnt solved