Skip navigation

Tag Archives: LCD

Gutted DVD Player

I recently picked up this old portable DVD player marked “Doesn’t Work” for cheap at the local junk shop. My intent was to figure out the LCD interface and attempt to drive the display. This article is just the investigation. Once removed from the player, the LCD module and backlight is contained in a metal can, connected via a flat-flex to a small interface board, which conveniently contains the back-light driver as well. Its probably easier to just use the provided interface, so I examined the signals going into that. Luckily, the screen still worked perfectly, and I was able to power up the device outside of the body in order to get my scope on the pins. There were 24 pins in total, and helpfully, there where 23 labels on the rear silkscreen of the interface board. The below table shows those pins from top to bottom of the board (the side with the 4 pin connector at the top), along with the labels and my findings. I’m using an old 20MHz analog scope, so some of the measurements may not be precise.

Probe Setup

Also, be sure to set your probes to x10 for high speed measurements. More info here.

TFT_STH High pulse every 64uS, very short pulse. Based on the PCB label and speed, I’ll call this ‘Horizontal Strobe’.
TFT_STV High pulse every 17mS, very short pulse. ‘Vertical Strobe’. Note that this timing shows about 265 ish Horizontals per Vertical. Also this implies 60 FPS.
CKV 4uS High pulse every 64uS. This pulse edge is 12uS before STH. ‘Vertical Clock’.
OEV 4uS High pulse every 64uS. This pulse edge is 4uS before CKV. ‘… Vertical’
OEH 4uS Low pulse every 64uS. The edge is 2uS after CKV. ‘?’
GND Ground
CPH1 .1uS Squarish Wave. About 10 MHz. As the fastest signal. I’m guessing this is the Pixel Clock. Not sure if the wave appearance is the fault of the scope, of if more is going on in there.
GND Ground
89P_VCOM 128uS Square Wave. Transitions in the middle of the CKV pulse. Seems to alternate high low every other line.
GND Ground
TFT_R Pixel data. Red. Couldn’t trigger on signal, but has patterns that align with pixel clock and CKV. Analog signal.
TFT_G Pixel data. Green. Couldn’t trigger on signal, but has patterns that align with pixel clock and CKV. Analog signal.
TFT_B Pixel data. Blue. Couldn’t trigger on signal, but has patterns that align with pixel clock and CKV. Analog signal.
GND Ground
GND Ground
GND Ground
VCC +5V
BLVCC +5V. Must be for backlight.
GND GND
GND GND
TFT+5V +5V
+5VPV +5V
GND GND

That actually paints a pretty cloudy picture of whats going on. Mostly because I cannot find the specs for this screen, so I’m going to have to guess the resolution. The vertical strobe shows that around 265 lines are transmitted per vertical clock pulse. That sounds like a good vertical resolution, but at 17mS per vertical strobe, that’s about 60 FPS. So there must be some kind of interleaving of data somewhere. That makes sense because the 89P_VCOM line alternates high/low for every other line. Possibly some type of high byte/low byte scenario? I ran the screen while holding this pin low, and the image became washed out. So its a possibility. Since each horizontal strobe is 64uS, and the pixel clock is .1uS, this shows about 640 bits per RGB channel per line. Now, 640 sounds like a reasonable horizontal resolution. Originally this had me confused as I assumed the RGB pixel data signals were digital, when they were actually analog.

That’s about all the info I can gather for now. I won’t be able to tell if my assumptions are accurate until I hook it up to something. I’ll end with my scope readings for those playing along at home.

I was able to confirm that the RGB lines going into the panel are in fact analog. I attached a potentiometer between 5V and ground to form a simple voltage divider and attached the tap to the Red line. Turning the knob I was able to adjust the Red level of the image.

CKV signal.
CKV

CKV Compared to 89P_VCOM line
CKV 89P

CKV Compared to Pixel Data Line
CKV Pixel Data

Pixel Clock With Pixel Data
PixClock PixData

Adjusting the analog red input.
Analog Red Input

A long time ago I picked up an old LCD module (this one, if its still there). Now the trouble with this module is that it does not have a built in controller. It’s more like a TV or monitor in that it needs to constantly be fed a signal containing the image data to display. Now a standard micro controller might have trouble doing this on its own, it would either require a bit of external circuitry, or have to dedicate the majority of it’s processing time to updating the display. This is a surplus part, and the datasheet provided is poorly xeroxed and lacking specific implementation details. However it is a nice monochrome display at 640×480 and well worth the price of $5.50, if you can get it to work. Luckily for me, I found one other person on the whole internet who managed to get this same display working, and remnants of his work for the MIT Model Railroad club were found here, http://www.nyx.net/~jpurbric/lcd/. Now he managed to implement this using a PIC micro, some discrete logic and some external memories. My plan is to first attempt to drive this from my Papilio board. I had a good start since this other project made really nice timing diagram to follow for the display.

First in implementing the VHDL, I defined as many constant values as I could think up. Using the timing diagram and the datasheet, I setup some time period and count constants.

--Timing Constants 
--Time constant integers in nanoseconds
constant CLK_PERIOD : integer := 31; -- approximate/rounded off
constant XSCL_PERIOD : integer := 166 ;

--FRAME CONSTANTS 	
constant WIDTH : integer := 640;
constant HEIGHT : integer := 480;
constant XPULSES : integer := WIDTH / 4;
constant YPULSES : integer := 242;

The timings I defined at the minimums defined in the datasheet. The nice part about utilizing constants like this, is that I can adjust these later and the whole design should adjust. The CLK_PERIOD constant is the main clock period, so it will be used to keep track of elapsed time. The XSCL_PERIOD is the minimum period of the XSCL pulse or “X Shift Clock”. Looking at the timing diagram it seems that the data is read in on the negative edge of this signal. At first I thought of several other timing constants, but as I worked out the design, they didn’t prove to be necessary. The other constants are pretty obvious, the HEIGHT and WIDTH of the screen in pixels, and the number of YPULSES and XPULSES to be sent in each frame of the signal. If you notice these numbers don’t match up to the size of the display. This display is organized as two screens, an upper and lower half. It’s also 1 bit per pixel. So, of the 8 bit data bus, 4 bits go to the top and 4 go to the bottom. So it only needs to write 160 times for each line to get 640 pixels and it will write 242 lines. Yeah, there are 2 extra lines in the signal but the don’t make it to the display. And now for a couple signals to get started with.

 --Timing signals
signal XSCL_TIME : integer range 0 to (XSCL_PERIOD + CLK_PERIOD) := 0;

--count signals 
signal XSCL_CNT : integer range 0 to 160 := 0;
signal YSCL_CNT : integer range 0 to 242 := 0;

The first is my main time delay count. XSCL_TIME will just add on the clock period each time through the main process to make sure we don’t violate our minimum time for the signal. Its defined as a range from zero to XSCL_PERIOD + CLK_PERIOD because I wanted to be sure that whatever size value it ends up being has enough room exceed the XSCL_PERIOD by one clock cycles worth. The XSCL_CNT and YSCL_CNT are regular increment counters to keep track of where we are in the signal and be the main drivers of the state machine.

signal STARTED : STD_LOGIC := '0';

The STARTED signal is just a flag that’s used to have the signal go through as start up process. After the start up, STARTED is set to 1 and stays there.

--Output Signals 
signal LP_YSCL : STD_LOGIC := '0';
signal XSCL : STD_LOGIC := '0';
signal UD : STD_LOGIC_VECTOR(3 downto 0) := "0000";
signal LD : STD_LOGIC_VECTOR(3 downto 0) := "0000";
signal DIN : STD_LOGIC := '0';

These are the various output signals, three timing signals and the data signals. For now we will just be sending test pattern on the data. Now for the main process. I think its well commented so I won’t give a line by line explaination. It’s basically a simple state machine, using the current state of the output signals, the XSCL_CNT/YSCL_CNT, and XSCL_TIME signals to track where it is in the process. It follows right along with the timing diagram. Remember that in the process, signals are not updated until after the process.

	--Process Definition
	main: process(clk)
   begin
		-- triggers action on rising edge of clock signal
     if rising_edge(clk) then
	    --increment counter, using time type
		 XSCL_TIME <= XSCL_TIME + CLK_PERIOD;
		 
		 
		 if STARTED='0' then
		   --initial state
			--first part of timing diagram, on LP pulse, and a up/down on XSCL
			if LP_YSCL = '0' then 
				--set signals
				LP_YSCL <= '1';
				XSCL <= '1';
				--reset times
				XSCL_TIME <=0;
			elsif LP_YSCL = '1' and 
						XSCL = '1' AND
						XSCL_TIME > (XSCL_PERIOD/2) then 
				--set signal
				XSCL <= '0';
			elsif LP_YSCL = '1' AND
						XSCL = '0' AND 
						XSCL_TIME > XSCL_PERIOD THEN 
				--clear started flag
				STARTED <= '1';
				--reset timer
				XSCL_TIME <= 0;
			end if;
		else
			--after started
			if LP_YSCL = '0' and
				XSCL = '0' and 
				XSCL_CNT = 0 THEN
				--occurs at the end of a row, timing specs say LP_YSCL must go to zero before XSCL goes high
				--Raise XSCL to HI			
				XSCL <= '1';
				--reset pulse timer 
				XSCL_TIME <= 0;
				
				--update X count 
				XSCL_CNT <= XSCL_CNT + 1;
			elsif LP_YSCL = '1' and 
			--first step, LP is H, XSCL is L, XSCL_CNT is 0
				XSCL = '0' AND
				XSCL_CNT = 0 THEN 
				
				--drop LP, Raise XSCL, load data
				LP_YSCL <= '0';
				XSCL <= '1';
				
				--temp data 
				UD <= "0101";
				LD <= "0101";
				
				--reset timer
				XSCL_TIME <= 0;
				
				--if first row, raise frame pulse
				if YSCL_CNT = 0 then 
					DIN <= '0';
				end if;
			elsif XSCL = '1' AND 
					XSCL_TIME > (XSCL_PERIOD/2) THEN
				--drop xscl to L
				XSCL <= '0';
				
			elsif XSCL = '0' AND 
					XSCL_TIME > XSCL_PERIOD THEN
								
				
				--load new data
				--TODO
				
				--IF at last pulse raise LP to hi
				if XSCL_CNT = XPULSES - 2 then -- use pulses-2 to compensate for cnt not updated yet and zero based index.
					--last X pulse, raise LP
					LP_YSCL <= '1'; 
					--update X count 
					XSCL_CNT <= XSCL_CNT + 1;
					
					--Raise XSCL to HI			
					XSCL <= '1';
					--reset pulse timer 
					XSCL_TIME <= 0;
					
				elsif XSCL_CNT = XPULSES - 1 THEN 
				   --new line, drop LP
					LP_YSCL <= '0';
					--reset XSCL_CNT
					XSCL_CNT <= 0;
					
					if YSCL_CNT = YPULSES - 1 then 
						-- this was the last pulse, go back to zero
						YSCL_CNT <= 0;
					else						
						--increment Y count
						YSCL_CNT <= YSCL_CNT + 1;
					end if;
					
				else					
					--Raise XSCL to HI			
					XSCL <= '1';
					--reset pulse timer 
					XSCL_TIME <= 0;
					--update X count 
					XSCL_CNT <= XSCL_CNT + 1;
				end if;
				
			end if;	
			
			--if on first line, first x, raise frame pulse
			if LP_YSCL = '0' AND 
				XSCL = '1' AND
				XSCL_CNT = 0 and 
				YSCL_CNT = 0 then 
				--raise frame pulse
				DIN <= '1';
			elsif LP_YSCL = '0' AND 
					XSCL = '1' AND 
					XSCL_CNT = 0 AND 
					YSCL_CNT = 1 then 
				--shut down frame pulse 
				DIN <= '0';
			end if;
				
		 end if; --started
		 		
     end if; --clk	 
 	  
   end process;

And the most important part, mapping the signals to the output pin.

	A(0) <= LP_YSCL;
	A(1) <= XSCL;
	A(5 downto 2) <= UD;
	A(9 downto 6) <= LD;
	A(10) <= DIN;

I currently don’t have it setup to connect the display to the FPGA board just yet. I need to wire that up with a 3.3 to 5 logic conversion, since the Spartan3 is a 3.3V part. And looking at the datasheet the minimum “1” voltage is .8*VDD and the minimum VDD is 4.75V. Assuming a 5V supply, I need at least 4V to drive these signals. However, I really should verify the output of this before I go through the trouble of hooking it up anyways. Thankfully, the Xilinx tools come with a simulator that can be used to verify your design.

SimulateDesign

If you click on your source file in the design explore on the left, select Simulation up top, and the right click on ‘Simulate Behavioral Model’ and select ‘Run’, you should be see the ISim window open up. For me, the first thing I had to do was setup the clock. Oddly, it runs the simulation first with the clock just set as ‘Undefined’. Under the simulation menu, click ‘Restart’ to clear out the current simulation. Right click on the ‘clk’ signal, and select ‘Force Clock’.

ForceClockRightClick

Then you enter the parameters for your clock signal. I really wasn’t sure of the meaning of ‘Leading Edge Value’ and ‘Trailing Edge Value’ so I entered 1 and 0 respectively as they are required fields. Then I just set the clock period of 31.25ns.

DefineClock

Once you’ve done that, can run that for the amount of time you want to see. These commands should be on the toolbar at the top of the window.

RunForTime

Each time you click on the ‘Run for Time Specified’ button, it will add to the simulation, so you can verify the signal a few blocks at a time.

LCDSimulation

Looks good so far. Hopefully soon I can get it wired up and see if it actually works.