Touchscreens and the propeller - SPI, 8bit parallel, 16bit parallel, 8080 or 6800 - Whats realistic?
Mahonroy
Posts: 175
in Propeller 1
Hey guys,
I have been trying to source a decent touch screen for a while now, and I have hit a dead end.
There are a ton of touch screens out there, they range from using different drivers such as the ILI9325 and the ILI9488. These also come in variations in different methods of communicating with the screen which seem to be SPI, 8 bit parallel, 16 bit parallel, then there is the 8080 & 6800 (I'm not entirely sure what this is, but I'm thinking one is 8 bit and the other is 16 bit?). I've very confused on what the best rout to go with is.
I have a few questions:
* Are there any drivers out there that people have been able to use with any of these popular screens? I could not find one legitimate driver available for the propeller. Well, I found 1 by Mark Tillotson, but it did not work at all.
* Are all SPI commands universal for every touch screen? If I find a library for one SPI screen can it be used on another, or is every screen unique? Finding datasheets on most of the touch screens out there seems impossible.
* Is any of this stuff universal - for any of the parallel drivers? Or is this the same problem... each screen has its own methods of working?
* Is SPI the best rout, or should I be looking for one of the different communication methods?
* Are there some popular screens out there that you guys have been using and have had good results with?
So far I have been experimenting with some of mcufriend.com screens, and some raspberry pi screens, but I am unable to find any information on how to get these to work, or even to start writing a custom library so I can use them.
I found these guys, and they seem to be pretty legit as far as screens go and cost, but I have no idea what I'm looking for:
http://www.buydisplay.com/default/tft-display/4-3-inch
I have used 4D Systems screens in the past, and while they are nice, the price is insane. Surely there must be a better way of doing this.
What do you guys think? Any help is greatly appreciated, thanks!
I have been trying to source a decent touch screen for a while now, and I have hit a dead end.
There are a ton of touch screens out there, they range from using different drivers such as the ILI9325 and the ILI9488. These also come in variations in different methods of communicating with the screen which seem to be SPI, 8 bit parallel, 16 bit parallel, then there is the 8080 & 6800 (I'm not entirely sure what this is, but I'm thinking one is 8 bit and the other is 16 bit?). I've very confused on what the best rout to go with is.
I have a few questions:
* Are there any drivers out there that people have been able to use with any of these popular screens? I could not find one legitimate driver available for the propeller. Well, I found 1 by Mark Tillotson, but it did not work at all.
* Are all SPI commands universal for every touch screen? If I find a library for one SPI screen can it be used on another, or is every screen unique? Finding datasheets on most of the touch screens out there seems impossible.
* Is any of this stuff universal - for any of the parallel drivers? Or is this the same problem... each screen has its own methods of working?
* Is SPI the best rout, or should I be looking for one of the different communication methods?
* Are there some popular screens out there that you guys have been using and have had good results with?
So far I have been experimenting with some of mcufriend.com screens, and some raspberry pi screens, but I am unable to find any information on how to get these to work, or even to start writing a custom library so I can use them.
I found these guys, and they seem to be pretty legit as far as screens go and cost, but I have no idea what I'm looking for:
http://www.buydisplay.com/default/tft-display/4-3-inch
I have used 4D Systems screens in the past, and while they are nice, the price is insane. Surely there must be a better way of doing this.
What do you guys think? Any help is greatly appreciated, thanks!
Comments
In regards to instruction sets these cheap and plentiful controllers they use on them are wide and varied and don't seem to stick to even a basic convention, typical. If it had been a US or European company that designed them then they would be a lot easier to work with and follow a convention that everybody could use. For instance, if you designed a remote control for your TV where would you put the play button? Yep, nice big one or maybe even use one of the colored ones but the reality is that you have to turn on the light and discover through the mute color scheme the print that says play in some unlikely corner on a small black button like every other one. Why would you think display controllers would be any better?
8080/6800 is just the signal convention.
8080 is using /RD and /WR lines, and 6800 uses a E CLK and a R/W signal
Parallel is faster than SPI, but needs more pins - common trade off.
If you want something comprehensive, maybe FTDI EVE based screens ?
Or, for lower end, try Arduniio Touch Screen shields, as they will usually include working software examples, that are not to hard to port.
Getting the working example is the hard part.
About the instructions, I have based my code on the UTFT library here http://www.rinkydinkelectronics.com/library.php?id=51 which supports a number of different displays. It targets Arduino-like boards and is not very optimized in some aspects but is a good starting point as it saves you from finding the right initialization sequence.
use the video interface. But of course that is very memory hungry.
Which driver of mine was that and do you know why it failed? I do test things before uploading
the Obex!! I thought I had several? In fact I have 5, for the ILI9341, ILI9320, ILI9325, uPD161704a (parallel and SPI)
Ok so let me see if I am understanding this correctly. 8 bit means 8 data pins + X amount of pins used for communication. 16 bit is 16 data pins + X amount of pins used for communication.
For X, this is where 8080 and 6800 come into play correct? Ok so these mcufriend.com displays I have here have 8 data pins, a RST, CS, RS, WR and RD - so these must be a 8 bit 8080 screens?
You mentioned FTDI EVE, is this basically just a SPI interfaced screen? I googled it and all I found was the chipset and 2x screens available on ebay.
Hi Mark,
The only one I found was the ILI9325 driver in the object exchange:
http://obex.parallax.com/object/282
I have no idea why it failed, I messed around with it for a while. I wired the screen to the propeller exactly the way the pins were defined in the tft-test-9325 program, and nothing happens other than the screen flickering a bit. So these screens I have are 8 bit 8080 which is identical to the driver, so I don't know? I am not sure how I should go about debugging this.
So your driver is ILI9325 and says its 320x240... however, the screens I have say they are ILI9325 but are 480x320. Is it possible to use different drivers e.g. ILI9325 on a ILI9341 or a ILI9488? What are the differences here?
Thanks again for all of the responses!
It looks like the drivers are to a specific size... so if I want to use any of the larger displays, I will need to create for example a ILI9488 driver. I'm wondering if I can take a pre-existing driver and modify it to be able to drive a different driver?
Google should also find the FTDI Data sheets & modules ?
EVE manages the LCD side, and takes higher level instructions from the MCU, so you are not rendering fonts & pushing pixels
I see they also now have a FT900 + EVE Board, which should have some good 'system examples'
https://www.indiegogo.com/projects/cleo-the-smart-tft-display-for-arduino#/
This module can even do this
The driver can be parametrized with the necessary data to identify the screen size and driver chip. Basically the driver needs to know how to initialize the display's driver chip and how to plot a pixel, once you know that you can do everything from drawing a line to rendering a font. UTFT does just that, I suggest to take a look at the source.
https://www.adafruit.com/datasheets/ILI9325.pdf
I am also comparing this with the library that macca shared a link for (its an arduino library in C).
Here is the init sequence in Mark_T's library:
init_data long $00E33008 long $00E70012 long $00EF1231 long $0A000001 long $00A40001 ' is this needed? long $0A070000 long $00010100 ' Source scan direction bit 0100 long $00020700 long $00031038 long $00040000 long $00080202 long $00090000 long $00070101 long $00170001 long $00100000 long $00110007 long $00120000 long $14130000 long $001017B0 long $32110137 long $3212001A long $00131800 long $3229002A long $00200000 long $00210000 long $00500000 long $005100EF long $00520000 long $0053013F long $00602700 ' gate scan direction bit 8000 long $00610001 long $006A0000 long $00900010 long $00920000 long $00930003 long $00950110 long $00970000 long $00980000 long $00300507 long $00310404 long $00320205 long $00350707 ' $00350002 long $00360000 ' $00360707 ' amp long $00370507 long $00380404 long $00390205 long $003c0707 ' $003c0700 long $003d0000 ' $003d0707 ' amp long $32070173 long 0And here is the init sequence in the arduino library:
So it looks like the format for Mark_T 's library is that digit 5 & 6 is the register address, and digit 1, 2, 3, and 4 is the setting (based on digits 1 through 8). I have no idea what digits 7 & 8 are used for.
For example look at this line from Mark_T 's library:
I also see something similar in the arduino library:
On page 50 of the datasheet, I see 01h as the register and its labeled as "Driver Output Control 1", but the setting numbers do not correlate with the datasheet? I dont see what 0100 is on the datasheet?
Also, in both libraries, I see E5, E3, E7, etc. register being used, but I don't see this in the documentation... what is this?
Where in the documentation does it say what the startup sequence is?
If its like you guys said, I can take the datasheet for the ILI9488 and look up this sequence, and modify the code and I should be good to go right? How do you know this sequence and the corresponding settings?
the initcode? Yes, that's right I googled for it, surprise surprise.
You have definitely had better luck than me haha.
EDIT:
I am still trying to figure out what the first 2 digits are of these longs? if the second 2 digits are the address, and the remaining 4 digits are the data, what are the first 2 digits? Mainly they are all 0, but there is some data in there periodically. I'm trying to compare it with other ILI9325 so I can make sense of it, but its not correlating. (and it looks like its never called in your program).
The fact that arg0 isn't refered to by name in PASM is irrelevant, that's not how things work
with parameters passed into cogs via PAR.
I think there is code buried there in the thread - able to play movies, a variety of fonts, little calculator programs etc. Lots of screenshots and a few movies in that thread.
We needed external ram to get a decent speed. Also one issue with many screens is they are resistive and you have to press quite hard to get a response. I think capacitive screens are starting to become available at a decent price.
Going back looking at that project, if I was designing it again, instead of discrete chips and a propeller, I think I'd redo it as a hybrid propeller/fpga design and put all the TTL chips inside a FPGA.
http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&productId=2215232&catalogId=10001&langId=-1&CID=FREQ&trk_msg=D6JI511S3694TF2OKQRUTU6FOO&trk_contact=VRHN5PE9SD55BATQAJFNUORNI8&utm_source=Listrak&utm_medium=Email&utm_term=Shield&utm_campaign=FREQPROD&utm_content=FREQPROD
ETA- It's from Adafruit I see. Out of stock though: https://www.adafruit.com/products/1947
lcd : "NH4_LcdDriver"
i2c : "PSB2_I2CDriver"
You can only get a few colors out of it with the Prop available ram, but I make it work. It is easy to define the graphic areas for touch. I like this free app found online called PixelFormer to generate bmp files, then Ray has some neat little apps(Prop 1 bit) to convert the bmp to .dat files that can be loaded direct into the Prop by adding the files to the DAT section. There are examples for all of this on his site. At some point you run out of ram if you are always loading .dat files, so the workaround is to transfer the dat file data to upper eeprom, then use fast I2C to read the graphic data and display it.
.
My preference is to conserve Prop resources and use a coprocessor that is already set-up for this sort of thing. The PicoMite (based on RPi Pico and derivatives) is dirt-cheap and so I use it as a front-end to the Prop and also as an I/O expander:
The manual can be found here
There is also a link to the source which might be a useful reference for the various display drivers.
Craig
This one runs the ArmMiteF4 firmware and here, it comes with the 16bit parallel display:
Craig
ILI9325 works quite well using 8bit