STM32F429I using DCMI in YCbCr mode with the TVP5150 and TFT LCD

Popcorn · ‎2014-10-10

Posted on October 10, 2014 at 17:16

Hello,

I am making a device that uses the TVP5150 via DCMI to display a video using YCbCr on an STM32F429I devicein 4:2:2 format. It is clear in the Reference Manual that the STM32F4 supports YCbCr in DCMI, but it is unclear how to use it correctly.

What I don't understand is after the frame is received, to display the frame in RGB on the TFT LCD, is any post processing needed on the YCbCr information received with the DCMI? I have looked at numerous camera examples, even looking at one provided for use with DCMI in the ''STM32F4 DSP and Standard Peripheral Library'' (STSW-STM32065)and it seems that goes as far as creating a function thatcanswitch the camera to ''YUV''but at no point in the program does it call that functionto actually do it.

If there is post processing needed to convert frames from YCbCr to RGB, would it be fast enough to show video at a ''non-choppy''paceat its 2048x2048 maximum DCMI resolution? Or would I have to use the FPU to do the conversions?

Thanks,

Patrick

#stm32f429 #stm32f429i

Popcorn · ‎2015-01-12

Posted on January 12, 2015 at 17:36

The version I have posted here is the fastest version, which receives the entire screen via DCMI, then converts it and displays it.

Precisely. The one version that came closest to working as I saw online was converting 1 of 4 quadrants of a DCMI capture so it would basically capture a full screen in 4 VSYNC pulses. Unfortunately he wasn't displaying the image and could afford to have a slight delay between conversions.

I presume it's still being captured as my program is converting. That way as soon as I display it, I have the next set of information to convert. I may try it once again in the near future, but I'm considering a method of getting the full RGB information to the STM32f4 rather than YCbCr and then converting it. It requires more external components, but it will mean I get this thing going a bit faster.

stm322399 · ‎2015-01-12

Posted on January 12, 2015 at 20:11

I am afraid you are wrong. The code stops DCMI capture, then converts the image and then enable DCMI again. It is likely that you are missing at least one frame during the conversion (maybe two), then when DCMI is re-enabled again, the capture will start at the beginning of the next incoming frame.

Popcorn · ‎2015-01-12

Posted on January 12, 2015 at 21:00

Sounds like you're right. If it were still capturing while I was converting then the DCMI would probably overwrite what I'm reading in the SDRAM to convert and weird things would happen in my conversion.

Makes sense now that it pauses when an interrupt occurs and it's in the DCMI handler routine.

I can't think of a way to capture n+1 while I convert and display n.

stm322399 · ‎2015-01-13

Posted on January 13, 2015 at 10:39

If you had twice the image size in SRAM it would be simple: the DMA capture use a double buffer (A/B), and you convert N while DMA captures N+1. The only condition: convert fast enough to end the conversion of frame N before N+1 terminates and that DMA will overwrite N with N+2.

If your conversion software is fast enough, you can use a single buffer for DMA capture, let it work continuously without intervention. The program the DMA to fire an interrupt when half the buffer has been transferred. When the interrupt happen, you start to convert the first half of a frame that is not yet finished to be received, and the DMA is in advance of the conversion by one half of the frame.

To make it safe, limit the conversion the the first half, then wait for end of DMA, and convert the second half.

waclawek.jan · ‎2018-08-17

This is the code attached to post at January 09, 2015 at 16:51, posting it here as it got lost in the conversion between the different versions of forum.