Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 51 to 75 of 77

Thread: How about a 3.5 inch 480x320 tochscreen display?

  1. #51
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    If the day had 48hours I'd really like to try one of these RGB to HDMI or data-to HDMI chips on a T3.6
    But that's impossible at the moment. Maybe next year.. i guess at least RGB to HDMI is somehow possible on the 3.6

  2. #52
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    Just taking a peak at the datasheet for the ILI9488, looks like it has Backlight control built in along with a PWM_OUT pin to drive the backlight LED. That would save us from needing a pin to PWM the Backlight. We would just have to add a fet to the breakout.

  3. #53
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    @Paul, any news ?

  4. #54
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,512
    Nope, sorry, I put this on hold for a while. Too many other urgent projects....

  5. #55
    You can also consider the ili9481 displays I am able to control the display with a Teensy 3.5 in 16 bit mode at 65k colors(RGB565). with very fast screen updates.



    I able to write all 16 IO pins:

    Code:
    void ILI9481_t3::setIO(uint16_t data)
    {
        // lower 8 bits
        GPIOD_PCOR = 0xFF;
        GPIOD_PSOR = data & 0xFF; // DB 7, 6, 5, 4, 3, 2, 1, 0
    
        // upper 8 bits
        byte a = data >> 8;
        (a & 0x80) ? (CORE_PIN31_PORTSET = CORE_PIN31_BITMASK) : (CORE_PIN31_PORTCLEAR = CORE_PIN31_BITMASK); // DB_15
        (a & 0x40) ? (CORE_PIN32_PORTSET = CORE_PIN32_BITMASK) : (CORE_PIN32_PORTCLEAR = CORE_PIN32_BITMASK); // DB_14
        (a & 0x20) ? (CORE_PIN29_PORTSET = CORE_PIN29_BITMASK) : (CORE_PIN29_PORTCLEAR = CORE_PIN29_BITMASK); // DB_13
        (a & 0x10) ? (CORE_PIN30_PORTSET = CORE_PIN30_BITMASK) : (CORE_PIN30_PORTCLEAR = CORE_PIN30_BITMASK); // DB_12
        GPIOA_PCOR = 0x3C000;
        GPIOA_PSOR = (a & 0xF) << 14; // DB 11, 10, 9 , 8;
    }

    I am still trying to make it work in 262k mode though.
    Last edited by roomtek; 07-28-2017 at 09:21 PM. Reason: code update

  6. #56
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,218
    Waking this thread until a better answer … the T4 Beta thread shows interest in a larger display - the ili9488 is functional on T_3.6 and T4 - but 18 bit color is too many bytes for fast SPI updates - and the with a couple different 9488's under test - some seem to have issues. Touch XPT2036 works - but Display I got like Paul's {p#1470&1473} shows MISO not tristated - so reading Touch means cutting/not connecting the TFT's MISO then it works with write only display. Most recent notes cluttering T4 thread are here XX

    The ILI9488's so far all want 18 bit color - if one were 'wired' to accept 8 and/or 16 bit that would drop the RAM/SPI hit - the PDF says it can be selected - but it seems there must be hardware bits set as well that preclude attempts to use 16 bit mode. So a better package is needed - 3.5" would be nice - higher res than 240x320 optional as 320x480 pixels are higher DPI and more numerous. Came across one that "works" on rPi - except it is missing the D/C pin and the PDF didn't show me commands/data working without that control bit?

  7. #57
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,584
    I guess that it it’s time to think about a “Teensy G”, a graphics (sub-)processor which would communicate with whatever “main” Teensy through a simple command set, similar to the gfx libraries and which would then care about rendering, frame buffering and efficient high-speed communication with the TFT, taking all that load away from the principal MCU.
    For 320*480, 24bit RGB (thinking for the future) and 8 bit alpha, one frame buffer would take 614400 bits of RAM...

  8. #58
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,833
    Some time ago I collected links of various displays, including displays that have a smart processor on them. Some are a little on the pricey side.

    Vizic Technologies


    Newhaven Display


    Gamedunio


    Raspberry Pi controlled display
    One option might be to use the Raspberry Pi as the driver. Unfortunately it can at times be hard to source the cheaper, smaller, less power hungry Pi Zero W in quantity (usually it is $5-10 for one at my local Microcenter, but the price goes up if you buy more than one, and in some places only quantity 1 orders are allowed). Lets see:
    • Rasberry Pi Zero W: $10
    • 32GB micro SD card: $4
    • ebay 3.5" resistive touch HDMI 480x320: $20



    I suspect the Newhaven displays are probably the best for interfacing with Teensy.

  9. #59
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    The T4 already has a GPU with a fast interface. Paul mentioned a larger variant... my hope is, it has the required pins, then.. even if the GPU is not very powerful - the interface alone would be very helpful.

  10. #60
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,833
    Quote Originally Posted by Frank B View Post
    The T4 already has a GPU with a fast interface. Paul mentioned a larger variant... my hope is, it has the required pins, then.. even if the GPU is not very powerful - the interface alone would be very helpful.
    Though I imagine there you want to get into having the ability to share memory with the display and/or use more pins in parallel to get around the SPI knothole of serially transferring 1 bit at a time.

  11. #61
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,584
    Without having looked it up, I’d guess that in the meantime, a few TFT controllers with QSPI interface should be available, thus making the bottleneck four times wider...

  12. #62
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    it is a parallel interface, configurable.

  13. #63
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Reviving this for the sake of info from Paul

    I'm ordering the 3.5" ILI9488 display from buydisplay.com
    I'll connect it to an FPC breakout board for testing. I know there are some additional components required such as the driver transistor for the backlight, but I see other components on the 3.2 adapter you built in 2017 and would be interested in seeing a schematic if possible

  14. #64
    Recently in the team we managed to install a 3.5 "FT813 HD screen, in the Teensy 4. After many hours of unveiling, we were able to link the Greiman SdFat beta library to the James 23X gameduino library, with the idea of ​​using the interface SDIO, as a means to store images, jpg or png, assets, cell arrangements and even videos in avi format with audio.The screen specifically is this: NHD-3.5-320240FT-CSXN-CTP, without using an external power source.

    They are somewhat expensive screens, however they have good resolution, are visible under sunlight, moderate consumption and have a 20-pin head that facilitates installation on a PCB. The SPI 1 bus can be configured up to 45 MHz!, in order to activate the display interface.

    Esta es la librerķa adaptada, incluye algunos ejemplos: https://github.com/FT81xMania/GD23ZUTX

  15. #65
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Quote Originally Posted by TFTLCDCyg View Post
    Recently in the team we managed to install a 3.5 "FT813 HD screen, in the Teensy 4. After many hours of unveiling, we were able to link the Greiman SdFat beta library to the James 23X gameduino library, with the idea of ​​using the interface SDIO, as a means to store images, jpg or png, assets, cell arrangements and even videos in avi format with audio.The screen specifically is this: NHD-3.5-320240FT-CSXN-CTP, without using an external power source.

    They are somewhat expensive screens, however they have good resolution, are visible under sunlight, moderate consumption and have a 20-pin head that facilitates installation on a PCB. The SPI 1 bus can be configured up to 45 MHz!, in order to activate the display interface.

    Esta es la librerķa adaptada, incluye algunos ejemplos: https://github.com/FT81xMania/GD23ZUTX
    It may have the upside of more GPU power (haven't looked into the details), but at 78 USD and a resolution of 320x240 it's not a relevant option, at least for my project.

  16. #66

    Tft display w 5 points capacitive screens

    Would like to ask the same. @paul, thank you for your consideration


    Quote Originally Posted by Rezo View Post
    Reviving this for the sake of info from Paul

    I'm ordering the 3.5" ILI9488 display from buydisplay.com
    I'll connect it to an FPC breakout board for testing. I know there are some additional components required such as the driver transistor for the backlight, but I see other components on the 3.2 adapter you built in 2017 and would be interested in seeing a schematic if possible

  17. #67
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Funny enough, I eventually used an Adafruite HX8357 display for my first prototype, but placed an order for the ILI9488 last week and it's arriving later on today!
    I'm looking forward to getting it to work - I'm following this schematic for wiring (Note the pin order is opposite on the buydisplay FPC) - there are minor differences, but the schematics seems pretty inline with the ILI9488 datasheed pin assignment

  18. #68
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,453
    @Rezo - The one of theirs I have I think is one of these: https://www.buydisplay.com/lcd-3-5-i...breakout-board
    Don't remember if it has touch on it or not... If I remember correctly I purchased it through EBAY.

    Personally I probably prefer the HX8357 over the ILI9488, at least if you are doing communications over SPI (4 pin), as if I remember correctly the HX8357 you can do 16 bit color writes to the screen. Where as the ILI9488 you do 18 bit colors (actually 24 bits) So things like fillScreen take 1.5 times as long.

    Also with things like Frame buffer, I did not want to go through all of the work to somehow make the frame buffer to work with 24 bits and DMA, so instead by default it stores as the same 16 bits as the colors we use and then when the screen is updated, it converts the 16 bits to 24 bits to output. If the operation is DMA than, this is done a buffer at a time, first at the start up to fill the first buffers and start up the DMA operation, and then it triggers an ISR when a buffer output is complete, and it converts the next portion of the frame into the buffer... So system overhead there as well.

    BUT I do have an option for T4.1 with external memory, where you can setup the Frame buffer for 32 bit pixels. Only 24 bits are used, conversation done when stored and DMA is setup to transfer 32 bits to the SPI.TDR register and SPI configured to transfer 24 bits out... So maybe wasted memory but no system overhead to output over DMA... I keep wanting to cleanup some of this code to allow it be configured by sketch instead of header file options... But I have not done so.

  19. #69
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Quote Originally Posted by KurtE View Post
    @Rezo - The one of theirs I have I think is one of these: https://www.buydisplay.com/lcd-3-5-i...breakout-board
    Don't remember if it has touch on it or not... If I remember correctly I purchased it through EBAY.

    Personally I probably prefer the HX8357 over the ILI9488, at least if you are doing communications over SPI (4 pin), as if I remember correctly the HX8357 you can do 16 bit color writes to the screen. Where as the ILI9488 you do 18 bit colors (actually 24 bits) So things like fillScreen take 1.5 times as long.

    Also with things like Frame buffer, I did not want to go through all of the work to somehow make the frame buffer to work with 24 bits and DMA, so instead by default it stores as the same 16 bits as the colors we use and then when the screen is updated, it converts the 16 bits to 24 bits to output. If the operation is DMA than, this is done a buffer at a time, first at the start up to fill the first buffers and start up the DMA operation, and then it triggers an ISR when a buffer output is complete, and it converts the next portion of the frame into the buffer... So system overhead there as well.

    BUT I do have an option for T4.1 with external memory, where you can setup the Frame buffer for 32 bit pixels. Only 24 bits are used, conversation done when stored and DMA is setup to transfer 32 bits to the SPI.TDR register and SPI configured to transfer 24 bits out... So maybe wasted memory but no system overhead to output over DMA... I keep wanting to cleanup some of this code to allow it be configured by sketch instead of header file options... But I have not done so.

    I'm willing to try the 9488 just because it's a third of the price, has capacitive touch and they can be ordered as bare displays and not as a shield (I've designed PCBs to surface mount the T4.1 behind the display using SMD header pins to keep a low profile)
    I am using the T4 with the HX display but I purchased two T4.1's with the PSRAM chips for the option of a bigger frame buffer for the 9488 - has the library been updated to utilize the extra RAM or is it something still being worked on?

  20. #70
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,453
    Quote Originally Posted by Rezo View Post
    has the library been updated to utilize the extra RAM or is it something still being worked on?
    Yes and someday yes

    That is today, with the library, if you look at the header file you will see:
    Code:
    //#define ENABLE_EXT_DMA_UPDATES  // This is only valid for those T4.1 which have external memory.
    If you uncomment it, then this option is enabled on ALL t4.1s... So it will only work on those T4.1 that have the memory. I HATE these types of options.

    Over time, I would like to have an option or sub-class or ??? where you can define if you wish the TFT to use 1 byte 2 bytes or 4 bytes per pixel in the Frame buffer.
    Today with T3.5/T3.6, 1 byte is the only option and we have a pallet(Palate) for those of us who are spelling challenged. For T4/T4.1 without extra memory, you can do 1 or 2... With ones with extra memory you have all 3 options.

    I can totally understand the price difference, but just wanted to give you a heads up on the speed differences.

  21. #71
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Quote Originally Posted by KurtE View Post

    That is today, with the library, if you look at the header file you will see:
    Code:
    //#define ENABLE_EXT_DMA_UPDATES  // This is only valid for those T4.1 which have external memory.
    If you uncomment it, then this option is enabled on ALL t4.1s... So it will only work on those T4.1 that have the memory. I HATE these types of options.
    I understand you - if you can get it to be configurable in the constructor it will make config much easier for the user, but at the moment I think people are competent enough to uncomment that line

    Quote Originally Posted by KurtE View Post
    Over time, I would like to have an option or sub-class or ??? where you can define if you wish the TFT to use 1 byte 2 bytes or 4 bytes per pixel in the Frame buffer.
    Today with T3.5/T3.6, 1 byte is the only option and we have a pallet(Palate) for those of us who are spelling challenged. For T4/T4.1 without extra memory, you can do 1 or 2... With ones with extra memory you have all 3 options.

    I can totally understand the price difference, but just wanted to give you a heads up on the speed differences.
    So even with the extra RAM and writing more bits at a time its till slower? I guess the only bottleneck is the SPI bus after all. But, I have seen someone here running the 9488 at 80Mhz! I can get the HX to run at 32Mhz at most and it looks exactly the same as it does at 26Mhz. Anything higher, it stops displaying.

    Perhaps one of these days someone will be able to get one of these displays running using 16 bit parallel - I guess that will speed things up, and can easily be done with the available digital outputs on the 4.1
    I would really love to see a true 24 bit display running without to many peripherals around it, but I don't see that happening anytime soon.
    For now, 4 wire SPI will suffice!

  22. #72

  23. #73
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    Quote Originally Posted by alfa66 View Post
    Yes, but without the GPU in a perfect world the Teensy would handle that, but the same TFT, yes.

    I got to soldering the FPC connector to an Adafruit breakout board - my first time soldering an SMD component and at such a small pitch (0.5mm) - quite proud of myself!
    Click image for larger version. 

Name:	IMG_4166.jpg 
Views:	11 
Size:	139.6 KB 
ID:	20885

    And I also created a pinout for the Adafruit/ILI9488 as the pin order is backwards on the ILI9488
    The even/odd consecutive-opposite numbers was quite confusing TBH but I eventually got it done without a glitch
    Click image for larger version. 

Name:	ILI9488_BREAKOUT_PINS.jpg 
Views:	16 
Size:	158.1 KB 
ID:	20886

    Will continue tomorrow and hopefully update that it is working

  24. #74
    Senior Member
    Join Date
    Oct 2019
    Posts
    146
    A quick update from my side:

    I got the display to work, but it's quite unstable. At first, the pads/pins would start crackling and smoking as soon as I'd power it up, and this happened only on adjacent 3v3/GND pins. This would also cause the backlight to flicker as there seems to be excessive current draw from what I suspect are micro solder shorts on the FPC connector.

    So I grabbed the other FPC breakout board I had along with a new connector and it seems to be working "Okay" yet still not too stable. I was able to run the demosuace sketch and confirm that the display does in fact work.

    I think the best way to continue testing this is to fabricate some PCBs with a T4/4.1 socket and an FPC to get it to work properly and stable as I have way too many jumper wires and I'm not even terminating the unused pins as I should be doing.

    Anyways, a fair success as far as I see it!

  25. #75
    Senior Member
    Join Date
    Jul 2020
    Posts
    332
    Quote Originally Posted by Rezo View Post
    what I suspect are micro solder shorts on the FPC connector.
    My experience suggests once down to 0.5mm pitch you need to use stencil/solder-paste/oven for reliable results,
    you need that strictly rationed amount of solder per pad.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •