←back to thread

76 points todsacerdoti | 3 comments | | HN request time: 0.554s | source
1. bmink ◴[] No.43686107[source]
I’m actually working on code for esp-idf / SSD1309 right now, a little bigger than the 1306. I went through a similar arc as OP.

I was actually surprised / disappointed by the poor quality of the drivers out there. If you instrument and log the bytes u8g2 sends to the device and how the buffer is sent, you see it’s pretty messy, inefficient and hacky. Seems like everyone copy+pasting everyone else’s code, without understanding fully.

So in the end I just decided to draw into a local buffer and then send that buffer in one single transaction to the display.

Once you figure out the data sheet it’s actually very easy to program these displays. For example, to test any SSDxxxx display, you need to send all of two bytes: 0xaf (display on), 0xa5 (all pixels on)

I am now looking at SSD1322, which is both grayscale and has enough internal RAM for two buffers for even smoother drawing (write into a non-displayed region of the RAM and then change the display offset)

replies(2): >>43686824 #>>43688978 #
2. grmnygrmny2 ◴[] No.43686824[source]
I discovered the same thing with u8g2, and digging through the abstraction layers it felt like improving it was going to be impossible. Sending a single transaction with a framebuffer is so much simpler and faster.

SSD1322 looks great and might be something I look at for the future..

3. mrheosuper ◴[] No.43688978[source]
that's the problem with Arduino library, they are hacky and messy