SPI Queue Execution Order

[rsimpsonbusa]

Hi Everybody.

Does anybody know if the

Code: Select all

spi_device_queue_trans(...)

has a FIFO order of execution?

This way we can check completion of a "block" of transactions by just checking the LAST entry in the Queue via

Code: Select all

spi_device_get_trans_result(...spi_transaction_t of last entry.....)

.

BTW, also has anybody queued several transactions with the SAME tx data to transmit? That way we can format an SPI device (FRAM in this case) by having 10 or more spi_transaction_t with the SAME buffer (all 0s) but different writing address in the FRAM?


Thanks.

[rsimpsonbusa]

Ill answer part of my own question.

Looking at spi_master.c we can see

Code: Select all

 r=xQueueSend(handle->trans_queue, (void*)&trans_buf, ticks_to_wait);

Its a FreeRtos queue which is, in theory, FIFO.

[ESP_Sprite]

Yes, the entire operation is FIFO. Also, it's allowed to attach the same data buffer to multiple transactions. Do note that each and every spi_device_queue_trans needs a corresponding spi_device_get_trans_result call.

[rsimpsonbusa]

Thanks ESP_Sprite

[rsimpsonbusa]

Hi ESP_Sprite.

Had the SPI driver in Half Duplex since 1 year or more ago due to the, at that time, "unknown reason" for read corruption. Now read the new 3.0 Docs and it "kinda" tells the reason for the apparent read error, MISO delay.

Now I have the SPI device in IOMUX pins, and tested it with a 40MHZ clock rate, half duplex and works fine, but half duplex and most importantly, NO DMA.

When using 8MHZ(for tests purposes) Full Duplex and just testing 1 command to the FRAM (getdeviceID 0x9F), it again fails when reading just 4 bytes. This is 8 more bits than that magic number 32 bits so much mentioned in the SPI driver. Tried a lot of things and always misses the 4th byte and at a very low speed.

Logic analyzer shows clearly that the FRAM is returning the correct data 0x047F 0x2703 but the esp32 always gets the last byte wrong, no matter what is done, 047F (correct) and 2742 (wrong its 2703 hex).

The Transaction block had 40 total bits and 32 rx_length giving 8 bits to transmit. BTW I guess this is the "math" the driver uses how calculate bits to transmit and how many to receive, since there is no explicit tx_length parameter (is this right?). Total bits - rx_length= "tx_length". Not awfully well explained and no example for reading SPI, just for writing. Should be explained a little more for us dummies.

The value for me is not the full duplex, seldom will a device really use full duplex, but not being able to use the DMA is a loss for the CPU that has to handle the mem-device exchange getting a busy CPU that may not be able to handle another load.

Any ideas?

Thanks.

[dzRBRglobal]

Did you try set the rx bits to 40 and see what happens?