Showing results for 
Search instead for 
Did you mean: 

Are there any plans for a MIPI CSI-2 peripheral?

Ben Webster
Posted on September 18, 2017 at 14:09

We are currently using an STM32F437 with a 12 bit parallel interface to a CMOS image sensor, and we are happy with performance etc. However many newer image sensors require MIPI CSI-2, and even the current sensor offers higher frame rates/resolutions with CSI-2. While it is possible to use converters from CSI to parallel, these still run into the bandwidth limitations of the parallel interface (although I notice this is a little better on STM32H7 at 80MHz rather than 54MHz on STM32F4), and it's a shame to have to use another IC.

Are there any plans to provide a MIPI CSI-2 interface on any STM32 devices? We would really like to have an upgrade path to new sensors without having to move to a competing device, e.g. a larger SoC. We would be interested in at least 1 lane, with support for at least RAW10 and RAW12 formats.

#stm32 #csi #dcmi
M. Jeong
Associate II

​I'm also curious if ST has such plan. Could some from ST can answer this question?

Strikes me that the rest of the hardware is ill-suited to actually do anything useful with the acquired data once it arrives.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Ben Webster

We've found that with the right code, the 437 is more than enough to do what we need to do with image data. STM32 performance is only increasing with time, so this should open up more possibilities (e.g. the H7 parts look to be something like 3 times faster than the 437).

I can't give details of our application, but see for example the OpenMV ( ), which does a pretty wide range of useful stuff - face and blob detection, QR code and other tag reading, etc. On the STM32H7x3 (as far as I can tell - I haven't tried this) it should be possible to JPEG encode images in hardware, which would give a data rate that can be pretty easily handled for streaming or storage.

Note that it is still useful to be able to achieve higher data rates even if those data rates could not be processed if used at 100% duty cycle - many newer sensors have only CSI-2, and must send data at a fixed (fairly high) rate, however this rate only occurs in bursts during frame readout. In normal use the average data rate is lower, and data can be buffered. If necessary many sensors can be operated at lower resolution, bit-depth and/or frame-rate to reduce the average data rate further. The problem is mostly just in implementing the data interface itself and handling the required clock rate, not dealing with the average rate of data arriving.

The advantages of using an STM32 are reduced cost and complexity, easier implementation of hard real-time image processing, better selection of low-level peripherals and much better documentation and lifetime relative to a cost-effective SoC (and possibly even compared to one of the pricier ones aimed at industrial use), so I think there's a very real niche for STM32 in imaging applications.

On the display side the rivets seem to start ​popping at rather pedestrian 800x600@60Hz. I can go higher but have yield some colour depth but the hull is definitely creaking.

Two channel DSI, on even the newest silicon, I can't see this doing 1080p let alone 2K or 4K​, or a memory subsystem with enough bandwidth.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..


Ben here has a point - for some applications taking still pictures you don't necessarily need significant processing power. And, camera input does not necessarily means you need to output or even store the picture.

Something similar may apply for displays - you don't always want moving picture with layers, and indexed colors are completely OK for many embedded applications. However, often the trouble is that you don't really can buy displays in sub-million batches with whatever properties you may wish for, and that includes the interface. My colleague has just shown me some new displays in interesting unusual form factors - and they don't even have an exceedingly high pixel count, just that they are 4-lane DSI.

All this said, we may have dreams about connectivity, but at the end of the day it's the big players who determine what comes true. I believe the main obstacle for any MIPI interface (or DVI/HDMI for that matter) are licencing issues.


Still wating MIPI CSI on stm32...

Waiting and hoping are not effective at advancing change. If you have a practical application take it to your sales contact, shake that tree and see what's in the pipeline / roadmap.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Sorry if my contribution is too basic - my background is software rather than microcontrollers so I apologise for my lack of knowledge.

I'm looking for the same thing for an unpaid research program - a microcontroller (#MCU) that supports #CSI-2.

This 2023 ST application note on #STM32MP15x says

"STM32MP15x Series interfacing with a MIPI® CSI-2 camera" says that "it is possible to extend the range of addressable camera sensors for instance MIPI® CSI-2 cameras (camera serial interface), thanks to the STMIPID02 MIPI CSI-2 deserializer discrete component"

I haven't tried this though.

One workaround for microcontrollers that don't support CSI-2 may be that some cameras support #I2C - I2C fast mode or I2C fast-mode plus - I don't know if these can reach the same transmission rates as CSI-2 though nor how well supported they are and careful design can be needed to avoid problems with interference in I2C buses.

One other option I'm looking at is the #SAMA7G54 "New 1 GHz SAMA7G54 is the First Single-Core MPU with MIPI CSI-2 Camera Interface" which was launched in 2022.

The Analog Devices #MAX78002 data sheet dated 2022 states

"Multiple high-speed and low-power communications interfaces are supported, including I2S, MIPI® CSI-2® serial camera"

This field is rapidly changing so I've included dates in the above.

At the moment the plan here is to use the the Raspberry Pi Camera Module 3 (Sony #IMX708 ) with a Raspberry Pi SBC however the power consumption of SBCs is significantly higher than microcontrollers and I haven't found any SBC that can rapidly wake from a low power sleep mode in the way that some microcontrollers can.