I wrote a linux driver for SPI protocol so RaspberryPi could communicate with my device that's using serial data transfer (the device has clock input and data output). It almost works, the problem is that breaks between transfers are too much for my device to handle - it has very small data buffer that will overflow if data isn't being read fast enough. This might be a bad device design, but I'm more into software engineering than electronics so I have to deal with it somehow through clever programming.

Ideally, SPI communication between RPI and my device should be infinite, with maybe just a few microsecond breaks between large transfers. As of now, using linux driver I wrote, even a few millisecond breaks occur from time to time (I guess it's due to imperfect scheduling on CPU), which is not acceptable for the device. Of course I set up another aync SPI transfer as soon as one is done, so it's not a matter of my driver being too slow.

So can I either:

  • make my driver's transfer completion procedure be more reliably scheduled so breaks between transfers are close to none, or
  • set up SPI communication in some other way (ie. using DMA directly with SPI peripheral, which I heard is doable, but I don't know if this should be handled in user or kernel space, and how)
  • insert a buffer device between the two ... maybe an ESP32
    – jsotola
    Mar 6, 2023 at 18:30
  • I may do that if I don't find any other solutions, but I'd prefer to solve it in software rather than in hardware.
    – PookyFan
    Mar 6, 2023 at 18:33
  • What happens if you use the existing kernel driver? It may not be the ultimate speedster but works well.
    – Milliways
    Mar 6, 2023 at 21:57
  • 1
    If I read from default SPI device, the breaks between transfers are going to be much worse, as I would be doing that from userspace, so I didn't even try it. I'm not convinced this is a good idea. Besides, I kind of use existing driver, my driver is just a protocol part of SPI stack, so the most high level one.
    – PookyFan
    Mar 6, 2023 at 22:01
  • If whatever unspecified device you have connected produces data without input from the SPI master it obviously DOES NOT support SPI so SPI won't work. You appear to be attempting to use as a USART - again this is possible to send from master but not receive.
    – Milliways
    Mar 7, 2023 at 21:34

1 Answer 1


You should be able to get more-or-less uninterrupted SPI transfers using DMA, as described here. There will be a brief pause when one DMA transfer ends and another begins, but that shouldn't be milliseconds.

You can have transfers larger than 64K, if you use a DMA channel that isn't 'lite', as described in the BCM2835 ARM Peripherals document.

  • This is just what I needed! I can control SPI transfers with so much precision it's almost frightening. ;] Thank you for your reply!
    – PookyFan
    Mar 12, 2023 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.