spidriver
spidriver copied to clipboard
jamesbowman
Pause between SPI transactions
I'm trying to read data from a sensor with a pretty fast sample rate, so I'm looking to get pretty close to the 500 kbps rate on the SPIDriver. I'm using one of the cheap Salae-8 knockoff logic analyzers and Pulseview for troubleshooting. I noticed that, while the actual SPI transactions are measuring 490 kHz, there's always a 30 microsecond pause between bytes.
What's the reason for these pauses, and is there any way to remove the delays? Here's a screenshot of what I see in Pulseview (sampling at 24 MHz) when I use the read(10) command to read 10 bytes.
That is puzzling. I expect there to be very little time between bytes.
For read(10) there's be a delay every 10 bytes, because of the API overhead, but not every byte.
Couple of questions:
Is that read(10) in Python?
Please can you post a zoomed-out screenshot to confirm the inter-byte delay?
Yeah, it's in Python. Just s = SPIDriver("/dev/SPIDriver"), then some setup code where I use a and b outputs to toggle a reset pin and start pin to wake up the peripheral, then s.read(10) and that's what I get.
The device is an ADS1299 EEG chip, but I'm pretty sure it's not an issue with the device. When I snoop on its SPI transactions with TI's demo software it doesn't have any gaps in SCLK. I could try SPIDriver with a different peripheral if you think that's worth checking though.
I'm just running the SPIDriver on the bench here and I see the same thing. The issue is that SPIDriver uses two-way communication to implement reads. (SPI Writes are fast, which is my confusion.) This introduces a read-write latency over the USB.
So yes, unfortunately this is a feature of the SPIDriver, at least the current version.
Have you set the USB latency timer to zero? That might help in this case:
setserial /dev/<tty_name> low_latency
Alas, that didn't change much. Brought it down to 29 us.
That makes sense though, thanks for explaining it. Even if SPIDriver isn't fast enough for our final application it's been a great troubleshooting tool.
Quick question: would this also happen if we used the C/C++ driver? I see that the EFM8BB1 MCU datasheet claims speeds up to 24 MHz. I'm way less competent in C though, so I'd hate to spend the time figuring it out only to learn it's still too slow.