1. What is the maximum value of the length of spi_transaction_t that can be transfer in one transaction?
2. Can the transmitted data be held in SPI Flash?
Colman
Max tx length of spi_transaction_t?
- martinayotte
- Posts: 141
- Joined: Fri Nov 13, 2015 4:27 pm
Re: Max tx length of spi_transaction_t?
According to specs, the SPI FIFO are 64 bytes.
Re: Max tx length of spi_transaction_t?
As far as I can see, if using spi_master driver, the size of the transaction transmit buffer is limited only by the amount of free heap (or stack, if you allocate the buffer on the stack).
Re: Max tx length of spi_transaction_t?
I have a buffer of 76.8K bytes(half of the LCD screen buffer), I want to use spi_master to transmit the whole buffer to SPI port in one transaction. After a trial, I found the maximum bytes that can be transfered in one transaction is 4095 bytes. It will send wrong data when the length is more then or equal to 4096 bytes. Is it possible to transmit more than 4096 bytes in one transaction?
And second question is the possibility of transmitting the SPI Flash content directly without copying to internal RAM.
Colman
And second question is the possibility of transmitting the SPI Flash content directly without copying to internal RAM.
Colman
-
- Posts: 9761
- Joined: Thu Nov 26, 2015 4:08 am
Re: Max tx length of spi_transaction_t?
At the moment, the maximum is limited by the maximum amount of bytes that fits in one DMA link descriptor. which is 4KiB. It can be improved by chaining DMA descriptors, but implementing this in the driver is still something I need to do. The transmission buffer also needs to be in DMA-able memory, which for the ESP32 is only the internal DRAM.
Re: Max tx length of spi_transaction_t?
I'm using modified spi_master driver to work with TFT displays which has added direct (not queued/DMA) mode. It works much faster that way. Writting lot of individual pixels (for example when displaying fonts) works more than 10 times faster than when using queued transactions. As display memory can be read as well as written, there is not much need for frame buffer (which I don't use).colman wrote:I have a buffer of 76.8K bytes(half of the LCD screen buffer), I want to use spi_master to transmit the whole buffer to SPI port in one transaction. After a trial, I found the maximum bytes that can be transfered in one transaction is 4095 bytes. It will send wrong data when the length is more then or equal to 4096 bytes. Is it possible to transmit more than 4096 bytes in one transaction?
And second question is the possibility of transmitting the SPI Flash content directly without copying to internal RAM.
Colman
My code is part of the Lua-RTOS project, but the driver code is independent so you can use it in other projects. The code is tested and works very well with clock speeds up to 40 MHz (on couple of ILI9341 board I've tested). You can check it at
https://github.com/loboris/Lua-RTOS-ESP ... os/drivers espi.c & espi.h (modified spi_master with added display handling functions)
https://github.com/loboris/Lua-RTOS-ESP ... les/screen tftspi.c & tftspi.h (low level display functions), tft.c (high level display functions and Lua functions)
Re: Max tx length of spi_transaction_t?
I'll be the first to say that I don't know what I'm talking about ...
Looking at the SPI driver docs, there appears to be the ability to register a callback function that is invoked when the transmission completes. If we are constrained to sending no more than 4K in one transmission but you have more data to send than that ... would it be possible to chunk the data you want to send into 4K units and register a callback that is invoked after each 4K unit completes to send the next unit?
Looking at the SPI driver docs, there appears to be the ability to register a callback function that is invoked when the transmission completes. If we are constrained to sending no more than 4K in one transmission but you have more data to send than that ... would it be possible to chunk the data you want to send into 4K units and register a callback that is invoked after each 4K unit completes to send the next unit?
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: Max tx length of spi_transaction_t?
As far as I know, the spi_master use DMA to transfer data, and its DMA mechanism use a linked lists to hold a chain of descriptors. I believe that the spi_master will setup a chain of descriptors to do the transfer. If the spi_master cannot allocate the linked lists due to not enough memory, it should return error rather then sending the rubbish out. Since there is no information about the format of the descriptor, I don't know how it done.
By the way, the linked lists can form an endless chain so that it will repeatedly sending out the buffer content after kicked off without further CPU attention.
Colman
By the way, the linked lists can form an endless chain so that it will repeatedly sending out the buffer content after kicked off without further CPU attention.
Colman
-
- Posts: 9761
- Joined: Thu Nov 26, 2015 4:08 am
Re: Max tx length of spi_transaction_t?
Yes, the SPI hardware can create a linked list of DMA transfers; however the SPI driver does not implement this yet. I'm planning to take a look at the SPI driver next week; I'll have a go at implementing that as well. That should allow you to do transactions of any size. I agree that handling of transactions >4K is not very good at this moment, my apologies for that.
Re: Max tx length of spi_transaction_t?
Hi,ESP_Sprite wrote:Yes, the SPI hardware can create a linked list of DMA transfers; however the SPI driver does not implement this yet. I'm planning to take a look at the SPI driver next week; I'll have a go at implementing that as well. That should allow you to do transactions of any size. I agree that handling of transactions >4K is not very good at this moment, my apologies for that.
I'm interesting to implement a chain of DMA for a spi communication...
Do you have implement the SPI driver?If not, do you have some trick/suggestion to do it?
Who is online
Users browsing this forum: Bing [Bot] and 109 guests