OLED display with I2C (SSD1306) in Raspberry Pi - Time & Space Complexity
When working with an OLED display using I2C, it's important to understand how the time to update the screen changes as the amount of data grows.
We want to know how the program's running time changes when sending more pixels or commands to the display.
Analyze the time complexity of the following code snippet.
import board
import busio
from adafruit_ssd1306 import SSD1306_I2C
# Initialize I2C and display
i2c = busio.I2C(board.SCL, board.SDA)
display = SSD1306_I2C(128, 64, i2c)
display.fill(0) # Clear display
for y in range(64):
for x in range(128):
display.pixel(x, y, 1) # Turn pixel on
display.show() # Update display
This code turns on every pixel on a 128x64 OLED display using I2C communication.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Setting each pixel on the display inside nested loops.
- How many times: 128 (width) x 64 (height) = 8192 times.
As the display size grows, the number of pixels to set grows with the total number of pixels.
| Input Size (pixels) | Approx. Operations |
|---|---|
| 10x10 = 100 | 100 pixel sets |
| 100x100 = 10,000 | 10,000 pixel sets |
| 1000x1000 = 1,000,000 | 1,000,000 pixel sets |
Pattern observation: The operations grow proportionally with the number of pixels, so doubling width and height quadruples the work.
Time Complexity: O(n)
This means the time to update the display grows directly with the number of pixels you want to change.
[X] Wrong: "Updating the display takes the same time no matter how many pixels I change."
[OK] Correct: Each pixel update requires time to update the internal buffer, so more pixels mean more time spent preparing data before sending over I2C.
Understanding how hardware communication scales with data size helps you write efficient code and explain performance in real projects.
"What if we only update a small portion of the display instead of all pixels? How would the time complexity change?"
Practice
show() method when using an SSD1306 OLED display with I2C on a Raspberry Pi?Solution
Step 1: Understand the display buffer concept
The OLED display uses a buffer to store what will be shown on the screen before updating.Step 2: Role of
Theshow()methodshow()method sends the buffer content to the OLED, updating the visible display.Final Answer:
To update the display with the current buffer content -> Option AQuick Check:
show()updates screen [OK]
- Confusing show() with clear()
- Thinking show() initializes I2C
- Assuming show() changes brightness
Solution
Step 1: Identify the method to clear the buffer
The SSD1306 library usesfill(0)to fill the buffer with zeros, effectively clearing it.Step 2: Confirm other options are incorrect
Methods likeclear(),reset(), orerase()are not standard in this library.Final Answer:
oled.fill(0) -> Option CQuick Check:
Clear buffer = fill(0) [OK]
- Using non-existent clear() method
- Confusing fill(1) with clearing
- Trying reset() which is not in library
oled.fill(0)
oled.text('Hi', 0, 0)
oled.show()Solution
Step 1: Analyze the code sequence
The buffer is cleared withfill(0), then 'Hi' is drawn at coordinates (0,0).Step 2: Understand coordinate system and show()
Coordinates (0,0) place text at top-left. Callingshow()updates the display.Final Answer:
The text 'Hi' appears at the top-left corner -> Option DQuick Check:
Text at (0,0) shows top-left [OK]
- Assuming text() needs more arguments
- Thinking (0,0) is bottom-right
- Forgetting to call show() to update
oled.text('Hello', 10, 10)
oled.fill(0)
oled.show()
What is the problem?Solution
Step 1: Check the order of commands
Text is drawn first, thenfill(0)clears the buffer, erasing the text.Step 2: Understand correct sequence
Clear buffer first withfill(0), then draw text, then callshow().Final Answer:
Calling fill(0) after text() clears the buffer -> Option BQuick Check:
Clear after draw erases text [OK]
- Thinking coordinates are invalid
- Assuming init() is needed every time
- Believing text case matters
Solution
Step 1: Understand how to avoid leftover pixels
Clearing the buffer before drawing new text removes old pixels that would remain otherwise.Step 2: Proper update sequence for smooth scrolling
Each frame: clear buffer withfill(0), draw new text, then callshow()to update display.Final Answer:
Clear buffer with fill(0), draw new text, then call show() each frame -> Option AQuick Check:
Clear before draw + show() = smooth update [OK]
- Not clearing buffer causes ghosting
- Calling show() only once delays updates
- Using non-existent clear() method
Ready to prove it?
Pass the test and this pattern moves unknown
