Vertical stripes

[Cyb3rn0id]

I've vertical stripes on a classic OLED 128x32 (see attached image) with every font I use. I'm using Arduino IDE 1.8.13 and the latest version of the library (2.1.1). Code is very simple, I want only to show a text:

`#include const DCfont *currentFont = FONT6X8; void setup() { oled.begin(); oled.setFont(currentFont); oled.clear(); oled.on(); oled.switchRenderFrame(); delay(50); }

void loop() { oled.clear(); oled.print(millis()); oled.switchFrame(); delay(1000); }`

[Cyb3rn0id]

Forgot to say: I'm using the "Digispark USB development board" connecting display on I2C lines: Pin 0 (I2C data/SDA) and Pin 2 (I2C clock/SCL). I also enabled chargepump, tried not using switchFrame/switchRenderFrame methods, tried the same display but in white color, all without success.

[datacute]

That looks like the TinyWireM bug with is data buffer size. I think the digispark board manager uses that for its Wire implementation? Maybe try downloading adafruit's latest TinyWireM and including that?

[Cyb3rn0id]

I've Installed "TinyWireM" by Adafruit and included it at top of the code:

<TinyWireM.h>

That issue don't occurs anymore. Thank you! Anyway the "printDoubleSize" method don't works. First of including the TinyWireM, this method produced readable characters even if they had some artifacts in, after including this library, the result is completely unreadable, while the normal "print" method works well

[datacute]

The printDoubleSize is a new experimental feature. I'm attempting to make it usable with normal print functions. https://github.com/datacute/Tiny4kOLED/wiki/Refactoring-to-support-double-sized-rendering In doing so I found a bug whereby it changes the memory addressing mode and doesn't change it back again.

[datacute]

I've released a v2.2.0 which replaces the printDoubleSize methods with new setFontX2 methods, so the wide range of normal print method capabilities are available in double size.

[sfbg]

Had a very similar issue (and other artifacts on a 128x64 oled) with an Olimexino-85. Finally managed to solve it by increasing the buffer in TinyWireM as described in the comments here.