0.96 inch LCD IIC module

[rudy]

Does anybody can give a tip regarding of simple program, just to light one pixel is enough, of LCD with SSD1306 controller, without any library, I want to make my on code.

Regards.

[temtronic]

simple, yes, easy well that all depends.

Just read the datasheet for the LCD module you have and see what the commands are.Usually the manufacturer will have 'sample' programs either in the datasheet or posted on their website.

I'm assuming the LCD controller/module is 3 volts so I'd use a 3 volt PIC to simplify the hardware to just PIC and controller otherwise running a 5 volt PIC with a 3V device will be costly.

Jay

[Ttelmah]

Seriously, just look at some of the driver attempts posted here. For example:

<http://www.ccsinfo.com/forum/viewtopic.php?t=52836&highlight=ssd1306>

Key is that the basic functions to send data and commands, here are only a handful of lines, and are easy for you to either use, or re-write for your own needs. Then the initialisation sequence is straight from the data sheet, and also shown, so all that is left, is to send the command/data to turn on the required pixel.

[rudy]

[MikeW]

rudy,

I spent ages trying to get it to work properly.

All of the Arduino etc drivers allocate 1K RAM, and the various font/line/circle routines just write to the ram buffer, then dump the 1K into the SD1306.

The SD1306 is addressed as 8 pages of 8 lines ( from recollection).

1K RAM is tough in PIC's easy in ARM or any Atmel avr.

I had a go, and it sort of worked.

if you pm me, i will send you what I have.

Mike

[Ttelmah]

Yes.

This is the common problem about displays. To 'change' something like a pixel, unless you use a RAM buffer, you have to read back each byte you are wanting to alter, then write this back. On this device, using I2C, this involves sending the command to read from the memory, sending the address, then switching to read, and reading the byte back, then making the change to the byte, sending the command to write, sending the address again (since it automatically increments), and writing the byte back. Ouch.
Whereas since the address autoincrements, if you have a copy of the display in RAM, you can just make the change on the buffer and write this sequentially to the display.

[rudy]

OK!!

But this is not what I am seeking for! Sorry to say that, but it seems to me that Arduino tries to jump a little of the knowledge. It seems like a shake-and-bake solution. I see many people that don´t really understand what is going on, doing some kind of complex things, it is not bad for one side, but the drawback is that some people don´t think too much, this is my feeling, may be wrong.
I just looking for the initialization of the LCD, some Friend in the top says, “Read the datasheet”, and he is completely right about this. In fact, I am only trying to save some time, but I am sure that is possible to do the routine much more DRY, without these lots of ready solution. I will follow his advice and, when I have time, I will post here my solution, not a shake-and-bake one.
Thanks for all help and please don´t misunderstand my words, ok?
Best Regards.

[Ttelmah]

The reason the Arduino does it that way, is for speed.

The basic operations to send a data/control byte/word to the display, are half a dozen line routines, and are in the code I pointed to. There is no reason at all, given these, that for a simple routine to 'set a pixel', can't be generated (though you are going to have to send quite a lot of initialisation first to configure the chip - the routine to do this is also in the code I pointed to). With the chip initialised, and the display cleared, setting a pixel just becomes a matter of writing a byte with the required bit set into a specific address.

[Ttelmah]

As an 'add on' to this, I've just posted a modified driver for this chip into the code library.

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

This allows you to use it as a _text_ LCD, with very little RAM.
Included with this is a 'bargraph' function that allows a bar to be drawn using special characters from the font.

Or to define a graphic window, and then use text elsewhere, and draw small graphics into this window (example with 64*16 included). You can draw using the same window, one set of graphics, put this on the screen, and then another set somewhere else.

Then finally, I've included a minimum program to just set a pixel using the raw functions I've provided. Take them apart and write your own, if you don't want my library.

The key point is that this allows stuff to be put on this display using only a little RAM.

It's also more efficient than the existing drivers. Nobody seems to have realised that you can burst transmit the setup commands as well as the actual data. This driver does this.

Remember this chip is a 3.3v device.