TFT Display 320x240 almost works!

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm back to this after some months having:

1. Changed processor to xMega192D3
2. Designed a board
3. Waited for Hong Kong post
3. Waited for Hong Kong post
3. Waited for Hong Kong post
3. )(*&(*& Didn't I already say that?

I've adapted some code I found somewhere, but the code doesn't say where, to xMega and ALMOST get the expected results. It draws on 1/2 of the display, leaving the "top" half blank. Or maybe this is the bottom half...

Perhaps the init code is fishy?

INIT method:

void TSLCDInit(void) //initial LCD
{
	delay_1ms(100);
	
	LCD_DH_DPRT = 255 ;
	LCD_DL_DPRT = 255 ;

	TSLCDOutIns(0x00E5);
	TSLCDOutDat(0x8000); 					//set the internal vcore voltage
	TSLCDOutIns(TS_INS_START_OSC);
	TSLCDOutDat(0x0001); 					//start oscillator
	delay_1ms(50);

	TSLCDOutIns(TS_INS_DRIV_OUT_CTRL);
	TSLCDOutDat(0x0100); 					//set SS, SM
	TSLCDOutIns(TS_INS_DRIV_WAV_CTRL);
	TSLCDOutDat(0x0700); 					//set 1 line inversion
	
	TSLCDOutIns(TS_INS_ENTRY_MOD);
	TSLCDOutDat(TS_VAL_ENTRY_MOD);			//set GRAM write direction, BGR=0

	TSLCDOutIns(TS_INS_RESIZE_CTRL);
	TSLCDOutDat(0x0000); 					//no resizing

	TSLCDOutIns(TS_INS_DISP_CTRL2);
	TSLCDOutDat(0x0202); 					//front & back porch periods = 2
	TSLCDOutIns(TS_INS_DISP_CTRL3);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_DISP_CTRL4);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_RGB_DISP_IF_CTRL1);
	TSLCDOutDat(0x0000); 					//select system interface
	TSLCDOutIns(TS_INS_FRM_MARKER_POS);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_RGB_DISP_IF_CTRL2);
	TSLCDOutDat(0x0000);
	
	TSLCDOutIns(TS_INS_POW_CTRL1);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_POW_CTRL2);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_POW_CTRL3);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_POW_CTRL4);
	TSLCDOutDat(0x0000);
	delay_1ms(200);

	TSLCDOutIns(TS_INS_POW_CTRL1);
	TSLCDOutDat(0x17B0);
	TSLCDOutIns(TS_INS_POW_CTRL2);
	TSLCDOutDat(0x0137);
	delay_1ms(50);

	TSLCDOutIns(TS_INS_POW_CTRL3);
	TSLCDOutDat(0x013C);
	delay_1ms(50);

	TSLCDOutIns(TS_INS_POW_CTRL4);
	TSLCDOutDat(0x1400);
	TSLCDOutIns(TS_INS_POW_CTRL7);
	TSLCDOutDat(0x0007);
	delay_1ms(50);

	TSLCDOutIns(TS_INS_GRAM_HOR_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_GRAM_VER_AD);
	TSLCDOutDat(0x0000);

	TSLCDOutIns(TS_INS_GAMMA_CTRL1);
	TSLCDOutDat(0x0007);
	TSLCDOutIns(TS_INS_GAMMA_CTRL2);
	TSLCDOutDat(0x0504);
	TSLCDOutIns(TS_INS_GAMMA_CTRL3);
	TSLCDOutDat(0x0703);
	TSLCDOutIns(TS_INS_GAMMA_CTRL4);
	TSLCDOutDat(0x0002);
	TSLCDOutIns(TS_INS_GAMMA_CTRL5);
	TSLCDOutDat(0x0707);
	TSLCDOutIns(TS_INS_GAMMA_CTRL6);
	TSLCDOutDat(0x0406);
	TSLCDOutIns(TS_INS_GAMMA_CTRL7);
	TSLCDOutDat(0x0006);
	TSLCDOutIns(TS_INS_GAMMA_CTRL8);
	TSLCDOutDat(0x0404);
	TSLCDOutIns(TS_INS_GAMMA_CTRL9);
	TSLCDOutDat(0x0700);
	TSLCDOutIns(TS_INS_GAMMA_CTRL10);
	TSLCDOutDat(0x0A08);

	TSLCDOutIns(TS_INS_HOR_START_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_HOR_END_AD);
	TSLCDOutDat(0x00EF);
	TSLCDOutIns(TS_INS_VER_START_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_VER_END_AD);
	TSLCDOutDat(0x013F);
	TSLCDOutIns(TS_INS_GATE_SCAN_CTRL1);
	TSLCDOutDat(0x2700);
	TSLCDOutIns(TS_INS_GATE_SCAN_CTRL2);
	TSLCDOutDat(0x0001);
	TSLCDOutIns(TS_INS_GATE_SCAN_CTRL3);
	TSLCDOutDat(0x0000);

	TSLCDOutIns(TS_INS_PART_IMG1_DISP_POS);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PART_IMG1_START_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PART_IMG1_END_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PART_IMG2_DISP_POS);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PART_IMG2_START_AD);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PART_IMG2_END_AD);
	TSLCDOutDat(0x0000);

	TSLCDOutIns(TS_INS_PANEL_IF_CTRL1);
	TSLCDOutDat(0x0010);
	TSLCDOutIns(TS_INS_PANEL_IF_CTRL2);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PANEL_IF_CTRL3);
	TSLCDOutDat(0x0003);
	TSLCDOutIns(TS_INS_PANEL_IF_CTRL4);
	TSLCDOutDat(0x0110);
	TSLCDOutIns(TS_INS_PANEL_IF_CTRL5);
	TSLCDOutDat(0x0000);
	TSLCDOutIns(TS_INS_PANEL_IF_CTRL6);
	TSLCDOutDat(0x0000);

	TSLCDOutIns(TS_INS_DISP_CTRL1);
	TSLCDOutDat(0x0173);
}

The main(void) code:

	PORTE.DIR = 255 ;
	//CrystalClock();
	TSLCDRst();
	TSLCDInit();
	

	Delay100ms(10);
	Delay100ms(10);
	Delay100ms(10);
	Delay100ms(10);
	Delay100ms(10);
	
	Clrb(LCD_BL_PRTS,LCD_BL_PIN);
	//Setb();
	TSLCDFillRect(0,TS_SIZE_X-1,0,TS_SIZE_Y-1,TS_COL_BLUE,TS_MODE_NORMAL);
	
	TSLCDFillRect(0,TS_SIZE_X-1,0,70,TS_COL_WHITE,TS_MODE_NORMAL);
	TSLCDSetFontColor(TS_COL_BLUE);
	TSLCDPrintStr(2,6,"Testing ELT240320TP with AVR",TS_MODE_NORMAL);
	TSLCDFillRect(20,80,90,130,TS_COL_BLACK,TS_MODE_NORMAL);
	TSLCDFillRect(30,90,100,140,TS_COL_YELLOW,TS_MODE_NORMAL);
	TSLCDFillRect(20,80,160,200,TS_COL_BLACK,TS_MODE_NORMAL);
	TSLCDFillRect(30,90,170,210,TS_COL_RED,TS_MODE_NORMAL);
	TSLCDFillRect(195,205,71,TS_SIZE_Y-1,TS_COL_WHITE,TS_MODE_NORMAL);
	TSLCDFillCirc(200,155,60,TS_COL_WHITE,TS_MODE_NORMAL);
	TSLCDFillCirc(200,155,50,TS_COL_BLUE,TS_MODE_NORMAL);
	TSLCDFillCirc(200,155,40,TS_COL_BLACK,TS_MODE_NORMAL);
	TSLCDFillCirc(200,155,30,TS_COL_RED,TS_MODE_NORMAL);


    while(1)
    {

    }
}

And lastly, the fillrect code:

void TSLCDFillRect(ts_pos_t sx,ts_pos_t ex,ts_pos_t sy,ts_pos_t ey,unsigned short color,ts_mode_t mode) //draw a rectangular
{
	unsigned int x,y;
	unsigned int i,j;
	if (sx < ts_margin_xl)
	sx = ts_margin_xl;
	if (ex > ts_margin_xr)
	ex = ts_margin_xr;
	if (sy < ts_margin_yu)
	sy = ts_margin_yu;
	if (ey > ts_margin_yl)
	ey = ts_margin_yl;

	TSLCDOutIns(TS_INS_START_ADX);
	TSLCDOutDat(sx);
	TSLCDOutIns(TS_INS_END_ADX);
	TSLCDOutDat(ex);
	TSLCDOutIns(TS_INS_GRAM_ADX);
	TSLCDOutDat(sx);
	x = ex - sx + 1;

	#ifndef TS_ORN_PORTRAIT
	sy = TS_SIZE_Y - 1 - sy; 	// mirror start y address
	ey = TS_SIZE_Y - 1 - ey; 	// mirror end y address
	TSLCDOutIns(TS_INS_START_ADY);
	TSLCDOutDat(ey);
	TSLCDOutIns(TS_INS_END_ADY);
	TSLCDOutDat(sy);
	TSLCDOutIns(TS_INS_GRAM_ADY);
	TSLCDOutDat(sy);//fix from bug of v1_00
	y = sy - ey + 1;
	#else
	TSLCDOutIns(TS_INS_START_ADY);
	TSLCDOutDat(sy);
	TSLCDOutIns(TS_INS_END_ADY);
	TSLCDOutDat(ey);
	TSLCDOutIns(TS_INS_GRAM_ADY);
	TSLCDOutDat(sy);
	y = ey - sy + 1;
	#endif

	TSLCDOutIns(TS_INS_RW_GRAM);

	if ((mode == TS_MODE_NORMAL) || (mode == TS_MODE_FULL))
	{
		for (j=0; j

My first thought was the "margins," so I called the method to set those to default. However, when you power the thingy up, it only displays the random gibberish on the bottom half during all the delay's before it starts drawing rectangles, so I guess it's the init parameters.

I figure the command defines must be somewhat close, or it wouldn't get this far. If you want to pick through all the gory detail, the semi-functional code is available at

http://www.barefootelectronics.c... (11KB)

Attachment(s): 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tom,

I see that you are still using a 'bare' module.

There are plenty of example codes out there.
Which controller are you using?
Which interface type?

I have had ILI9320, ILI9325, SSD1289 running on Arduino, Xmega and several ARM chips.

I have used 8-bit parallel and SPI.
16-bit and 18-bit seem like too many wires for me !

All the chips have ID registers. If you are running at 3.3V there is no problem to read registers as well as write them.

Most "5V" boards simply use a one-way level shifter. Hence you can write but not read back.

Anyway, once you have read the correct ID, this means that you have no shorted/open tracks. Hence you can send the correct initialisation to your chip, and away you go !

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm. Ask it what it is. Good idea.

With an xMega, micro SD card, NRF radio, this baby's 3v all the way! Actually, I included a boost converter to provide 5v to light the backlight as I wasn't sure 3 could do it. That would be something to check.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell us the controller type one more time... (I got most of my init functions from newhavendisplays... good stuff on lots of different controllers)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Tell us the controller type one more time... (I got most of my init functions from newhavendisplays... good stuff on lots of different controllers)

Well, that's making the rash assumption that I know the controller type. I figured all of these were ILI9325. Apparently not. Experiments to follow.

1. Read register 0.
2. Invent a way to output the results. Like maybe store it in eprom and read it with my ISP.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe that it was explained in the very first reply to your very first "TFT" thread.
e.g. read (16-bit) register #0 for Ilitech controllers. It will return 0x9320, 0x9325 or whichever. Solomon SSD1289 returns 0x1289.
The Sitronix 7735 controller has its ID in read register #4.

As far as I can see, ILI9320, ILI9325, ILI9328, SSD1289 are the most "common" controllers.

If you are still struggling, just tell us what values you get from reading the first 10 registers from power up.

Yes, even when you know the chip, the values you initialise with are very critical. I just trawl the internet for working examples. It is easier when the list of reg#, regvalue is organised in a table.

Inline code like in your example is hard to follow.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at
http://www.henningkarlsen.com/el...

UTFT library

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm... I read 0x0028 from register 0, which means

A. My read register code is naf.
B. I probably have a ILI9328.

Quote:
I believe that it was explained in the very first reply to your very first "TFT" thread.
e.g. read (16-bit) register #0 for Ilitech controllers. It will return 0x9320, 0x9325 or whichever. Solomon SSD1289 returns 0x1289.

But that was way too long and too many tries ago for this ADD brat to remember.

Hmm. Iggy's link to a library that works? Na, can't be. I'll just have to download it and prove I can't make it work

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh my goodness! Iggy's link even has docs on how to use it? Perish the thought!

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you will find that ILI9325 and ILI9328 initialisation is the same. (looking at the library code.

Post your read and write primitives.

The covers many controllers.
The code is really SLOW but at least it works !

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah! Reg 0 says, 9328!

I added a NOP to my bogus "read" primitive to give it some time between setting the CS low and reading the low and high:

	Setb(LCD_RS_PRTS,LCD_RS_PIN);

	Setb(LCD_WR_PRTS,LCD_WR_PIN);
	Clrb(LCD_RD_PRTC,LCD_RD_PIN);

	Clrb(LCD_CS_PRTC,LCD_CS_PIN);
    
	NOP;
	dat = (LCD_DH_PINP << 8 ) | LCD_DL_PINP;
	
	Setb(LCD_CS_PRTS,LCD_CS_PIN);
	Setb(LCD_RD_PRTS,LCD_RD_PIN);

And now it says 9325.

Ok, the first 10 registers say:

Reg 0: 0x9325
Reg 1: 0x0000
Reg 2: 0x0400
Reg 3: 0x0030
Reg 4: 0x0000
Reg 5: 0x0000
Reg 6: 0x0000
Reg 7: 0x0000
Reg 8: 0x0808
Reg 9: 0x0000

This is after I reset the display, pulsing the reset line low, and before I init it, setting all the registers to bogus values.

(On the left, there, it's trying to draw a number. They're upside down and every other column of pixels is missing.)

Attachment(s): 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

There are plenty of example codes out there.

And the trouble is, 3/4 of the stinking things are crap. I invest a few hours into turning one of them into an xMega program, and discover that the author knows less about it than I do.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My strategy is to start off with an Arduino library running on a UNO.

I port the C++ code to an Xmega or an ARM.

In fact, I have translated the C++ to C and used on an 8051.

The advantage of this approach is that you start with a working library and working examples. So at every stage of the 'port' you have something to compare to.

Actually, my first TFT was a 9320. So my first job was to modify the code to support 9320 as well as its original 9325/9328.

I won't say that every 'port' has worked first time. However the 9320 addition to was painless. Hint. I found a link to suitable 9320 initialisation via Google.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yo DP: Can you post a 'check list' of how to cvt the arduino c++ and classes in the h files to c? Just make every method in every class a subroutine with a unique name?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have an arduino :D

I do have a big program in C++ that displays pictures from sd card, plays packman, has a terminal program...

I've avoided diving into that one as I barely know C, much less C++. Perhaps I'm in the C-- stage.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most Arduino libraries are fairly straightforward.
i.e. basic methods are not overloaded.

Of course, when it comes to inheriting the Print class, overloading is extensive. But think about it. Print methods end up creating a string. Your TFT C library just has to handle the string.

So I wrote some SED scripts to automate the editing/translation of the .CPP and .H files. Nothing is foolproof. However once the bulk of the editing has been automated, you are less prone to typos. e.g. the bass() method of the Bob library would be called Bob_bass().

Yes, in an ideal world you would mangle the overloaded methods into unique C functions. e.g. Bob_bass(), Bob_bass_uint8(), Bob_bass_uint32(), ...

Personally, I would avoid this. I would prefer intuitively named functions. OTOH, multiple constructors() seem a good idea. You tend to make single invocations of constructors.

I came to the conclusion that it is easier to use C++ toolchains. E.g. this forces me to use avr-gcc with AVR. Rowley-AVR only supports C. CodeVision only does C.

But with ARM, both RealView and GCC support C++.
The free RealView is limited to 32kB, which is fine for a lot of small projects. Incidentally, it produces smaller and faster code than arm-g++ or avr-g++.

Oh. SDCC for 8051 is barely capable of C. There is no hope of C++.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It must be a hardware problem, or something odd about this display.

This is the result of a completely different program, this time in C++ from an entirely different reference. You can see the drawing is completely different, but the symptom is identical. Well, not quite: There's nothing in the program that causes the darker stripes.

Attachment(s): 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just noticed that NewHaven sells these small ones for $15. Completely different pinout, however.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the newhaven init look exactly like yours? If not, does thiers work better?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tom,

The controller registers will handle the "home" location and direction.
e.g. top LHC or bottom RHC and possibly bottom LHC etc.
They also handle the writeable "window".

So it all comes down to those initialisation tables.

Quote:
I don't have an arduino Very Happy

I do have a big program in C++ that displays pictures from sd card, plays packman, has a terminal program...


At least use your "big" program to verify your LCD works.

For the future, buying an Arduino is not expensive.
I like the Seeeduino. You can run it at either 5V or 3.3V and it has 0.1" friendly extra headers..

Bog-standard Arduinos only work at 5V. You can get a 3.3V 'reference' but the MCU runs at 5V.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup. With the big C++ program, the symptom is unchanged.

I now have 3 programs from 3 different downloaded examples, all of which leave left side of the display dark.

The NewHaven display: I just ordered 2. If the stinking thing works, it's worth changing the board layout.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It still looks like the SM and GS bits in registers R1 and R6, like it's taking the odd lines and showing them elsewhere. Except the elsewhere is the ...

I've fiddled with those a bit, tried all 4 combinations, but none seem to correct the problem here.

My thinking with the NewHaven display is that what I have from who knows where in China isn't what I think I have. My main evidence is: everybody ELSE has the damn thing working in hours, and here I am after months and I can effect what is on the display, but not control it.

I'll put together another of these boards for the other display and see if it behaves any different. Maybe I'll crawl under my blanket and put my thumb in my mouth for a while first :roll:

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the other one? She's blank. Let's see, all the signals are getting to their pins... (I did a binary count on the 16 data lines and probed with my scope: All nice square waves and each half the frequency of the one before. Did the same on the control lines.) Nope, she's nada working. Perhaps one of these traces on the flex board has broken since I was playing with it before.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The consensus of several wise, but non-technical friends is I have 2 defunct displays (out of 2). The suggestion is that I remove them from my little red boards and find a different disreputable Chinese supplier.

The friends differ, however, on what to do with the defunct displays: Most suggest finding a handy, hard, vertical surface, taking a running start and flinging them with all the force I can muster. Another proposes taking them to the railroad and letting a train run over them.

My own opinion, as a barefoot terror of mice, frogs, toads and bugs, is to dissect them. Perhaps I'll find a tiny board I can repair with my frypan? Probably not. I never managed to actually REPAIR a frog.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you look at the Curt Lagerstam ILI9325 init at NHD in the program examples directory? Its for an 8051, so you need to rewrite the putcommand and putdata and the RSHI and RSLO macros they use. I massaged one of those 8051 files to an AVR flavor. We just want to init the ctrl and fill the screen to see if its working, right?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've tried more sample libraries than I can count. (Remember, I'm dyslexic.) Including yours. The results are always the same: 1 display shows only on half the display, the other doesn't show anything.

Oh, yes. The bloody guts:

Carefully removing the metal shield from the back reveals, um, nothing:

The glass touch panel removes easily. In fact, I had to glue this one down once 'cause it kept coming up on its own accord:

("... and he just curled up on the ground like that on his own." -- Alabama Moon)

The TFT part itself is a translucent gray thing, fastened only at one edge.

And under that is a transparent sheet. Under that is a shiny diffuser.

And under that is.... nothing.

"No user serviceable parts inside."

It's much less gooey than a mouse and has less moving parts than a frog. The works themselves must be under the epoxy at the edge of the tft panel.

To the train next, or to the wall?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oddly, the one I disassembled is the one now working

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's how I used to fix my pc. Remove and reinsert all boards and cables...

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's actually not a bad strategy. When I was a technician and knew Kit Carlson, my rule was "Always suspect wiring and connectors first."

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.