Phone screens for "home" projects.

[rew]

My phone screen is damaged so I bought a new one on aliexpress. I still have to replace the screen, but that's not the issue.

The thing is with the LCDS for "home" projects., they quickly become more expensive once they become bigger than say 4.3 inches. So for an (almost?) 6" screen my replacement screen is quite cheap and it has 4x more pixels than the screens intended for hobbyists.

Now my phone is able to display at least 30 fps almost-full-HD on that screen, so the interface  is probably quite fast. But with a bit of trickery an RP2040 could be convinced to drive things like that, even though it doesn't have the memory for a framebuffer of that size. We'll think about that later.

The connector is a bit "small pitch" but looks doable to solder one of those on a board. I'm not afraid of that.

So... I have a screen, would it be possible to figure out the pinout of that connector? Would it be possible to figure out the chip that's driving the screen? (The way I understand things, the chip driving this screen probably has 1440*3+1920 pins for driving the LDC alone. There is not that many lines in the FPC: I know that from 3km away. So there must be a driver chip in the LCD part...)

[fchk]

This is most likely a MIPI DSI display.
https://www.mipi.org/specifications/dsi
The specs for this interface are only available to members, and the interface is quite complicated. The differential pairs can be either act as a true LVDS pair or as two independent single ended signals.

Have a look at this video:


fchk

[Terry Bites]

I didn't get invited to your sleepover so I don't know what phone you have or what screen you've bought.
There are a limited number of screen protocols, look up the one for the display you have.
Industry standard pinouts will propbably apply.

[Doctorandus_P]

This is just silly:

... even though it doesn't have the memory for a framebuffer of that size. We'll think about that later.

Sit down, plan a systems overview and select parts that fit together. You won't get 30fps from a slow uC, without a screen buffer it may also be difficult. Does the screen you have selected have any internal memory, or does it require a constant stream of data to show anything?

Just recently I bought a few WeAct boards with an STM32G031, some loose STM32G031 uC's and some crystals in 3225 size format. When the parts were underway and I was designing a custom PCB for the loose uC's I had ordered I discovered that those uC's in TSSOP20 package do not even have pins for the high speed crystal oscillator. Those are only available in the bigger packages. That was a really *&^%$#@! moment.

[DavidAlfa]

Largest hackable screen I know was the S5230 display, 3" 240x400: https://brne.narod.ru/s5230.htm

[Andy Chee]

The only phone display I've ever repurposed was the Nokia lcds



Then again, the only CPUs I've been interfacing are slow 8-bit MCUs (as opposed to ESP32 etc.)

[NiHaoMike]

There was a time when one could get a (basic) smartphone for as little as $5. While likely intended for younger children, they also were popular for those building cryptocurrency mining clusters.

[rew]

From the Video posted by fchk it becomes clear that most probably the display will be using MIPI/DSI. Even the much smaller ipod uses that.

And from that same video it is clear that generating those signals on an RP2040 is not going to be the first attempt.

We also learn that the display chip will probably keep on displaying an image even if we don't send data. That... for the future indicates that a clever hack with an RP2040 may eventually be possible. This will require doing several clever tricks that are not trivial. Stuff like just writing single lines whenever an update happened on that line or even writing small "windows". You WILL have to regenerate the  rest of the image every time you refresh say a line (if you don't revert to writing single pixels with lots of "on the line" overhead. Electrically the RP2040 doesn't have LVDS drivers for starters. I'm guessing that running the data clock at 125/2 is not going to upset the display too much. But it will not be remotely close to the intended electrical signals. For now: Not gonna try.

@Terry bites: It doesn't matter what display I happen to have. If this discussion ends up that "If you buy XYZ display John  has already done the reverse engineering work and the code is here" then I'd go out and buy THAT. And this display I've got now will end up in my phone. It'd save me a couple of bucks if the one that comes out of my phone can be the one I use for testing whatever I'm going to do. But cash isn't THAT tight that I can't spend $15 for such an experiment. But if you really want to know: I have a Redmi 6.

@Davidalfa: Yeah, but that resolution and size is commonly available as "full specs provided" modules for hobbyists for reasonable prices.

@Doctorandus_P ("dodenrit" hier nu uit de speakers.) <= If you don't get it. He does I do. That was not for you.
Yeah, I could form a business plan, but for now I'm exploring options to hack one or more of the "cheap displays" that you can buy on Aliexpress. I think the volume of the smartphones causes relatively highquality displays to be sold for relatively low prices.

Anyway, from this discussion so far: I come to the conclusion that it is most likely just DSI. Does anybody know a cheap device that can do DSI ? I do. Raspberry pi. So once I figure out enough to know the pinout I'll make a flex adapter for the raspberry pi. I have the DSI breakout (FPC to 2.54" ) boards at hand here. That means I can probe the signals the RPI produces. I might also have to open up the redmi to probe there. My preference (as opposed to mike in the video) would be to make an FPC  "extension cord" for the small connectors (one F, one M) and then design bigger probe points on there. It'll take two weeks or so for that to get here but I'm not in a rush.

[SiliconWizard]

Quite a few MCUs do have MIPI DSI interfaces now, for instance STM32's and many other vendors. I would use that rather than try "hacking" a RP2040 to do it - if you're able to control the display at all, the refresh rate will be miserable.
Pick something with a MIPI DSI interface, enough RAM and at least a Cortex-M4. I would still check that they can support the intended resolution (full HD), as the typical use case for MCUs with a MIPI DSI interface is controlling smaller screens, like the round displays for smart watches, which are usually MIPI DSI as well, with a much lower resolution than full HD.

[DavidAlfa]

Anyways, buffer-less displays requiring Megabytes of local ram, mipi interfaces, none in the bucket of cheap or simple, definitely not DIY.
Just get a hdmi->mipi-dsi converter at aliexpress, will interface virtually any phone display.

[rew]

Quite a few MCUs do have MIPI DSI interfaces now, for instance STM32's and many other vendors. I would use that rather than try "hacking" a RP2040 to do it - .

Yeah! That's what I was already saying. First get it to work outside the phone with ANY hardware that natively supports the DSI stuff. Then worry about driving it with cheaper hardware.

[amyk]

Those phone screens are closer in interface to computer monitors than the typical embedded 8-bit MCU stuff.

[inse]

Just a little bit of guesstimation: for a project (cancelled almost 10 years ago) the MIPI interface had been repurposed for a different use case.
I have learnt that it is a kind of DMA interface which keeps transferring a continuous data stream via a dedicated unit in the host microcontroller.
Maybe one more indication that the display does not have a frame buffer.
Again, just guessing…