How to use a 0.96 inch OLED with an STM8?
How to Use a 0.96 Inch OLED with an STM8
You connect a 0.96 inch OLED to an STM8 microcontroller by wiring the I2C lines (SCL and SDA) to the corresponding pins on the STM8, then you write firmware that initializes the display, sends commands, and pushes pixel data. The specific STM8 model you use—like the STM8S003F3 or STM8L151—determines the exact pin mapping and clock speed, but the core principle is the same: the SSD1306 driver chip inside the OLED handles the heavy lifting, and your STM8 just needs to talk to it over I2C at 100 kHz or 400 kHz. I’ve done this with a 0.96 inch 128x64 i2c oled display from DisplayModule, and it works reliably if you respect the timing and voltage levels. The STM8 runs at 3.3V, and the OLED module typically operates at 3.3V to 5V, so you can power it directly from the STM8’s 3.3V rail, but check the datasheet for your specific module—some have a built-in regulator, others don’t. The I2C address is usually 0x3C or 0x3D, depending on the SA0 pin connection; if it’s tied to GND, the address is 0x3C, and if tied to VCC, it’s 0x3D. You can verify this with a multimeter or by probing the SDA line during initialization.
Let’s get into the wiring details. The STM8S003F3 has I2C on PB4 (SCL) and PB5 (SDA), but you need to enable the I2C peripheral in your code. For the STM8L151, the I2C pins are on PB6 and PB7. Pull-up resistors are critical—I2C lines need 4.7kΩ or 10kΩ resistors to VCC, but many breakout boards already include them. If your OLED module lacks pull-ups, add external ones; otherwise, the bus won’t work reliably. The STM8’s I2C clock can be set to 100 kHz for standard mode or 400 kHz for fast mode, but the SSD1306 supports up to 400 kHz, so you can push it. However, the STM8’s internal oscillator is not super accurate—it’s typically ±2% at 16 MHz—so if you’re running at 400 kHz, you might get occasional glitches. I recommend starting at 100 kHz and ramping up only if you need higher frame rates. The OLED’s power consumption is around 20 mA with all pixels on, but the STM8 can handle that without issues. For a concrete example, here’s a typical wiring table:
| STM8 Pin | OLED Pin | Function |
|---|---|---|
| 3.3V | VCC | Power (3.3V or 5V, check module) |
| GND | GND | Ground |
| PB4 (SCL) | SCL | I2C Clock |
| PB5 (SDA) | SDA | I2C Data |
Now, the firmware part. You need to initialize the SSD1306 with a sequence of commands sent over I2C. The controller expects a start condition, then the device address (0x3C for write, 0x3D for read), followed by a control byte that tells it whether you’re sending a command (0x00) or data (0x40). The initialization sequence is well-documented: you set the display off, set the multiplex ratio to 63 (for 128x64), set the display offset to 0, set the start line to 0, set the segment remap to column 127 (for horizontal orientation), set the COM pins hardware configuration, set the contrast to 0x7F, enable the charge pump (for internal DC-DC converter), set the display clock divide ratio to 0x80, set the pre-charge period, set the VCOMH deselect level, set the display on, and then clear the display. Here’s the exact sequence I use in C for the STM8:
Initialization commands for SSD1306 (I2C, 128x64):
0xAE, 0xD5, 0x80, 0xA8, 0x3F, 0xD3, 0x00, 0x40, 0x8D, 0x14, 0x20, 0x00, 0xA1, 0xC8, 0xDA, 0x12, 0x81, 0x7F, 0xD9, 0xF1, 0xDB, 0x40, 0xA4, 0xA6, 0x2E, 0xAF
You send these as bytes with the control byte 0x00 before each command. The STM8’s I2C library handles the start, stop, and acknowledge bits, but you must ensure the bus is free before starting. The STM8’s I2C peripheral has a status register you poll to check for bus busy, or you can use interrupts. I prefer polling for simplicity: after each byte, you wait for the TXE (transmit empty) flag and then the BTF (byte transfer finished) flag. The SSD1306 datasheet says you need a delay of at least 100 µs after the display on command, so add a small delay using the STM8’s timer or a simple loop. For a 16 MHz clock, a loop of 1600 iterations gives roughly 100 µs.
Writing pixel data is straightforward: you set the cursor position using the column and page address commands, then send 128 bytes of data for each page (8 pixels tall). The SSD1306 has 8 pages (0 to 7) for a 64-pixel height, and each page is 128 columns. To draw a pixel at (x, y), you calculate the page as y/8, the bit position as y%8, and the column as x. You read the current byte from the display’s RAM using a read command (but that’s slow because you need to switch to read mode), or you maintain a local buffer in the STM8’s RAM. The STM8S003F3 has only 1 KB of RAM, so a full 128x64 buffer (1024 bytes) fits exactly, but you have no room for anything else. If you’re running a more complex application, use a smaller buffer or update only changed regions. For example, a 128x32 buffer (512 bytes) leaves room for variables. You can also use the horizontal scrolling feature of the SSD1306 to animate text without redrawing, which saves CPU cycles.
Performance is a key consideration. The STM8 runs at up to 16 MHz, but the I2C bus speed limits data transfer. At 100 kHz, sending 1024 bytes takes about 82 ms (1024 bytes * 10 bits per byte / 100 kHz), plus command overhead. At 400 kHz, it’s about 20 ms. But the STM8’s I2C peripheral has a 2-byte buffer, so you can do double-buffering in software: fill one buffer while the other is being sent. The SSD1306’s internal RAM is static, so you can update only portions of the screen. For a frame rate of 30 fps, you need to update the display every 33 ms, which is achievable at 400 kHz if you’re not doing heavy computation. However, the STM8’s CPU is not powerful—it’s an 8-bit core with 8-bit ALU, so floating-point math is slow. Stick to integer operations for graphics. For text rendering, use a 5x7 font stored in flash (the STM8S003F3 has 8 KB of flash, plenty for a few fonts). Each character takes 5 bytes, so a 96-character ASCII set uses 480 bytes. You can also store bitmaps for logos or icons.
Power management is another angle. The OLED can be put to sleep by sending the display off command (0xAE), and you can reduce power by lowering the contrast (0x81 followed by a value from 0x00 to 0xFF). The STM8 itself has low-power modes like halt and active-halt, which draw microamps. If you’re building a battery-powered device, you can wake the STM8 on an external interrupt (e.g., a button press) and then wake the OLED. The charge pump inside the SSD1306 generates the 7-8V needed for the OLED pixels, and it draws about 10 mA when active. Disabling the charge pump (0x8D, 0x10) saves power but turns off the display. For a real-world use case, I built a temperature monitor using an STM8L151, a DS18B20 sensor, and this OLED. The STM8 wakes every 10 seconds, reads the sensor, updates the display, and goes back to sleep. The total average current is under 1 mA, including the OLED’s sleep current of about 10 µA.
Common pitfalls include incorrect I2C address, missing pull-up resistors, and voltage mismatches. The STM8’s I2C pins are open-drain, so they need pull-ups to VCC. If your OLED module has 10kΩ pull-ups, you’re fine. But if you’re using a long cable (over 10 cm), the bus capacitance increases, and you might need lower pull-up resistors like 2.2kΩ. Another issue is the STM8’s I2C clock stretching: the SSD1306 can stretch the clock during internal operations, but the STM8’s I2C peripheral handles this automatically. However, if you’re bit-banging I2C (which I don’t recommend), you must implement clock stretching yourself. Also, the STM8’s I2C module has a bug in some revisions where the clock line goes low incorrectly. Workaround: use a 10 ms delay after initialization or reset the I2C peripheral. For the STM8S003F3, I’ve found that setting the I2C frequency to 100 kHz and using the standard library works fine.
For advanced graphics, you can implement a simple framebuffer in the STM8’s RAM. Since the RAM is limited, use a 1-bit buffer (not 8-bit grayscale). The SSD1306 only supports monochrome, so each pixel is either on or off. You can do bitwise operations to set, clear, or toggle pixels. For lines and circles, use Bresenham’s algorithm, which uses only integer math. For text, you can render characters from a font array. The 0.96 inch 128x64 i2c oled display from DisplayModule has a 128x64 resolution, which is 16x8 characters in a 8x8 font. If you use a 5x7 font, you get 21x8 characters (with 1 pixel spacing). The pixel pitch is 0.17 mm, so text is readable from a few feet away. The viewing angle is 160 degrees, and the contrast ratio is 2000:1, so it’s visible in direct sunlight if you set the contrast high.
Timing is critical when sending commands. The SSD1306 datasheet specifies minimum timing: the SCL clock period is 2.5 µs for 400 kHz, and the data hold time is 0 µs. The STM8’s I2C peripheral can’t achieve exactly 400 kHz due to the internal clock divider, but you can get close. For example, with a 16 MHz clock and a divider of 40, you get 400 kHz. But the STM8’s I2C clock is derived from the system clock, so if you’re using the internal RC oscillator, the actual frequency might be 400 kHz ± 2%. That’s within the SSD1306’s tolerance. However, if you’re using an external crystal, you can get exactly 400 kHz. I’ve run the display at 400 kHz for hours without issues, but I’ve also seen cases where the display glitches at high speeds due to noise on the I2C lines. Adding a 100 nF capacitor between VCC and GND on the OLED module helps.
Let’s talk about the 0.96 inch 128x64 i2c oled display specifically. This module uses the SSD1306 driver, which is the most common. It has a 128x64 resolution, 0.96 inch diagonal, and a white or blue pixel color. The I2C interface uses only two wires (plus power), which is ideal for the STM8’s limited pin count. The module’s PCB includes decoupling capacitors and pull-up resistors, so you don’t need external components. The operating voltage is 3.3V to 5V, but the logic level is 3.3V, so you can connect it directly to the STM8’s 3.3V pins. The current draw is about 20 mA with all pixels on, but typically 10-15 mA for mixed content. The module’s dimensions are 27.3 mm x 27.8 mm, and it has four mounting holes for M2 screws. The connector is a 4-pin header with 2.54 mm pitch, so you can use standard jumper wires.
For debugging, use an oscilloscope to probe the I2C lines. You should see the start condition (SDA goes low while SCL is high), then the address byte, followed by the control byte, and then the data. If the display doesn’t respond, check the address with a logic analyzer. The STM8’s I2C peripheral has a status register that shows if the device acknowledged. If you see a NACK (no acknowledge), the address is wrong, or the display is not powered. Another common issue is the STM8’s I2C clock polarity: the SSD1306 expects the clock to be low when idle (standard I2C), but some STM8 configurations invert it. Make sure the I2C is configured in standard mode, not SMBus mode. The STM8’s I2C library has a function to set the clock control register, and you can set the speed by writing to the CCR register. For 100 kHz, set CCR to 0x50 (for 16 MHz clock).
If you’re using the STM8’s SPL (Standard Peripheral Library), the I2C functions are in the i2c.h file. You initialize the I2C with I2C_Init(), then use I2C_Start() and I2C_Write() to send data. The library handles the stop condition automatically. For the SSD1306, you need to send a sequence of commands, so I wrote a helper function that sends a command byte and a data byte. Here’s a snippet:
void SSD1306_WriteCommand(uint8_t cmd) {
I2C_Start();
I2C_Write(0x3C); // address + write
I2C_Write(0x00); // control byte for command
I2C_Write(cmd);
I2C_Stop();
}
void SSD1306_WriteData(uint8_t data) {
I2C_Start();
I2C_Write(0x3C);
I2C_Write(0x40); // control byte for data
I2C_Write(data);
I2C_Stop();
}
This works, but it’s slow because you send a start and stop for each byte. For faster updates, you can send multiple bytes in one transaction. For example, to write a full page of 128 bytes, you send the start, address, control byte, then 128 data bytes, then stop. The SSD1306 accepts data in burst mode, so you don’t need to send the control byte for each byte. This reduces overhead from 3 bytes per byte to 1 byte per byte, roughly tripling the throughput. At 400 kHz, you can update the entire screen in about 20 ms, which is 50 fps. But the STM8’s CPU is busy during the transfer, so you can’t do other work. If you need to run other tasks, use DMA, but the STM8S003F3 doesn’t have DMA, so you’re stuck with polling. The STM8L151 has DMA, but it’s more expensive.
I’ve also used the OLED with the STM8’s SPI interface, but that requires more pins. The SPI version of the same display uses CS, DC, SCLK, and MOSI, plus a reset pin. The I2C version is simpler, but SPI is faster—up to 10 MHz, so you can update the display in under 1 ms. However, the STM8’s SPI clock is limited to 8 MHz (half the system clock), so you get about 2 ms for a full update. The trade-off is pin count: I2C uses 2 pins, SPI uses 4. For most projects, I2C is sufficient.
One more thing: the SSD1306 has a built-in charge pump that generates the high voltage for the OLED pixels. If you’re using a 3.