SPI delay before each transfer

zajili

Hello everyone,

I've been working on a project using SPI (cf this discussion). I've been struggling with some delay that appears before each transfer.
It's not a constant delay and it varies roughly between 40 µs and few hundreds microseconds, as you can see in the screenshot.

The time references are taken between two consecutive code lines in the render.cpp file. In pseudo code it would be something like that, see the comments:

setup() {
    ...
    spiDevice.setup({
        .device = "/dev/spidev1.0",
        .speed = 16000000, 
        .delay = 0,
        .numBits = 8,
        .mode = Spi::MODE1
    });
    ...

    SpiTask = Bela_createAuxiliaryTask(readSpi, 50, "bela-Spi", (void*) context);
}

readSpi(...) {
    if (data_ready) {
        custom_select_device(); // end of instruction is the first time mark
        spiDevice.transfer(Tx, Rx, transmissionLength); // this begins the transfer, supposedly second time mark
    }
}

The custom_select_device is a function that writes to some IO to select a device through some custom HW block.
I'm using the Spi library of the Bela project #include <libraries/Spi/Spi.h> .

At first I thought the delay was introduced from preemption by the RT audio thread, so I tried to move the SPI transfer inside the render function but I had the same results.

Do you have any idea where this delay is coming from, and how can I workaround it ?

I might have to try using the PRU to bitbang the SPI protocol, but I'd rather be sure of the cause of this behavior beforehand.

Thank you for reading, any help would be appreciated

giuliomoro

In short, that's expected. If you need shorter delays between chip select and beginning of the transmission, you should use the chip select line from the spi peripheral itself instead of using a generic gpio as you are doing now. That will reduce that gap to a few nanoseconds. However, the gap between calling the function and the function actually starting will still remain similar to what you've observed so far.

Bitbanging from the pru will limit the bitclock speed (8MHz I believe) and may be overkill if you have actual spi pins availabl, unless the relative timing of spi and other hardware i/o is critical

giuliomoro

To give some more context: the time it takes for the CPU to execute one line is not infinitesimal, especially if that line contains a function call that contains a system call. 40 microseconds is not at all bad in that case, even if no pre-emption due to the scheduler takes place (e.g.: there may be something happening in the kernel during the system call that requires synchronisation or what not). If preemption happens, that's where you can get several hundred microseconds delay. Running it in the audio thread won't give you much of an advantage because the latency guarantees of the Xenomai thread cease when you perform a system call.

zajili

Ok thank you so much for the details, much appreciated as always.

Unfortunately the HW block we use to select the SPI device is not compatible with using the peripheral CS line directly for chip select.
Moreover I'm not sure I'm in the case where relative timing of SPI and other hardware I/O is critical, but eventually the SPI transfer should be driven by an interrupt from another I/O line (I have yet to look how to set this up).

Basically I would like to sample 8 devices at 2 kHz at least with a data payload of 48 bits. Then I would like to output 8 audio channels based on the acquired data.
If I configure the audio buffer length to be 16 frames, this implies that the audio task will be called at 44.1kHz/16 = 2.75 kHz right ? Which in turns gives a time interval of roughly 362 µs between each call.

At 8 MHz for the SPI bus, the minimum time required for the SPI transfer with 1 device, is going to be payload_size * 1/f_spi = 48 * 1/8e6 = 6 µs. So in theory, it should take at least 48 µs to acquire all 8 devices without including the time needed to switch the CS line.
So in theory this leaves us plenty of time to do other stuff relative to the 362 µs between each audio thread call.

Unfortunately, as you have seen the delay makes it impossible to hold that constraint, so I'm basically left with 2 options:

bitbanging SPI on the PRU, with custom chip select and triggering the transfer with interrupts
offloading the sensor acquisition/audio output to another MCU + audio codec (yet to define)

I'm not sure which way I should go and how to establish synchronization/communication between PRU and project code.

Could you please help me clarify if I'm not mistaken in my reasoning and confirm if I can use the PRU for that ?

giuliomoro

What Bela board are you using ?
Are you using the analog inputs?

zajili

giuliomoro

I'm using the CTAG FACE Starter Kit RevC, so no analog inputs.

giuliomoro

OK. The PRU code already has provisions to perform 4 SPI rx/tx per each audio sample, for reading the analog inputs. In your case there's no analog inputs, so you could perform some modifications to the existing code to perform your SPI rx/tx instead. The advantage here is that you'd be placing the results in sample-accurate memory buffers.

This requires you to:

edit Bela_getHwConfigPrivate() in core/RTAudio.cpp so that it still uses the 8 analogInChannels even with a BelaHw_CtagFace
edit pru/pru_rtaudio_irq.p to perform the desired operations instead of the stock ones. Note that the existing code reads and stores 16 bits at a time.