Shop OBEX P1 Docs P2 Docs Learn Events
Touchscreens and the propeller - SPI, 8bit parallel, 16bit parallel, 8080 or 6800 - Whats realistic? — Parallax Forums

Touchscreens and the propeller - SPI, 8bit parallel, 16bit parallel, 8080 or 6800 - Whats realistic?

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!

Comments

  • I've only bothered to use the ones with internal display RAM as the Prop doesn't have any to spare nor does it have I/O to spare as address/data bus unless that's all you use it for. So this means SPI but if a pixel requires a full 24-bit RGB value this means a display update isn't as fast as you may like it. However SPI requires only 3 pins really, the clock, data, and select. There are Tachyon drivers for a 3.5" touchscreen etc. 4D is $$$.

    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? :)
  • jmgjmg Posts: 15,140
    Mahonroy wrote: »
    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?).

    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.

  • ErNaErNa Posts: 1,738
    you can find examples of tft touchscreens on the pages of rayman rayslogic.com/Manta_Full_Front_Small.jpg. An overview: rayslogic.com/Propeller/Products/Products.htmThe interface is documented here: rayslogic.com/Propeller/Products/PSB/PSB.htm. but this product is discontinued
  • I have used one of these displays http://www.ebay.it/itm/Display-Grafico-3-2-TFT-Touch-Screen-SD-Card-Arduino-Pic-Atmega-AVR-LCD-320x240-/181978440978 with the propeller, it uses the SSD1289 chipset with a 16 bit interface, it requires a lot of pins (26 if you want the full features with the SD card and share the SPI interface), not much left for other things.

    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.
  • Don MDon M Posts: 1,647
    I have used the 4D displays. While the price is more it does save a ton of time in programming which also comes at a cost and also preserves much of the Propeller assets.
  • The reason there are so few TFT drivers for the Prop is that it can drive a VGA screen anyway so people
    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)
  • jmg wrote: »
    Mahonroy wrote: »
    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?).

    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.

    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.
    Mark_T wrote: »
    The reason there are so few TFT drivers for the Prop is that it can drive a VGA screen anyway so people
    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)

    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!
  • How are you guys creating these drivers by the way? I saw macca mentioned he took some other already made librarys for arduino and ported them into a SPIN library.

    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?
  • jmgjmg Posts: 15,140
    Mahonroy wrote: »
    jmg wrote: »
    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

    .... 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?\
    Yes.
    Mahonroy wrote: »
    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.
    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 :)
    kifnqyijst0rnlb84kuo.png

  • Mahonroy wrote: »
    How are you guys creating these drivers by the way? I saw macca mentioned he took some other already made librarys for arduino and ported them into a SPIN library.

    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?

    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.
  • Beau SchwabeBeau Schwabe Posts: 6,544
    edited 2016-02-27 02:13
    Yes, touch screens can be costly, but most of the price difference is whether they are a considered "intelligent" screens or simply just a "monitor". There are other factors to consider as far as durability and what environment they will be used. I wrote an object awhile back in the OBEX for the 3.5" touch screen from 4D Systems, but it seems to have vanished. ... Honestly, not to detour away from the Propeller or any other processor, but using a processor to control a 4D Display is redundant in my opinion. The 4D displays have a very capable processor within them that is native to the display. The code is very much like BASIC, but also has very similar characteristics of SPIN. It's one of many programming hats I happen to wear at work.... Even, today I programmed and calibrated a batch of 7" displays (see image) that will be used in our forensic machines. The machines that the displays will go into range in cost from $5k to $100k, so a $200 display doesn't have a huge impact.

    TS.JPG
  • Ok so I found this datasheet on the ILI9325. I am trying to correlate whats in the datasheet with what is in Mark_T 's library. Here is the datasheet:
    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    0
    


    And here is the init sequence in the arduino library:
    	LCD_Write_COM_DATA(0xE5, 0x78F0); // set SRAM internal timing
    	LCD_Write_COM_DATA(0x01, 0x0100); // set Driver Output Control  
    	LCD_Write_COM_DATA(0x02, 0x0700); // set 1 line inversion  
    	LCD_Write_COM_DATA(0x03, 0x1030); // set GRAM write direction and BGR=1.  
    	LCD_Write_COM_DATA(0x04, 0x0000); // Resize register  
    	LCD_Write_COM_DATA(0x08, 0x0207); // set the back porch and front porch  
    	LCD_Write_COM_DATA(0x09, 0x0000); // set non-display area refresh cycle ISC[3:0]  
    	LCD_Write_COM_DATA(0x0A, 0x0000); // FMARK function  
    	LCD_Write_COM_DATA(0x0C, 0x0000); // RGB interface setting  
    	LCD_Write_COM_DATA(0x0D, 0x0000); // Frame marker Position  
    	LCD_Write_COM_DATA(0x0F, 0x0000); // RGB interface polarity  
    	//*************Power On sequence ****************//  
    	LCD_Write_COM_DATA(0x10, 0x0000); // SAP, BT[3:0], AP, DSTB, SLP, STB  
    	LCD_Write_COM_DATA(0x11, 0x0007); // DC1[2:0], DC0[2:0], VC[2:0]  
    	LCD_Write_COM_DATA(0x12, 0x0000); // VREG1OUT voltage  
    	LCD_Write_COM_DATA(0x13, 0x0000); // VDV[4:0] for VCOM amplitude  
    	LCD_Write_COM_DATA(0x07, 0x0001);  
    	delay(200); // Dis-charge capacitor power voltage  
    	LCD_Write_COM_DATA(0x10, 0x1090); // SAP, BT[3:0], AP, DSTB, SLP, STB  
    	LCD_Write_COM_DATA(0x11, 0x0227); // Set DC1[2:0], DC0[2:0], VC[2:0]  
    	delay(50); // Delay 50ms  
    	LCD_Write_COM_DATA(0x12, 0x001F); // 0012  
    	delay(50); // Delay 50ms  
    	LCD_Write_COM_DATA(0x13, 0x1500); // VDV[4:0] for VCOM amplitude  
    	LCD_Write_COM_DATA(0x29, 0x0027); // 04  VCM[5:0] for VCOMH  
    	LCD_Write_COM_DATA(0x2B, 0x000D); // Set Frame Rate  
    	delay(50); // Delay 50ms  
    	LCD_Write_COM_DATA(0x20, 0x0000); // GRAM horizontal Address  
    	LCD_Write_COM_DATA(0x21, 0x0000); // GRAM Vertical Address  
    	// ----------- Adjust the Gamma Curve ----------//  
    	LCD_Write_COM_DATA(0x30, 0x0000);  
    	LCD_Write_COM_DATA(0x31, 0x0707);  
    	LCD_Write_COM_DATA(0x32, 0x0307);  
    	LCD_Write_COM_DATA(0x35, 0x0200);  
    	LCD_Write_COM_DATA(0x36, 0x0008);  
    	LCD_Write_COM_DATA(0x37, 0x0004);  
    	LCD_Write_COM_DATA(0x38, 0x0000);  
    	LCD_Write_COM_DATA(0x39, 0x0707);  
    	LCD_Write_COM_DATA(0x3C, 0x0002);  
    	LCD_Write_COM_DATA(0x3D, 0x1D04);  
    	//------------------ Set GRAM area ---------------//  
    	LCD_Write_COM_DATA(0x50, 0x0000); // Horizontal GRAM Start Address  
    	LCD_Write_COM_DATA(0x51, 0x00EF); // Horizontal GRAM End Address  
    	LCD_Write_COM_DATA(0x52, 0x0000); // Vertical GRAM Start Address  
    	LCD_Write_COM_DATA(0x53, 0x013F); // Vertical GRAM Start Address  
    	LCD_Write_COM_DATA(0x60, 0xA700); // Gate Scan Line  
    	LCD_Write_COM_DATA(0x61, 0x0001); // NDL,VLE, REV   
    	LCD_Write_COM_DATA(0x6A, 0x0000); // set scrolling line  
    	//-------------- Partial Display Control ---------//  
    	LCD_Write_COM_DATA(0x80, 0x0000);  
    	LCD_Write_COM_DATA(0x81, 0x0000);  
    	LCD_Write_COM_DATA(0x82, 0x0000);  
    	LCD_Write_COM_DATA(0x83, 0x0000);  
    	LCD_Write_COM_DATA(0x84, 0x0000);  
    	LCD_Write_COM_DATA(0x85, 0x0000);  
    	//-------------- Panel Control -------------------//  
    	LCD_Write_COM_DATA(0x90, 0x0010);  
    	LCD_Write_COM_DATA(0x92, 0x0600);  
    	LCD_Write_COM_DATA(0x07, 0x0133); // 262K color and display ON    
    

    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:
    long    $00010100  ' Source scan direction bit 0100
    

    I also see something similar in the arduino library:
    LCD_Write_COM_DATA(0x01, 0x0100); // set Driver Output Control
    

    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?
  • Ok so in Mark_T's library it looks like the "init_data" sequence is never actually called in the program... ever? Can this be correct?
  • I'd have to read the code to figure it out, its a while back now, but init_data definitely is used:
    arg0 := @init_data
    
  • The E3, E7 and EF registers - no idea, they are undocumented. How do you think I determined
    the initcode? Yes, that's right I googled for it, surprise surprise.
  • MahonroyMahonroy Posts: 175
    edited 2016-02-28 18:36
    @Mark_T , I see that arg0 gets set to a pointer to init_data, but its never used. If you search for "arg0" throughout the entire program, arg0 only gets set to things, its never actually used.

    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).
  • I'm thinking if someone could help me explain a few things here I might be good enough to get started on this. I am going over the code over and over and there are some things here that are not making sense to me.
  • Mahonroy wrote: »
    @Mark_T , I see that arg0 gets set to a pointer to init_data, but its never used. If you search for "arg0" throughout the entire program, arg0 only gets set to things, its never actually used.

    You have definitely had better luck than me haha.

    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2016-03-13 22:48
    We had some fun a few years back with touchscreens http://forums.parallax.com/discussion/137266/propeller-gui-touchscreen-and-full-color-display/p1

    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.
  • I use the Newhaven 4.3 Cap Touch. It is almost $60 but is the best looking screen IMO. I use modified versions of Rayslogic.com drivers.

    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.
  • celtic3celtic3 Posts: 1
    edited 2023-12-27 07:04

    .

  • 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

Sign In or Register to comment.