SSD1351 module problems

Hi there,
I am a student of the University of Salerno. :raised_hands:t2: :sweat_smile:
I’m new to Zerynth (started a few days ago) and I tried out the SSD1351 module from the latest release (r2.5.0) on an ESP32 DevKitC connected to a 128x128 OLED display over SPI.

I tried to test it with one of the available examples, but there is something wrong.
Let me explain better: the display turns on and responds to some commands (off(), on(), set_contrast()), but:

  • the color representation is incorrect (e.g. instead of red gives me blue);
  • the text appears in reverse (mirror effect: right to left);
  • these problems I encountered with 96x96 resolution, while the maximum resolution supported by the display (128x128) creates others.

I attach a video of the functioning and the connections I made between MCU and display. (2.9 MB)

Thank you for your answer. :v:t2:

Hi @francescolonardo
Are you sure of the hardware connections? could you test with the continuity of the jumpers with an AVO meter?
Do you have these problems with both of the examples, the blinking image, and print on OLED display?

Thanks for the reply @karimhamdy1,
no, unfortunately I do not have an AVO meter available, but I check with another IDE to run some test code with the same connections and the display responds well (I attach a video about it). (1.9 MB)

And yes, I tested both examples and the blinking image doesn’t even let me see the image (I tried with other images besides the zLogo).

I have a doubt anyway:
I tried to connect the VCC pin (of the display) to both: the 3v3 pin and a digital pin (and with the latter I passed in the constructor of the SSD1351 class the pin name (the ‘pwr’ pin));
why did I make different (better in the test with the 3v3)? The power supply is USB.

I’ll test the display drivers, hopefully soon, and I will tell you the updates.

Operating voltages have ranges, propably 3.3v is the nominal and 5v could be in the upper values of the range, I think the display could be burnt if it is kept above its norminal operating voltage.

I solved.

The problem was with the remapping, and especially this point:
     self._command(CMD_SETREMAP) # Segment remapping
changing it to this:
     self._command(CMD_SETREMAP) # Segment remapping
fixed things up.

I also add the methods:

  • invert()
    Sets the display in complementary mode.
  • normal()
    Sets the display in normal mode.

I attach the modified module. (5.4 KB)

Great!, I will check it and let you know.

I stand corrected, the correct code is:
at the line 225.

I attach the updated module. (5.8 KB)

Can I include some extended ASCII
characters in the available font (Tahoma Regular 7)?
And what if I wanted to use another font (like Roboto)?
Thanks for the feedback.

1 Like

I have the same problem regarding the font for SSD1306, the characters are printed very small.
Thanks for the feedback.

I think fonts are imported from the file in the library directory ssd1351.
So I think you can add the fonts bitmap.
The font data could be taken from other libraries such as this:

Thanks, i have another question:
Once I import these fonts into the file, how do I tell the display to use that specific font?

add another font in and in in line 576 use the other font:
self._set_font(font=fonts.guiFont_Tahoma_7_Regular, font_color=0xFFFF, encode=False)

Let me know how it goes. (1.8 KB)
From a tool, i convert “ABCab” in C language, and in this file i create a new variable (i delete the characters not used in Python)
In “ssd1306” I use self._set_font(font=fonts.guiFont_Tahoma_8_Regular…) but it’s the same.

Do you have any information on the format of, especially the initial header? _set_font is looking for specific information at the beginning of the file and I’d like to know how that relates to the rest of the bit map.

I’ve used to generate bitmaps, and the headers are similar, but not identical. Any help would be appreciated.