Home/Questions/Q 1457
Next
In Process
Rutuja
  • 0
Asked: 2022-07-22T15:17:09+05:30 In:

Way to reduce the SPI buffer size.

  • 0

In our project, the parser reads the G-code from the SD card through the SPI interface, using a usual SD.h library. The problem is that regardless of the size of the SD card buffer, the SPI reads 4092 bytes every time, puts them in the DMA buffer, and reads the next 4092 only when the buffer is free. Because of this, the time for reading g-commands is extremely uneven. Most are read in 20µs, but each 146th is read in over 4500µs. (The average length of g-command is 28 bytes, so 4092/28=146.)
4500µs is approximately equal to the transmission of 4KB at 10MHz. This is a terribly unacceptable time that kills all the advantages of the speed of the microcontroller.

Is there a way to reduce SPI buffer size using arduino IDE? I tried to re-initialize SPI with this construction:

#include “driver/spi_master.h”

#define PIN_NUM_MISO 19

#define PIN_NUM_MOSI 23

#define PIN_NUM_CLK 18 static void spi_init() { spi_bus_config_t buscfg; memset(&buscfg, 0, sizeof(spi_bus_config_t)); buscfg.miso_io_num=PIN_NUM_MISO; buscfg.mosi_io_num=PIN_NUM_MOSI; buscfg.sclk_io_num=PIN_NUM_CLK; buscfg.quadwp_io_num=-1; buscfg.quadhd_io_num=-1; buscfg.max_transfer_sz=64; //default to 4092 if 0 spi_bus_initialize(VSPI_HOST, &buscfg, 1); //DMA channel 1 };

This probably works (message “E (280387) spi: spi_bus_initialize(756): SPI bus already initialized” in console), but in general, the situation does not change. Each 146th g-command is still read in 4500µs. SPI bus is still working through some huge 4KB buffer. And I have totally no idea how to divide it into small chunks of 64-128 bytes.

dma bufferg-codespi
Share

    Related Questions

    1 Answer

    1. If you use a RTOS-aware structure (like a ringbuffer, queue, whatever) then you don't need to delay: the push into the buffer will block for you while there's no room available. The amount of elements in a ringbuffer is limited by its size, so you can double, triple, however-many-le buffer the thingRead more

      If you use a RTOS-aware structure (like a ringbuffer, queue, whatever) then you don’t need to delay: the push into the buffer will block for you while there’s no room available. The amount of elements in a ringbuffer is limited by its size, so you can double, triple, however-many-le buffer the things by simply increasing the size of the ringbuffer. Also, perhaps good to mention that by ‘ringbuffer’ I specifically mean the esp-idf ringbuffer construct, as that is RTOS-aware. If you use the bytebuffer mode of that, it would be good.

      See less
      • 0

    Leave an answer

    You must login to add an answer.

    Need An Account,