Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 2 of 2

Thread: The right approach of driving LCD's in time critical Applications.

  1. #1
    Member Van's Avatar
    Join Date
    Mar 2018
    Location
    Dresden, Germany
    Posts
    35

    The right approach of driving LCD's in time critical Applications.

    Hi guys,

    this is more general question.
    I'm currently developing sort of MIDI sequencer using the teensy 3.1.
    I've got an ILI9341 TFT using the ILI9341_t3 lib.
    Yes, its much faster then other libs and TFT drivers out there, but still got flickering and the transitions and overall look are not so smooth like I wanted it to be.
    So, what are the right approaches to drive an display? Update only small portions? Use an dedicated graphic chip(another teensy )? some smart and clever multiplexing? or is this simply too much for an small teensy and gpu's are the only solution?
    How is this done f.e. in the industry?
    Any idea or knowledge about this topic would be a great help!

    cheers , Van

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    The problem is most likely not the teeny, but the technique of how the display is used.
    Flickering can only be reliably prevented by a buffer and/or synchronization with the screen refresh.
    The display has no buffer, and syncing is not possible. Double or triple buffering are normal ways to prevent flickering..but here: no chance.

    But you can try to minimize the flickering, for example by:


    - update only changed display contents
    - you do not delete the area before updating, of course, but simply overwrite it (otherwise it would even be two updates!)

    With a bit luck and clever programming, you can make the flickering almost invisible.

Posting Permissions

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