Go Down

Topic: µOLED-160-G1 serial oled lib in the making (Read 2053 times) previous topic - next topic


Hi all,

I've got a oled display from 4d systems. Eventually i want to make a library for it so i've started with writing all the separate functions to control the display. The lib for arduino that is available at http://jennylc.com/4d/ is outdated and incomplete but gave me a start.

At the moment i'm looking for some constructive criticism about the code and the comments. Things like "Is it clear what a function does", "is the actual code readable" and "are the comments actually helping".

The sketch is basically a loop that starts with a reset and initialize of the screen and then all functions are called that are implemented. As the display sends an acknowledgment if a command is understood the result of each function call is reported by serial line to a computer with terminal. All the actual functions are after the main loop.

You can get the sketch here http://www.sendspace.com/file/s6wkbn

Feel free to not help me as i know it is a rather long read. Obviously hoping that someone will.

Thanks in advance,



Nov 10, 2009, 12:31 am Last Edit: Nov 10, 2009, 12:32 am by jluciani Reason: 1
I did a C library for the 160 and 32024 for the ATmega168 and ATmega644. A couple of comments --

 The types for x, y should be unsigned char since they never go negative.
 If you think you may want to use the uOLED 32024 you may want to
 make the types unsigned integers. With compile time constants you can
 make the same code work for the 160 and the larger displays.

 For the library I wrote I implemented my own serial output routines that
 use a circular buffer. This keeps the UART running at maximum rate since
 when it empties an interrupt is generated and the next character is pulled
 from the buffer.  I have never read the Serial routines so I am not sure if
 this would be possible or even help.

(* jcl *)

www: http://www.wiblocks.com
twitter: http://twitter.com/wiblocks
blog: http://luciani.org
www: http://www.wiblocks.com
twitter: http://twitter.com/wiblocks


Thanks for your tips/time jluciani.

The types for x, y should be unsigned char since they never go negative.
After checking the extended reference about unsigned char i think i will go for byte because of
For consistency of Arduino programming style, the byte data type is to be preferred.

If you think you may want to use the uOLED 32024....
After reading (more like glancing over) the datasheet of uOLED 32024 i think i will stick to a uOLED-160-G1 only lib. There are some differences between the two. One is that they both use different graphical processors and some commands use different formats.

For the library I wrote I implemented my own serial output routines that use a circular buffer.
Although that is a more elegant solution i don't think that i implement that at this time. Main reason is that at this stage it gives me some confidence/clearity that the program will not advance before the last char is in the output buffer. At this point i don't mind the blocking of a serial.write.

Any more tips from the community are welcome.

Thanks again,




I have just wrote a basic library for serial displays of this kind, mail me and I can send you a copy of my code



A have send you a lib by email, please let us know how it works

by the other hand, if someone knows how to put a zip file in this forum please send me the trick!


I've received and read your library. A couple of thoughts;

I'm using an arduino mega which has multiple hardware UARTs. Could we come up with a strategy to pass the desired serial port to the library?

Does your StartUp() function works reliable? I have had a lot of errors until i programmed this. Quote from manual
Within 100ms of powering up, the host should make sure it has its transmit (TX) line pulled HIGH.

Why did you decide to make the result of RBack() a global variable (char res)? Not to attack your decision as there are multiple ways to accomplish this. I've implemented that as a return from each function. Planning to extend that to return multiple error messages. (ack, nack, weard response, timeout)

I use Serial.write(bytevalue) instead of Serial.print(bytevalue, BYTE) based on thread http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1257276571 But i haven't tested/measured for any changes in speed/codesize/memory usage.

I have written some additional functions (getPixelColour for example) but i'm a bit scared to put them in your library as i haven't learned 'library brewing' yet. How do i add a function to your library that returns something when called?

Thanks for sharing your code. If you are interested in mine i can send a copy or you can get it from http://www.sendspace.com/file/s6wkbn.



I use an Arduino Pro 328 - 5V/16MHz and tiny 4D display, until now it works fine

Good point about the serial ports....  mmmmm!!  I think that we need to ask to some Serial comunication guru  ;D

could be that using SoftwareSerial LIB can help us but I don't know if this increase dramatically the execution time (i guess you need to messure with an oscilloscope), other posibility can be use some compiler instructions on LIB, so when Arduino complie code it insert correctlly waht serial port is called by the PDE file. :-?

based on your observations I modify some Methods on code

Code: [Select]

uOLED::uOLED(int pin, int baud)
 pinMode(PinReset, OUTPUT);
 BRate = baud;

//Make a Reset for uOLED and Clear Screen
void uOLED::StartUp()
 //Reset display

 //Send 0x55 to stablish baud rate for serial communication


I just move Serial.Begin from class constructor to StartUp, this is important because as soon as you call Serial.begin it also takes care about TX pin line to put it into HIGH becasue HI state signal on RS232 means no data is send, when Serial.print (or any other send function) is called TX signal follows RS232 protocol (start bit, data bits, stop bit). I also verify this with oscilloscope. On your cade you manipulate manually TX pin that in my pont of view has no sense!

I put RBack as private method that modify a public attribute into the uOLED class because not always is needed to verify or debug response from 4D Display if you want to check respronse just type

Code: [Select]

char 4DDisplayResponse;
/*extra coding*/
4DDisplayResponse = My_uOLED.res;

I haven't tested neither how works Serial.write compared with Serial.print (data,BYTE) this will be a good exercise to test, waht I see that Serial.write use less space when you compile the code

if you want to add a instruction on LIB follow this steps

1. On uOLED.h declare as Public method the function

Code: [Select]
unsigned int ReadPixel(chat x, char y)

2. into uOLED.cpp coding the function as a member of uOLED class

Code: [Select]

unsigned int uOLED::ReadPixel(chat x, char y)
 unsigned int data;
 char temp;
 res=RBack(); //wait for ACK
 data=int (RBack());
 return data;

3. on your PDE program just call method

Code: [Select]

PixelColor = my_uOLED.ReadPixel(10,10);

I hope this can help! ;)


Thanks for your time JuMCaR,

As i don't have my hardware at hand at this time i can't test anything yet. I will respond on the subject probably tomorrow.

I hope that someone could give a hint on how to pass the desired serial port to the lib. Either at compile time (Wouldn't that limit the options of a class if you have more than one display connected) or when the class is constructed by the program.

Do you want to receive the separate functions or the complete lib with additions i make?

Thanks again,



It is possible to have many displays connected, because every time that you define a varible as uOLED each will have their own parameters and of course their own serial port (when this will be implemented)

will be cool to recive the LIB modificated. I'll try to buy Arduino Mega to test also what you found about this topic, I'm  pretty interested to make  a "decent" LIB for this comunity (just for hobbie :D)

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131