ATtiny85 SSD1306 128x32 not displaying correctly

[venomboss985]

Describe the bug When compiling the graphics demo for the SSD1306 on an ATtiny85, the display doesn't seem to be displaying the proper output and is rather slow for some reason (see screenshots). I tried a few different things that I thought would improve or fix the issue, but to no avail. These things include: Using 3v and 5v, changing display definition with DisplaySSD1306_128x32_I2C display(-1, {-1, 0x3C, PB2, PB0, 0});, changing the frequency to 400000, 100000, 0, and -1, commenting out software I2C in UserSettings.h, and using the damellis and ATtinyCores.

After all this, I haven't seemed to get the display working properly. I have double checked that the SCL and SDA pins aren't backwards and tried using the default settings with the wiring in the wiki under hardware setup despite those pins not being the hardware I2C pins listed on the ATtiny85's datasheet. I'm not sure what the issue could be and I am hoping to get some suggestions to fix this. Any and all help is appreciated and thank you in advance.

To Reproduce Steps to reproduce the behavior:

1. Open 'File/Examples/lcdgfx/demos/ssd1306_demo'
2. Flash to ATtiny85
3. Setup wiring using default settings (SCL->Pin 3, SDA->Pin 4)
4. Turn power on

Expected behavior Clear image with readable text and recognizable images.

Screenshots https://github.com/lexus2k/lcdgfx/assets/45863773/28ef83aa-5561-4b2f-925b-9b8baad4f5e8

Please complete the following information:

• Library version: 1.1.5
• Display: SSD1306 128x32
• OS: Windows 11 Pro 22H2
• Platform: ATtiny85
• IDE: Arduino IDE 2.1.0

Additional context N/A

[lexus2k]

Lcdgfx supports only software i2c for Attiny85. You can find the implementation for Attiny85 in lcdgfx/src/lcd_hal/avr/i2c_embedded.cpp and lcdgfx/src/lcd_hal/avr/i2c_embedded.h files.

High frequencies are not supported because of that. In your case I'm sure that you have an issue with timings. The library supports internal pull-ups for software i2c, but you can additionally apply 10K to VCC resistors to SCL and SDA lines.

The simple test could be to run simple clear() test to check if display becomes black after app start.

[venomboss985]

I tried it with 1k, 10k, and no pullups; they all seem to produce the same output. What's weird is that it will initially make that scattered pixel pattern, then when given enough time, will start printing text. I went and made a simple test:

#include <lcdgfx.h>

DisplaySSD1306_128x32_I2C oled(-1);

void setup() {
    oled.begin();
    oled.setFixedFont(ssd1306xled_font6x8);
    // oled.clear();
}

void loop() {
    oled.clear();
    oled.printFixed(0, 8, "ATtiny85", STYLE_NORMAL);
}

What appears to be happening is when the screen initializes, it displays the scatter pattern. Then when oled.clear(); gets called, it takes forever for the screen to actually clear and takes a long time again to write the text to the screen. I knew software I2C was slow, but I didn't think it was this slow. Do you know why updating the screen is super slow and potential fixes (outside of using a faster micro with hardware I2C)? I couldn't find any example projects using an ATtiny85 and lcdgfx, so I'm not sure if this is what I should be expecting.

[lexus2k]

At what frequency do you run Attiny85? 1MHz? This is the only reason, why software i2c is very slow. For example, Arkanoid game was tested for Attiny85 with BSP from https://github.com/damellis/attiny. And it works.

[venomboss985]

I've been using 8MHz for everything so far. I just now tested it with 16MHz (which I didn't know the ATtiny85 could do until now), and the screen is updating much faster. The code I've written previously makes the display super flickery and removing the oled.clear(); in the loop fixes that, but then the scattered pixels come back. I see there's the nano engine, so I'll have to experiment with that at 8MHz a bit to see if I can do this project. Thank you so much for the assistance, it is much appreciated.