ESP32 Forum

Hi,
i'm new to the esp32 and also never done anything meaningful with the esp8266.
I was studying the esp32-cam-demo source code and some questions occured.
Maybe someone can enlighten me.

What i don't quite understand why "s_dma_buf"/"s_dma_desc" ist defined/used 3 items big or at which times the different items are used.
Also i don't quite understand why the corresponding buffer is line_width * 4 big.
I understand that the used i2s interface gives out 16bit instead the used 8bit but don't quite understand the numbers, or the complete flow of data.

Actually, s_dma_buf has two elements, these are two DMA buffers used in a round robin fashion.
Each buffer needs to hold one scan line of an image. Each pixel is represented with two bytes read sequentially from the camera. As you have mentioned, I2S peripheral stores 16 bits of data at a time even if only 8 data inputs are connected to the camera. So the size of the buffer is line_width * bytes_per_pixel * 2, i.e. line_width * 4.

The data written to s_dma_buf is processed by line_filter_task: luminance component is extracted and stored into the frame buffer. This happens while the next scan line is being filled by the I2S peripheral.

Oh... i was totally focused on 3 buffers, (i don't know why..) and was therefore completly confused by the index flipping between 0 and 1.
I was also confused why the final fb seems to be smaller as "height * (line buffer - 16)", but only using the luminance component of the pixels explain this.

Thank you.

Another question:
I see that the interrupt "ETS_I2S0_INUM" is triggered by the (falling?) edge of WS (PCLK).
I'm looking into also capturing JPEG frames, i see that falling vsync edge is captured with a loop looking at the gpio level.
Would it also be possible to use an interrupt to trigger an interrupt on vsync to also stop jpeg capturing?
Or should i better look if an JPEG footer happens in the incoming data?

The JPEG transmitting seems kinda tricky and partly undefined to me.

To the long cable problem that happened to you: Could this probably also be a timing issue?

Are there performance reasons that every second line is skipped and the previous line is copied in place or is this just to ease the "ascii-conversion" that happens later?

Yes, I think I was initially writing this code when only 80MHz clock frequency was available, so I had to skip every other scan line to keep up with frame rate.

Regarding I2S interrupt, it gets triggered when given number of samples have been received. The number of samples is written into I2S_RXEOF_NUM_REG before starting I2S.