A faster SPI slave driver for byte-by-byte transactions (IDFGH-3225)

[carlossless]

Hello everyone!

Recently, I've been playing around with an ESP32 trying to implement a customized SPI protocol. This protocol is your regular run-of-the-mill SPI, only that it requires the slave (ESP32) to drive a separate ACK signal and set it high for a few µs in between every byte that is transferred through the SPI bus.

Queueing every byte in its own transaction and driving the GPIO for the ack signal doesn't seem to be fast enough for the 8us delays between bytes that the master sends.

I'm not very familiar with FreeRTOS, but I presume this is due to the queueing/locking mechanism that's part of the SPI drivers and without them it could work much faster.

I am wondering whether making a variant of the slave driver without the locking mechanisms would be possible but also whether it would make sense in the first place?

Thank you.

[holubcsongor]

I don't think that the lock will be the cause of your problems.
Are you sure, that the esp hardware is capable of handling this speed?

[carlossless]

So, I've actually managed to write a derivate of the esp-idf spi-slave driver which takes multi-byte transactions, transfers them byte-by-byte by setting up and transceiving each byte in the spi interrupt until the transaction if finished (or fails).

This allowed me to use one queue item for the whole transaction, instead of multiple ones for each byte and thus made this whole latency issue I had with queues no longer a problem.

@holubcsongor yes, the esp32 is supposed to handle SPI clocks up to 80MHz, which is well within spec for the 250kHz spi clock I'm dealing with here, that's even with the additional GPIO driving that I need to do in the 8us pauses between bytes.

[Chreepi]

@carlossless I'm currently having a similar issue, where I need to read the bytes to my c-program during the SPI transaction, as the master device is expecting an answer before the CS line is set to high again. Would it be possible for you to show how you solved the issue, because your description above, sounds exactly as the functionality I need.

[carlossless]

@Chreepi my code is pretty specific to my use case, but in essence, the state machine of the transaction is handled within the interrupt:

1. Prepare the transaction, load up the first byte, enable the interrupt.
2. Xfer the byte
3. Based on the byte received load up the next byte. Repeat steps 2 and 3 until the transaction is done.

Good luck!

[Chreepi]

@carlossless Thank you. I'll try to get the interrupt working in this way.