Reduce required minimal frame blanking period of CX3 GPIF

[MaOs_1615421]

Hi

I read in multiple threads that the fixed function GPIF of the CX3 requires a ~200us frame blanking period to wrap up the partial DMA buffer associated with the end of a frame. Unfortunately, for our application we need to deal with frame blanking periods that are as small as possible (preferably only a few microseconds). I've read about a solution that makes sure that the DMA buffer size is chosen in a way that the last buffer of a frame is full and the CPU does not need to wrap it up. However, the firmware has to count the buffers then, in order to detect the frame end. Furthermore, I understood that this solutions would require some changes to the GPIF. How can I change the GPIF of the CX3? Does someone already have a working solution for such short frame blanking periods?

Thanks.

[Hemanth]

Hi,

Can you please let me know howmuch will the frame blanking be?

Regards,

Hemanth

[MaOs_1615421]

Hi

The ideal frame blanking period would be 2.5us. But if this is not possible, we can configure our sensor to reduce the data rate and increase the frame blaning period to about 10us. I would have to check to see how much further we could increase without sacrficing too much bandwidth.

Best regards,

Marc

[Hemanth]

Hi Marc,

If you are using SDK 1.3.4, can you try with 10uS frame blanking?

Regards,

Hemanth

[MaOs_1615421]

We are already using SDK 1.3.4. In the attached image you can see that it works well with a frame blanking period of >276us. If we go below that, the FPS drops to half. For your reference, in the image shown below, we operate our sensor in a test pattern mode where we can arbitrarily set resolution, fps and frame and line blanking periods. The parameters for this test were set as follows:

Resolution: 1024x200
Format: RGB888 (24bit)
FPS: ~310 Hz
Line blanking: 2us
Frame blanking: 276us

The signals are direct measurements of the PLCK, VSYNC and HSYNC testpoints on the Denebola board.

When we keep those settings but reduce the frame blanking to ~200us, we already loose every second frame:

[MaOs_1615421 · Accepted solution]

I'd like to share a quick update on our progress. We managed to get it working through a workaround: we basically send an infinite long frame which never ends such that the GPIF never goes into the frame end state. We only transmit full DMA buffers and we count the lines in the firmware and add start end end of frame headers accordingly. It seems to work fine. We can handle frame and line blanking of 2us now.