Crius OLED display

So you still have no text on your display at all?
When I open up the .ino file, the config.h and data.c tabs appear next to it. If yours are not there you can add them by clicking Sketch, Add File and add them both.You shouldn't have to set a path to the .h file. Let me know if you still have problems. You can also edit out the #define INTERNAL_I2C_PULLUPS as well. Depending if you have your i2c lines already pulled up or not.

Hi

Google Code Archive - Long-term storage for Google Code Project Hosting. might work. Uncomment

U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE);

in the examples.

Ensure that you correctly connect the display to the HW I2C lines of your board.

Oliver

You are absolutely right with your description about the 2 additional tabs.
I sweear they weren't there the first time i opened it so i made the reference.
Now it compiles OK and i'll have a go to see if i can upload and have something happening on those screens.
As a matter of fact i just did that, and oh joy, there's pixels on the first screen now.
Can't make anything of it, but for now it lives !

Thank you for sharing this.
I'll have a look to see how to actually use it

Hi olikraus.
I'll check your u8glib this weekend.
At the moment i've got scrolling , inverted garbage on the screen and still need to see how to get a practical use.
As it's 0:30 now over here and tomorrow is a working day, i'll go to have some sleep (will sleep very well) and this upcoming weekend is already booked.
Thanks guys !

In the example I attached the scrolling and inverting is disabled so it should be impossible for you to see this. The code only displays text to verify that things are wired correctly and your screen works. Verify your SCL and SDA pins are on A4 and A5 and you should be good. You can also try editing out the internal pulls in the .h file. If you use my code and follow these instructions but do not see text then your display is bad. I'm I using another display that I picked up on eBay. The adafruit graphics library works with it.

I cannot get the graphics library to work on the Crius display. Believe me, I've tried.

Well, i'll play around with the bitmaps then.
No text is displayed and the UNO can be connected in 2 ways which both offer the same result.

The inverting and the scrolling is what i've been playing with to see what happens so it seems to me these commands work.
When scrolling, i can see the smae pattern is displayed over again so that seems to work too.
I can edit the scroll speed and so forth so i'll have a play with other bitmaps.
I'll report back with the results.

I'll play for 10 more minutes and then try to catch some sleep.

There should only be one way to connect it to the UNO. SCL, SDA, +5 and ground. Can you use the original example code I sent again without editing it in any way? If nothing then just comment out the internal pull-ups and send that code to the UNO again.

UNO R3 has pins A4 and A5, as well as SCL and SDA but that doens't matter now.
Editing out anything that says pullup results in an empty screen.
I tried making a photo but that's hard to do because of the way a display like this works.

I'll be back

Hi everyone, thanks for the replies! i tried the sketches provided but none of them seem to work. am wondering if the display itself is faulty...is there a way i can check it? thank you

It's very likely. I just took this picture now. The code is the exact same that sent yesterday.

Mike

Hmmm just to be sure its on the A4 and A5 right?

It should be, that's what is mentioned in the coments in the sketch.

I had some more success taking a picture during daylight, so here is what my display shows.


This happens immediatly after powering up, but not if the display has been off for a while.
Then it takes a second or so before something appears.
Looks like both units have a memory problem.
I can control the functions like inverse and scroll, so Arduino communicates and this communication is processed.
I read somewhere about a reset problem and soldering a SMD capacitor and resistor to pin 14 of the flatcable (after disconnecting that pin) might help in such case.
This is a very small pitch connector (to me), yet i'll have a try at that some time.
I think i'll look for the command set for this ssd1306 chip to see if i can send some command instead before i get destructive.

I just plugged mine in now and the screen is garbage like yours. Strange. I took a working screenshot this morning and it was fine. Tried tweaking the delays in the init and it started working, and then not. Right now i'm not sure what the problem is. Maybe the pullup resistors are necessary, decoupling caps or it might be something in the code. I'm using another display with great results. The Crius one isn't very good. I'd trash it and get pretty much anything else.

When i worked with u8glib on a Seeedstudio 96x96 OLED, i noticed that the chip is very sensitive to wire size and I2C speed. 100kHz is already the limit for this controller. I2C fast mode (400kHz?)was never working with my OLED.

Another reason for not beeing able to communicate with the controller could be the look state. A library should send an unlook sequence (0x0fd, 0x012) as first command.

Oliver

@olikraus: That's way over my league, but i know communication is not completely gone while this sketch is running.
As stated, i can see different stages.
Sometimes i can even see some blinking dots at the moment data is sent.
I put some 2 second delays between the senStr commands as a debug help, and can see a pause in the blinking dots at respective delay points.
The display inverts and gets back, inverts again and then starts scrolling.
This is a clue (to me) that communication works, but the buffer that holds the screen content, doesn't erase on startup or is in another way corrupted.
Is there a way to set the I2C speed to a lower (but more reliable) rate ?

To eliminate wire length, i removed the I2C jumper wires and used an angular header (or whatever it's called) and plugged the original wire directly to the board.
Both ollikraus and 0miker0 spoke of a possible problem with that
Makes no difference at all.

I removed the endless while loop and added an end to the scroll, so this way i see that commands keep coming in.
The contents of the display seems to be always the same on each display, but each screen has its own pattern (so the 2 displays show a different picture).

Still seems to me that the buffer / memory isn't erased and filled so that present data is displayed.

Is there a way to set the I2C speed to a lower (but more reliable) rate ?

This must be programmed into the ATMega. For example see lines 120ff in Google Code Archive - Long-term storage for Google Code Project Hosting.

Oliver

Got it !

It is an initialisation problem.
Searching the interrnet brought me to a page i visited already.
I tried everything on there except cutting and resoldering 1 pin of the flatcable to a RC network.
None of that worked, but this must have been a problem in the examples.
So i read all over there and found a tip which is very easy to try:
Add a 100 Ohm resistor between the power supply and the module.
The resistor and the capacitance of the leads on the board are assumed to make just enough delay for the driver to finish the reset.
So i tried again, and voila !


Both displays work correctly now.
Have a look at the photo.
Tip in case someone likes to make a photograph of his display: dim it a lot or else your camera has trouble focussing, set it to 20h or less (i used 08h).

Played around some more.
Just tried to connect both displays at the same time.
The first one is connected to pins A4 and A5 using those jumper pins.
The second one connected to the SDA and SCL pins next to the reset button, using 6 centimeter jumper wires.
Power supply of the second display connected via 100 Ohm to vcc pin of the ICSP connector (don't know if that is a good idea).
This results in damaged data on both displays, and removing display 1 still gets damaged data to display 2, so the wire length of 6 cm is already too much.
Wouldn't expect that, maybe splitting the I2C wires an other way will solve this.

So @desmondttm123: try wires as short as possible, like 0miker0 did.
And try the 100 Ohm resistor.

I guess this means this display can't be used together with other I2C devices.
That would be a shame, i was planning on using it to display ADXL345 results.

That would be interesting if long wires were the problem all along. I'll cut my wire length way down and try this on mine as well on Monday. I have a project board with a different display and a bunch of other i2c sensors on it. The length from the microprocessor to the OLED is only 1". Each sensor on the board has a different i2c address. The i2c address for the display is 0x3C so i'm guessing you cannot have two exact displays working if they both have the exact same i2c address of 0x3C.