ssd 1306 initialization problem

[rudy]

Hi there.
The SD1306 datasheet is a mess, poor work done by SOLOMON SYSTECH unfortunately. Well, I am trying to initialize the LCD with horizontal addressing mode, but besides tons of changes and attempts, no positive results!!! The only thing I never tried is to first initialize the LCD, and after that, prior to send data, change the memory access to horizontal, I will give a shot moreover at night.
This is my procedure to initialize the LCD, is there anything wrong with this code? I inform that, apparently, everything works well, besides of no change in memory access that remains always as page access.

Any help or clue will be much appreciated.

Regards.

[MikeW]

This code works a treat.

just change for your chip, and SDA/SCL pins. no otherr changes are needed.

if it still doesnt work, its a hardware problem such as

pullup resistors etc

http://www.ccsinfo.com/forum/viewtopic.php?t=54453

[rudy]

Mike, Thanks.

Anyway, the logo that I am trying to show only appears in the top of the LCD (PAGE 0), like the page access is always running. It don´t seem to me to be a pull up resistor problem, once that commands like Entire LCD on (at the very end of code) works very fine.
I really don´t know what to do, but there is also an RDA5807 FM radio on the line, I will take it out from SDA and SCL pins, and check how it goes.
Thank you.
Regards.

[Ttelmah]

If you just want to write a logo, then the 'draw_window' function in my driver, can do this for you. It just writes a block of memory (from the area defined as 'window_buffer' if you are using the graphic functions I supply), directly to any 'cell' location on the display (0-127 x 0-7). The block it transfers is defined by the 'WINDOW_WIDTH' & 'WINDOW_HEIGHT' defines, so easy to change. It is easy to rewrite.

Don't get confused by the layout of the screen. The pixels run vertically down the columns, and you advance to the next column when you get to the bottom. Switching mode will only help you if you are going to fill an entire row or column, which with a small logo is unlikely to happen. This is why the draw_window function calls the address function when it gets to the end of each column it is sending.

[rudy]

Ttelmah, I disagree with you, a little!
Your code is good, no doubt. It clear my mind trough this mess that is the datasheet, unfortunately, and congratulations to you to find a way in this confusion.
I see that there are three different ways to address the LCD. This three ways, in my understanding, is for avoid you to move large quantities of data every time you need to update the LCD information. The horizontal and vertical memory data access is exactly to do this, depending only of the way you draw your initial image. Once you move the entire LCD initial information, with a little quantity of code, you can access any particular portion of the LCD, making small changes where needed, it is poor mentioned in datasheet, but for sure it does this.
I am sure that, once that I discover how to change this memory access mode, I will be able to do what I need. It is almost what you did in the “draw_window” function, but it is slight different. When finish I will update my approach.
Thank all anyway.

[Ttelmah]

Where I disagree with you is in using horizontal address mode.

Problem is that since the data is organized vertically in the display, you end up writing eight bits vertically, then moving horizontally, across the row, and then going back to continue the next row of the character. I'd suggest that it is much easier to use the vertical mode, and complete each column in turn.
I'd say that horizontal mode only makes sense, when the display is operating rotated the other way.

Then you need to ensure that the limits are turned off after your logo is written, otherwise any subsequent write is going to wrap again.

I'd also split things up. Set the unit up, then change modes.
For instance, this is my 'contrast change' routine:

[rudy]

Kkk (Leffen), ok. (This is a very good discussion, but allow me to disagree again.)
From my point of view, in VERTICAL access mode, you can go through, for example, COL 0 to COL 7 straight, in this case there shall be 64 bits directly. I see that vertical and horizontal depends only of your graphic design, better, how you generate the array of bits (bytes) to be send to LCD, just that.
Anyway, give me some time to deep check this issue, I may be wrong also. The good thing is that for sure this will help lots of people who seek for information about this subject.
Regards.

[Ttelmah]

The display always _outputs_ the data one byte at a time organised vertically (in the standard organisation). You don't get 64 bits across a row, you get 64 (or 128) bytes across the row, each carrying 8 bits vertically.
So you can't send 64 bits sequentially along a row (it'd be lovely if you could). Look carefully at the output diagrams showing how the drive bits are derived from the bytes. The horizontal/vertical modes, change how you increment through the bytes, when sequential ones are sent, not how the bytes are organised on the display. Since the bytes are organised vertically, I prefer to finish each column in turn.

[rudy]

Ttelmah, good day!

Well, I was right!!!!

I also discovered an error in the “MESS” datasheet (How many must have more..). The error is at page 34, concerning with PAGE access, as follows:

Where you read “Set the lower start column address of pointer by command 00h~0Fh.”

You must note that first segment (column) is not 0x00, but 0x01, this is also valid for 0x0F, the end column number is 0x7f or 0x80 (not tested the end column number)

Also, where you read “Set the upper start column address of pointer by command 10h~1Fh” it shall be exactly as above, someone please test all situations and update the forum. I will do it myself, but don't know when.

Regarding with the issue of PAGE, HORIZONTAL and VERTICAL Addressing mode. What I was trying to explain is that I should be able to move 1024 bytes of information in a single shot, if I started by using H or V addressing modes, depending only of the way my image was build. You can use LCDAssistant or FastLCd to do your logos, I use Windows Paint to draw and LCDAssistant to convert bitmap to my array. FastLcd don't work fine.

In my case, after initialization, you can see two lines of code, i2c_write(0x20); and i2c_write(0x00);.
The first, I am accessing register 0x20, that handles the memory access mode, the second, I move 0x00, changing to H memory access mode. Once I did that, I could move the entire 1024 bytes in just one loop, avoiding to move 128 bytes, change page, plus 128bytes and change page again till end of page 7, so my code is very light and fast.

Of course I will need to access other specific parts of the LCD, but now, and only now I will have to deal with PAGE, COLUMNS and so on, just to rebuild small parts of the image.

Try this simple example by yourself and check how it goes.

Hope to that this code helps more peoples.

[ckielstra]

Thanks for sharing your code and putting in all the effort.

Just a few remarks, not related to your issue but will make you a better programmer:
1) Using the goto command is considered bad programming as it soon leads to spaghetti code. The command is in the C-language to make it possible to create special code like exception handlers. I'm not a hardliner against the use of 'goto' as I used to be, but for situations like here it is the wrong solution.

2) Why use a watchdog? In my experience they cause more problems than they solve. Only when no user is present to reset your device it makes sense having a watchdog. In all other cases they cause code clutter and hard to find problems.

3)

[Ttelmah]

What I have to ask (still) is why you were fiddling with the mode?.
To burst transmit 1024 bytes, you only need to set the write address to 0, and write 1024 bytes. Nothing else needed. No mode changes etc..

This is what my OLED_CLS function does. It writes 1024 bytes (assuming the display is 128*64) of either all 1's or all 0's (depending if you have the display inverted), straight to the display.

[rudy]

Answering ckielstra!

Thanks, I know this is not the best way, but I learn this way and so now I could not change. For each value of page I write some code to do something different.

I don´t know, it seems more structured to me I guess, that´s why I never changed the way I write. But thank you anyway.

Regarding with WDT, I never had problems with it, and always leave it running to restart CPU if any crash happens.

The code is not finished yet, so there will be more "pages" to hold all the functions needed. Please don´t blame me, everybody says it is wrong, it is not the first time I heard that, but works for me.

Answering Ttelmah.

In fact, I had some trouble to true understand your code, my stupidity only, I am not so skilled C writer.

I had tried the burst transmission you provided, but there is some other functions that is needed to change page address and so on. When you write to more powerful processors, there may be more ram memory. In my case, for 16F688, there is not.

So I trying to enjoy the fact that the pointer is automatically updated when you reach the end of page columns, avoid more codes to do this, that´s why.

I soon discover some problems that I will try to solve moreover with H or V address mode, for example after a power up. Today morning, before I left to work, I turned on the power, and the display only was updated on the first page (PAGE=0).

It seems to me that something still need to be done at the lcd_init() code. As soon as I find out I will update the final code.

Thanks all!

[Ttelmah]

The pointer does this all the time. No need to change anything!.
Also look at how I send the initialisation. No need for loads of separate calls, I just write the data straight from a ROM array.

[rudy]

Ttelmah, you are right.

Checking your code I could see 0x20 plus 0x00, indicating that your code also pointed to H address mode. Unfortunately, my LCD module stops to answer to this command, it simple just don’t change more for H or V address mode, just remain fixed in 0x02 that is PAGE address.
I cannot wait long time to receive another one, to check if it is a problem in my code or some damage to the module itself, so I moved to work with PAGE address mode only.
I will check if others registers may have something with this issue, like clock, mux and so one. Anyway, moreover I will post my code to share with all.
Regards.