Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSD1306 display drivers and font rendering

subalpinecircuits.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: SSD1306 display drivers and font rendering

#11

Post by Graziano_M »

To embed a binary in esp-idf I believe you need something like:

    create_resources(${CMAKE_CURRENT_LIST_DIR}/../../binaries/RAM_APP ${CMAKE_BINARY_DIR}/binaries.c)
    set_property(SOURCE ${CMAKE_BINARY_DIR}/binaries.c PROPERTY GENERATED 1)
Or using `EMBED_FILES`

I just happened to be looking at this very thing today that had to do this: https://github.com/espressif/esp-serial-flasher/blob/master/...

Re: SSD1306 display drivers and font rendering

#12

Post by arghwhat »

generj wrote: post #9
arghwhat wrote: post #5

Go for the SPI version, which is the same chip but just s different breakout board. Many ESP32's can only do 400kHz I2C, whereas their SPI peripheral can often do 80 MHz or more (although you wouldn't want to go that fast here). 400kHz sort of works, but if you also want to handle other I2C devices it can easily become a problem.

I2C is nice because it is (with Adafruit and Sparkfun’s Stemma QT/Qwiik) literally plug and play for beginners, with a wide variety of sensors available. Plus not needing to dedicate a control pin per device added to the bus. Though of course if data throughout is an issue SPI is better than I2C.

I2C is fine for sensors and other low-bandwidth devices, but inappropriate for displays and other high-bandwidth devices.

When used with those kits, you'd use the QWIIC/whatever connector for all the sensors and other low-bandwidth things like I2C is meant for, while the display would be connected with SPI.

(I2C isn't more plug and play than SPI though, and a preterminated plug shouldn't be a big deal.)

Re: SSD1306 display drivers and font rendering

#13

Post by grmnygrmny2 »

Graziano_M wrote: post #11

To embed a binary in esp-idf I believe you need something like: create_resources(${CMAKE_CURRENT_LIST_DIR}/../../binaries/RAM_APP ${CMAKE_BINARY_DIR}/binaries.c) set_property(SOURCE ${CMAKE_BINARY_DIR}/binaries.c PROPERTY GENERATED 1) Or using `EMBED_FILES` I just happened to be looking at this very thing today that had to do this: https://github.com/espressif/esp-serial-flasher/blob/master/...

Amazing! Thank you!

Re: SSD1306 display drivers and font rendering

#14

Post by arghwhat »

grmnygrmny2 wrote: post #7
arghwhat wrote: post #5

Go for the SPI version, which is the same chip but just s different breakout board. Many ESP32's can only do 400kHz I2C, whereas their SPI peripheral can often do 80 MHz or more (although you wouldn't want to go that fast here). 400kHz sort of works, but if you also want to handle other I2C devices it can easily become a problem.

(author here) I've been pondering this, yeah. I'm currently sharing the I2C bus with a DAC and that's working alright, but the refresh rate issue is enough to make me consider SPI. I know the SPI peripheral supports DMA as well, and the I2C one doesn't (sort of? I know there's "async" transmit now but can't tell if that's really doing DMA)

The I2C peripheral is DMA - a write just queues an operation descriptor in a hardware FIFO, and interrupts fire whenever something exciting happens or the FIFO is drained. The synchronous implementation is just blocking on a condition set by the interrupt handler.

But this is exactly the kind of thing the SPI peripheral is meant for. This cannot be said for the I2C peripheral, with its measly fast mode support.

Depending on the chip and your usecase, you might also want to use I2S for your DAC.

Re: SSD1306 display drivers and font rendering

#15

Post by grmnygrmny2 »

mikeInAlaska wrote: post #10

Here's a rust version i made with bitmapped fonts for both i2c and SPI https://github.com/scopenews/minimalSSD1306driver/ I was running this on my pi as a demo. I normally work with C++ on esp32 for these little displays, and in there I use a screen buffer for partial refreshes which makes them very fast !!

That’s very cool - I definitely gotta work on adding partial refreshes. Thanks for sharing!

Re: SSD1306 display drivers and font rendering

#17

Post by atVelocet »

There is also https://github.com/pioarduino/platform-espressif32 which allows one to use Arduino > 3.2 and IDF > 5.4. If you use PlatformIO put this into your platformio.ini

  [espressif32] ; PLATFORM
  platform = espressif32
  board_build.embed_txtfiles = folder/file.ext ; embed null-terminated file(s)
Also have a look at https://docs.platformio.org/en/latest/platforms/espressif32.....

Re: SSD1306 display drivers and font rendering

#18

Post by peteforde »

I really love the u8g2 library, but unfortunately I love my SSD1327 OLED even more. It supports 16-tone greyscale (which u8g2 cannot do) allowing 80s/90s video game style image dithering.

Getting up and running with lvgl was honestly kind of brutal, but now that it's done, I am generally happy with it. As you determined, it's much more of a UI toolkit than u8g2; the sort of thing designed with fancy thermostats and smart watches in mind. u8g2 has a menu toolkit but it is pretty narrow in scope.

I am planning on releasing a bare bones IDF-SDK v5.4 + lvgl 9.x + SSD1327 starter project soon so that I can hopefully save future travelers some pain.

Re: SSD1306 display drivers and font rendering

#20

Post by hadlock »

kaycebasques wrote: post #2

I really love the SSD1306 for its educational value. If you've bought a sensor kit for Arduino or ESP32 or Pico or whatever, chances are decent that you already have an SSD1306 lying around. There's so much example code for it. And the datasheet was pretty easy to grok IMO. My first exposure to it was in the pico-examples repo: https://github.com/raspberrypi/pico-examples/tree/master/i2c... There's a few Rust librari…

I love the SSD1306 simply because a simple arduino can drive it at ~150fps making for some really smooth graphics. 1 bit per pixel monochrome OLED means it's got a tiny frame-buffer, and you can drive it ridiculously fast especially over SPI. It's really great for stuff like realtime gauges etc.
Post reply on HN