Announcement

Collapse
No announcement yet.

uOLED-160-G2 UART Speed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • uOLED-160-G2 UART Speed

    Hello all,

    I have a project that is using an iMX6 platform with embedded Linux to communicate serially to a uOLED-160-G2 via UART at 115200 baud. The display is being used as a status readout for a control module. As such, there will be about 11 lines of data that will need to be updated.

    ---------------------
    | A: XXXXXXX |
    | E: XXXXXXX |
    | T: XXXXXXX |
    | M: XXXXXXX |
    .......etc..............

    Now I have all of this working, however I can only get the display to refresh at about 3 Hz. After scoping the pins, this is a result of the module waiting for "ACKs" from the display. Is there any way to speed this up? Several other notes follow:
    • Programming the display directly really isn't an option as once these modules are deployed, getting to them for updates/changes/fixes can be near impossible
    • I am hoping to get closer to about 10 Hz for the display refresh
    • Currently I am writing the data to a line, moving the cursor, then writing the next line
    Any thoughts on how to get the display to respond faster or is there a way to write the display registers directly and bypass the whole "ACK" system.

    Thanks
    Last edited by mmorgan1361; 4 weeks ago.

  • #2
    The ACKs are sent when drawing of the text is complete, so ignoring them is not an option.

    The display itself can draw opaque text at about 404 characters per second using the internal font, the coms overhead at 115200 baud reduces that by about 3%

    So the main trick is to not (re)send anything that hasn't changed.

    The display can draw transparent text at about 1467 characters per second using the internal font, the coms overhead at 115200 baud reduces that by about 11%. The problem with that is that there is nothing overwriting the old text. You can 'fix' that using a filled rectangle before sending the transparent text. This will still be faster than opaque text, but it's appearance will be different. When you do this you wont have to pad out lines to clear the leftover text as it will all have been erased.

    Another thing to think about is why are you aiming for 10Hz? Can you read everything that fast?

    Mark

    Comment


    • #3
      This display will be attached to the main control module for a large satellite communications antenna that can move fairly quickly. The 10 Hz goal isn't so much a "I can read it that fast" thing as it is a "the customer is spending almost a million dollars on our product and >=10 Hz looks smoother/prettier" thing. So in reality it isn't technically a requirement but it would be nice. You propose an interesting idea that I will have to try out and see how it works. Thanks.

      Comment


      • #4
        I have a follow up question. Is there anyway to get a long string to wrap on the display or do you have to send a new command for each line?

        Comment


        • #5
          use a '\n' (0x0a) in the string, it will then place the following text on the next line, aligned with the last specified column, if txt_MoveCursor has been used, or the last left pixel, if gfx_MoveTo has been used.
          Mark

          Comment

          Working...
          X