STM32 DCMI - RGB565 input data, manual not clear

[Yansi]

Hello,

anyone any experience with the DCMI peripheral on STM32F4 series?  The peripheral can input 8-10-12 or 14 bit input words from a video source. I would like to try capture a VGA sized video signal, in 16 bit color (RGB565). Reference manual states the following:



Follows some more description, but what caught my eye is the obvious requirement for two clocks per pixel. That is very atypical. Not sure, if normal for real camera devices, but certainly not for other video sources. I would need to double the pixel clock and multiplex 16 input as 2 times 8. My source of video simply gives 16bit data, pix clock, H and V.

Anyone actually tried to input RGB565 into the STM32F4 using DCMI? How have you solved the data multiplexing and pixel clock doubling?

Y.

[pcprogrammer]

If you want to do it in a single clock you just have to drop two color bits and make it 14 bit instead of 16. The decoding will be another issue. Have not looked into the DCMI that deep. You probably just have to use monochrome mode and have the software deal with the color parts.

Think it is best to drop one bit from green and one from blue, to make it RGB554. 

[Yansi]

Further bit dropping is already unacceptable, my target was to input at least RGB666 (18bit color), already dropped 2 bits as I do not see any other sensible way, to input it.

Wider DCMI modes (10-12-14 bits) do stack the data within 32 bit word in such a manner, the CPU will shit bricks to make it into any usable formatted data for further processing. (Same I don't understand, why there is any support for YCbCr in DCMI, as those STM32F4 do not provide any support for these formats, other than bruteforcing it again all using CPU power). Like if someone could get hurt, adding 2 extra bits to make the DCMI actually usable without need for hacks. 

Also have noticed, that if I double the pixel clock, I will be almost approaching the maximum allowed pixelclock of 54 MHz. (VGA runs at slightly above 25 MHz).

[pcprogrammer]

Where is this VGA signal coming from and what do you plan on doing with it in the F4 MCU?

For the YCbCr format, it can directly output it on the DSI peripheral to have it displayed on a suitable display.

I'm not familiar with cameras and their video data formats, but I assume the people who designed the DCMI based the design on some common standards for cameras and not for capturing other video data formats.

None of the F4 MCU's have the power to do intense video processing, so it sounds to me that you want something the F4 range is not suited for and maybe you should search for a better match to you application.

[Berni]

What do you actually want to do with the video?

Small MCUs like that are not exactly designed for video processing and don't have the horsepower to do much more than DMA the data around. This peripheral is mostly designed to let you interface low resolution cameras to the STM32 where it could then perhaps display a preview, detect motion or just take single snapshots. It certainly wouldn't be recording video or doing processing on it live.

Often a small FPGA is a better solution for video as they are good at performing processing on steadily streaming data like that.

[dmendesf]

Look at this document to understand how bits are captured and processed by the DCMI:

https://www.st.com/resource/en/application_note/an5020-introduction-to-digital-camera-interface-dcmi-for-stm32-mcus-stmicroelectronics.pdf

[Yansi]

pcprogrammer: From an analog VGA or DVI/HDMI input. That part is not decided yet. Does not matter, the output format will be always practically the same. RGB 16bit color, H+V sync, clock at ~25 MHz.

Also not familiar with cameras, but I am very sure, that limiting the DCMI input to 14 bits and not implementing full 16 bits, was a very dumb idea. Would it hurt so much, to make it 16 bits? Also, the format the DCMI is stacking the captured data in memory, for any width other than 8bit input capture, is nothing standard and is further incompatible with other graphic oriented peripherals in STM32. CPU hogging required to reformat captured data.

Yes, later models of STM32 got upgraded with DMA2D, that could do YUV-RGB colorspace conversion. However, in STM32F4 product line, there is (to my best knowledge) none device that supports YUV (YCbCr) by other peripherals.  So the only practically usable mode for live viewing cameras, is RGB565, which is crippled, because of 2 missing bits in the input data interface, so some (I think) rather not common multiplexed 8bit mode must be used. Hate stupid STM32 limitations like these. 

Berni: What to do with the video? Not that surprisingly, I will try to display it somewhere. Don't take it as a rude answer please, that is simply what I plan to do.

Sure, not much processing power by just CPU itself, but the DMA2D is a pretty useful tool. I would not call this "just DMA", it is capable of doing much more than regular DMA.

I agree, that an FPGA would be much better choice for video processing. But this time I'd like to try something a bit more special. As a learning experience, mostly.

dmendesf: That document is unfortunately only a glorified colorized copy of the exact text from reference manual. No bonus explanation regarding the RGB565 input mode. But at least the document lists important tricks for the DMA to transfer more than 65536 words, by using the double-buff mode, reprogramming addresses on-the-fly from within a DMA interrupt.