SSD1306 : text or graphics mode?

I just switched to Klipper, comming from Marlin+Octoprint, and it has been a matter of hours ! Thanks to the great information all over the Internets. Started yesterday, why didn’t I switch when I first see OctoKlipper in the plugins ???

I’d like to port to Klipper Screen something I developped a couple years back. Long story short, it is a emulator that displays the Marlin UI as an overlay on top of Octoprint, on the Pi display, using the dispmanx APIs. I have been using it a lot, as I prefer a rotary encoder to any button when it comes to moving axis for example (I’m not Hector Salamanca !). My custom Pi hat + rotary encoder emulates a ST7920 or a SSD1306 (jumper on board) in graphics mode (the Marlin GUI uses a U8GLIB fork, that works in graphics mode only).

I searched about the low level displays supported by Klipper, and discovered that for the RepRap Full Graphics Blah, Klipper uses text mode (of course it’s more efficient).

Does Klipper also uses text mode for the SSD1306 ?

Reasons why I ask :

  • emulating the text mode is much more difficult than the graphics mode (char generator required)
  • setting up the wiring, the logic analyzer, the scope, etc. would be a pain if it is just for discovering that it is text mode
  • I was unable to locate the C source files for the Klipper firmware (the answer is in the code, obviously)

BTW : how does Klipper generate the firmware ? Is it in Python, as strings that are later compiled ? I only was able to see the object files…

Does this help?

The firmware that is running on the board is compiled C and the host process Python

Thanks for your answer. It helps, and at the same time it doesn’t !

Had another look to the datasheets. The 7920 LCD has a character table, the 1306 OLED does not (I didn’t remember).

At the time I coded these things, I was unable to understand the datasheets. (and still am !) I hooked a scope and a logic analyzer, watched the packets, and reverse engineered the packets with some help from the datasheets. You can see videos : Marlin Mode for OctoPrint TouchUI (work in progress) - YouTube (and a couple more), and hardware + software on my Git : GitHub - yet-another-average-joe/MarlinOctoHat_PCBs ; all this crap is integrated and properly wired in a 3D printed (of course…) enclosure. My explanations are most likely unclear, hope the videos will be !

Reading again the SSD1306 datasheet (previously was a few years back…), I see no included character table (unlike the ST7920). Meaning Klipper (or the motherboard firmware) generates characters and sends rasters to the OLED. At least, it is a guess…

If Klipper writes rasters/bitmaps to the OLED, it is easy to decode/reencode.
This is what I did, and been using on my printer for some time : OLED, SPI (only had the SPI OLED). No SPI slave support on the Pi. Used a STM32 as a slave, emulating the SSD1306. It receives the packets (vertical pixel blocks), rearanges these pixels as a more conventional bitmap (easy, it is just some matrix mirroring), then sends a signal to the Pi when a bitmap is completed (i.e. when the OLED is refreshed). The Pi receives this “ready to send” signal, and launches the “SPI conveyor belt”, in order to get the data and then display them in the framebuffer using dispmanx. I later emulated the ST7920 graphics mode because of the lack of support for the OLED with the SKR 1.4 (this was fixed a couple days ago with a bugfix release)

This is low level, but not as low level as what does u8glib or Klipper (this is beyond my understanding).

Definitely worth experimenting with the SSD1306 ; now pretty sure Klipper does send bitmaps to the OLED. Easy to see on the LA : should be 8x pages, that can be seen.

The hardware is there, and after all, it is just a matter of running the Pi software as a service instead of a regular software (have to re-learn how to do it !), after declaring the OLED in printer.cfg… Just in case, I had broken out the OLED pins on my custom Pi Hat : easy to wire.

Will keep you informed (don’t remember how to run my crap as a service, but this is what I did before I decide to launch it through Octoprint…). Going the Klipper route, will not look back. Trying to keep some features I had a hard time to create…

(was about to print, but the controller is now back in the lab…)

Now imagine the Klipper MCU with its encoder replacing the Marlin UI…

[EDIT] had a look to the data Klipper sends to the SSD1306 ; it does not refresh the whole display, and uses a different addressing mode. Would have to redo everything from start, not worth the effort. Klipper Screen does nearly everything that I was missing with OctoPrint, and doing with the Marlin UI.
Will build another printer instead !