←back to thread

SSD1306 display drivers and font rendering

(subalpinecircuits.com)
76 points todsacerdoti | 2 comments | 14 Apr 25 17:08 UTC | HN request time: 0.528s | source
Show context
arghwhat ◴[14 Apr 25 17:54 UTC] No.43684165[source]▶
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.

replies(2): >>43684255 #>>43684297 #
grmnygrmny2 ◴[14 Apr 25 18:01 UTC] No.43684255[source]▶
(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)
replies(2): >>43685194 #>>43689251 #
1. arghwhat ◴[14 Apr 25 19:26 UTC] No.43685194[source]▶
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.

replies(1): >>43685944 #
2. grmnygrmny2 ◴[14 Apr 25 20:26 UTC] No.43685944[source]▶
Ah! That makes sense, thanks!

And yes, the audio data runs over I2S - the chip I’m using just uses I2C for control.