DMA and Camera input - a notion about 16bit input data

[kolban]

I've been studying the OV7670 camera and the I2S support in ESP32. Specifically, I've been studying the DMA support provided by the I2S peripheral. As I understand the story, the OV7670 presents data in 8bit units each camera clock cycle. The camera becomes the master and the ESP32 becomes the DMA slave. Each time the camera transitions a pixel clock, a new 8 bits of data becomes available.

Now I start to get hazy ... my understanding is that the ESP32 MUST read 16bits of data as a unit. In our samples, we don't configure the upper 8 bits so only read 8 bits of data into each 16 bit sample from the bus that is then written to RAM.

For example, if I am going to read 160 pixels where each pixel is transmitted as 2 clock cycles giving the 1st 8bits of pixel data and then the 2nd 8 bits of pixel data ... then my desire is to ingest 320 bytes. However, because the data is presented as 2 cycles of 8 bits each rather than 1 cycle of 16 bits, then I need to allocate 640 bytes. The data then written to RAM will be

P0L 00 P0H 00 P1L 00 P1H 00 P2L 00 P2H 00 P3L 00 P3H 00 ...

where:

PxL = pixel num Low
PxH = pixel num High

And now the notion that I have in mind. What if we used some simple digital electronics between the camera and the ESP32. Specifically, what if we use a divide/2 counter on the clock so that only every other clock pulse from the camera is sent to the ESP32 and in addition, an 8 bit data latch.

The result would then be that we could present a full 16 bits of data to the ESP32 for each DMA read.

Even clock pulses from the camera would load the 8 bit data latch while odd clock pulses would be passed through to the ESP32 so that it could read 8 bits directly from the camera and 8 bits from the previously latched data.

My electronic skills aren't super great but I believe that these components exist and are cheap. The result would be data in RAM that would consist of:

P0L P0H P1L P1H P2L P2H P3L P3H ....

and hence no wasted RAM space and 1/2 the load on DMA processing.

Again, these are just musings on my part but happy to discuss.

[BuddyCasino]

Wild guess: chain an 8 bit shift register to a 16 bit shift register. I have no idea if this could work though.

Camera to => 8Bit shift register via parallel in, then serial out to => serial in of 16bit shift register => 16bit parallel out to ESP32

[ESP_igrr]

Camera to => 8Bit shift register via parallel in, then serial out to => serial in of 16bit shift register => 16bit parallel out to ESP32

You would need to delay HSYNC/VSYNC/PCLK by correct number of clock cycles though, so that they are still in sync with the data after the shift registers.

My thinking is that you can use something like 74hc573 (e.g. https://assets.nexperia.com/documents/d ... HCT573.pdf), an octal latch IC. First you feed the pixel clock from the camera into a divider by 2. Divided clock is fed into one latch, and inverted divided clock is fed into the other latch. This way, one latch samples the first 8 bits and the other latch samples the next 8 bits. Circuit idea attached (not tested... might need some tweaking of the clock phase which goes to the ESP, e.g. delay it by 1/2 cycle).

I see the main benefit of such solution not in reducing DMA transfer overhead, but in allowing higher speed PCLK signals from the camera. As you know, ESP32 is limited to 20MHz PCLK. However some applications require higher pixel clocks (for example if you want to record broadcast PAL/NTSC, you need 27MHz, i think. If you use this circuit to convert 8-bit 27 MHz stream into a 16-bit 14.5 MHz stream, then ESP32 can be used in this application. The only issue is that you need 16 input pins, which really stretches ESP32 to its limits.

New Doc 2017-08-01.jpg (444 KiB) Viewed 11617 times

[BuddyCasino]

nice! I see igrr knows his 74er series chips

[ESP_igrr]

nice! I see igrr knows his 74er series chips

There was a time when i used them to remember my PIN codes

[kolban]

Thanks guys for the thinking ...

@igrr,
Very interest in something you said "The only issue is that you need 16 input pins, which really stretches ESP32 to its limits.".

Give that the ESP32 has more than enough exposed GPIO pins and that DMA support exposes 16 bits of input bus ... isn't a 16 bit parallel input stream within the "core specs" of the ESP32? Is there something in the internal architecture of the ESP32 that we would be stressing reading all 16bits of input? I'm not seeing the concern or why reading 16bits as a unit would be more costly than reading 8 bits as a unit and zeroing the upper 8 bits (as in the sample app)?

[ESP_igrr]

ESP32 has more than enough exposed GPIO pins

Well, you need 16 pins for data, hsync, vsync, pclk (all inputs), xclk (output), I2C (2 pins) then you need at least UART (2 pins), SPI flash (4-6 pins). Maybe some pins are used for bootstrapping (which prevents them from being used as inputs or for I2C), in total I think this is close to the number of pins available on the chip. You have a small number of pins left, but basically this means almost no other peripherals, no SD card, no JTAG. And you need to use a bare chip, not a module. Still doable, and I would very much like someone to design a board around this concept!

[michcfr]

Hello,
And what about coupling D0-D15 to 16-Bit I/O Expander like the MCP23S17 that can do high speed SPI at 10Mhz to the ESP32?
It would save ESP32 pins and use SPI DMA access.

Regards,
Michel