Announcement

Collapse
No announcement yet.

µOLED-160-G1(SGC) - Scree Copy Paste for console emulation

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

  • µOLED-160-G1(SGC) - Scree Copy Paste for console emulation

    I am working on a commercial product of which we have at the moment chosen to use the uOLED-160-G1

    At boot-up of the device this is a console like display, essentially lots of text that comes in row by row to show the user the device status.


    My original method was to just clear the screen and send all of the text for the screen. This was horrible as it introduced some bad flicker as the screen chooses to immediately update the display and has no way of turning drawing on or off (please correct me if I am wrong)


    So instead I have chosen what should be the faster method from both the micro and the screen side of things.

    I do a Screen Copy Paste to shift all the text up by one line, I draw a black box over the location of the original bottom line of text, then write a new line of text.

    How ever this seems to produce a Wiping effect across the whole screen, which takes a good couple of seconds.

    I have uploaded a video that you can stream from here (19.4MB) that shows the issue

    https://www.dropbox.com/s/nnahrwuil92twxm/2012-12-19%2017.13.55.mp4

    The documentation I have specifies "This is a very powerful feature for animating objects, smooth scrolling, implementing a windowing system". How ever with the kind of refresh rate I am getting, I doubt that statement very much.

    I copy the text like so..
    0x63, 0x00, 0x08, 0x00, 0x00, 0x9F, 0x70

    Then draw the box...
    0x72, 0x00, 0x68, 0x9F, 0x70, 0x00, 0x00

    And then draw the text with the 0x73 command.

    Any ideas on how I can make this faster? is there a way to buffer up a redraw of the screen?

    Regards

    Paul

  • #2


    'Modern' displays are not designed for traditional scrolling type consoles (ever seen a windows console 'emulator' that goes much faster than 9600 baud?)

    Thus when you try to emulate one it appears very slow.

    It's because each pixel must be addressed, read, addressed and then written, there is no internal scroll function either hardware of software based.

    So what you are doing is about the fasted way it can be done 'that way'. Actually it looks very much like my recollections of the ADM3A's scrolling

    Maybe move all lines up except the last (visible) one and then erase it, it might have a better look.

    Otherwise a complete redesign might help (i.e. updating parts of the screen at a time, not the whole screen)
    Mark

    Comment


    • #3


      Ok thats fair enough, I may revert back to my old method of just redrawing the whole screen as that did appear faster.

      I could also restrict the console/log to only 5 lines so the effect is less dramatic.


      Thank you for your response.

      Comment

      Working...
      X