SPI delay time between transactions.

[AG1702]

Hello there,

I'm using SPI communication to interface with an external ADC. I need to send first 1 byte, wait at leas 8us, and then send 3 bytes. I implemented this in 2 different spi_device_transmit (because I need to wait 8us between them).

Code: Select all

spi_transaction_t t;
t.flags = SPI_TRANS_USE_TXDATA | SPI_TRANS_USE_RXDATA; 
t.length = 8*1;
t.rxlength = 8*1;
t.tx_data[0] = 0xFF;
t.tx_data[1] = 0xFF;
t.tx_data[2] = 0xFF;
t.rx_buffer = NULL; 

spi_transaction_t r;
r.flags = SPI_TRANS_USE_TXDATA | SPI_TRANS_USE_RXDATA; 
r.length = 8*3;
r.rxlength = 8*3;
r.tx_data[0] = 0xFF;
r.tx_data[1] = 0xFF;
r.tx_data[2] = 0xFF;
r.rx_buffer = NULL;

spi_device_transmit(spiHandler, &t); 
spi_device_transmit(spiHandler, &r);

After seeing the performance of this code through a logic analyzer, I noticed that there is a huge waste of time between this 2 transactions, almost 60us, even though this instructions (spi_device_transmit) are executed one after the other. Image attached.
There's no other tasks running concurrently.

Is there a way to reduce this time between transactions?

In this case, SPI is configured to run at 2MHz (maximum speed to interface with my ADC).

[Scott.Bonomi]

It is not clear why you have such a delay. It appears that you have a conflict in the description of the T transaction. I believe you want to send a byte with T and Receive 3 with R. you are set up to receive on both since your rx length is equal to total length in both. for a TX byte, I would expect the Rx.Length to be zero.

It may help to increase your OS Clock rate in case you are waiting for a switch event between them. I do not thint you are, but might.
Another option is to send the first message without looking for a response, I believe this is spi_device_queue_trans() but that might not give you enough time before then next transmit.

[AG1702]

Thanks for the reply.

I believe you want to send a byte with T and Receive 3 with R.

Correct. I tried with Half-Duplex mode without success, I'm not sure how to configure the spi_transaction_t struct for transmit and then receive. I would like if anyone can provide an example of SPI Master in Half-Duplex.

In meantime I will try increase OS Clock and using spi_device_queue_trans().

[PeterR]

80uS is a little more than I would expect.
I measured around 20uS with DMA enabled and around 16uS without DMA.
I doubt that the OS tick period has much to do with this, 80uS is much faster than any reasonable scheduler tick.

The main issue is that the SPI driver reprograms the hardware when you start each transaction. DMA takes longer to setup - there are more registers to program.
Also there might be bus sharing issues although in this case one would expect only occasional extra delays.
Check that you have CONFIG_SPI_MASTER_IN_IRAM as without you might run slow.

I wonder if you might have more fun with the RMT module. You should be able to setup one transaction?

[jialin.yang]

I also encountered the same problem

[fallafenflufen]

Moving the code to IRAM might help, but really the high level HAL function probably compile to 1000 machine instruction, because they setup everything, every time.
For lowest latency one would have to prepare SPI configuration and DMA configuration beforehand and then only toggle the DMA enable bit.