• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

OLED driver

Status
Not open for further replies.

arhi

Member
Some PIC samples to drive OLED panels would be nice ... I managed to look at pinouts of 3 different OLED's and noted that they all have same pinout (yeah I know 3 is not a big pool of samples).

I'd like someone who is using OLED's to say if they are "compatible" or they are in the "I'm my own standard" mood...

Some source for C18 or C30 would be nice

thanks in advance
 

arhi

Member
thanks ... after lot of googling I was unable to find that myself :) ..

Just found out that bloody oled's are not standardised :( .. every manufacturer think he is the smartest :( .. damn :( .. but, good info is that they have SPI/I2C :D that was a nice info :)

Downloading that examples now
 

Papabravo

Well-Known Member
The ones I'm looking at from FEMA require power sequencing at power up and at power down. Damage may result according to the manufacturer if the rules aren't observed. Also they dont't typically come with character generators so there is a big slug of program memory for blanking codes. With 16 level grayscale it takes 4 bits per pixel to make the characters.
 

arhi

Member
I'm interested in driving ones with SSD1303 controller (UG-2864GMBAF01, DD-2864BY-1A etc)... the interesting thing is that all "examples" I encountered (including the microchip dev tool linked few post ago) do not say what is the controller type they are giving the example for ?!

with regards to character generator, you only need rom for that ... so a spi / i2c / 1wire eeprom should do the trick .. (or uC with enough eeprom room for character map), and as I bet you like to display splash screen with your logo, few nice pics between this and that ... eeprom is the way to go .. same as with any gfx lcd's ...

EDIT: I never used OLED before but I got RepRap kit from BitsFromBytes (man that is one nice kit) and I managed to f**k up the provided OLED display (it was not easy but I manage to cut the plastic flat cable - or how ever that cable is actually called) and the display is UG-2864GMBAFG01. I recon the DD-2864BY-1A that is available trough FARNELL is compatible on ordered 2 of them .. so if they are compatible, I will use the second one for testing in my own projects. I like the idea of fast SPI gfx lcd :)
 
Last edited:

Papabravo

Well-Known Member
We're proposing to use the SSD1322 for a 256x64 panel.
 

arhi

Member
I recon SSD1322 should be compatible with SSD1303 on the software side ... just different resolution ... If you have some code examples that work (C18 or C30 for pic) I'd be grateful :D ... I managed to find a pdf giving some insight into SSD1303 but I cannot say it is complete.
 

Papabravo

Well-Known Member
I've received some sample code based on an 8051 demo board. When I used the CodeVision AVR compiler to build it for the ATmega2561, it threw a number of warnings and errors. The warnings include basic programmer mistakes like using local variables before assigning them a value. I'd be willing to bet large sums of money that the code does not work, and they are still debugging it. I'm sure you can ask the folks at FEMA and they'll be glad to send it to you. I wouldn't feel right about passing it on without permission.

Because of the way the internal RAM is accessed the 5x7 characters actually occupy 8 columns instead of the usual six. To get a 5x7 font to have the proper spacing it is necessary to convert each 1-byte character to 5-byte columns, add a blank column, and a pad on the beginning or the end so that the number of columns being written to RAM is a multiple of 8. Pretty tricky stuff, I'll let you know what I come up with, as soon as the other bright guys figure out how to modify our power supplies to support power sequencing.
 
Last edited:

Sceadwian

Banned
Ummm... an AVR2561 is not an 8051 =) Of course the code isn't going to work.
 

Papabravo

Well-Known Member
Ummm... an AVR2561 is not an 8051 =) Of course the code isn't going to work.
Duh! Of course it isn't, and I never said it was. If the same C-code compiles on two different compilers then it certainly has a shot at working. If the C code uses local variables without giving them a value then it certainly won't have much of a chance of working on ANY platform. Some compilers will tell you about this kind of thing and some won't.

The actual target is irrelevant, using this example code only requires the mapping of the SPI interface signals to the appropriate pins. Since I don't yet have a hardware platform, getting a clean compile is as far as I can go at the moment. Give me a little credit wiilya! I've only been doing this stuff for half a century.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top