help on SSD1306 driver for Cortex M4

sherwin tiongson said:

OLED we are going to use is SSD1306.

Doubtful - more likely SSD device is Oled Control IC.  (which I have confirmed)

Maker has "named" several of their Oled Display Assemblies "SSD1306!"  Certainly novel - although bit ineffectual/confusing.  Had we in Lcd field done such - there would be 10K+ Lcd variants - all with name HD44780.  (never even dawned on us to "name" the display module via IC nomenclature)

TI supports several Oled displays on various Eval Boards.  Review of the SSD1306 "real" spec (that of the control IC) followed by study of the TI Oled offerings should be a productive beginning for you...

hi cb1 mobile,

good day!!

the controller chip SSD1306 from solomon systech.

thanks

I've not used an SSD1306 and have not read the datasheet but we do have a drivers for various SSD controllers already and one of these may be helpful as a base. The ones I can find and the kits they are included in are:

• SSD1332 (ek-lm4f232)
• SSD1300 (ek-evalbot)
• SSD1329 (ek-lm3s8962, ek-lm3s6965 and ek-lm3s2965)

You may also find this appnote on writing new display drivers helpful.

cb1_mobile said:

TI supports several Oled displays on various Eval Boards.

Great minds (true at least in your case) thinking somewhat alike...

One caution perhaps - "fruit-based" display module producer - along with being tad "part name challenged" - may have interposed their own MCU and implemented some form of command interpreter - obviating any need for SSD read/mastery...  Incoherence in their naming scheme (multiple, different displays bearing identical SSD1306 name) caused me to flee their site...

Hi Dave,

Good afternoon!!

I already have a not fully working display driver for SSD1306. I was able to compile and link it to graphics library. But when I tried using GrStringDraw() function it displays not what I expect it... it displays filled rectangles in the screen. Even if I change to different strings. I'm kind of confident enough on my SD1306 library functions because I already tested each function and it really can execute the below functions as specified by the AN01287 document. Do you know where to find the source code for GrStringDraw() function? This would help me a lot so that I would know which display driver function is called by GrStringDraw().

FYI.. I am using Stellaris EKL-LM4F232 Eval Board, my display is SD1306 OLED, interface is via SPI. One thing to note though is that in SD1306 we dont have capbility to read OLED controller memory so in my implementation I have a local display_buffer that is the replica of the oled's memory and just flush this buffer.

void PixelDraw(void D ayData, long lX, long lY,   *pv ispl
                   unsigned long ulValue);
 
    void PixelDrawMultiple(void *pvDisplayData, long lX, long lY,
                           long lX0, long lCount, long lBPP,
                           const unsigned char *pucData,
                           const unsigned char *pucPalette);
 
    void LineDrawH(void *pvDisplayData, long lX1, long lX2,
                   long lY, unsigned long ulValue);
 
    void LineDrawV(void *pvDisplayData, long lX, long lY1,
                   long lY2, unsigned long ulValue);
 
    void RectFill(void *pvDisplayData, const tRectangle *pRect,
                  unsigned long ulValue);
 
    unsigned long ColorTranslate(void *pvDisplayData,
                                 unsigned long ulValue);
 
    void Flush(void *pvDisplayData);
 

thanks,

Sherwin Tiongson

Sherwin,

 When drawing strings, GrLib uses the display driver's PixelDrawMultiple and LineDrawH functions. For PixelDrawMultiple, the lBPP parameter is always 1 so I would take a look at the code in that display driver function and see if your 1bpp case is working as expected. While you are working on this, make sure that you are testing with ASCII strings first since these should show up correctly with pretty much any font or codepage settings you happen to have. Once you get ASCII to display properly, you can be guaranteed that the display driver is fine and can then move on to dealing with other codepages, alphabets and fonts if necessary.

hi Dave,

Good day!

When GrLib calls PixelDraw(void D ayData, long lX, long lY,   *pv ispl,unsigned long ulValue) function, do you happen to know what value would he passed when he wants to display white or any color?  is there any documents you can recommend describing color-mapping in GrLib? I am concern on this because my OLED is monochrome. I think this is the source of my   

There's some information on color handling in this app note which discusses creating new display drivers. The color you are passed in ulValue here is the value your driver returned on a previous call to the ColorTranslate() function. It is up to your driver to decide how it handles colours - ColorTranslate will be passed a 24 bit RGB value and it must return a value that it can use later to represent that color on the display. For a monochrome display, you may want to return "1" for any color value other than 0 (black) or you may like to pick some threshold and return 1 (on) for colors above the threshold and 0 (off) for colors below it.

(Edit: Added missing hyperlink to the app note)

got it working.. thanks guys for your great support..