1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Mon Jun 27, 2016 4:17 pm

I'm currently hogging logic analyzer to a V6.0 display. I'll post the results later. Also I'll try to get some good photos of the PCB.

Tried this board with driver V6.1 which results in all colors inverted. It seems they're changing something on a regular base to make reverse engineering hard.

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Mon Jun 27, 2016 5:33 pm

1n4148 wrote:I'm currently hogging logic analyzer to a V6.0 display. I'll post the results later. Also I'll try to get some good photos of the PCB.
Well, I was planing to do it in some future....
One you have this figured out and got some understanding where to look at what, try run other kernel versions for earlier lcd's.
1n4148 wrote:Tried this board with driver V6.1 which results in all colors inverted. It seems they're changing something on a regular base to make reverse engineering hard.
I don't think so, they just change the LCD display which have a little different init sequence (see v1 and v2 - identical circuit but a little different init - if you mixed v1 with v2 then you got a inverted colors too), where probably using an undocumented command adjust the LCD panel RGB stripes to RGB data-word - I've read about this somewhere, that those cheaper LCD modules have mixed RGB stripes and their layout is "adjusted" by undocumented controller commands.

I think it's "not wise" (mildly speaking ;) ) to not publish at least init seq. for produced displays. With those made public, KeDeis lcd would be really popular, instead they just want profit, and don't really care for own "mark"; not to mention "no support".
As for now, KeDei's lcd are better to avoid (unless you get duped by seller), better to spend 2-3$ more and buy something that's works with (now) native fbtft driver.
To compare, the RPi official display, don't have public docs too, but have great support from creators, and don't force user to use outdated, closed source (and behaving suspicious) kernel - it's work on public available kernel (source).

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Mon Jun 27, 2016 6:53 pm

One you have this figured out and got some understanding where to look at what, try run other kernel versions for earlier lcd's.
It's very hard to get a good signal, the L_CS pulse is very short so at the necessary high sample rate my OLS logic analyzer runs out of memory quickly. A cypress USB based analyzer is limited at 12MHz sample rate :(

But at first sight, the driver is always shifting 32bits (frist 8bits always 0) through before rising L_CS for some nanoseconds.

Maybe I'll build a quick & dirty SPI sniffer with a uC or FPGA to emulate the cascade of 595s

Quite hard to make clean pictures of a black PCB

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Tue Jun 28, 2016 8:12 pm

So, made the first init-captures with my quick & dirty FPGA based TFT sniffer (basically implemented 3x595 in HDL, capturing only the data which is on the outputs after L_CS has risen)

Captured to boots from a V6.0 image. The start may differ as there is some junk on the line as I've seen on the scope.

If there are interests for captures of the other Vx.y images please leave me a note
Attachments
Capture_2.zip
(28.32 KiB) Downloaded 320 times
Capture_1.zip
(28.32 KiB) Downloaded 261 times

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Wed Jun 29, 2016 9:08 pm

Good job :)

But I would just solder 16 wires to HC595 outputs (5 control signals (round-up to whole byte) + 8 lower data bits), and connected TRIG IN in OLS (through buffer) to SPI0.CE1 (latching signal for '595...).
But I don't have that buffers so I did not do it... (I have in my shopping list to buy OpenLogicSniffer Wing and adapt one channel (#31) to CLKI signal on OLS board).

I gave a quick look on this, and I'm pretty sure that 15:8 bits are control signals (8..12 bits to be more precise).
5 signals:
- LCD_CS (might be more than one)
- LCD_WR
- LCD_RD
- LCD_DC (data/command)
- LCD_RESET ?

I think there is a lot of junk :), interesting is bit8 - this might be CMD/DATA... As for other signals, I have no idea which is which...
You're sampling data every 20ns not whenever the L_CS is going L->H. Sampling starts at first transition and continues until the buffer is full. If you want to trigger a sample at specific moment then you have to use CLKI input (this is available on 4 additional pads for 2x2 goldpin right over XTAL).

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Jun 30, 2016 8:40 am

The result would be the same, I'm emulating the shift registers in a FPGA using the build in Signal Tap II analyzer to store only latched data, instead of fiddling around with a lot of wires.

Ignore the timestamp in the csv-file, it's not true. Every line is the actual output of the shift register after it's latched (CS going high), so it's only the data which the LCD would physically see on the 595s outputs, no unnecessary junk.
If I replay this data through the FPGA the display is behaving like attached on a Pi (I also implemented a capture & replay function, but the internal memory is too small, I'll activating an attached SDRAM to capture up to 128MB display data), so my quick & dirty sniffer is working fine :)

As soon as the downloads are finished I'll capture the start up bytes for every image (V1.0 to V6.1). So we can compare them.

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Jun 30, 2016 10:31 am

I've put the first captures into my github: https://github.com/1N4148/Kedei

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Jun 30, 2016 11:17 am

Unfortunately I've cracked my screen when I accidently droped it from my lab bench so I can tell you the display is a YXT35MH357-A, photo from the layout side will follow

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Sun Jul 03, 2016 9:15 pm

Hi,

1n4148 (btw. good nick :D ), this suck's :/ , thx for creating repo @gihub with inits. When I will have a some time I'll take look at v1/v2 init and see how much it's different from those I have.

Did you try already "play captured" init from RPi?
Did you manage to to "display something" after "playing init"?

OT: those lcd modules YXT35MH357-A cost about 2,6-3,7 USD/pcs - so I'm not suprised that he build "newer" versions because he make some decent money from them (I know parts & manufacturing costs too, and middleman have to earn something too).

1n4148
Posts: 7
Joined: Mon Jun 27, 2016 4:13 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Jul 07, 2016 7:55 am

saper_2 wrote: Did you try already "play captured" init from RPi?
Did you manage to to "display something" after "playing init"?
On my last setup I've captured the whole display traffic into an SDRAM attached to the FPGA and was able to playback the sequence until the desktop is up without an RPi. But during decoding the line assignment my screen went to crack heaven so I couldn't my lcd code on an uC for using the display without a Pi.

GAMELASTER
Posts: 38
Joined: Sat Feb 14, 2015 8:05 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Tue Jul 12, 2016 7:25 pm

Any tips for cheap display with good (driver) support?
I need at least 30FPS and possible to run Full screen apps like RetroPie?

Thanks

tinylcd
Posts: 206
Joined: Sat Oct 26, 2013 4:07 am

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Wed Jul 13, 2016 4:24 am

Hello

Our clients have installed jessie and retropie successfully on this screen

http://www.neosecsolutions.com//product ... 8&cPath=17

regards
tinylcd

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Aug 04, 2016 2:57 am

For those that care, I finally got around to building a logic analyzer for the KeDei v5.0.

It handles data very strangely, IMO; It looks like they made a boo-boo on the board, and fixed it with software.

The entire log is attached; first column is the data, second column is microseconds*250 from the time the logic analyzer started.

The display goes loony at ~line 172, where the controller sends a 0x29 command; and holds the SS line at 5v; so several frames are lost.

Capture environment:
rpi_35_v5_jessie8_kernel_4_1_19.img from KeDei burned to an SD Card
core_freq=1 in config.txt (yes, I set the core frequency to 1MHz, simple way to drop the SPI bus to the speed of smell, but it takes ~5 minutes for the RPi to boot)
Captured on an ESP8266 programmed in Arduino IDE with a home-brew logic analyzer.

Replaying this exact sequence (from the log file) yields the display working, and displaying the first 1/8 or so of the raspbian boot screen; decoding and modifying it is still a WIP.

TLDR:
Init sequence for KeDei v5: all values are hex, first on each line is sent as a command, rest is data. everything byte requires a 2 4byte packets. The display will respond properly if you only give it 2 bytes; until you get to rgb data. That is a whole other can of worms.

RGB data is split and shifted everywhere, like a tornado hit it. Work in progress.

the first 2 bytes of each packet appear to be garbage (read as 0), except rgb data.
for encoding, lsb of 3rd byte is stored in bit5 of byte4, then shifted right one position. Pretty sure this is due to a engineering flaw, as it makes it a PITA to program for.

<Pulse reset>
00
11
EE 02 01 02 01
ED 00 00 9A 9A 9B 9B 00 00 00 00 AE AE 01 A2 00
B4 00
C0 10 3B 00 02 11
C1 10
C8 00 46 12 20 0C 00 56 12 67 02 00 0C
D0 44 42 06
D1 43 16
D2 04 22
D3 04 12
D4 07 12
E9 00
C5 08
36 2A
3A 66
2A 00 00 01 3F
2B 00 00 01 E0
35 00
29
00
11
EE 02 01 02 01
ED 00 00 9A 9A 9B 9B 00 00 00 00 AE AF 01 A2 01 BF 2A

<data>
Attachments
201608032223_log.zip
(25.43 KiB) Downloaded 191 times

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Aug 04, 2016 2:38 pm

Conjur wrote:For those that care, I finally got around to building a logic analyzer for the KeDei v5.0.
You're stubborn :D
Conjur wrote: It handles data very strangely, IMO; It looks like they made a boo-boo on the board, and fixed it with software.
Yes, they just fit new screen on board, and re-route tracks from shift reg to lcd in the simplest way as possible. Then they just "fix" driver to new pcb layout.
Conjur wrote:The display goes loony at ~line 172, where the controller sends a 0x29 command; and holds the SS line at 5v; so several frames are lost.
goes "mad"/"crazy" ?????
Conjur wrote: Capture environment:
rpi_35_v5_jessie8_kernel_4_1_19.img from KeDei burned to an SD Card
core_freq=1 in config.txt (yes, I set the core frequency to 1MHz, simple way to drop the SPI bus to the speed of smell, but it takes ~5 minutes for the RPi to boot)
Captured on an ESP8266 programmed in Arduino IDE with a home-brew logic analyzer.

Replaying this exact sequence (from the log file) yields the display working, and displaying the first 1/8 or so of the raspbian boot screen; decoding and modifying it is still a WIP.
Look at the data stream and split it every 3 or 4 bytes (that much data they usually load, 3 or 4 bytes. If 4 bytes used one almost every time is 0x00 to "clear" shift reg).
Decode those data chunks to binary format and compare them, there should be changed only few bits between two chunks (those are control lines). That I would do at least :)
Conjur wrote: TLDR:
Init sequence for KeDei v5: all values are hex, first on each line is sent as a command, rest is data. everything byte requires a 2 4byte packets. The display will respond properly if you only give it 2 bytes; until you get to rgb data. That is a whole other can of worms.
So split "rgb stream" into 4bytes and there you have, 1st byte shifted out should be always that same (probably 0x00- to "reset" shift regs).
I don't think they would go for 18bit RGB color, this must be a 16bit RGB... but I can be always wrong...
Conjur wrote: RGB data is split and shifted everywhere, like a tornado hit it. Work in progress.
Just as I suspected, they routed connections from shif reg to lcd as easy as possible, the software takes the task to rearrange data...
Just got the idea, the lcd might be using a 8bit color so there is need for 3 transfers for 1 pixel (8bit R, 8bit G, 8bit B)....
Conjur wrote: the first 2 bytes of each packet appear to be garbage (read as 0), except rgb data.
for encoding, lsb of 3rd byte is stored in bit5 of byte4, then shifted right one position. Pretty sure this is due to a engineering flaw, as it makes it a PITA to program for.
This might be some leftovers form bit-shift operations.... Or they might be negated control signals (LCD have those too -_- ).
Conjur wrote: <Pulse reset>
00
11
EE 02 01 02 01
ED 00 00 9A 9A 9B 9B 00 00 00 00 AE AE 01 A2 00
B4 00
C0 10 3B 00 02 11
C1 10
C8 00 46 12 20 0C 00 56 12 67 02 00 0C
D0 44 42 06
D1 43 16
D2 04 22
D3 04 12
D4 07 12
E9 00
C5 08
36 2A
3A 66
2A 00 00 01 3F
2B 00 00 01 E0
35 00
29
00
11
EE 02 01 02 01
ED 00 00 9A 9A 9B 9B 00 00 00 00 AE AF 01 A2 01 BF 2A

<data>
I'm holding thumbs for your success :) , as for my screens. I gave up, they are PITA to deal with :)
So I'm going to avid KeDei for rest of my life with huge distance :D

@GAMELASTER
As tinylcd mentioned, this lcd will work with native raspbian drivers (those need to be configured anyway). This lcd is clone of adafruit and it work with nottro fbtft driver. Here is driver config: http://www.averagemanvsraspberrypi.com/ ... t-for.html and there is some description of screen: http://www.averagemanvsraspberrypi.com/ ... y-for.html ...

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Fri Aug 05, 2016 6:20 am

So, as it turns out, the colors are normal; just had to write a separate spi write block for them, so the LSB wasn't pushed into the control byte.. Below is a fully functional Arduino program for an ESP8266, that will init a KeDei v5.0 display, and cycle through a bunch of colors, with a big plus in the middle of the screen (for alignment, to make sure it wasn't shifting)

I realize this is the Raspberry forum; but the most important part of this code is the init sequence and math behind making this thing actually work.

To validate, put this in a .ino, load into Arduino IDE, and program it to an ESP8266 (160MHz mode preferred). Pinout is:
GPIO13 -> MOSI
GPIO14 -> CLK
GPIO4 -> L_CS

Disclaimer: My code is a mess. I'm just posting it to show proof of concept, and help out anyone else with the v5.0.

and for some reason, no other "firmware" from KeDei send any data out without the proper LCD plugged in, so to analyze other versions, I apparently need to physically have one here. They seem to use some sort of bitbanged message on the IRQ line when the CS goes low; almost like a version report.

Code below is public domain, yada yada yada

Code: Select all

#include <SPI.h>

#define SPI_MISO 12
#define SPI_MOSI 13
#define SPI_SCLK 14
#define SPI_SS_L 4
#define SPI_SS_T 5
#define SPI_TIRQ 2

//borrowed from Adafruit. Thank You.
#define ILI9341_BLACK       0x0000      /*   0,   0,   0 */
#define ILI9341_NAVY        0x000F      /*   0,   0, 128 */
#define ILI9341_DARKGREEN   0x03E0      /*   0, 128,   0 */
#define ILI9341_DARKCYAN    0x03EF      /*   0, 128, 128 */
#define ILI9341_MAROON      0x7800      /* 128,   0,   0 */
#define ILI9341_PURPLE      0x780F      /* 128,   0, 128 */
#define ILI9341_OLIVE       0x7BE0      /* 128, 128,   0 */
#define ILI9341_LIGHTGREY   0xC618      /* 192, 192, 192 */
#define ILI9341_DARKGREY    0x7BEF      /* 128, 128, 128 */
#define ILI9341_BLUE        0x001F      /*   0,   0, 255 */
#define ILI9341_GREEN       0x07E0      /*   0, 255,   0 */
#define ILI9341_LIGHTBLUE   0x061F      /*   0, 192, 255 */
#define ILI9341_CYAN        0x07FF      /*   0, 255, 255 */
#define ILI9341_RED         0xF800      /* 255,   0,   0 */
#define ILI9341_MAGENTA     0xF81F      /* 255,   0, 255 */
#define ILI9341_YELLOW      0xFFE0      /* 255, 255,   0 */
#define ILI9341_WHITE       0xFFFF      /* 255, 255, 255 */
#define ILI9341_ORANGE      0xFD20      /* 255, 165,   0 */
#define ILI9341_GREENYELLOW 0xAFE5      /* 173, 255,  47 */
#define ILI9341_PINK        0xF81F

uint16_t colors[] = {ILI9341_BLACK,ILI9341_NAVY,ILI9341_DARKGREEN,ILI9341_DARKCYAN,ILI9341_MAROON,ILI9341_PURPLE,ILI9341_OLIVE,ILI9341_LIGHTGREY,ILI9341_DARKGREY,ILI9341_BLUE,ILI9341_GREEN,ILI9341_LIGHTBLUE,ILI9341_CYAN,ILI9341_RED,ILI9341_MAGENTA,ILI9341_YELLOW,ILI9341_WHITE,ILI9341_ORANGE,ILI9341_GREENYELLOW,ILI9341_PINK};

uint8_t color;

uint8_t b[3];

void lcd_spi(void) {
  digitalWrite(SPI_SS_L,0); SPI.write(b[2]); SPI.write(b[1]); SPI.write(b[0]); digitalWrite(SPI_SS_L,1);
  yield();
}

void lcd_rst(void) {
  GPOC = 1<<SPI_SS_L; SPI.write(0); GPOS = 1<<SPI_SS_L; delay(10);
  GPOC = 1<<SPI_SS_L; SPI.write(1); GPOS = 1<<SPI_SS_L; delay(50);
}
void lcd_cmd(uint8_t cmd) {
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x11+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x1B+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_dat(uint8_t dat) {
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x15+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x1F+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
  yield();
}

void lcd_color(uint16_t col) {
  GPOC = 1<<SPI_SS_L; SPI.write(col>>8); SPI.write(col&0xFF); SPI.write(0x75); GPOS = 1<<SPI_SS_L;
  b[0] += 10; //set bits 1 and 3
  GPOC = 1<<SPI_SS_L; SPI.write(col>>8); SPI.write(col&0xFF); SPI.write(0x7F); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_init(void) {
  pinMode(SPI_SS_L,OUTPUT);
  pinMode(SPI_SCLK,SPECIAL);
  pinMode(SPI_MOSI,SPECIAL);
  SPI.begin();
  SPI.setClockDivider(0x00081001);
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE1);
  lcd_rst();
  lcd_cmd(0x00);
  lcd_cmd(0x11);delay(10);
  lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
  lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAE); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x00);
  lcd_cmd(0xB4); lcd_dat(0x00);
  lcd_cmd(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0x00); lcd_dat(0x02); lcd_dat(0x11);
  lcd_cmd(0xC1); lcd_dat(0x10);
  lcd_cmd(0xC8); lcd_dat(0x00); lcd_dat(0x46); lcd_dat(0x12); lcd_dat(0x20); lcd_dat(0x0C); lcd_dat(0x00); lcd_dat(0x56); lcd_dat(0x12); lcd_dat(0x67); lcd_dat(0x02); lcd_dat(0x00); lcd_dat(0x0C);
  lcd_cmd(0xD0); lcd_dat(0x44); lcd_dat(0x42); lcd_dat(0x06);
  lcd_cmd(0xD1); lcd_dat(0x43); lcd_dat(0x16);
  lcd_cmd(0xD2); lcd_dat(0x04); lcd_dat(0x22);
  lcd_cmd(0xD3); lcd_dat(0x04); lcd_dat(0x12);
  lcd_cmd(0xD4); lcd_dat(0x07); lcd_dat(0x12);
  lcd_cmd(0xE9); lcd_dat(0x00);
  lcd_cmd(0xC5); lcd_dat(0x08);
  lcd_cmd(0x36); lcd_dat(0x2A);
  lcd_cmd(0x3A); lcd_dat(0x66);
  lcd_cmd(0x2A); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x01); lcd_dat(0x3F);
  lcd_cmd(0x2B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x01); lcd_dat(0xE0);
  lcd_cmd(0x35); lcd_dat(0x00);
  lcd_cmd(0x29);delay(10); // Display On
  lcd_cmd(0x00);delay(1); // NOP
  lcd_cmd(0x11);delay(10); // Sleep Out
  lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
  lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAF); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x01); lcd_dat(0xBF); lcd_dat(0x2A); lcd_dat(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0xDF); lcd_dat(0x2E);
  lcd_setframe(320, 480, 0, 0);
}

void lcd_setframe(uint16_t h, uint16_t w, uint16_t x, uint16_t y) {
  lcd_cmd(0x2A);
  lcd_dat(x>>8); lcd_dat(x&0xFF);  //x
  lcd_dat(w>>8); lcd_dat(w&0xFF);  //width
  lcd_cmd(0x2B);
  lcd_dat(y>>8); lcd_dat(y&0xFF); //y
  lcd_dat(h>>8); lcd_dat(h&0xFF); //height
  lcd_cmd(0x2C);
}

void setup() {

  Serial.begin(250000);
  lcd_init();
  
  
}
void loop() {
  // put your main code here, to run repeatedly:
  yield();
  delay(100);
  Serial.printf("Setting %u at %lu\n", color, millis());
  lcd_setframe(320, 480, 0, 0);
  for(int row=0;row<158;row++) {
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
  }
  for(int pix=0;pix<1920;pix++) { lcd_color(0); }
  
  for(int row=0;row<158;row++) {
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
  }
  color++;
  if (color==sizeof(colors)) {color=0;}
}

EDIT: Cleaned up the code, and optimized it considerably.

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Fri Aug 05, 2016 11:28 am

Conjur wrote:You're so stubborn :D, but I was too. I could sit till dawn to make lcd or other chip to work :D

....

and for some reason, no other "firmware" from KeDei send any data out without the proper LCD plugged in, so to analyze other versions, I apparently need to physically have one here. They seem to use some sort of bitbanged message on the IRQ line when the CS goes low; almost like a version report.
I don't think, but there might be something in touch controller (serial number or something - I didn't read it's datasheet). The interface to LCD is write-only...

If you tried v6 then it might be a real mess (or nothing), looking at what 1n4148 published, the latest version (v6 v61/v62) is really screwed up (in electrical connections and in software... actually I wanted to use different word :D but I don't want read complaint from mod that I use offensive words ;) )
Conjur wrote: Code below is public domain, yada yada yada
I want to add your code to my repo, do you have any objections? Also, would be great if you could take few photos of circuit and working lcd :) I would like add them to repo too :)

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Thu Aug 18, 2016 7:07 pm

I have been out of country for a few weeks, so I cannot get a video of it working; below is the last functional code I have. I believe I had the SPI Mode wrong in the code I posted above, it should be SPI.setDataMode(SPI_MODE0);. GPOS/GPOC are DMA registers for the Setting/Clearing the GPIOS. Be careful with them. writing to "internal" GPIOS tends to do nasty things to the flash.

TLDR: USE GPIO 4 as your Chip Select. Other GPIOS have not been tested.

V/r,
Mike

Code: Select all

#include <SPI.h>
#define SPI_MOSI 13   //blue
#define SPI_SCLK 14   //grey
#define SPI_SS_L 4    //brown

//borrowed from Adafruit. Thank You.
#define ILI9341_BLACK       0x0000      /*   0,   0,   0 */
#define ILI9341_NAVY        0x000F      /*   0,   0, 128 */
#define ILI9341_DARKGREEN   0x03E0      /*   0, 128,   0 */
#define ILI9341_DARKCYAN    0x03EF      /*   0, 128, 128 */
#define ILI9341_MAROON      0x7800      /* 128,   0,   0 */
#define ILI9341_PURPLE      0x780F      /* 128,   0, 128 */
#define ILI9341_OLIVE       0x7BE0      /* 128, 128,   0 */
#define ILI9341_LIGHTGREY   0xC618      /* 192, 192, 192 */
#define ILI9341_DARKGREY    0x7BEF      /* 128, 128, 128 */
#define ILI9341_BLUE        0x001F      /*   0,   0, 255 */
#define ILI9341_GREEN       0x07E0      /*   0, 255,   0 */
#define ILI9341_LIGHTBLUE   0x061F      /*   0, 192, 255 */
#define ILI9341_CYAN        0x07FF      /*   0, 255, 255 */
#define ILI9341_RED         0xF800      /* 255,   0,   0 */
#define ILI9341_MAGENTA     0xF81F      /* 255,   0, 255 */
#define ILI9341_YELLOW      0xFFE0      /* 255, 255,   0 */
#define ILI9341_WHITE       0xFFFF      /* 255, 255, 255 */
#define ILI9341_ORANGE      0xFD20      /* 255, 165,   0 */
#define ILI9341_GREENYELLOW 0xAFE5      /* 173, 255,  47 */
#define ILI9341_PINK        0xF81F

uint16_t colors[] = {ILI9341_BLACK,ILI9341_NAVY,ILI9341_DARKGREEN,ILI9341_DARKCYAN,ILI9341_MAROON,ILI9341_PURPLE,ILI9341_OLIVE,ILI9341_LIGHTGREY,ILI9341_DARKGREY,ILI9341_BLUE,ILI9341_GREEN,ILI9341_LIGHTBLUE,ILI9341_CYAN,ILI9341_RED,ILI9341_MAGENTA,ILI9341_YELLOW,ILI9341_WHITE,ILI9341_ORANGE,ILI9341_GREENYELLOW,ILI9341_PINK};

uint8_t color;

void lcd_rst(void) {
  GPOC = 1<<SPI_SS_L; SPI.write(0); GPOS = 1<<SPI_SS_L; delay(25);
  GPOC = 1<<SPI_SS_L; SPI.write(1); GPOS = 1<<SPI_SS_L; delay(25);
}
void lcd_cmd(uint8_t cmd) {
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x11+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x1B+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_dat(uint8_t dat) {
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x15+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x1F+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_color(uint16_t col) {
  GPOC = 1<<SPI_SS_L; SPI.write(col>>8); SPI.write(col&0xFF); SPI.write(0x75); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(col>>8); SPI.write(col&0xFF); SPI.write(0x7F); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_init(void) {
  lcd_rst();
  lcd_cmd(0x00);
  lcd_cmd(0x11);delay(50);
  lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
  lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAE); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x00);
  lcd_cmd(0xB4); lcd_dat(0x00);
  lcd_cmd(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0x00); lcd_dat(0x02); lcd_dat(0x11);
  lcd_cmd(0xC1); lcd_dat(0x10);
  lcd_cmd(0xC8); lcd_dat(0x00); lcd_dat(0x46); lcd_dat(0x12); lcd_dat(0x20); lcd_dat(0x0C); lcd_dat(0x00); lcd_dat(0x56); lcd_dat(0x12); lcd_dat(0x67); lcd_dat(0x02); lcd_dat(0x00); lcd_dat(0x0C);
  lcd_cmd(0xD0); lcd_dat(0x44); lcd_dat(0x42); lcd_dat(0x06);
  lcd_cmd(0xD1); lcd_dat(0x43); lcd_dat(0x16);
  lcd_cmd(0xD2); lcd_dat(0x04); lcd_dat(0x22);
  lcd_cmd(0xD3); lcd_dat(0x04); lcd_dat(0x12);
  lcd_cmd(0xD4); lcd_dat(0x07); lcd_dat(0x12);
  lcd_cmd(0xE9); lcd_dat(0x00);
  lcd_cmd(0xC5); lcd_dat(0x08);
  lcd_cmd(0x36); lcd_dat(0x2A);
  lcd_cmd(0x3A); lcd_dat(0x66);
  lcd_cmd(0x2A); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x01); lcd_dat(0x3F);
  lcd_cmd(0x2B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x01); lcd_dat(0xE0);
  lcd_cmd(0x35); lcd_dat(0x00);
  lcd_cmd(0x29);delay(50); // Display On
  lcd_cmd(0x00);delay(1); // NOP
  lcd_cmd(0x11);delay(50); // Sleep Out
  lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
  lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAF); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x01); lcd_dat(0xBF); lcd_dat(0x2A); lcd_dat(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0xDF); lcd_dat(0x2E);
  lcd_setframe(320, 480, 0, 0);
}

void lcd_setframe(uint16_t h, uint16_t w, uint16_t x, uint16_t y) {
  lcd_cmd(0x2A);
  lcd_dat(x>>8); lcd_dat(x&0xFF);  //x
  lcd_dat(w>>8); lcd_dat(w&0xFF);  //width
  lcd_cmd(0x2B);
  lcd_dat(y>>8); lcd_dat(y&0xFF); //y
  lcd_dat(h>>8); lcd_dat(h&0xFF); //height
  lcd_cmd(0x2C);
}

void setup() {
  pinMode(SPI_SS_L,OUTPUT);
  pinMode(SPI_SCLK,SPECIAL);
  pinMode(SPI_MOSI,SPECIAL);
  GPOS = 1<<SPI_SS_L;
  
  SPI.begin();
  SPI.setClockDivider(0x00081001);
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE0);
  Serial.begin(250000);
  lcd_init();
}

void loop() {
  delay(100);
  Serial.printf("Setting %u at %lu\n", color, millis());
  lcd_setframe(320, 480, 0, 0);
  for(int row=0;row<158;row++) {
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
  }
  for(int pix=0;pix<1920;pix++) { lcd_color(0); }
  
  for(int row=0;row<158;row++) {
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    lcd_color(0);
    for(int col=0;col<238;col++) { lcd_color(colors[color]); }
  }
  color++;
  if (color==sizeof(colors)) {color=0;}
}

Conjur
Posts: 17
Joined: Wed Apr 06, 2016 8:55 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Mon Aug 22, 2016 2:12 am

Final post on the KeDei v5.0 code.

Below are images of the reverse of the board to show connections and version; and an image of it loading a bmp from SPIFFS.

Here is the exact code (poor formatting and all!) used in these pictures.

MOSI -> GPIO13
CLK -> GPIO14
L_CS -> GPIO4
5V -> 5v supply
GND -> GND

lcd_img() displays an image from SPIFFS, only 24 bit BMP/DIB as saved by MSPAINT is supported.

rotation works; the commented out code in the loop just repeatedly rotates the screen, filling it with sequential colors, and adding a bar in the top-left corner (to verify orientation) my 0 degree rotation is upside down from the default; but its easier having the connectors on top :)

I removed a vast amount of useless init code; it just re-sets the defaults that are set with lcd_rst().

Code: Select all

#include <SPI.h>
#include <FS.h>
#define SPI_MOSI 13   //blue
#define SPI_SCLK 14   //grey
#define SPI_SS_L 4    //brown

uint8_t lcd_rotations[4] = {
  0b11101010, //  0
  0b01001010, // 90
  0b00101010, //180
  0b10001010  //270
};
volatile uint8_t lcd_rotation;
volatile uint16_t lcd_h;
volatile uint16_t lcd_w;

uint16_t colors[17] = {
  0b0000000000000000,        /* BLACK   000000 */
  0b0000000000010000,        /* NAVY    000080 */
  0b0000000000011111,        /* BLUE    0000ff */
  0b0000010011000000,        /* GREEN   009900 */
  0b0000010011010011,        /* TEAL    009999 */
  0b0000011111100000,        /* LIME    00ff00 */
  0b0000011111111111,        /* AQUA    00ffff */
  0b1000000000000000,        /* MAROON  800000 */
  0b1000000000010000,        /* PURPLE  800080 */
  0b1001110011000000,        /* OLIVE   999900 */
  0b1000010000010000,        /* GRAY    808080 */
  0b1100111001111001,        /* SILVER  cccccc */
  0b1111100000000000,        /* RED     ff0000 */
  0b1111100000011111,        /* FUCHSIA ff00ff */
  0b1111111111100000,        /* YELLOW  ffff00 */
  0b1111111111111111,        /* WHITE   ffffff */
  0b0000000000000000         /* BLACK   000000 */ //added to fix my poor coding (color+1)
};

uint8_t color;

uint8_t buf[54];
uint16_t p, c;
uint32_t isize, ioffset, iwidth, iheight, ibpp, fpos, rowbytes;


void lcd_rst(void) {
  GPOC = 1<<SPI_SS_L; SPI.write(0); GPOS = 1<<SPI_SS_L; delay(25);
  GPOC = 1<<SPI_SS_L; SPI.write(1); GPOS = 1<<SPI_SS_L; delay(25);
}
void lcd_cmd(uint8_t cmd) {
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x11+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(cmd>>1); SPI.write(0x1B+((cmd&1)<<5)); GPOS = 1<<SPI_SS_L;
}
void lcd_dat(uint8_t dat) {
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x15+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write(dat>>1); SPI.write(0x1F+((dat&1)<<5)); GPOS = 1<<SPI_SS_L;
}
void lcd_color(uint16_t col) {
  GPOC = 1<<SPI_SS_L; SPI.write16(col); SPI.write(0x75); GPOS = 1<<SPI_SS_L;
  GPOC = 1<<SPI_SS_L; SPI.write16(col); SPI.write(0x7F); GPOS = 1<<SPI_SS_L;
  yield();
}
void lcd_init(void) {
  //reset display
  lcd_rst();
  lcd_cmd(0x00);
  lcd_cmd(0x11);delay(1); //Sleep Out
  lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
  lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAE); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x00);
  lcd_cmd(0xB4); lcd_dat(0x00);
  lcd_cmd(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0x00); lcd_dat(0x02); lcd_dat(0x11);
  lcd_cmd(0xC1); lcd_dat(0x10);
  lcd_cmd(0xC8); lcd_dat(0x00); lcd_dat(0x46); lcd_dat(0x12); lcd_dat(0x20); lcd_dat(0x0C); lcd_dat(0x00); lcd_dat(0x56); lcd_dat(0x12); lcd_dat(0x67); lcd_dat(0x02); lcd_dat(0x00); lcd_dat(0x0C);
  lcd_cmd(0xD0); lcd_dat(0x44); lcd_dat(0x42); lcd_dat(0x06);
  lcd_cmd(0xD1); lcd_dat(0x43); lcd_dat(0x16);
  lcd_cmd(0xD2); lcd_dat(0x04); lcd_dat(0x22);
  lcd_cmd(0xD3); lcd_dat(0x04); lcd_dat(0x12);
  lcd_cmd(0xD4); lcd_dat(0x07); lcd_dat(0x12);
  lcd_cmd(0xE9); lcd_dat(0x00);
  lcd_cmd(0xC5); lcd_dat(0x08);
  
  lcd_setrotation(0);
  lcd_cmd(0x29);delay(2); // Display On
  lcd_cmd(0x00);   // NOP
  lcd_cmd(0x11);delay(1); // Sleep Out
}

//lcd_fillframe
//fills an area of the screen with a single color.
void lcd_fillframe(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint16_t col) {
  int span=h*w;
  lcd_setframe(x,y,w,h);
  for(int q=0;q<span;q++) { lcd_color(col); }
}

void lcd_setframe(uint16_t x, uint16_t y, uint16_t w, uint16_t h) {
  lcd_cmd(0x2A);
  lcd_dat(x>>8); lcd_dat(x&0xFF);
  lcd_dat(((w+x)-1)>>8); lcd_dat(((w+x)-1)&0xFF);
  lcd_cmd(0x2B);
  lcd_dat(y>>8); lcd_dat(y&0xFF);
  lcd_dat(((h+y)-1)>>8); lcd_dat(((h+y)-1)&0xFF);
  lcd_cmd(0x2C);
}
void lcd_img(char *fname, uint16_t x, uint16_t y) {
  if (SPIFFS.exists(fname)) {
    File f = SPIFFS.open(fname, "r");
    f.seek(0,SeekSet);
    f.read(buf,30);
    isize =   buf[2] + (buf[3]<<8) + (buf[4]<<16) + (buf[5]<<24);
    ioffset = buf[10] + (buf[11]<<8) + (buf[12]<<16) + (buf[13]<<24);
    iwidth =  buf[18] + (buf[19]<<8) + (buf[20]<<16) + (buf[21]<<24);
    iheight = buf[22] + (buf[23]<<8) + (buf[24]<<16) + (buf[25]<<24);
    ibpp =    buf[28] + (buf[29]<<8);

    Serial.printf("\n\nFile Size: %u\nOffset: %u\nWidth: %u\nHeight: %u\nBPP: %u\n\n",isize,ioffset,iwidth,iheight,ibpp);
    lcd_setframe(x,y,iwidth,iheight); //set the active frame...
    rowbytes=(iwidth*3) + 4-((iwidth*3)%4);
    for(p=iheight-1;p>0;p--) {
      fpos=ioffset+(p*rowbytes);
      f.seek(fpos,SeekSet);
      // p = relative page address (y)
      for(c=0;c<iwidth;c++) {
        // c = relative column address (x)
        f.read(buf,3);
        lcd_color(((buf[2]&248)<<8) + ((buf[1]&252)<<3) + (buf[0]>>3));
        
      }
    }
  
  }



  
}




void lcd_setrotation(uint8_t m) {
  lcd_cmd(0x36); lcd_dat(lcd_rotations[m]);
  if (m&1) {
    lcd_h = 480;
    lcd_w = 320;
  } else {
    lcd_h = 320;
    lcd_w = 480;
  }
}
void setup() {
  SPIFFS.begin();
  pinMode(SPI_SS_L,OUTPUT);
  pinMode(SPI_SCLK,SPECIAL);
  pinMode(SPI_MOSI,SPECIAL);
  GPOS = 1<<SPI_SS_L;
  color=0;
  lcd_rotation=0;
  SPI.begin();
  SPI.setClockDivider(0x00081001);
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE0);
  Serial.begin(250000);
  lcd_init();
  lcd_fillframe(0,0,480,320,0); //black out the screen.
  lcd_img("/boot.bmp", 50, 5);
}

void loop() {
  /*
  //Update rotation
  lcd_setrotation(lcd_rotation);

  //Fill entire screen with new color
  lcd_fillframe(0,0,lcd_w,lcd_h,colors[color]);

  //Make a color+1 box, 5 pixels from the top-left corner, 20 pixels high, 95 (100-5) pixels from right border.
  lcd_fillframe(5,5,lcd_w-100,20,colors[color+1]);

  //increment color
  color++;
  //if color is overflowed, reset to 0
  if (color==16) {color=0;}

  //increment rotation
  lcd_rotation++;
  //if rotation is overflowed, reset to 0
  if (lcd_rotation==4) lcd_rotation=0;
  */
  delay(500);
}
If anyone is near Michigan, and has any other version of this LCD, I'd love to get other versions working..

V/r,
Mike

EDIT: can't upload images... bleh

Image
Image

mpsnet
Posts: 4
Joined: Tue Aug 23, 2016 5:49 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Tue Aug 23, 2016 6:22 pm

I have a Kedei V5 screen.
How do I use your drive?

martin010
Posts: 1
Joined: Mon Jan 16, 2017 7:30 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Mon Jan 16, 2017 7:39 pm

Hi,

I have just managed to install my KeDei 3.5" after a long search on the net, but one thing is still not working, despite all the tutorials I find/follow. My touches are note working?!
If i run evtest, and check for inputs it seem to respond to all touches on the screen, yet when I run startx the display comes up nicely, but no responses from the gui to a touch on the screen

dmesg doesn't show any issues or errors.. and shows a correct registration of the input devices..

Any ideas??

Bla
Bla
...
[ 0.956447] input: ts_kedei_ts as /devices/virtual/input/input0
...
...

doublehp
Posts: 77
Joined: Wed May 02, 2012 1:11 am

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Wed Feb 01, 2017 12:54 pm

I am using the official ROMs from manufacturer:
http://kedei.net/raspberry/raspberry.html
it was working fine for years, untill I need I2C. Some people complained i2cdetect was not included in some versions of the software ( rpi_35_v6_0_2_jessie_kernel_4_4_11.rar ). After upgrade to rpi_35_v6_1_2_3_jessie_kernel_4_4_19.rar the command is in again, but it will not find any I2C bus:

[email protected]:~# i2cdetect -l
[email protected]:~#

While on older raspbian (official from this website):
[email protected]:~# i2cdetect -l
i2c-0 i2c bcm2708_i2c.0 I2C adapter
i2c-1 i2c bcm2708_i2c.1 I2C adapter
[email protected]:~#

Is there a trick to get I2C working on KeDei versions of Linux ? Is it absolutely uncompatible (conflict between I2C and SPI ) ? Is it easier to use an official Raspbian and patch to KeDei ?

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Sat Feb 04, 2017 9:54 pm

Hi,

I don't use nor have those images + I don't use the displays :D - I think I still have them but I don't even want to remember where they are, they're just crap...
Anyway, did you enabled overlay for I2C ? If I remember right, from kernel 3.6 there is device-tree and to enable hardware you have to add dtb overlay in config file...
Did you try to load i2c kernel modules manually?
Check if you have i2c-x in /sys/dev/bus/ (not sure if this is right location, i'm writing this from head)...


PS. This is better thing to ask in separate topic, this topic is dedicated to reverse engineering display, and helping those who have problem with setting up the display. And this topic is getting too long :D

taghof
Posts: 1
Joined: Wed Feb 22, 2017 6:50 pm

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Wed Feb 22, 2017 6:53 pm

Hello,

I am struggling to make this work. I have installed the custom kernel with LCD35_v. The screen works perfectly but I cannot make the touchscreen work.

I see that the Raspberry Pi recognizes it, but I cannot use the toichscreen. I use XFCE and under Mouse and Touchpad I cannot see any pointer devices. What am I doing wrong? Am I missing some configuration in X.org?

Thanks!


# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="ts_kedei_ts"
P: Phys=
S: Sysfs=/devices/virtual/input/input0
U: Uniq=
H: Handlers=mouse0 event0
B: PROP=0
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=1000003


# dmesg | grep kedei
[ 0.000000] Linux version 4.4.19 ([email protected]) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #16 Mon Jan 9 21:18:40 CST 2017
[ 1.521950] input: ts_kedei_ts as /devices/virtual/input/input0

# uname -a
Linux raspberrypi 4.4.19 #16 Mon Jan 9 21:18:40 CST 2017 armv6l GNU/Linux

doublehp
Posts: 77
Joined: Wed May 02, 2012 1:11 am

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Fri Feb 24, 2017 2:26 pm

Saper_2 : my issue is fixed now: viewtopic.php?f=44&t=173272 There used to be bugs in the KeDei ROMs (they had removed the I2C drivers around mid 2016, and put it back later). But I2C is still disabled on legacy pins (including ... they disabled the I2C bus on non soldered socket of rPi.1), but ... possible via other methods on other pins (via kernel and/or user bitbanging). Here is a very good place to regroup all questions related to KeDei product.

taghof do you use the I2C LCD ? For sure ? (not the HDMI one, which is also a KeDei product, but offtopic here). Which ROM do you use ? They have a huge mess of at least 15 different ROMs. You need to use the file called rpi_35_v6_1_2_3_jessie_kernel_4_4_19.rar . Older versions have bugs. Other tastes are tuned for specific aims. http://kedei.net/raspberry/raspberry.html . Triple check the hardware version of your screen. Use the IMG column, not Kali or Ubuntu. In SPI section (not HDMI). This ROM will launch X immediately, as is, and will let you touch the screen. Once this works "out of the box", then, you know your hardware is fine.

If this works out of the box, you messed up your software. Do your modifications one by one, untill you find the one that breaks things.

If it does not, you damaged something. Either rPi or screen is defective.

Works for me fine with rPi 1 and 2, and screens 3 and 6.

The output of your commands on my systems give exactly the same, except for this part in dmesg and uname:

Code: Select all

#15 Tue Jan 3 18:08:30
So, it seems you are using the correct ROM, but, a more recent version. So, please, try to download exactly the same version as me, write the SD, boot it, mouse should work at once.

I am not using X on my rPi for now; but here is a quick test to check the mouse from CLI: garbage appears when you move any mouse (mice groups all mice attached; mouse0 is the first detected one if you have several, including USB. Don't know the difference between event and mouse; I think that event produces things on screen that does not break my terminal:

Code: Select all

# cat /dev/input/event0
ÏA°X[<  LÏA°X[< ¢ÏA°X[< JÏA°X[< ÏA°X±  ÿÏA°X± SÏA°X± ÏA°X &
ªÏA°X &
ëÏA°X &
ÏA°Xä›
BÏA°Xä›
qÏA°Xä›
ÏA°Xø
     ÑÏA°Xø
           »ÏA°Xø
                 ÏA°X-
                       ÏA°X-
                              íÏA°X-
                                     ÏA°X¢p

User avatar
saper_2
Posts: 240
Joined: Sun Aug 03, 2014 10:08 am
Location: PL

Re: KeDei 3.5 inch 480x320 TFT lcd from ali

Sun Feb 26, 2017 5:34 pm

Hi,

I'm certainly not a specialist for KeDei's SPI displays :D (especially when it comes to ROMs) , but it easy to zap (electrostatic discharge) the display/controller when you grab the board in hand - just check how many people got their RPi Camera fried this way :( ...

event generates only a "Event" when hardware properties changes (and this is already processed by driver-filter), while "/dev/mouse" will stream to terminal everything that happens on it, even when you not moving the stream (well packets, but usb HID have polling interval below 10ms) is going on, so I guess the terminal just get overflowed and probably receives some control codes that make it freeze/hang .

The I2C0 is now explicitly used by GPU only for DSI & CSI interfaces only (RPi display & RPi camera , and HAT), so some I2C pins might not work, beside for them to kill whole I2C means they had a issues with driver because gpu tried accesing display that did not exits, this also show that the their SPI interface/driver is no good too - they should just to switch to FBTFT SPI interface, and not to burying themselves into their spi I/F .

This is a off-topic but I put a review on latest kedei creation : hdmi display :D viewtopic.php?t=175616

Return to “Interfacing (DSI, CSI, I2C, etc.)”