OLED graphics... suggestions welcomed.

Coding and general discussion relating to user created compiler modules

Moderators: David Barker, Jerry Messina

Francis
Registered User
Registered User
Posts: 314
Joined: Sun Mar 25, 2007 9:40 am
Location: Devon

Post by Francis » Sat Jun 19, 2010 8:10 am

I did a rewrite of the Driver routines so that the graphics updates were bitwised in RAM and then did the OLED CGRAM write in a loop.
(AS opposed to the 'traditional' method of reading CGRAM / bitwising/ writing back which is fine if you haven't spare RAM)
It ended up a little messy as I was struggling with the Fonts, but I was running out of time.
The result is full screen update in <5mS for that particular OLED.

That particular OLED (Denistron/Univision with SSD1305 controller) is quite cheap - but monochrome.

DarpanaM
Posts: 1
Joined: Thu Jul 01, 2010 7:25 am
Location: Australia

Post by DarpanaM » Fri Jul 02, 2010 1:03 am

Hi Francis,

I am currently working on replacing the a Univision OLED display that uses the SSD1303 with a SSD1305 on our current product.

According to the datasheets, there are no major differences between the 1303 and 1305, that make the 1305 backwards incompatible with the 1303.

One of the first things I tried to do when I received the OLED display, was to prove we could write to the extremities of the display, by drawing a rectangle on the boundaries.
With the previous OLED displaym using the SSD1303 driver, I could do something like this:
rect x=0 y=0 width=96 height=64

But for the new OLED display with the SSD1305 driver, we have to do the following:
rect x=18 y=0 width=96 height=64

Is this similar to the problem you were observing?

I believe there might be an offset in their memory map, which is why we have to do this. I am waiting for a response from Univision's tech support, so hopefully I will know if that is definitely the case or not.

Will definitely be interested to know if anyone else has faced the same issues.

Cheers,
Darpana

Francis
Registered User
Registered User
Posts: 314
Joined: Sun Mar 25, 2007 9:40 am
Location: Devon

Post by Francis » Fri Jul 02, 2010 8:00 am

I wrote a fresh GLCD driver (based on the standard format) and I've never used the 1303.

I don't have the code to hand but I don't recall any issues like that.
However, it was over a week ago so I may have forgotten :wink:

I'll have a look later.

User avatar
ohararp
Posts: 194
Joined: Tue Oct 03, 2006 11:29 pm
Location: Dayton, OH USA
Contact:

Post by ohararp » Sat Jul 03, 2010 4:56 pm

Nathan, do you mind sharing your SSD1303 driver.bas? I would like to try and get up and running with this module http://www.crystalfontz.com/product/CFA ... -Y-B1.html from crystalfontz and any help would be appreciated!
Thanks Ryan
$25 SMT Stencils!!!
www.ohararp.com/Stencils.html

User avatar
RangerBob
Posts: 152
Joined: Thu May 31, 2007 8:52 am
Location: Beds, UK

Post by RangerBob » Mon Jul 05, 2010 11:16 am

Hello Ryan,

Of course you may have a copy - You can get it on this thread or you can download it from here. It refers to SSD0323 but the SSD1303 is identical (SSD0323 was exclusively for OSRAM I think).

It isn't the most polished of code and I have #defines that refer to my obsolete OSRAM displays; you'll obviously want to go through your datasheet to get the correct initialization commands.

Let us all know how you get on, and any questions please feel free to ask.

Nathan

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Post by RadioT » Tue Jul 06, 2010 4:01 pm

Great to see you got that routine going. I hope my old SSD1339 code was of help! The SSD1339 is now obsolete so I'm looking for a replacement. It would be fantastic if there was such a thing as an OLED that was compatible with an LCD from the same company so that I could substitute the LCD where applications called for operating in direct sunlight. I hope I am wrong, but all the OLEDs I have seen don't have enough oomph to be read in sunlight. Has anyone ever seen an OLED/LCD pair from any manufacturer? For that matter, is there such thing as an "ultrabright OLED" that is useful in sun? Maybe I should post this as a new thread....

73's,
de Tom

User avatar
ohararp
Posts: 194
Joined: Tue Oct 03, 2006 11:29 pm
Location: Dayton, OH USA
Contact:

SSD1305/Adafruit

Post by ohararp » Fri Jan 07, 2011 2:08 am

Reviving an older thread here, but I just noticed Adafruit has these in stock now at a pretty good price.

http://www.adafruit.com/index.php?main_ ... cts_id=326

After reviewing this thread is there existing SSD1306 code for SF that I could use as a starting point? There is an Arduino library as well from Adafruits site, so that might also make this an easy change to SF.
Thanks Ryan
$25 SMT Stencils!!!
www.ohararp.com/Stencils.html

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Post by RadioT » Mon Jan 17, 2011 8:35 am

Hi ohararp,

The code formats are not that much different from the SSD1339 code I put up. Of course there are some different functions in this chip. They also dropped the "graphic" functions, like being able to draw a circle with one command.

One nice improvement is that I see Solomon now has compensated for having no "ready" signal in earlier chips. There is now a RAM write synchronization signal. This will let you write to it at full speed, so you are no longer stuck having to use timeouts before sending more commands. The i2c also has the "acknowledge" pulse as per the standard, so even with that it allows you to throw messages at it as long as the i2c keeps up. http://www.adafruit.com/datasheets/UG-2864HSWEG01.pdf shows these nice improvements. As you can guess, I lost a lot of hair getting timing right with the SSD1339. And then they go and obsolete the part.

So I can see that starting with SSD1339 code, you can go through the commands and compare them to the SSD1306 datasheet and tweak them. The formats of the commands would give you a starting point that works. Maybe just use the bare-bones setup and build from there.

One point to remember, these chips are sensitive to the settings for display operation parameters like pre-charge period, display clock divide ratio, Vcomh deselect level and such, with an incorrect combination usually resulting in a blank screen. Happily, Adafruit gives settings you can start with in the evaluation kit guide, http://www.adafruit.com/datasheets/UG-2 ... 0guide.pdf .

73's,
de Tom

Post Reply