(In case the link stops working - the connectors on the back of it are
L_CS T_CS IRQ GND 5V 5V
GND CLK MISO MOSI GND GND
and no other pins - no data pins, DC, or RESET.
It's supposedly an ILI9341 with a XPT2046 touch controller, 3,5", 320x480 resolution.
Is there a chance of getting it working with an Arduino Uno R3 or Mega2560? The graphics libraries that use SPI that I've found keep mentioning the RST and DC lines, which aren't present on this board.
It looks like a neat little thing, would be a shame to only use it on RasPi.
Well, it looks as if it uses SPI for the LCD. i.e. L_CS for chip-select.
It probably uses 9-bit SPI with an ILI9481 controller.
I would guess that U4 is the XPT2046.
What do U1, U2, U3 do? The Raspberry has got 3.3V logic. Even so, you only have 7 logic lines to translate (if you are using 5V logic)
I have 9-bit SPI ILI9481 with a single SDA pin. This is an absolute pain with AVR which only has 8-bit SPI.
Even more so, the bidirectional SDA pin has no hardware support from Atmel.
Since you have MOSI and MISO, I would hope that your ILI9481 does not use bidirectional.
No I have not looked at the tar.gz file.
Identify the U1-U3 chips first. Run it with the Rpi. Is it 480x320 ? Does it behave like an ILI9481?
Correct, U4 is the XPT chip. U1-U3 are 74HC595D, level converters I think?
I haven't had the opportunity to try it on a Raspberry Pi yet. From pinouts of raspi (googled images) they only have one long strip of GPIO/etc connectors, do they not? Even if plugging this board onto the 40-pin connector, where the two 5V pins match up, on the raspi the opposing two aren't GND, they're listed as "+3,3V" and "SDA". Something tells me that.. well, either I'm missing something, or this display needs some form of connector between itself and the raspi it's meant to run off originally. (Oddly enough, they came with raspi-with-TFT-on-top plastic enclosures, which wouldn't leave any space for rewiring pins.)
Since the display has no data pins, I'd hazard a guess it's wired for SPI-only communications already.
Well, one thing made feel like a dunce - I was tired enough to read NC as GND next to 5V, so the board wasn't grounded. Now GND is plugged in correctly, and I get the (as usual..) only a full white screen.
I have never used a Rpi. It might use a separate SDA pin for the TFT and MOSI,MISO for the Touch.
I doubt it. It would be a lot cleaner with regular SPI for both. You just change mode each time. e.g. 9-bit mode #3 for TFT. 8-bit mode #0 for the XPT.
I presume that the TAR file contains the source code and maybe a schematic.
You can line up the header pins to see how they mate with the Rpi. I guess that the GND next to the 5V is actually n/c.
Ah-ha. The HC595 is a shift register. They might use them to produce 16-bit parallel to drive the TFT. If they do, it will be a nightmare. Even worse than 9-bit SPI.
I finally found a tarball for the display, for raspi, that didn't give me a 404. I'll grab and look around in it once it's downloaded.
And seeing that the two pins I first thought were GND actually were NC, makes things a lot clearer about how to connect it. Sheesh, I can't believe I missed that.
Well, it'll be interesting to see if I get this to work eventually. A quick guess would be that with L_CS pulled low, the LCD chip gets to talk with the MISO/MOSI lines. After initializing it, I suppose the next step will be to (read datasheet..) and see if the MISO/MOSI-lines are used to clock out display data with L_CS high so the LCD chip doesn't listen to that garbage, or if it is meant to be fed through the LCD chip aswell.
Read the files in the tarball. Or post a link for others to read.
You can just look for traces on the pcb. It will be pretty obvious what the 595s are used for. Even better with a schematic.
Kedei is apparently a very nice chap. Unfortunately his source code / documentation is a dogs breakfast (on other shields)
16-bit modules are cheaper than SPI display modules. So it is quite possible that he has crippled the display with shift registers instead of buying a proper SPI module.
I'm getting tarballs and full images from http://pan.baidu.com/s/1kVKsAF1 now. The first 4GB image I found still only showed a white screen when the rpi booted - perhaps it's too old, or I have to run a command once it's booted up. (Though the description said it should work as-is.)
I'm trying to get more specific files from that file hosting service now, and keep getting cut off, so it may take a while. I'll report back when/if I get a newer tarball downloaded, and images of the display circuit board if that's of interest.
Hrmm.. I don't think source is included. In the lcd_show_xx blobs are just kernels and modules, with a couple of very small scripts to copy the LED or HDMI kernel to the /boot place of the filesystem. (And no error checking, if you try copying the LED kernel, it backups the original kernel, but if you then run the copy-LED-kernel command again, it happily overwrites your original kernel, leaving you with two LED-enabled kernels and no original. hrrf..)
The traces are just about as good as can be seen on the first URL I pasted in the previous post - there are only a few of them going from the connector blocks to the U1-U3 chips, and then they vanish into the circuit board. I don't feel like bending them open on the off chance that I'll see where they reappear, so.. I'll cut my losses and if it gets working on an rpi, great, otherwise they go into the 'big bin of spare parts'.
This is an intelligent guess at how to drive this display (this is the way I would design it for the RPi):
To drive the TFT:
There is a 24 bit shift register
You clock the 8 bit command in plus the DC bit (9bits total) into the shift register (DC likely to be last bit)
You pulse L_CS low then high to write the command
You clock 18 bits for 6R+6G+6B (RGB order unknown) plus the DC bit into the shift register using SCK and MOSI
For commands that need 8/16 bit data you only need to clock in 9/17 bits (8/16 bits + DC)
You pulse L_CS low to write data
(You cannot read back the TFT data)
By experiments you could work out the bit order (MS most likely to be clocked in first, DC follows last)
To write the same colour to "N" pixels, send the CASET, RASET and RAMWR commands, load the 18bitRGB colour and strobe the L_CS line N times (so filling large areas is fast)
To talk to the touch controller you use standard SPI protocol with T_CS as the chip select + MOSI and MISO
A Due would drive it nicely, the shift register probably expects 3.3V logic levels.
Well, I downloaded the whole 35MB .GZ file. Unpacked it and found 3402 .ko files. I presume that these are kernel object files. Nothing that looked remotely like source files for your TFT display.
Like Bodmer, I suspect that it is parallel driven by a 24-bit shift register.
Since the ILI9481 can be driven directly by SPI, this seems a crazy way to do things. Especially since a HC595 might be clockable at 100MHz but you need to wiggle all 24-bits. And an AVR can only manage 8MHz on a good day.
It would be interesting to see schematic and shift register code.
david_prentice:
Since the ILI9481 can be driven directly by SPI, this seems a crazy way to do things.
Not when you consider that once you have loaded an 18 bit colour all you need to do is toggle the T_CS pin at say 10MHz and you can load the same pixels sequentially at 10Mpixels/s (=180Mbps) i.e. clear the screen faster than it is refreshed. With SPI you have to keep serially sending the same pixel N bits of colour over and over again, which is very inefficient. In the worst case (where sequential pixels are different colours) the shift register still wins if you can clock it faster than an SPI link maximum rate (easy on higher performance computers) because the same number of bits need to be clocked whatever interface is used.
I found this schematic but is is a combination of the original 595 shift register connections and a new hacked circuit replacing the original 595 shift register parts! but it gives clues as to the original connections.
This suggests more control bit are shifted in than is actually needed, but my hunch of an 18 bit + control parallel interface to the TFT seems to be correct.
The OP has got 3 74HC595s. I can only think that 24-bits of databus and control signals are clocked in for every operation. And this means two operations to create the WR strobe pulse.
I am not sure how the schematic with a 4040 will work. You are still shifting a lot of bits.
Somehow a separate WR line would look easier. i.e. latch all the data and control bits on the shift registers. Then strobe the WR line. Ok, it costs one extra GPIO. It makes a block-fill very efficient.
There is also something worrying when Kedei has multiple revisions of his hardware. The board in the OP's link is no longer available.
david_prentice:
There is also something worrying when Kedei has multiple revisions of his hardware. The board in the OP's link is no longer available.
Agreed, it looks like users have had trouble getting it working as a whole new kernel install was needed. I expect the basic control approach has not changed much. The design is not very good, I am not convinced the timings end up being data sheet compliant just using the CS line as the strobe.
The approach used is time inefficient but I suspect it made the software a bit simpler and allows the SPI port only to be used.
While easy to identify the tarball to get for just my board (v6.1), indeed, it's a bit unsettling that every board rev 2,3,4,5,6,6.1 has its own tarball available. Disseminating one version board may not help with the others then.
That aside, I sort of assume I'll need a 3,3V logic converter, since the rpi has 3,3v GPIO pins and most arduinos have 5V? So I don't accidentally burn out the display chips.
I would concentrate on getting it running on the Rpi first.
You will definitely require 3.3V logic conversion for a 5V Arduino.
Yes, I expect that bodmer or myself could probably get you working if we made some inspired guessing with the schematic. You could always email Kedei and ask him for the genuine schematic. Make sure that you tell him the Revision number(s) on the pcb.
If you own a Rpi, just use it there.
You can buy an ILI9481 Arduino shield pretty cheaply. Either for Uno or Mega2560. This will work better with an AVR.
I had success with downloading Kedei's 4GB images specific for the 6.1 board and putting on an SD card. Now the raspi boots up, and I see the boot messages scroll by. The original article said 'expect about 6fps from the display' and that seems right - it's jerky, but works.
Once booted up (with the 'jessie' image) I get put straight into X, and touchscreen support works aswell, I can click menus and such.
It doesn not appear to come with source though, inside the image either. (Like in the kernel-only tarball.) But, it does work, so that confirms the display unit is operational.
I'm going to order a couple of logic level converters now (a pair of 74LVC245 should do nicely on a breadboard), and then I can poke at it from an arduino environment.
Downside: I don't have an 8GB SD card to try it out on, so will just hope that stuff is the same as in the 4GB 'jessie' image.
Extra details: In the jessie image, the module loaded when booted up are: (things that I'm sure aren't related, such as wifi, removed) module name and usage count
evdev 6
joydev 0
bcm2835_gpiomem 0
uio_pdrv_genirq 0
uio 1 (uio_pdrv_genirq)
i2c_dev 0
fuse 3
Well, I guess it's no big leap to imagine the display driver being compiled into the kernel itself, since it's present at boot-time already and not using an init-ramdisk for its modules.
On the rpi, I must say I'm actually pleased at how crisp the display is (though not much viewing angle), and how 'fairly good' the touchscreen is calibrated. Shame only that the software was such a pain to find and find info about.
The rpi and screen together uses 260mA, reports a little amp-meter on the USB cable.
