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

Thread: fastest OLED display ?

  1. #1
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9

    fastest OLED display ?

    hello,
    i am working on a MIDI project with a Teensy 3.5 that requires each iteration of the main loop to be as fast as possible ( right now around 90 microsec for 1 loop ), because it's managing MIDI delays ( each entering note, sometimes 6 notes/bar at 300BPM, generates 4 delays ).
    i realized after trying to optimize different things that the main factor in slowing down the whole process is the displaying on the OLED screen ( through I2C because i had too few 'easily accessible' pins available for SPI )
    what would be the best option to minimize as much as possible the time necessary for a display ? i think i read once about OLED that had their own microcontroller to diminish the duty on the main controller.. is that an option ?
    Sylvain

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Hard to say.... Maybe depends on your requirements for the display and the like:

    That is if you are not doing anything fancy with the displays, you might for example look at some display that can be controlled by a serial port (UART). I have not used one in a long time, but I think there are some out there like: https://www.digole.com/index.php?productID=540

    Then you simply need to have code that outputs the display update information into the Serial port and allow the system to take care of the actual outputs...

    IF you were using SPI with something like ST7735, ST7789, ... Where for example we have versions of the software that allow you to update the display using DMA... Then those might work for you.

    I have never tried doing something similar for I2C...

  3. #3
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    thanks for the answer, Kurt,
    it gives me some good directions to explore.
    i dont need to do anything fancy, just display some information once in a while, for instance scrolling a menu
    Sylvain

  4. #4
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    357
    Simplest way to speed up the program is only updating the display a certain number of times per second instead of once per loop using a timer. So instead of updating your display 10,000 times a second you can do something reasonable, like 30 or 60 times depending on what you prefer.

  5. #5
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    Depending on your speed/power/etc. requirements, you could consider using something like a Teensy LC to control the display, and have the main teensy communicate to the LC what to write, and let the LC deal with menus, redisplay, etc. Of course you need to be able for the LC to say when it is getting backed up.

    As KurtE said, the Dig-ole displays can be configured to take i2c, spi, or UART (I only used UART when I used them). The display is smart, so you only send a few characters to do an update.

    I have to imagine anything wtih i2c is going to be slow. Dig-ole might be acceptable, because you won't try to update the whole screen.

    Note, in the past when I've switched between LCD and OLED displays, the OLED display ran much slower than the LCD display (this is for uncanny eyes where the processor is trying to update the display as fast as possible). While adding a pull-up resistor helped with corruption issues I was having, I still had to set the SPI bus slower for the Adafruit OLED displays than the Adafruit TFT LCD displays.

    I think with the latest TFT LCD displays (the 240x240 and 240x320) from Adafruit, they claim that the display now has a pixel addressable frame buffer, one technique would be to not erase the whole display each time, but just update the bits that changed from the last time.

  6. #6
    Not sure what you have tried in software or what hardware you have, but I have had good success speeding up a 2.4" Monochrome Oled 128x64 on SSD1309:
    1) I2C clock speed from 400khz to 2000khz
    2) Blanking lines of text on screen either by re-drawing the old text in black before printing the new line in white, or by drawing a Black box over the old text before drawing the new text in White. (to avoid using display.clearDisplay())
    3) Using pixel colour inversion to remove pixels from the display (to avoid using display.clearDisplay()) (my memory is hazy on this - I would need to look at some of my old code)
    4) Manually calling display.display() only when absolutely needed.
    5) Automatically calling display.display() using the metro library every 0.1 seconds when I need animations.

    There are possibly other tools/arguments in i2c_t3 library to speed things up but I did not need any more improvement so did not dig deeper.

  7. #7
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,166
    Quote Originally Posted by iniitu View Post
    ... because it's managing MIDI delays ( each entering note, sometimes 6 notes/bar at 300BPM, generates 4 delays )...
    I think we need to understand this part as I don't think it's a standard thing in MIDI so perhaps the solution is in managing updating the screen around what else you are doing.

  8. #8
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,166
    Quote Originally Posted by vjmuzik View Post
    Simplest way to speed up the program is only updating the display a certain number of times per second instead of once per loop using a timer. So instead of updating your display 10,000 times a second you can do something reasonable, like 30 or 60 times depending on what you prefer.
    If you are trying to update in the loop then that is the problem...

    The elapsedMillis() function is super easy to use to get something to run at set intervals.
    https://www.pjrc.com/teensy/td_timin...pedMillis.html

  9. #9
    Member
    Join Date
    Oct 2018
    Location
    London
    Posts
    55
    Sounds interesting. I think it all comes down to the numbers you are getting and the numbers you need. If the problem is that writing to the display takes too long, then you might be able to partition that process.

    In one of my projects, I write text / draw pixels to an off-screen buffer. When ready, I copy the pixel data via SPI to the display. I use an interruptible update function that passes a reference to a function to be called periodically. The callback function takes care of serial processing and button presses etc., so that the system remains responsive. The update function takes about 4200 micro-seconds to complete, but allows the system to remain responsive to within a millisecond.

    If you really need full processor attention for the midi work, perhaps you could upgrade the midi stuff to a T4 and have it pass the data to be displayed via Serial to another Teensy (3.5) that handles display and possibly some other tasks?

  10. #10
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    Quote Originally Posted by MichaelMeissner View Post
    you could consider using something like a Teensy LC to control the display, and have the main teensy communicate to the LC what to write, and let the LC deal with menus, redisplay, etc. .
    interesting option : could they simply communicate through the serial Rx/Tx ? i've never done that before. are there some important things to know before jumpint into this option ?

  11. #11
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    Quote Originally Posted by oddson View Post
    I think we need to understand this part as I don't think it's a standard thing in MIDI so perhaps the solution is in managing updating the screen around what else you are doing.
    it is standard MIDI, but pushed to its limit speed, so when a very small delay arises, it's audible, as some kind of glitch. the whole calculation and MIDI note on/off is fast, but updating the screen ( even a single digit ) is comparatively very slow.

  12. #12
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    Quote Originally Posted by oddson View Post

    The elapsedMillis() function is super easy to use to get something to run at set intervals.
    https://www.pjrc.com/teensy/td_timin...pedMillis.html
    good idea, indeed, i'll have a try.

  13. #13
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    Quote Originally Posted by microderm View Post
    If you really need full processor attention for the midi work, perhaps you could upgrade the midi stuff to a T4 and have it pass the data to be displayed via Serial to another Teensy (3.5) that handles display and possibly some other tasks?
    sounds right. T3.5 is fast enough for the MIDI calculations, when now hindered by printing on the screen, one main loop takes abou 70-80 microseconds.
    do you have any good examples on combining 2 Teensy ? as i asked above, simple serial communication ?

  14. #14
    Member
    Join Date
    Oct 2018
    Location
    London
    Posts
    55
    Quote Originally Posted by iniitu View Post
    do you have any good examples on combining 2 Teensy ? as i asked above, simple serial communication ?
    I don't. At least not yet. I think the way to go with inter processor communication is to use the CAN bus. That allows you to send small packets of data between chips at high speed with error detection.

    Speeds of up to 60MHz have been quoted in other threads: https://forum.pjrc.com/threads/56035...N-for-Teensy-4

    Just 2 pins are required, leaving the I2C, SPI and auto pins free for other work. The nice thing about serial communication in this way is that you don't have to wait for it to complete. You send to data and the hardware takes care of when its ready, the main processor being free to handle the midi work. I'm excited to look into this myself, but I have a few other things to take care of first.

  15. #15
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Note: I keep wondering if you might be able to simplify your stuff, if you could gain access to SPI on any of the three SPI busses of T3.5?
    If so you could probably easily use one of current displays like ili9341 or ST7735, ST7789 and a few others, which some of us have made versions of the libraries that allow you to setup a frame buffer (memory) backing for the display. So you can do all of your updates, which just update memory and then when it is appropriate, you can kick off a DMA operation to update the screen. However warning DMA on T3.5 on SPI1 and SPI2 is not as nice as it is on T3.6 or T4... But it could probably easily handle the stuff in the background...

  16. #16
    Junior Member
    Join Date
    Jun 2019
    Location
    Tournai, BE
    Posts
    9
    what about a completely different option : using a Nextion screen ? if i understand properly how it works, it should unload a lot of microcontroller work on the display...

  17. #17
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    Quote Originally Posted by iniitu View Post
    what about a completely different option : using a Nextion screen ? if i understand properly how it works, it should unload a lot of microcontroller work on the display...
    Gamedunio3 and Gamedunio3x are other options that have the separate microprocessor on the display, and you communicate over SPI (nextion uses a serial port)


    Dig-ole also has a set of screens with a microprocessor attached. They aren't as fancy as the Nextion or Gamedunio. With dig-ole, you can use either a serial UART, I2C, or SPI:


    While I've used gamedunio3 (briefly) and dig-ole, another entrant is Visic, that I have never used:


    However, note I believe both Nextion and Gamedunio use TFT LCDs and not OLED displays. There are various differences between the various display technologies (angle of view, brightness, power consumption, color representation, refresh rate, etc.).

    In my limited experience comparing 128x128 TFT displays to 128x128 OLED displays, I could run the TFT displays with a faster SPI bus speed than OLED. But the OLED display looked a lot better than TFT. Finding larger OLED displays might be tricky, as most of the larger OLED displays are swallowed up by cell phone manufacturers.

  18. #18
    Junior Member
    Join Date
    Sep 2017
    Location
    Pistoia, Italy
    Posts
    8
    Quote Originally Posted by iniitu View Post
    what would be the best option to minimize as much as possible the time necessary for a display ? i think i read once about OLED that had their own microcontroller to diminish the duty on the main controller.. is that an option ?
    Sylvain
    Best would be to update the display only if there is free CPU time. Now it takes to look at the code to find out, where and when in the loop this could be.
    Think of the loop as a "frame". I've made a controller with T3.6 that reads several sensors each frame and can still update a SSD1306 OLED without any noticable intereference to a 2k frame rate, just because updates to the display are scheduled on a buffer and only then sorted out and written to the display, if there is cpu time available. This requires adding some scheduling logic to the code, avoiding any locking situations like "while (waitforinput)", etc ,by using polling and state switching.

  19. #19
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,428
    Again we have spi displays that support doing their updates in background using dma.

    Maybe at some point might try to do same for I2C display, if it would make sense...

    I think at this point, to give any relevant recommendations you may need to give more specific information on you sketch, like what display you are using and what library, and actual flow of the code...

    Also what things you have now tried.

Posting Permissions

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