Pixel draw

[scargill]

Something up (latest version as of this afternoon..

SSD1306 32 pixel display.

      ssd1306_clearScreen(); ssd1306_drawRect(0,0,127,31);
      for (int a=0;a<25;a++)
        {
        ssd1306_putPixel(a+1,29); 
        }

After the rectangle is drawn (ok) - this new line is wiping out the rectangle underneath it.

I think it is writing a vertical line with the correct pixel lit up - but actually writing an entire byte vertically...

[scargill]

The more I think about this, how COULD you write a single pixel - you are not reading the internal buffer back to get the previous state of that byte??

[lexus2k]

Hi Peter,

According to SSD1306 and PCD8544 datasheets, there is no way to read data back from RAM of LCD controllers in spi or i2c modes. The functions in ssd1306.h are direct display control functions. They do not do any buffered output, what is described in the documentation to this library:

 * @warning Please, take into account that there is no way
 * to read data from ssd1306, thus since each byte contains
 * 8 pixels, all other pixels in the same byte will be cleared
 * on the display. Use ssd1306_putPixels() instead.
 * If you need to have buffered output, please, refer to NanoCanvas.

So, the way out is to use NanoCanvas class.

[scargill]

I didn't realise you had another method of doing this. Actually looking at the spec, I could have sworn that you can read that byte and hence mask in the new bit... It would slow the drawing down a little but avoid having to have a huge buffer which is problematic for a 328 chip with other libraries using their own bit of RAM. I'll take a look at the NanoCanvas class... but I know what that means - a 512byte buffer for 32 high display and a 1k buffer for the 64 high display which takes me back to the issues with the u8g library - ie getting dangerously low on RAM.

[lexus2k]

@scargill , Reading ssd1306 datasheet, I still didn't find correct way to read GDRAM via i2c line. In PIN description section they say that R/W pin must be connected to Vss all the time for i2c interface. They have description of read procedure only for parallel interfaces. Although it is mentioned that R/W bit is part of i2c address, it seems that reading over i2c doesn't work. I captured data with Saleae Logic Analyzer, and on attempt to read anything ssd1306 controller returns NACK. Does i2c reading work for you?

Time [s], Analyzer Name, Decoded Protocol Result 2.930090750000000,I2C,Setup Write to [x (0x78)] + ACK 2.930118500000000,I2C,'0' (0x00) + ACK 2.930145625000000,I2C,! (0x21) + ACK 2.930172875000000,I2C,\n (0x0A) + ACK 2.930200000000000,I2C,\n (0x0A) + ACK 2.930227250000000,I2C," (0x22) + ACK 2.930254375000000,I2C,'1' (0x01) + ACK 2.930281625000000,I2C,'7' (0x07) + ACK 2.930326250000000,I2C,Setup Read to [y (0x79)] + ACK 2.930352875000000,I2C,'3' (0x03) + NAK

[scargill]

Hi there

I've not tried reading - but clearly you can read from the device to some extend as you can read registers etc... so I can't see why they would not have you read the RAM.... I'm awaiting shipment of a decent logic analyser, hopefully on receipt of that I can do some tests myself.

[scargill]

Incidentally have you tested your software on ESP8266 where RAM would not be such an issue?

[lexus2k]

Hi Peter,

Yes I tested on ESP8266. I have ESP-01 module with only 2 GPIOs available, I changed Wire.begin() to Wire.begin(0,2). And it works (ssd1306_demo sketch).

[lexus2k]

Hi Peter,

It looks like there is no way to read data from ssd1306 over i2c. I2c is serial mode interface and datasheet says, that serial interface is always read only:

9.1 Data Read / Write To read data from the GDDRAM, select HIGH for both the R/W# (WR#) pin and the D/C# pin for 6800- series parallel mode and select LOW for the E (RD#) pin and HIGH for the D/C# pin for 8080-series parallel mode. No data read is provided in serial mode operation.

[lexus2k]

Hi Peter,

I'm closing this issue, because there is no way to read GDRAM from ssd1306 controller in SPI or I2C mode. If you find the way to do that one day, please reopen the issue.