I am posting here rather than a private message for the sake of other users in case they run into the same problem. Note that I posted a message in your code library section but I'm not sure how often it is monitored.

I'm fiddling around with your SSD1306 OLED driver on a 128x64 OLE display and all seems to work fine except for two things, the second one being the most important:

Problem 1: In my post in the code library section, I ran into a situation where trying to display stuff on the screen caused the last 6-7 rows of pixels and 8-9 columns of pixels to turn-on random pixels and render them unusable, even after powering-cycling the display. I magically got around this by powering-off the circuit for a few hours and upon my return, all was worked well by just flipping the switch back-on. Is it possible that some segments keep an electrical charge for a while?

It's not a big deal but I'm just curious.

Problem 2: This is where I'm not sure what's going-on.

I can display the following in large fonts:

ABCFDEFGHI
abcdefghi
012345678
098765432

I have displayed the lines inverted therefore to show the limits of the screen therefore all pixels are ON except for the ones needed to display the characters.

When I look at the screen, after the last character on each line (I, i, 8 and 2), there's more than enough space to display at least one more character per line. However, the problem is that if I add just one extra character on line for for instance, then the left half of the first line is erased but I see the 'J' at the end of the line. Basically, the first line is cut in half at letter 'F'. Same with other lines: adding one extra character at the end of the line "erases" the left half of that line.

Because of this problem, there's a good chunk of the right section of the display that is unusable limiting each line to 9 characters wide rather than 10 or even 11.

Any idea what can cause this?

Thanks!

Ben

Last edited by benoitstjean on Wed Dec 27, 2017 9:54 am; edited 1 time in total

temtronic

Joined: 01 Jul 2010Posts: 6549Location: Greensville,Ontario

Posted: Tue Dec 26, 2017 10:43 am

I can answer #1 , easy....
Yes the display can hold the charge for a long time. Classic...reminds me of an old BYTE mag or Circuit Cellar Ink issue, where LCD was added to a PC, got some 'weird' stuff going on.
The 'cure' was to do a hard reset on the LCD.

#2 sounds like a 'pixel pointer' problem. Not familiar with the LCD but numbers used to access the pixels are probably not linear. It's a case where you need to read the datasheet and see how EACH pixel is addressed (# for X, # for Y).

Jay

Ttelmah

Joined: 11 Mar 2010Posts: 14081

Posted: Tue Dec 26, 2017 11:05 am

Hmm.

I've used the full width of the display without any problems.
What text size are you using?. The small text or the double height/width?.
Are you using the older code or the new version?. The new version is slightly more efficient in relocating to display write pointer, and avoids a potential problem here. Definitely worth switching to the later code if you are using the older version. If you are using the newer version, this can also offset the display right by two pixels for the SH1106.
Do you have a link for the actual display you are using?.

There weren't any specs as this was to integrate on a MultiWii for my quad copter.

I eventually decided not to use it and it sat there for a while.

Two years later (now), I decided to give it a whirl and found your driver at the link above so I would guess this is the most recent.

As I said, all works fine except when I get to more than 9 characters on a line.

I'm using the larger font.

As for the SH1106 pixel offset, even if it was offset by two pixels, it still wouldn't matter on the display as there's more than enough pixels on the right, enough to display probably two more letters.

Ben

Ttelmah

Joined: 11 Mar 2010Posts: 14081

Posted: Tue Dec 26, 2017 2:36 pm

The memory map doesn't work like that. When you write to the wrong pixel beyond the line it results in other lines being corrupted. If you try to run the 1106 without the offset, you get a big swathe of the display corrupted....

Double check yours has the later OLED_address function. I changed just this at the start of December.

benoitstjean

Joined: 30 Oct 2007Posts: 302Location: Ottawa, Ontario, Canada

Posted: Tue Dec 26, 2017 3:21 pm

Yep, the OLED_address() function is in there.

[EDIT] Regardless if I add #define SH1106 or not in the OLED_address() function, the display still cuts half the first line in the center of the screen.

As a side note, this is my first try at this type of LCD display (individual dots) and I don't have the specs so troubleshooting is difficult... I have no idea how the addressing and registers work, no idea how the screen is configured etc. I've played a lot with alphanumeric displays using the HD44780 controller and that's easy but no idea on this OLED module.

So printing individual characters in specific positions work but printing the entire string causes the problem.

benoitstjean

Joined: 30 Oct 2007Posts: 302Location: Ottawa, Ontario, Canada

Posted: Tue Dec 26, 2017 4:49 pm

UPDATE: Ok, here's what I have discovered:

In the OLED_text( ) function, the last part is a do/while loop.

Your original loop ends like this:

while( --number );

This is causing the issue when printing ABCDEFGHIJ. Original problem.

If I change it to this:

while( number != 6 );

It works fine when I try it one line at a time.

If I try it for two lines, then only 8 characters are displayed!

Ttelmah

Joined: 11 Mar 2010Posts: 14081

Posted: Wed Dec 27, 2017 1:32 am

Makes total sense then....

The OLED_text function _does not handle line feeds_.
It only transcribes the passed line directly to the display.
It requires you to position the cursor where it needs to be, and pass a line that fits in the space. No control characters, wrapping etc..

The OLED_putc 'wrapper' function adds handling for CLS, LF, & CR.

You are trying to do something the function does not support.

benoitstjean

Joined: 30 Oct 2007Posts: 302Location: Ottawa, Ontario, Canada

Posted: Wed Dec 27, 2017 8:33 am

Regarding the 'number' variable changed to 6 in the loop, that was just a test. I know it does not work because printing short strings fail. I put your code back how it was.

I am not printing any control characters either, just text.

Since I can't find the specs for the display, I'm just trying stuff.

Using the OLED_text() function, writing 10 characters individually works just fine. Writing a string of 10 characters 'ABCDEFGHIJ' with the same function fails.

The failure with 10 characters causes the line in question to be partially erased therefore everything from A to half of letter 'D' is blank (I see the rounded part of 'D');

So definitely there's something wrong in that function when 10 characters are printed.

The problem is also consistent on every line: I can print 9 characters correctly on lines 1-2 and then on the third line, if I try to print 10 characters, I get the problem. If I invert the colors, the pixels that 'erase' the first part of the line are all turned-on.

I am trying to eliminate code in the function to see where it happens because there's not much to the main() other than this:

Then the OLED_text() function uses OLED_address() and macros DOUBLE_B_HIGH and DOUBLE_BIT. So there's not that much code.

I will do more tests. If you think of anything else let me know.

Thanks,

Ben

[EDIT] I notice that OLED_Address takes two unsigned int8 as parameters but when you are using the function, you are typecasting to two unsigned int16. Shouldn't the OLED_Address take two unsigned int16 instead?

In the section where you wrote < Now an example program using the driver in 'text mode' only: mainssdtext.c >.

I had not realized that the temporary 'char temp[9]' was 9 bytes long! I didn't pay attention to the main because it is so trivial... but of course, that's where I should have looked first!

I changed it in my code to 11 rather than 9 and now I can print 10 bytes properly on all lines.

So _that_ was the problem!

Ben

temtronic

Joined: 01 Jul 2010Posts: 6549Location: Greensville,Ontario

Posted: Wed Dec 27, 2017 9:39 am

aaarrgh...well that explains a thing or two !
I was going to suggest a picture of the display to find a 'part number', then googling it, thinking it _might_ be specially coded for the original application.
Maybe do that anyway ? to find real documentaion ??
Way too cold here to go out and play....-20*C and kindy windy.
Jay

benoitstjean

Joined: 30 Oct 2007Posts: 302Location: Ottawa, Ontario, Canada

Posted: Wed Dec 27, 2017 9:53 am

Yep, cold here as well in Ottawa @ -24*C temperature but around -30*C with the wind. That's still better than Regina @ -41*C with the wind!

Thanks all for your help.

Ben

Ttelmah

Joined: 11 Mar 2010Posts: 14081

Posted: Wed Dec 27, 2017 2:54 pm

Quote:

I had not realized that the temporary 'char temp[9]' was 9 bytes long! I didn't pay attention to the main because it is so trivial... but of course, that's where I should have looked first!

We have all had moments like that...

I think I'll stick a comment into the file just to make sure it doesn't hit anyone else.
Have done so.

In small text mode, you can put 21 characters on a line.

The point about OLED_address is not that the function is there (it was there in the older code as well), but the syntax of it. If you look the new copy has the test for the #define for SH1106. The newer version is worth having, since it is faster, and slightly 'better' written.

Have a good day.

If you want I have also done a 'big font' character table for it using an actual font that it twice the size. Obviously you lose the small text ability, but the fonts are then really well formed. However uses a lot more ROM. Can send you this if you want to try it. 16*12pixel fonts.

MikeW

Joined: 15 Sep 2003Posts: 175Location: Warrington UK

many thanks

Posted: Thu Dec 28, 2017 3:41 am

@Ttelmah

I just wanted to say thank you for all of your help and work on this OLED driver, and of course all your other help on this forum.

Whilst it sounds a bit "grovelling", it is meant truthfully

Mike

Ttelmah

Joined: 11 Mar 2010Posts: 14081

Posted: Thu Dec 28, 2017 5:08 am

Thanks Mike.

As a question, has the larger font worked for you? (I gave him this a while ago).