ESP32 Forum

ESP_Sprite wrote: ↑

Wed Aug 05, 2020 6:15 am

It's a hard problem in general... as you need software to set up the start of each separate 16-bit transaction, there will be a lot of overhead. Only way I can imagine to do it in software would be to abuse the I2S hardware.... theoretically, you can put it into 16-bit mode and use the data output to pulse the SYNC line. That would involve poking the hardware registers directly (or modifying the existing I2S driver), however, as the current driver is not made to do this.

ESP_Sprite wrote: ↑

Wed Aug 05, 2020 8:34 am

Whoops, I initially imagined you wanted to set up an ADC. A DAC may be even easier. Effectively, I2S allows you to set up a continuous SPI-like stream of data, read from a memory buffer without any CPU interference; the only thing the CPU needs to do is to make sure the memory buffer gets 'topped up' with new data once in a while. Suggest you look at the I2S documentation in the ESP32 technical reference manual and see if you would be able to generate the correct waveforms your DAC needs with that hardware.

ESP_Sprite wrote: ↑

Wed Aug 05, 2020 8:34 am

Whoops, I initially imagined you wanted to set up an ADC. A DAC may be even easier. Effectively, I2S allows you to set up a continuous SPI-like stream of data, read from a memory buffer without any CPU interference; the only thing the CPU needs to do is to make sure the memory buffer gets 'topped up' with new data once in a while. Suggest you look at the I2S documentation in the ESP32 technical reference manual and see if you would be able to generate the correct waveforms your DAC needs with that hardware.

#include "Arduino.h"
#include "driver/i2s.h" 

static const i2s_port_t i2s_num = I2S_NUM_0;

static const i2s_config_t i2s_config ={
    .mode = (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_TX),
    .sample_rate = 100000,
    .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
    .channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,
    .communication_format = (i2s_comm_format_t)(I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB),
    .intr_alloc_flags = ESP_INTR_FLAG_LEVEL1,
    .dma_buf_count = 8,
    .dma_buf_len = 1024,
    .use_apll=0,
    .tx_desc_auto_clear= true,
    .fixed_mclk=-1
};

static const i2s_pin_config_t pin_config ={
    .bck_io_num = 27,
    .ws_io_num = 26,
    .data_out_num = 25,
    .data_in_num = I2S_PIN_NO_CHANGE
};

void setup() {
    Serial.begin(115200);
    i2s_driver_install(i2s_num, &i2s_config, 0, NULL);
    i2s_set_pin(i2s_num, &pin_config);
}
void loop()
{
    static uint16_t Value16Bit[18]={ 0, 0b010, 0, 0b010101, 0, 0b10101010, 0, 0b010, 0, 0b010101, 0, 0b10101010, 0, 0b010, 0, 0b010101, 0, 0b10101010 };

    size_t BytesWritten;

    unsigned long tt=micros();
    unsigned long count=0;
    while (micros()-tt<1000000)
    {
        i2s_write(i2s_num, Value16Bit, 36, &BytesWritten, portMAX_DELAY);
        count+=9;
    }
    Serial.println(count);
}

ESP_Sprite wrote: ↑

Wed Aug 05, 2020 3:02 pm

You may want to set USE_APLL to 1 as well as use a larger dma_buf_len... could be that the issue is that the ISR gets called too often or that the I2S driver has issues generating the frequencies you need.

PeterR wrote: ↑

Thu Aug 06, 2020 12:17 am

Hey,
Not sure about Ardunio but DMA under IDF adds a 20uS+ (ish) hit.
A key point is the construction of the SPI transaction. IDF you can create this 'command' on the fly or you can create a command and then reuse. The performance difference is very important as frequency increaces...
I am not sure about the Ardunio interface but my IDF experience is that the SPI libary is quite laggy. I have 3 transactions at peak 250KHz and that (latency wise) pushes a core to limits. So I find it hard to sustain 750KHz (few SPI bytes) SPI transactions using IDF. I live with this ATM and have not yet made the obvious improvement of saving/reusing a transfer object. The SPI handler is short and sweet but still latency bites.
Adding DMA for short (<8 byte) transfers is not productive. Too much added setup time in the ESP library.
So... with a quick glance at your code I do not see the ability of your library to return a 'spi transaction' object. This suggests that the 'spi transaction' object is being created in each request. ESP IDF allows you to create the transaction & then reuse. This does shave 10-20uS from each transaction.
Its not a great answer but I would suggest IDF and create your SPI transaction at startup. Forget DMA and (obviously) setup processing/interrupts on core 1. If you use Ethernet then you will be hit with 2mS+ random latency. Would be interested in your experience there as that is another issue I live with.
In short, ESP software library latency
PS
Abusing I2C is an interesting approach. I think though that you might just achieve 1.25MHz under IDF with prepared requests, IRAM and proper core discipline. If you use Ethernet then you are screwed; you will get <2 mS random hits. Low frequency so guess it depends on noise immunity.