In our opinion, reverse engineering may be one of the best ways to tease your brain. [Andy] just did that by reverse engineering the Sony Ericsson Vivaz high resolution LCD (cached copy here). In his (very) nicely written article, [Andy] explains all the steps that led him to the result shown in the picture above. He started by finding the repair manual of the Vivaz, to discover that the display could be interfaced with 8080 type parallel signals. That meant that he could use a standard microcontroller without high speed buses to interface with it, in this case the STM32F4. Next in his adventure, [Andy] ordered the appropriate connector and took a more educated guess for the onboard microcontroller. A long Google search brought up the R61523 from Renesas. So he designed his breakout board, got it produced and a few hours later a nice picture was being shown on the LCD. He even took the time to compare the original display with the clone he found on the webs, and modified his graphics library to support this display.

Hey Mike,
First of all, thanks for your _very_ constructive comment. Second, I actually spent a while finding what the original author meant by “8080 interface signals” as I’m not as familiar as you with this kind of bus.

I see the timing of the above posts, and I appreciate that you might have been starting to feel a little… “gotten at”, however, I really think you should have let that one lie.

Mike has a fair point, it was a basic error, but perhaps one made through (admitted) lack of understanding? If this is the case, then maybe less *transcribed* detail is needed in the HaD write-up. Stick with the obvious facts.

Something like “This guy did some pretty nicely documented reverse engineering work on a cheap, 640 x 360 phone LCD display, and then hooked it up to a stm32 (and an Arduino Mega) to boot!”, but with a little non-technical padding (similar projects, etc)?

Realistically, anyone who is interested in the project content is going to skim the blurb for keywords, and click on through if they like the sound of that.

Yes, it hooks up directly to SPI port on C13 on the Pi. And Raspberry Pi software support is done, so the GD library and samples/demos/games all run fine on the Pi.
Last updated: Monday Oct 14, 10:53am EDT

It’s very nice of you to offer a cached page link to the project. I would however put the cached link as first because the first link is the one that almost everyone would click. Also, I would choose the Coral Cache any day over the Google one. Just add “.nyud.net” after the domain name of the link to load the cached one.
As an example this project link would becomehttp://andybrown.me.uk.nyud.net/wk/2013/10/19/vivaz-u5-lcd/

Cell phone cameras are riddles wrapped up in enigmas hidden under NDA’s. They are extremely complicated to control and much of the necessary info is trade secreted. What public info and example code is available for some cameras is incomplete and very poorly documented. I once had a talk with the guy who designed the CMUcam4 and it took a ridiculous effort to work out the interface for its cell phone camera sensor.

The problem with most camera sensors (cellphone or otherwise) I suspect is that the data you get back from the sensor isn’t in a form you can use, you need specific image processing algorithms that are tied to the specific characteristics of the sensor you are using that turn the raw output from the sensor into a nice jpg or whatever.

It’s interesting after reading articles on here about possible modular phones designed to minimize digital hardware waste that judging by these comments the biggest hindrance to that effort would be closed design practices. I mean there’s literally millions of broken phones out there that basically can’t be used for anything else because they’re “riddles wrapped in enigmas hidden under shattered gorilla glass”

I rescued the half-VGA display from my ancient Palm Tungsten T3 (480×320), along with the resistive touch overlay. I wonder if something similar would work for getting it usable on some future project.

“The schematic shows that there’s a single pair of power lines connected to the backlight, LCD_BL_K and LCD_BL_A. That means that the LEDs that form the backlight are arranged in serie…”
How do I know? Cause LEDs in parallel also have single pair of power lines (+,-).

I wouldn’t call 640 x 360 “high resolution” at all at today’s standard. It would be really nice if people can start reverse engineering the 720P and 1080P displays in one of the current cellphones, they would make DIY projects really useful.

The parallel data bus on this display is a far cry from the packetized differential bus that is MIPI DSI, which is what a huge number of the new high-res displays use. Think printer port versus USB3.0 – one’s much easier to “fake” (from the MCU side) than the other, which requires protocol adherence and quite high speed. Add to that the fact that DSI is a closed standard, so even if we wanted to draw up some programmable logic that implements it, we’d first have to pay a few thousand dollars for the specification…

I’ve got some very preliminary concepts for driving the iPhone 4 display kicking around, albeit pretty far down my list in priority. Requires an intermediate purpose-built IC to convert raw pixel data to DSI, and the raw data is a 24-bit parallel data stream at some tens of MHz – so in any case even if you could talk to these screens, they tend to require more horsepower than most DIY projects can afford to throw at them.