MIPI DSI FPGA board - Page 1
Forum section: electronics / general

author: davorin
author_rank: Unknown
timestamp: May 14, 2018, 07:50:57 am
content: Huomenta sveitistä (o;Has someone came across a nice FPGA board which comes with a DSI display?Or are there any DSI displays with adapter boards so I don't have to solder tiny 0.4mm pitch connectors at my age? ;-)I know of the UltraWearable board from Lattice which is sold bloody cheap at US$ 270 and comes with absolute no examples in source form (o;

author: Berni
author_rank: Super Contributor
timestamp: May 14, 2018, 01:11:57 pm
content: Lattice is actually one of the rare ones that gives you the MIPI DSI code for free. Others tend to want to sell you IP for that.

author: davorin
author_rank: Unknown
timestamp: May 14, 2018, 01:36:35 pm
content: Ah okay...that would explain the high price...I've seen their sample code but no sample code for the UltraWearable board (o;Would implementing DSI in a commercial product mean to be a member of some whatever MIPI group?

author: Berni
author_rank: Super Contributor
timestamp: May 14, 2018, 03:03:26 pm
content: I think the licensing mostly applies for chip manufacturers that make ICs with built in MIPI.There are examples on the Lattice site of doing MIPI with MachXO2 (And i thing a few others). But its not all open source. The actual MIPI part of it is provided as a binary blob, but it does the hard parts of MIPI for you of driving the IO pins and synchronizing itself to the packets on the bus. For my use with a raspberry pi i found that the provided demo code didn't quite work so i rewrote some of the data parsing, but the part that turns MIPI into a convenient 8 bit parallel bus worked great.You have to be part of the MIPI group to get the full spec, but i could still find enough information online to be able to know what every byte sent over the bus meant.Also if you are looking to drive a LCD you likely also need the LCD documentation for it or at the very least a product that runs the LCD so you can sniff the data. This is because MIPI is not a completely intercompatible bus like HDMI where you plug it in and it simply works. The LCD might have specific timing requirements to make it happy or even require an initialization sequence. Much like some parallel RGB bus LCDs need to be initialized and configured over I2C or SPI these MIPI displays can have similar internal registers that sometimes have to be written to using specific MIPI commands. Timings can be found out by trial and error, but whole initialization sequences no way.

author: davorin
author_rank: Unknown
timestamp: May 14, 2018, 08:25:48 pm
content: Well I also have a new 400x400 round AmoLED display where I just got the whole initialization code from the supplier and tomorrow I should receive more documents from their engineers. Interestingly it is much longer as in their public datasheet ;-)Also some small square touchscreens are lying around to experiment with. But all displays require an adapter PCB with 0.4mm pitch connector, and in case of OLED special power supply with S-Wire control.The official 7" RPi display would be great to use, but the specs seems to be a very good secret.

author: tsman
author_rank: Frequent Contributor
timestamp: May 14, 2018, 10:44:16 pm
content: Quote from: davorin on May 14, 2018, 08:25:48 pmST sell a cheapadapterto connect the RPi display to a STM32F769 Discovery board so somebody must have the required specs for it. The RPi touchscreen is strange anyway because it is a DPI screen that they've got a custom DSI to DPI board bolted to the back.

author: Berni
author_rank: Super Contributor
timestamp: May 15, 2018, 06:32:57 am
content: The 7 inch raspberry pi display uses a Toshiba MIPI to RGB chip (I know because blew it and needed to replace that damn tiny BGA). You can get a datasheet for that chip if you dig trough google long enough.As far as i know the LCD panel itself does not need any initialization, but there is also a Atmel 8bit MCU on there that sits on the I2C of that same flex cable to the Pi. This MCU lets the Pi auto detect the display on boot and also controls the backlight by generating the PWM dimming signal to the switchmode regulator for the LEDs. You can get around that part tho by just adding a bodge wire that ties the backlight drivers enable signal permanently high.Also yes some STM32F7 MCUs have built in MIPI video output. You will likely need external SRAM/SDRAM for the framebuffer at those resolutions, but it means you don't have to develop any of the low level MIPI stuff.You are on a good path since you got all the proper documentation for it. One always has to be careful with the chinese and there datasheets as i found tons of mistakes and gaps in them before.

author: davorin
author_rank: Unknown
timestamp: May 15, 2018, 06:41:37 am
content: I could write a song about wrong datasheets from China...especially for those old round TFT displays (which I have plenty lying around ;o)What confuses me for the MIPI displays datasheets is the fact that I see never mentioning veritcal or horizontal timing...Is DSI always meant to drive a display with internal frame buffer where timing is handled internally?But first thing is to do a small PCB for the power supply of the MTD0139AZOG-1 round AMOLED display....and in the mena time experiment with the UltraWearable kit...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 15, 2018, 07:05:18 am
content: Quote from: davorin on May 15, 2018, 06:41:37 amYes.

author: Berni
author_rank: Super Contributor
timestamp: May 15, 2018, 07:07:51 am
content: Actually there are two ways to send pixels to a display over MIPI.The more common one for large resolutions is the DSI way where its essentially a serial version of the RGB bus where giant packets of pixels carry the image and sync packets are mixed in between to toggle virtual Vsync and Hsync lines.The other way is the MIPI DCS mode. This is essentially a serial version of the parallel MPU bus displays where the framebuffer is internal and you just write pixels anywhere you want on it.The DSI mode tends to be more common since not needing a framebuffer makes the displays controller chip cheaper and most applications with powerful CPUs prefer that to avoid tearing issues on moving images. They should not be too picky about the timings as long as your sync packets are in the right place and you are trying to refresh the display at somewhere near 60 fpsEDIT:The 400x400 resolutions is a sort of middle of the range resolution so its possible that it could be DCS or it could be DSI. When you get to resolutions like 1080p you pretty much only get DSI type interfaces

author: daveshah
author_rank: Unknown
timestamp: May 15, 2018, 07:12:51 am
content: Quote from: Berni on May 15, 2018, 07:07:51 amMany smartphone displays are actually moving back to MIPI DCS mode (but the panel typically supports both options), primarily for power saving - no point keeping an expensive multi-gigabit link running just to keep a static display on the screen. Many of the DDICs for the higher resolution displays actually compress the framebuffer internally (if not using Qualcomm FBC/VESA DSC compression over the DSI link) to reduce the required framebuffer RAM by 1/2 to 1/3.

author: davorin
author_rank: Unknown
timestamp: May 15, 2018, 07:31:08 am
content: Does someone know what type the LG LH154 MIPI display is in the UltraWearable kit?Don't see anything mentioned regarding the driving mode...also not on the 400x400 AMOLED display...But there is an interesting project over at github for driving the LG display with an ICE FPGA:https://github.com/gtjennings1/UPDuino-LH154Q01-Display

author: daveshah
author_rank: Unknown
timestamp: May 15, 2018, 08:46:48 am
content: That example drives the LH154Q01 in video mode (no in-panel framebuffer).

author: vaualbus
author_rank: Frequent Contributor
timestamp: June 15, 2018, 11:43:35 pm
content: no you can have dsi video mode wher ethe frame buffer is in the "CPU" memory and not on the display

author: Berni
author_rank: Super Contributor
timestamp: June 17, 2018, 09:24:33 am
content: No need for translation, here is a detailed enough spec in english:http://bfiles.chinaaet.com/justlxy/blog/20171114/1000019445-6364627609238902374892404.pdfI think this the document i used to implement my DSI slave in a FPGA. It shows you the timing diagrams for the signals, how multiple lanes split data, how CRC is calculated and lists out the standard set of commands to send over it.(But some displays may need extra commands to initialize them)

author: carljrb
author_rank: Contributor
timestamp: June 17, 2018, 09:13:17 pm
content: Thanks for that spec! BTW, there is also mikeselectricstuff on youtube that did some FPGA work with MIPI DSI screens, basically reversing the whole thing from scratch. It's kinda long but still has a good amount of info. Personally, I'm mainly gonna use STM32F7 MCUs with 'em.