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

[Popcorn]

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

[megahercas6]

Posted on October 10, 2014 at 22:12

You have a problem, pins between DCMI and LTDC_RGB565 output are conflicting, you could make it work by using FMC and on board TFT controller like SSD1963, or at least i think that way

[Popcorn]

Posted on October 10, 2014 at 22:33

I just checked back and noticed the original post was empty so I put text back in.

I'm not sure why that happened.I am using the STM32F429I (176LQFP)There are no pins that are conflicting. I am getting the correct information via the DCMI in YCbCr format.I am using the FMC for SDRAM, and I am using the LTDC in ARGB888 format. There are no conflicts between them

[Tesla DeLorean]

Posted on October 10, 2014 at 23:14

Perhaps you posted from a mobile device? This quality Microsoft forum software works worse than some from 15 years ago.

I think the DMA would fail long before you got to 2048x2048. I'm not sure the DCMI interface really cares about the palette format of the data it's transferring, so configure the bit connections to suit your needs.

[zeus_zhn]

Posted on November 13, 2014 at 10:12

Hi,Chung:

I met the same problem as you, the ADV7180 only supports ITU656 output, so I am not sure how to interface with the DCMI and how to display it on the LCD. I also use the STM32F429, Any suggestion?

[Tesla DeLorean]

Posted on November 13, 2014 at 17:44

The DCMI only supports parallel data width of up to 14-bit, it thus won't support 16-bit wide buses. You'd probably need to configure it as 8-bit.

You'll either have to configure your codec, or display, to use compatible pixel formats and colour depth, OR you'll have the manage the transcoding of them yourself. The DCMI is agnostic to the bit format, as far as I'm aware. So understand your source and destination formats, and capabilities/configurability of your capture and display devices. And understand the physical interconnect of bits and clocks via the DCMI.

[Popcorn]

Posted on January 05, 2015 at 23:02

You are absolutely correct clive. I posted it from my mobile phone originally.

Well I had to take a long break from this project and I've been back at it for a couple weeks now.After some testing, some internet research for people that have done the same, and more testing, I've come to the conclusion that this chip is not fast enough to receive YCbCr information and convert it to RGB so it can display with its own LTDC controller. I did not find one person that completed their project to convert YCbCr input to RGB for screen display, only lots of started projects and unanswered questions.I've created code as fast and large as possible, going from converting from YCbCr to RGB with precalculated lookup tables and absolutely no math.I found an example of a person online that also uses a TVP5150 on his STM32F4, but he is not displaying the picture converted from the TVP5150. He is converting it in 4 separate quadrants (each quadrant per VSYNC so a full image is ''captured'' with 4 frames) but he is using the captured information to alter lighting characteristics of the actual video output that's external to the STM32F4.I've even tried overclocking my STM32F429 to the presumably maximum stable clock rate (250MHz) and it shows very slight signs of improvement.I'm pretty confident that if it were pre-converted RGB received via DCMI in the NTSC size (720x525) that it would be quick enough to display on its own LCD controller since DCMI will basically just be writing the received RGB information directly into the SDRAM and LTDC display buffer. I have yet to find a chip that is capable of doing NTSC/PAL to Digitized RGB with 8 to 12 input lines to the DCMI. The STM32F4 seems capable of displaying RGB video cameras at 320x240 and 640x480, but it is not capable of converting YCbCr to RGB and then displaying it quickly.The DCMI should be renamed DSCMI (Digital still camera interface)Unless I'm missing something entirely. Anyone have any input?

[stm322399]

Posted on January 06, 2015 at 08:14

Hi Chung,

it's true that is is not easy to cope with DCMI->SDRAM transfer, plus YCrCb->RGB computing, plus SDRAM->LTDC transfer. If you restricts your project to 640x480, memory transfer are manageable. On the other side I have no clue at all on the CPU power required for the color conversion. Could you elaborate and post time measurements (say for a single 640x480 picture), maybe with some conversion code, so that we can debate and argue.

[Popcorn]

Posted on January 09, 2015 at 16:51

Unfortunately I can't reduce the conversion size. The NTSC standard is 720x5

I didn't physically record any measurements. I only performed mental notes. But when I was receiving from the DCMI line by line I got a clear picture of its conversion speed inadequacy. First, I checked if the DCMI could capture the entire frame on a line by line basis. I set up the DCMI IRQ Handler to open up on every HSYNC pulse and every VSYNC pules. I found that it would get all 525 lines of HSYNC pulses. And reset the capture position correctly on each VSYNC pulse. (At times it would randomly shave one line off of the capture, but I wasn't too concerned) I then tried to convert each line as it was received by the DCMI. It went from successfully capturing 525 lines, to capturing around 20 to 30 lines and converting. I thought maybe it was my external memory speed (Downloading via DCMI to SDRAM, then reading the SDRAM and converting and placing back in SDRAM). So I minimized the use of SDRAM. I captured a single YCbCr line to internal memory. When I received the HSYNC pulse, I converted it to RGB and dumped it to the LCD display buffer at 0xD0000000 in SDRAM. The resultant speed remained the same. The SDRAM turned out not to be the bottleneck. In the same respect, if I capture line by line YCbCr to internal memory, then shove it in RAW format to the LCD display buffer without conversion so I'll only see noise, it is able to do all lines with no issues. Of course, it is also fluid in the refresh rate where the converted RGB is always choppy. I've attached the fastest version I could piece together with some of my own code and some things I found on the internet. It is crude and uncommented, but mainly because I just wanted to get it working, then I could clean it up after if it worked out. This version is not line by line as my testing above explained. This version captures the full screen and converts it with YCbCr to RGB lookup tables. I also have some cropping in there to take off front and back porch. ________________ Attachments : DCMI.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0SY&d=%2Fa%2F0X0000000bcq%2FTvg2h25kb.b7HxoKYVBozenJ4gg2Xr0i_QEUGeJQgf8&asPdf=false

[stm322399]

Posted on January 09, 2015 at 19:41

If I understand correctly, your example captures a single frame (DCMI to internal SRAM, via DMA), then it converts to RGB (internal SRAM to DRAM via software loop). The LTDC is not synced with capture, this is not an issue, it only consume a part of the DRAM bandwidth.

The sequential nature of this design (capture, conversion, capture again, ...) is not optimal. To make it better, the capture shall not stop during conversion. Ideally, you need to convert frame N, while receiving frame N+1. If you run out of internal SRAM, think converting and capturing frame by halves.