Home     Contact     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS     Terms of services     Privacy policy  
 Home      Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science   

20 December 2010
Author: Giorgos Lazaridis
Reverse-Engineering an LCD Display

How it works anyway?

Right. That is an interesting subject for those that will get a similar LCD. First, i need to note that this LCD does not have a controller. It would be extremely convenient to have one, but it doesn't. That is normal though, if you consider that this is an OEM part.

So, i need to make the controller myself. And here is how this LCD works. It has 240 scan lines, and each scan line has 320 pixels (this makes the 240x320 LCD resolution). To show an image, you need first of all to break this image into horizontal scan-lines. Then, you load the first scan-line on the LCD. This is done by sending packets of 4-bits to the LCD, a total of 80 packets are needed for one complete scan line (80x4=320). When this is done, the LCD shows the first scan line. Then, the second scan line has to be sent, again in packets of 4 bits. When this is done, the LCD shows this second scan line, and so on, and so on.

Someone would now think: "Ok, when you load 240 scan lines, you stop sending data to the LCD and a static image is shown, right?". Wrong! The problem with a controller-less LCD is that when you send a new scan line, the previous scan line is lost. Actually, there is ONLY ONE scan line that is shifted from bottom to top. And in every new position, this same scan-line changes its bits according to the image. So, to have one static image on the LCD, the scan-lines must be sent non-stop. And to avoid screen flickering, this process must have a refresh rate of more than 50Hz, which means that each second, the screen must refresh itself 50 times..

Speed? More speed? Even more speed?

I should have start from this point, but i went backwards (as usual). What i mean is, i had to theoretically calculate the frequency needed for the PIC to run, before going into programming. This cost me many hours. Anyway. Here is the problem. 50Hz refresh rate, means 50x240=12000. So the controller must send 12000 scan lines in one second. Considering also that each scan-line has 80 packets of 4 bits, this means that the controller must send in one second at least 12000x80=960000! Can a PIC do that? Let's see. I will not use a classic 20MHz PIC, instead i will use something like the 16F1937 which has 32MHz max CPU speed, which is rather fast. As we know, to complete one full instruction cycle, the PIC needs 4 clock cycles. So with 32MHz, it can run 8.000.000 instructions per second.

This number looks good, but then you must consider how many cycles must be carried out for a screen to be delivered. Suppose that the image is uploaded to a serial memory, and the only thing that the PIC needs to do is to recall this image. Here is a simple algorithm to do this:

  • 0. Set number 240 to LineCounter [ 2 instructions ]
  • 1. Set number 80 to ColCounter [ 2 instructions ]
  • 2. Send a clock pulse to memory [ 2 instructions ]
  • 3. Send a clock pulse to memory [ 2 instructions ]
  • 4. Send a clock pulse to memory [ 2 instructions ]
  • 5. Send a clock pulse to memory [ 2 instructions ]
  • Up to here, all 4 bits are sent to the SIPO shift register

  • 6. Reduce ColCounter [ 1 instruction ]
  • 7. If ColCounter=0, Go-To step 2 [ 2 instructions ]
  • 8. Reduce LineCounter [ 1 instruction ]
  • 9. If LineCounter =0 then RETURN [ 2 instructions ]
  • 10. Go-To step 1 [ 2 instructions ]
  • The above algorithm will ONLY send data from external ram to the LCD. There are more instructions to load memory base positions and such, but they cause a very slight delay. Now, let's count the instructions needed: There are total 20 instructions right? Wrong again! Because there are two nested loops: The first loop contains 11 instructions and it will run 80 times (line 2 to 7), and the second contains the first loop plus 10 instructions and it will run 240 times. Doing the multiplications, you get the total number of instructions which is 386400 instructions for a full screen. Divide the maximum speed of the PIC by this number: 8000000/386400 makes approximately 20.7 Hz. So, A PIC Cannot control the LCD this efficiently. Actually, to get 50 Hz refresh rate, you need to have a PIC with 80 MHz clock, but this is not a good solution - high clock means designing problems of the PCB.

    So what?

    The answer is simple: Use simple TTLs to run the above process. See the following circuit (click to enlarge):

    The circuit on a breadboard for test

    So, let's see how the data are transferred from the PIC to the external memory, and then how they go from the memory to the LCD (which is the interesting part). The first part is simple. The PIC I/O RA0 sends the data to the memory (Serial Input pin). The clock pulses are delivered from the PIC pin RD0, through the OR gate of the 7432 chip. At this point, the other input of this OR gate is all the time LOW. So, the pulses are delivered as-is to the SCK (Serial ClocK) of the memory chip. So, the PIC is able to fully control the memory chip, although this is done in a slow speed, but this is not a problem. One full screen (top to bottom) is transferred to the memory within a second.

    So far so good. Now it is time to display this saved screen. The PIC RD0 stops delivering pulses and becomes LOW. Then, the PIC output RC4 (pin 23) becomes HIGH. This is connected to one of the 2 inputs of a NAND gate. The other input is connected to the PIC pin 14, which is actually the CLKOUT (CLocK OUT) pin. This pin delivers all the time 1/4 of the PIC's oscillator. If you do the NAND truth table, you will now see that the output of this NAND gate will be the inverted pulses of the PIC's CLOCK OUTPUT pin, 100% synchronizes with the PIC instruction cycles. The internal oscillator of the PIC is 16MHz, the clock output is 16/4 = 4MHz. If i use external oscillator (which i will use a 32MHz later on), i will get pulses directly from the 32MHz, to multiply by 8 times the refresh rate.

    With 16MHz internal PIC oscillator and 4MHz frequency to the LCD driving circuit, the refresh rate is 50Hz

    So, as i was saying, the output of this NAND is the inverted pulses of the CLOCK OUT of the PIC. This output is driven to both inputs of another NAND gate. This acts as an inverting gate. The output of this NAND is the PIC's CLOCK OUT pulses with same phase. These pulses are then driven to the input of the OR gate. The other input (as we said before) is kept LOW, so the output of this OR is the same pulses as the PIC's CLOCK OUT, which are finally driven to the clock input of the memory chip. So, the memory chip is now using a high frequency to serially output its data.

    The LCD requires 4 bits parallel data load. So, first of all, i have to convert the serial output of the memory chip into parallel data. This is done by the 74195 chip which acts as a SIPO (Serial In Parallel Out) shift register. I also have to "inform" the LCD controller, whenever a new packet of 4 bits is ready to be transmitted. This is done by a pulse on the 3rd input of the LCD. This pulse has to be sent once every 4 bits that are transferred from the memory chip to the SIPO shift register. To achieve this, i put the 74393 binary counter. The clock input is taken form the inverted clock pulses (for synchronization reasons). The 1/4 output of this chip is then driven to the 3rd input of the LCD.

    What's the reason for all these?

    50Hz is already very good refresh rate, but it can climb up to 400Hz with an external oscillator

    Remember before, the length of the algorithm that the PIC requires to show a full screen? It was 386400 instructions. The circuit above can do it much faster. As a matter of fact, it can do it in just 240x320 clock pulses, which is 76800 pulses total. If i use the CLOCK OUT of the pic (with 16MHz internal oscillator), this means 76800 instruction cycles, which results in 4000000/76800=52Hz refresh rate, which is already very good. But if i use an external 32MHz oscillator and drive the circuit's clock directly from this oscillator, the refresh rate will rise up to 32000000/76800=416.6Hz, more than 20 times faster as the software solution with the same PIC and same oscillator.



      Email (shall not be published)


    Notify me of new posts via email

    Write your comments below:
    BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.


  • At 23 February 2014, 15:44:27 user leemidi wrote:   [reply @ leemidi]
    • very cool - nice work man!!!

  • At 11 June 2013, 14:18:43 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Allan Its all explained in teh 3 pages of this document

  • At 11 June 2013, 13:42:13 user Allan wrote:   [reply @ Allan]
    • Very interesting. Thanks for taking time to make these videos. What exactly does your breadboard circuit do in order to shift (scroll) to the next scan line on the LCD ?

  • At 7 December 2012, 15:33:14 user BBotany wrote:   [reply @ BBotany]
    • 25AA256 might only work with clock to 10MHz (Microchip datasheet). But 104Hz refresh is still pretty good.

  • At 6 December 2012, 19:46:25 user mariwan wrote:   [reply @ mariwan]
    • thanks for the answer.
      I think this will be useful


  • At 5 December 2012, 21:16:02 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Mariwan well... i know that laptop screens have controllers on their sides, so it depends on the controller...

  • At 4 December 2012, 20:39:13 user Mariwan wrote:   [reply @ Mariwan]
    • Thanks for sharing.
      I have a question .. Do you think that it will be possible to use a laptop screen in the same way?

  • At 24 August 2012, 7:22:43 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @kiranvarma-npeducations which software do you mean? The PIC software? It is very messy and i made it only for testing the LCD. If this is what you want, i can certainly give it to you. But it is not commented.

  • At 22 August 2012, 16:45:42 user kiranvarma-npeducations wrote:   [reply @ kiranvarma-npeducations]
    • @Giorgos Lazaridis
      Really thanks for your reply! could you give the software for a trail! I really liked it.

  • At 3 July 2012, 12:28:04 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @kiranvarma-npeducations the software for PC program is visual basic 6, kinda old but still works ;)

  • At 3 July 2012, 8:36:44 user kiranvarma-npeducations wrote:   [reply @ kiranvarma-npeducations]
    • Is that software shown in video is designed by you, its cool! simply generating binary code for bitmap images and serializing.. to LCD panel via some controller (i think from Philips). Which language that u have used to develop software. Final output in LCD panel is mind blowing, you are genius in both software and hardware part. Really amazing video, really reverse engineering. Thanks for such wonderful project tutorial. I will bookmark your site for my learning benefit

  • At 6 May 2012, 20:31:17 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @sdfdsfadsjk But first i will finish my coffee maker for which this LCD is supposed to go. But due to lack of funds, the project will be delayed for a while.

  • At 6 May 2012, 20:03:03 user sdfdsfadsjk wrote:   [reply @ sdfdsfadsjk]
    • I hope you can finish the article sometime. I'm eager to learn how it all comes together.

  • At 21 November 2011, 5:41:30 user Kammenos wrote:   [reply @ Kammenos]
    • @Annonymois sure there are methods for this, but not by hacking the LCD that way. There are programs for example for PCs and others for telephones to do this, there are also very VERY cheap gadgets (http://www.ebay.com/sch/?_kw=gsm%20spy&_clu=2&_fcid=5&_localstpos=&_sop=15&_stpos=&gbr=1). If i were you, i would start with a simple PC format, and then install a firewall on the PC. Any surveillance program installed would then be erased.

  • At 20 November 2011, 22:10:52 user Annonymois wrote:   [reply @ Annonymois]
    • Hi. I saw your YouTube video about reverse engineering an LCD screen. And some posters had said this process is used by hackers in order to spy on people through their computer screens? And I started googling this questions because I perceive I am being watched by people I know. I don't know how. I suspect there is a website where the hackers stream the audio and visuals to the recipients who include friends and so-called family members. They drop subtle hints to me as to the fact they they know what I'm doing by posting comments on YouTube videos I've just watched or they repeat the words I've just spoken by writing it down on my Facebook wall or in my junk email subject line. If you google gang stalking, cause stalking, gas lighting, you will see that there are a lot of people who are experiencing electronic surveillance. It's crazy. I know I saw a real life police show once and they were receiving visual feed from the cell phone of a criminal. I don't know how they did it. But I have been abused by people I know at work and in the last year by my own family because they used to like / love me and now they hate me. My brothers family in particular and my nephew from my sister have been befriended by these cause stalkers and they constantly let me know I'm being watched. They don't admit it but I've heard them talk about private conversations I've had when they were no where near me! It's crazy.

      Once again the question is: can I be seen when I'm in my pajamas in front of my PC monitor, iPhone screen, even if the camera is not pointed at me. Just through the screens? Thank-you

  • At 20 October 2011, 14:11:02 user Tom wrote:   [reply @ Tom]
    • posted photos under this forum topic...


  • At 20 October 2011, 5:30:11 user Kammenos wrote:   [reply @ Kammenos]
    • @Tom cool! will you post any images to see what you are making? You can use the forum, or a free image host.

  • At 20 October 2011, 2:29:47 user Tom wrote:   [reply @ Tom]
    • Kammenos,
      I finally got my display working! It's only 160x80 so I can get great refresh rates from a pic... right now the controller is an 18f2455 and i'm using it's internal ram for the display. Currently it only displays a test image that I stored in program memory, but I plan to add a 5x7 font, a gal for timing logic, external serial display ram, and serial character input... then I'll use it for console output on a couple of hacked linux devices. Thanks for all the information!!

      Found the spec for your panels on-line. Just making a physical connection to those panels would be very difficult because of the 60+ FPC connector on the stupid thing... unless you have a breakout board in the works? If you can physically connect to it, making a controller is certainly doable. You might need an fpga or something else that's pretty fast to do the more complicated rgb timings.

  • At 4 August 2011, 12:51:17 user Charlie wrote:   [reply @ Charlie]
    • Hello all,

      I have obtained a large (200-300) lot of bare LCD Screens (no driver/controller boards). About half of them are 3.8" Sharp LQ038 screens. These were stored loose in a box and many are obviously broken. I would like to do something with these and I am at this point looking for a simple circuit so that I can test them, also possibly a way to turn them into digital photo frames. I am an Electrical Engineer, but it has been a while since I have done detailed component work like this and I have never worked with Color LCD displays before. Can someone direct me to where I can find some circuit designs that I may be able to use?

      Thank You,

  • At 2 August 2011, 18:34:26 user Kammenos wrote:   [reply @ Kammenos]
    • @Tom its too cool to hear that you are doing fine. I'm waiting for your video to see the results ;)

  • At 2 August 2011, 18:30:42 user Tom wrote:   [reply @ Tom]
    • Just recently got back to my lcd project... The M signal is to drive the LCD voltages: the col/seg drivers use it to alternate the voltage applied to the cells, otherwise the lifespan is shortened. The pic simply alternates M from high to low every frame.

      My lcd is only 160x80, and I've generated a test image with a pic18f2455... I'm only running at 20MHz right now but the refresh rate is good because it's a much smaller screen. Thanks again!!

  • At 29 April 2011, 4:59:56 user Kammenos wrote:   [reply @ Kammenos]
    • @vga the problem that i faced with vga is the speed. a 1024x768 @60hz monitor will receive data with a rate of abput 47.2MHz (1024*768*60). Moreover, the signal comes in 3 analog lines, 0 to 0.7 volts. My knowledge is not sufficient to select the proper chips for the job, read and recreate the signal correctly.

  • At 29 April 2011, 4:30:48 user vga wrote:   [reply @ vga]
    • Can you reverse engineer VGA?
      I have 4 identical LCD monitors.
      I like to wire them together in one LCD screen.
      So from PC will go one vga cable to a box. In this box will be 4 vga outputs for my other 4 screens.

  • At 12 April 2011, 21:00:08 user jparker wrote:   [reply @ jparker]
    • You are very good at debugging (reverse engineering). I like your honesty when you talk about your projects/experiments. You also inspire me to explore some of my broken devices parts. Hang on to the curiosity you have and it will be kind to you in the future I'm sure. Thx for the website.....

  • At 7 April 2011, 17:50:50 user Vasilis Kostelidis wrote:   [reply @ Vasilis Kostelidis]
    • Oh hello. I am sorry I missed your post.

      So, when I say that this is not very flexible, I mean that you have to do everything by yourself, example: Let's say you want to print a string on the screen.

      With your design, you have to take the fonts, calculate the exact position on the screen, take care of the background (and not delete it) and load the image in the external memory.

      With a smart controller, like the SED, you just say that you want to output on the screen the specific string. It will take care of it. I will also not delete the background image, so, when you take the letters out, the background will be there.

      My first monochrome LCD, like yours, didn't have a smart controlle, I put the LC7981 controller on it and it worked. My second monochrome LCD was this:

      I had to do a change there. It's been a long time and I don't remember but here is bottom line: The SED1335 supports a 16 bit address bus and the memory on this LCD is only 8 kBytes. I found an 32 kBytes RAM with the same layout as the 8 kBytes. The difference was that the 8 kBytes RAM had two NC lines in the place of the two extra address lines on the 32 kBytes RAM. So, I replaced the RAM, hardwired the NC pins to the correct SED1335 pins and it worked perfectly :)

      Good luck with that if you decide to go with it.

  • At 28 March 2011, 5:15:49 user Kammenos wrote:   [reply @ Kammenos]
    • @Tom 1. Yes, square wave signal for both
      2. i am not sure what these pins do. in my case, the 3 79430 chops have their 3 M pins connected to a strange chip labeled 73101YXA at pin #3. When i began to RE, i could not find any info about this chip. Luckily, i did not have to. If you manage to find something about pin M or this chip, please email me to upload it for others.

  • At 27 March 2011, 21:10:58 user Tom wrote:   [reply @ Tom]
    • Nice work! You gave me the idea to work on my own 160x80 lcd which has the same common and segment driver. Two questions if you don't mind...
      1. you said you connected your pins 2 and 3 (CP for the 79431 and 79401) to your function generator - was this just a square wave connected to both CP inputs?
      2. what is the M pin (pin 94 on the 79430 and pin 86 on the 79401) on your lcd connected to? i have a pin on my connector that goes to M on the drivers and i'm not sure what to do with it... the specs say M is an input - "LCD drive output alternating current (AC) signal"
      Once I figure those two points out I'll make up some programmable logic to take the place of all the discrete TTL chips. Thanks!!

  • At 5 March 2011, 12:07:48 user bodyartcrew wrote:   [reply @ bodyartcrew]
    • hi!
      nice vids,

      I got exactly the same lcd optrex dmf 500081n f.fw-2 96z2m1.
      They were used in so called "Maas" cofee machine prepaid system.
      it came also with the complete controller and keypad.
      If needed i can provide the datasheet of the lcd .

      Good work!

      Greetings Halriasa

  • At 26 February 2011, 22:17:45 user Kammenos wrote:   [reply @ Kammenos]
    • Bill, i really had no idea of this SED1335! I might give it a try. But what do you mean that this is not very flexible?

  • At 25 February 2011, 19:47:01 user Bill Kostelidis wrote:   [reply @ Bill Kostelidis]
    • Hello there.

      The solution you are taking, although very creative, it is not too flexible. You cannot do many things with this design.

      What I would suggest, after of course you finish with the current design, is to put a SED1335 controller hooked up in there. The controller is so easy to play with, you will find so many drivers in C or assembly.

      And if you want to re-invent the wheel (I assume you want, we engineers are the same yes?) then you can write them yourself!

      You can buy the SED1335 on a board if you like

      Have fun!

  • At 17 February 2011, 13:58:52 user Salomon wrote:   [reply @ Salomon]
    • I would like to reverse eng. a BB color LCD.

  • At 16 February 2011, 6:50:04 user Kammenos wrote:   [reply @ Kammenos]
    • Jonathan you know what? your idea has a strong base, and i will certainly give it a shot! i think it will work. thank you for reading posting this comment!

  • At 16 February 2011, 1:00:33 user Jonathan wrote:   [reply @ Jonathan]
    • I think the 16F1934 can do it without extra hardware, using the MSSP and sacrificing four I/O lines.

      You can have a 32MHz INTOSC (8MHz with 4x PLL; see section of the 16F1934 data sheet). You can also use the MSSP to fetch bytes from the external memory for you at one bit per CPU cycle while sending the previous byte to the LCD, or get display data from internal program memory or even RAM instead.

      Instead of 11*80 instructions to display a line, try 14*40 or less, something like:

      ; send one line to LCD
      ; RD[7..4] LCD data, RD[3..0] N/C, RB0 -DCLK
      ; setup FSR1L/H and dotcnt (6)
      MOVF INDF1,W ;1 (2 for PM, try MOVIW for internal mem)
      INCF FSR1L ; 1 (remove for SSPBUF)
      MOVWF tmp70,F ;1 store byte
      MOVWF PORTD,F ;1 output high nybble
      BCF PORTB,0 ;1 strobe
      BSF PORTB,0 ;1 unstrobe
      SWAPF tmp70,W ;1 read low nybble
      MOVWF PORTD,F ;1 output
      BCF PORTB,0 ;1 strobe
      BSF PORTB,0 ;1 unstrobe
      DECFSZ dotcnt ;1 next byte
      GOTO do_dots ;2

      FSR1 could point to SSPBUF (which can easily keep up), linear RAM, or program memory (+1 cycle per 8 bits). If using RAM, save one cycle by removing the write to tmp70 and changing SWAPF INDF1,W. If using internal memory, try the MOVIW INDF1++ instruction instead of the MOVF/INCF pair to save 1 cycle.

      At 138000 cycles per frame (worst case rounded up), you can maintain a ~58Hz refresh rate at 32MHz with no extra hardware.

      Of more interest is that with small changes you can store tiles in program memory for easy character display. It is slightly slower, but can (barely) achieve 50Hz screen refresh with a fully tile-based screen layout. For example, code to choose among 64 tiles, 16x16 pixels in size (2kword program memory), might look like:

      ; draw 16 lines with tiles
      ; set FSR0 to tile index base
      ; set FSR1H to tile bitmap base, must be 256-byte aligned
      MOVLW 10h
      MOVWF linecnt
      MOVLW 80h ;1
      ADDWF lineoffset ;1
      INCF FSR1H ;1
      MOVLW 14h ;1
      MOVWF dotcnt ;1
      MOVIW INDF0++ ;1 (2 for PM)
      ANDLW 3Fh ;1 just for safety, can be eliminated
      IORWF lineoffset,W ;1
      MOVWF FSR1L ;1
      ; [MOVF INDF1,W... essentially the old inner loop, twice...
      ; but instead of INCF FSR1L, do BSF FSR1L,6 to get 2nd byte]
      DECFSZ dotcnt
      GOTO do_dots
      ADDFSR FSR1,-20 ;1 correct tile index ptr for next scan
      ; [strobe LCLK...]
      DECFSZ linecnt
      GOTO do_lines

      You get the idea.

  • At 15 February 2011, 15:06:29 user Luke wrote:   [reply @ Luke]
    • Was a Raymarine fathom-meter, from the resolution of the screen seems also provide a kind of graphic for the bottom view.

      it's around 2003 product, made by 3 different board: sounder, main pbc with "CPU" and LCD driver

  • At 24 December 2010, 19:25:24 user Kammenos wrote:   [reply @ Kammenos]
    • At the end, this article will reveal the raw power of the combinational circuits over the sequential circuits. The video will be uploaded within a couple of hours. I will finish this page tomorrow.

  • At 24 December 2010, 19:05:32 user Luis wrote:   [reply @ Luis]
    • Simply Awsome, all this to the conclusion that pic is not enough, very educative. Always is a pleaasure read your articles

    reddit this Reddit this

     HOT in heaven!

    NEW in heaven!

    New Theory: AC electric motor working principle

     Contact     Forum     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS   

    Site design: Giorgos Lazaridis
    © Copyright 2008
    Please read the Terms of services and the Privacy policy