Pause between SPI transactions

[Rodgers-PAC-Lab]

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.

[jamesbowman]

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?

[Rodgers-PAC-Lab]

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.

[jamesbowman]

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

[Rodgers-PAC-Lab]

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.

[Rodgers-PAC-Lab]

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.