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

Thread: Display refresh Latency

  1. #1
    Junior Member
    Join Date
    Mar 2020
    Location
    Italy
    Posts
    16

    Display refresh Latency

    Hi,
    i'm working with Teensy 4.0 connected via USB to my PC. I'm newbie in firmware develop, sorry if it's a stupid question.

    PC and Teensy are communicating correctly and the speed of communication is good.
    I decide to connect a little display (128x64) via i2c using <Adafruit_GFX.h> <Adafruit_SSD1306.h> driver.

    After this I noticed a big slowdown in the communication. So I would to understand if there is a best practice to manage a display refresh in order to mantein a good serial communication speed.


    This is the easy code that I'm testing

    //Setup
    if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) { // Address 0x3C for 128x64
    Serial.println(F("SSD1306 allocation failed"));
    for(;; // Don't proceed, loop forever
    }



    //LOOP
    display.clearDisplay(); //Pulisce il buffer da inviare al display
    display.setCursor(0,0); //Imposta la posizione del cursore (Larghezza,Altezza)
    display.println("BERNIE"); //Stringa da visualizzare
    int gain = gain_rotary.getValue();
    display.print("GAIN: ");
    display.println(gain);
    display.display();



    Is there a best practice to manage a display refresh? dedicated thread? Or other solution? Asynch method!?

    I just think to move on a SPI Display to increase the communication speed.


    Andre

  2. #2
    Junior Member
    Join Date
    May 2020
    Posts
    14
    afaik. i2c can also used at higher speeds ... that might improve your display speed:
    https://www.arduino.cc/en/Reference/WireSetClock

    but SPI will always be way faster...

  3. #3
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,583
    Using 1MHz I2C speed, a 50% ping-pong buffer and DMA (with a self-tuned version of the i2c_t3 library and hand written rendering code instead of using a gfx lib with overhead), I could get a refresh rate of a little more than 60fps on a 128x64 OLED with a Teensy LC. Thus, it should also be possible with a Teensy 4. But since your eyes are not infinitively speedy and will not be able to read so many updates of the gain value, I think that you should rather use a 100-200ms interval timer to update the display at 5-10fps (which is sufficient) outside the loop(), so that the latter may turn more often for other tasks.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,828
    Quote Originally Posted by Theremingenieur View Post
    Using 1MHz I2C speed, a 50% ping-pong buffer and DMA (with a self-tuned version of the i2c_t3 library and hand written rendering code instead of using a gfx lib with overhead), I could get a refresh rate of a little more than 60fps on a 128x64 OLED with a Teensy LC. Thus, it should also be possible with a Teensy 4. But since your eyes are not infinitively speedy and will not be able to read so many updates of the gain value, I think that you should rather use a 100-200ms interval timer to update the display at 5-10fps (which is sufficient) outside the loop(), so that the latter may turn more often for other tasks.
    Sadly i2c_t3 not updated yet to work on T_4.x's

    The adaF SSD1306 does have a param for i2c speed to be used though - that makes a difference. Not sure if Wire max was pushed past 2 MHz? But it goes higher than the default speed ... but is still blocking until done.

    @mjs513 had new clock values in beta that pushed the high end on Wire and worked at 3-4 Mhz - but it pushed up the min speed available and that never got resolved/pulled in IIRC.

  5. #5
    Junior Member
    Join Date
    May 2014
    Posts
    17
    My post in the other forum details this. https://forum.pjrc.com/threads/61060...light=I2c+oled

    Basically I am seeing 1000 times difference in how long the display update call takes to return between 400KHz and 1MHz speeds for some unknown reason.

  6. #6
    Junior Member
    Join Date
    Jan 2017
    Posts
    19
    I've also encountered this. Not in terms of 'my eyes seeing it', but some other things not running as fast as they should. I'm using it together with audio output and that is more prone to latency that is noticeable. What I concluded was that you should try to avoid the 'clear display' function (takes over 20ms) and just print stuff to the screen when needed (i.e. when something needs to change on the display).

Posting Permissions

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