search

oscaralcalde12 / u8glib

Automatically exported from code.google.com/p/u8glib
Other
0 stars 0 forks source link

OLED SSD1306 via i2c // AVR Studio - 328P #147

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

1. Executing any visual output commands to the SSD1306 controller via i2c 
(128x32) with the 1.10 library for AVR Studio. 
Only SDA and SCL are used. (RST is commented out anyway) 
MCU = Atmega328P / F_CPU = int. 8MHz

What is the expected output? What do you see instead?
Expected: 
*********
Just to test the display, a simple string: "Problem" at the correct display 
position. (0, 20) xy

Instead:
********
Even with "&u8g_dev_ssd1306_128x32_i2c" initialization the 128x32 seems halved, 
and acts as such on the upper part. The lower part contains the string i have 
used before, which was "Halli Hallo!", which is also not displayed correctly, 
while using the "u8g_FirstPage(&u8g);"-function. (Picture & Code attached) 

What version of the product are you using? On what operating system?
1.10 using AVR Studio 6.0.1996 on WIN7 x64. (AVRGCC - 3.4.1.95)

Please provide any additional information below.
A very powerful library! 
Is there an issue with the initialization? - when commenting out 
"u8g_FirstPage(&u8g);" the display seems to work, copying the lower to the 
upper half - changing the page continuously after the delay... so the issue 
lies within 128x64/128x32 initialization?

Thank you in advance for any help!!!

Original issue reported on code.google.com by Tsku...@gmail.com on 23 Feb 2013 at 7:42

Attachments:

GoogleCodeExporter commented 8 years ago 
to me it is not fully clear what exactly happens. instead please draw the 
following
void draw(void)
{
        u8g_SetFont(&u8g, u8g_font_fub14);
        u8g_DrawStr(&u8g, 0, 20, "Problem!");
  u8g_Line(&u8g, 0, 0, 127, 31);
}

picture loop must be like this (do not call u8g_FirstPage() inside the while 
loop):

       u8g_FirstPage(&u8g);
       do
       {
               draw();
       }
       while (u8g_NextPage(&u8g));

then do the following:
1. flash your device
2. disconnect power for some seconds
3. reconnect power (the new pic should be displayed)
4. what do you see? perhaps you can attach a picture here

Original comment by olikr...@gmail.com on 23 Feb 2013 at 8:12

GoogleCodeExporter commented 8 years ago 
should be
void draw(void)
{
        u8g_SetFont(&u8g, u8g_font_fub14);
        u8g_DrawStr(&u8g, 0, 20, "Problem!");
  u8g_DrawLine(&u8g, 0, 0, 127, 31);
}

Original comment by olikr...@gmail.com on 23 Feb 2013 at 8:14

GoogleCodeExporter commented 8 years ago 
Thank you for your fast reply!

Yes, after discharging the capacitors there is always this kind of "static" in 
the lower section. 
When left on and reflashed without the "u8g_FirstPage(&u8g);"-function the 
"static" will be overwritten, and after another reflash with 
"u8g_FirstPage(&u8g);" it stays overwritten. The overwritten text is 
unreadable, like in the first picture. 

Thank you for your help!

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 8:54

Attachments:

GoogleCodeExporter commented 8 years ago 
It is clearly visible that just the upper half of the display is operational, 
somehow the program thinks 31 is half of the display, even when in the 
"u8g_InitI2C"-func the correct dev is selected. The static pattern seems to be 
constant..

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 9:07

GoogleCodeExporter commented 8 years ago 
it seems, that every second line is skipped.
Well, this is something which sometimes happens. The problem is, u8glib does 
not know the mapping between controler memory and acutal pixel positions.

Can you provide the datasheet for the display? Can you also provide exactly the 
code, which had produced the picture above?

Oliver

Original comment by olikr...@gmail.com on 23 Feb 2013 at 9:10

GoogleCodeExporter commented 8 years ago 
Of course, thats the least i can do. -Attached
Display: UG-2832HSWEG02 (SSD1306) I2C only. 4Pin (5V VCC;GND;SCL;SDA)

When using non-existant values for eg. "u8g_DrawLine(&u8g, 0, 0, 127, 40);" the 
line just gets cut off when the static begins.
Graphic commands such as "u8g_SetRot180(&u8g);" work.

Thanks a lot for your help!!

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 9:42

Attachments:

GoogleCodeExporter commented 8 years ago 
The libraries to create oleds.c have not been altered, and no other were used. 
Shop/pictures:
http://www.ebay.at/itm/I2C-0-91-128x32-Monochrome-OLED-display-module-compatible
-Arduino-/160874357190?pt=LH_DefaultDomain_0&hash=item2574dbe1c6

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 10:02

GoogleCodeExporter commented 8 years ago 
Please locate file
http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_ssd1306_128x32.c
uncomment line 173 (univision OLED)
comment line 176
let me know if this works.

Oliver

Original comment by olikr...@gmail.com on 23 Feb 2013 at 10:18

GoogleCodeExporter commented 8 years ago 
if this is not working correctly and the display content differs from the 
previous picture, it would be great if you could attach another picture of the 
display content.

Original comment by olikr...@gmail.com on 23 Feb 2013 at 10:48

GoogleCodeExporter commented 8 years ago 
I have tried all four initializations, where unfortunately only adafruit 2 & 3 
work. with adafruit 2 there is a slight delay (approx. 0.2 sec) before it 
starts, where adafruit 3 runs almost instantly. Both of them display the same 
issue.
With the univision startup nothing is displayed. Is there anything i can change 
elsewise?

Thank you for trying to help!

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 10:57

GoogleCodeExporter commented 8 years ago 
In the attachment is the adafruit-code that should get this particular display 
to run with i2c, but it uses arduino libraries i'm unfortunately not familiar 
with. 
The startup sequence which is stated in the code should work, but where is the 
difference? 

Thanks for looking into this!

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 11:15

Attachments:

GoogleCodeExporter commented 8 years ago 
ok, then please revert changes in
http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_ssd1306_128x32.c
back to the adafruit 3 init sequence - i do not remember differences :-(  
but if adafruit 3 is working, then let as continue with this.

I need to do some research on the ssd datasheet...

Original comment by olikr...@gmail.com on 23 Feb 2013 at 11:52

GoogleCodeExporter commented 8 years ago 
i have updated lines 121 and 132 in the 
u8g_dev_ssd1306_128x32_adafruit3_init_seq init sequence of file 
http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_ssd1306_128x32.c

Please takeover these changes (or replace your file with the raw download from 
the repository above)

What will happen to the display?

Original comment by olikr...@gmail.com on 23 Feb 2013 at 12:05

GoogleCodeExporter commented 8 years ago 
I have changed lines 121 and 132 exactly, and the problem unfortunately still 
persists. 
The static pattern is inconsistant though, it changes with each power connect 
(after discharge). -pic

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 12:34

Attachments:

GoogleCodeExporter commented 8 years ago 
When using the "u8g_dev_ssd1306_128x64_i2c" attribute it seems to be working 
fine for horizontal size, but vertically it is false. - picture & code

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 12:58

Attachments:

GoogleCodeExporter commented 8 years ago 
Using this attribute was just for testing. How come the display is able to 
convert this information? So - as you have assumed - is there is a mapping 
error?

I have noticed that sometimes after disconnecting and reconnecting it won't 
start, redoing it will "fix" it..

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 1:19

GoogleCodeExporter commented 8 years ago 
At the moment i am thinking, that the display is connected to every second 
line. So you can use the 128x64 variant, but with every second line dropped. 
The problem now is, that pixels are stored in one byte, which goes from top to 
down. This means, that every second bit in a byte has to be dropped. But i do 
not have graphics procedure which handle 4 pixel per byte where every second 
has to be dropped. Luckily there is another memory mapping mode, where bytes 
are stored horizontally. I will check this and come back with an updated 
version.

Original comment by olikr...@gmail.com on 23 Feb 2013 at 3:19

GoogleCodeExporter commented 8 years ago 
ok, i was thinking, that i have at least an OLED with SSD1306 in my lab. But 
this seems to be wrong :-(

If you are willing to do some more tests, i will rewrite the SSD1306 128x64 
device, but probably you need to do some testing...

Original comment by olikr...@gmail.com on 23 Feb 2013 at 3:42

GoogleCodeExporter commented 8 years ago 
ah, i mean i will rewrite the 128x32 device (i think it was never tested...)

Original comment by olikr...@gmail.com on 23 Feb 2013 at 3:43

GoogleCodeExporter commented 8 years ago 
Thank you for looking into this!!

Yes, i have read somewhere that the 128x32 SSD1306 i2c code was implemented, 
but not tested/verified. 

Of course i would do some more testing, i would be happy to contribute to 
improve/repair the library. It also would be interesting for everyone i think.

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 4:11

GoogleCodeExporter commented 8 years ago 
i switched from page adr. mode to horizontal adr. mode.
Plead download the new code from here:
http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_ssd1306_128x32.c

does it make a difference? How does the screen look like?

Original comment by olikr...@gmail.com on 23 Feb 2013 at 6:26

GoogleCodeExporter commented 8 years ago 
Thank you a lot for working on this issue!!!

I think you can flag it as fixed :}. 
I have attached two photos - 1. the new "u8g_dev_ssd1306_128x32" with bit 
skipping and 2. with the same "u8g_dev_ssd1306_128x32" as before but with very 
minor modification and a little formatting. (attachment - 
new_u8g_dev_ssd1306_128x32.c)

The problem was at first in the initialization sequence which you have 
recognized early, and -on my side- with avr studio. I had to make some random 
change to oleds.c in order to re-compile all correctly every time, otherwise 
the changes were not compiled. I have restarted the program a few times in the 
process, which led me to the mistake. Very odd. 
Nevertheless adafruit 3 is working fine now - tested/verified. 
Graphics - working. Various fonts/colors/alterations - working. 
No starting issues. Really great library! 

Thanks a lot for helping me out!! I'd like to donate you a display if you 
provide me anything to ship to. 
Anyway, if i have anything to aid you, i will provide :).

Thanks a lot //!\\

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 8:43

Attachments:

GoogleCodeExporter commented 8 years ago 
no need to donate something. But maybe you can tell me which code i could add 
to u8glib now.

You mean, that the code from new_u8g_dev_ssd1306_128x32.c is the one which is 
working correctly?
Can I copy the code from new_u8g_dev_ssd1306_128x32.c to 
u8g_dev_ssd1306_128x32.c and it will work like in your 
ssd1306_128_32_working.jpg?

Thanks, Oliver

Original comment by olikr...@gmail.com on 23 Feb 2013 at 8:57

GoogleCodeExporter commented 8 years ago 
Yes, the "new_u8g_dev_ssd1306_128x32.c" contains the working code & updated 
comments (not added any on purpose - readability). You can just copy the raw 
code or rename the file. No additional changes have been made, and the SSD1306 
i2c communication should work just fine. With "oleds.c" it should generate the 
same result as in ssd1306_128_32_working.jpg. 
I have to say i never experienced such competent and fast help!

It's me who has to thank you :}

THANKS A LOT /!\ Cheers!

Original comment by Tsku...@gmail.com on 23 Feb 2013 at 9:18

GoogleCodeExporter commented 8 years ago 
No problem. I glad that another part of the code is verified. :-)

I will close this issue...

Original comment by olikr...@gmail.com on 23 Feb 2013 at 9:22