• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 1350 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

4BPP OLED Graphics Driver

Ted Mawson
Intellectual 360 points

Other Parts Discussed in Thread: TM4C1231H6PZ, EK-LM3S8962

I'm working up a design that uses a TM4C1231H6PZ Tiva CPU driving a Newhaven OLED NHD-2.7-12864UCY3 using parallel 6800 mode. I'm using Port D for 8 bit parallel data transfer.

The OLED display is monochrome 128 x 64 pixels; it uses an SSD1325 controller IC and has 16 levels of brightness per pixel so it uses 4 bits per pixel and one byte written to the display represents 2 pixels, one per nibble. This presents the issue that I have to read the other nibble before I write a byte because each pixel has a 'sister' represented by the other nibble in a written byte. One way to do this would be to read a byte from the display then OR that with the new nibble data and then write the byte back - that would be very slow.

According to the Tiva Graphics UG, a better way is to keep a 'GrOffScreen' copy of the display values in RAM (128 x 64 needs 8 kB but the TM4C1231H6PZ has 32 kB so that's not a big issue). The graphics system can perform RMW pixel updates to the off-screen RAM and then issue a GrFlush command which copies the contents of the RAM to the display. The UG says that it's possible to keep a record of which bytes have changed and then have the GrFlush command only update the bytes that have changed but it also states that this is NOT done in the library - i.e. you have to write your own 'dirty' byte tracker; assuming that 1 bit tracks one dirty byte, then a 128x64 display would need another 512 bytes to do this.

Chapter 3 of the Tiva graphics library UG goes into detail about how 4BPP can be defined with such statements as GrOffScreen4BPPInit but there is no actual project examples and I'm fairly new to the graphics library and I'm hoping that someone who has done this before can help me get the right set of files together - or give me something similar enough to be adapted.

I'm also seeking help writing the actual graphics driver file if one isn't available.

Any help greatly appreciated.

  • 0
    TI__Intellectual 855 points

    Hi Ted,

    Sounds like you are definitely on the right track! The qs-logger example application for the EK-LM4F232 uses a 4BPP offscreen buffer. You can find it in your TivaWare installation folder under examples/boards/ek-lm4f232/qs-logger. Most of the relevant graphics code is contained in menus.c.

    Additionally we have an application note on how to develop display drivers for the Graphics Library. It's based on the older StellarisWare, but the graphics library has remained mostly unchanged so it still applies to Tiva parts.

    Regards,

    Sam

  • 0
    Guru 117855 points

    Have past done similar - you may benefit from our findings...

    a) while 4 bit "color" yields real recognition/value - we found 4 bit, mono "brightness" - to be of very minor value.  The added complexity - expanded memory requirements - and excess time demanded for each/every "screen transaction" led to our rejection of such displays.  One factor in their favor - the possible "import" of existing images (too difficult for 2 bit mono) - failed as we determined 6-8 bit mono brightness to be a usable minimum.

    b) most recently - the cost delta between color TFTs (2.2 - 2.4" diagonal) and your 2.7" OLED may now favor the TFT.  Further - this size TFT usually provides QVGA (320x240) or above resolution - swamping your OLED.   And - should your design reach any volume - there are far more vendors of TFT than OLED.

    c) for engineering/science apps. - the ability to segregate or highlight display data via: Red, Blue, Black, Green etc. simply overwhelms, "slight shadings - of one color."

    d) suspect that your experimentation & growth w/this vendor's Graphic Lib. will be far faster - and less stressful - if you stick to their "targeted display controllers."  (or stay in that near vicinity)  After you've so succeeded - you should have far better feel & appreciation for both the "need" and "effort required" to extend/enhance...

    Update: 13:36 CST - just saw "Sam's" post (above).  His points are good - do note that the display he references is color - not "shaded" mono.  May prove useful to visit Epson or Solomon-Systech site as well - see how "real" graphic controllers work...  (i.e. off-screen "buffer" described is incapable of serious size/pixel capacity display...)

  • 0 in reply to cb1_mobile
    Intellectual 360 points

    Thanks cb1_mobile, if I were to switch to a TFT, would you recommend a particular one?

  • 0 in reply to Ted Mawson
    Guru 117855 points

    Thanks to Sam as well.

    Much depends upon your plans/objectives and potential volume - for your project - and use of the display.  Our group only very occasionally uses such, "pixel shrunk" displays (i.e. only when client demands) - believe the QVGA is about minimal, "serviceable." 

    Should you read the electronic trades/press - most products still "clinging" to mono are not well received.  My attempt was to alert you to this fact - the effort you were about to expend seems outside your best interest...

    Very hard to well predict your current - and future needs.  I'd like you to "end up" w/ display suitable for now - and into the reasonable future.  And...doubt that would be mono - pixel restricted - and code-challenging...

     

  • 0 in reply to Ted Mawson
    TI__Mastermind 26900 points

    You may also like to download the last StellarisWare release for the ek-lm3s6965 or ek-lm3s8962 kits and take a look in the board's "drivers" directory for their display driver. Although this isn't a GrLib-compatible driver, it's pretty close and It uses an offscreen, 4bpp frame buffer. As an illustration of how you can go about developing a driver that uses this model, it's probably worth a look. Also, if you've not read it already, there's an app note that describes the GrLib display driver interface. You can find it here.