In this guide
You soldered the last wire, powered the board, and the screen shows… nothing readable. Or it works on your desk and turns into a grey mirror the moment you take it outside. Or the battery that was supposed to last a week dies by lunchtime. In every one of these cases the display was chosen last, by price or by looks, and the display is exactly what is failing.
A display is not a component you swap late in a project. It decides the enclosure opening, the board layout, the battery size, the microcontroller you need, and a chunk of the firmware. This guide explains the four display families a student project actually uses — character LCD, OLED, colour TFT, and e-paper — how each one makes light, what it costs in power and pins, and how to pick between them with a five-question test you can run before you order anything.
Quick answer
A display turns data into something a person can read, and the right one follows your hardest constraint, not the prettiest picture. Pick a character LCD for cheap text readouts, an OLED for crisp small graphics on low power, a colour TFT for fast full-colour interfaces, and e-paper for battery-powered signs that must stay readable in sunlight.
| Display | Best for | Watch out for |
|---|---|---|
| Character LCD (16x2) | Cheap text, fixed readouts | No graphics, needs a backlight at night |
| OLED (SSD1306) | Small crisp graphics, low power | Burn-in on static screens, small sizes |
| Colour TFT (ILI9341) | Full-colour UI, fast updates | Backlight eats the battery, needs RAM |
| E-paper | Battery signs, sunlight-readable | Very slow refresh, no animation |
How each display makes light
Everything about a display follows from how it makes light. There are only three answers, and they explain the power draw, the sunlight behaviour, and the refresh speed of every panel you will meet.
LCD and TFT transmit light. A liquid-crystal display does not produce light of its own. It sits in front of a backlight and twists liquid crystal to let that light through, pixel by pixel. A character LCD is the simplest form: fixed segments or a grid of characters. A TFT is an active-matrix colour LCD, with a thin-film transistor behind every pixel, which is what makes full colour, high resolution, and video-rate refresh possible. The backlight is the price: it draws current the whole time the screen is on, and in sunlight the backlight has to fight the sun — which is why phone screens go dim outdoors and why a cheap TFT is unreadable in a bright lab window.
OLED emits light. Each pixel in an organic LED display makes its own light, so there is no backlight at all. That makes OLEDs thin, extremely high in contrast (a black pixel is simply off), and readable from wide angles. Power depends on content: a mostly-black screen draws very little, a mostly-white screen draws much more. The organic emitters age with use, and a pixel left on for weeks can leave a permanent ghost — burn-in — which matters for static menus.
E-paper reflects light. An electrophoretic display moves charged pigment particles inside tiny capsules; once they are in place, the image stays with no power at all. It reflects ambient light like paper, so it is superb in direct sunlight and terrible in the dark. Changing the image costs energy and time — a full refresh typically takes one to three seconds — so e-paper is for content that changes rarely.
The four technologies in detail
Character LCD: the 16x2 workhorse
The HD44780-based 16x2 character LCD is the display most student projects start with, and for fixed text it is still hard to beat. It shows two lines of 16 characters — enough for a temperature, a status word, and a value. It runs on 5V logic, talks over a parallel interface (usually wired in 4-bit mode, six pins including RS and enable), and is driven by the built-in LiquidCrystal library on Arduino. A backlight is optional and draws roughly 20mA when on — small, but not nothing on a battery. Contrast is set by a potentiometer on the Vo pin, which is the single most common reason a "dead" 16x2 is actually fine: turn the contrast pot before you assume the wiring is wrong.
Use it for: sensor readouts, counters, status displays, anything where the output is a few numbers and short words. Do not use it for graphs, icons, or anything that needs to change shape — it can only show the characters in its built-in font.
OLED: the SSD1306 small screen
The SSD1306 is a monochrome OLED controller, most often in a 128x64 pixel module about an inch across. It runs on 3.3V logic, talks over I2C (two wires) or SPI (four wires, faster), and is driven by the Adafruit_SSD1306 library. Because each pixel emits its own light, a dark screen with a few bright numbers draws very little current — typically around 20mA or less for a mostly-dark readout, rising with the amount of white on screen. Text is crisp, viewing angles are wide, and the module is small enough to fit on a wearable or a handheld device.
The two limits to respect: size and burn-in. PMOLED modules this cheap are small — under about three inches — so do not plan a dashboard on one. And a static menu left on for the whole demo week can ghost. If your screen shows the same header for hours, dim it, blank it after a timeout, or shift the image by a pixel now and then.
Colour TFT: the ILI9341 full-colour screen
The ILI9341 is a 240x320 colour TFT controller, most often in a 2.4-inch or 2.8-inch module with a resistive touchscreen option. It runs on 3.3V logic, talks over SPI, and is driven by the Adafruit_ILI9341 or TFT_eSPI library. It is the only display in this guide that does full colour, smooth animation, and detailed graphics — gauges, graphs, photos, a proper menu system.
The price is power and memory. The backlight typically draws around 100mA, which dominates the power budget of a battery project (see the worked example below). And a full frame buffer at 240x320 in 16-bit colour is about 150KB — more RAM than an Arduino Uno has in total, and a large share of an ESP32's. Libraries handle this by drawing in strips or by using the controller's own memory, but a full-screen animation on a small microcontroller is not free: check the library's memory notes before you promise a slick UI. The touchscreen, where fitted, is resistive — it works with a stylus or a fingernail, not a light finger tap like a phone.
E-paper: the battery sign
E-paper modules (driven by libraries like GxEPD2) come in sizes from about 1.5 inches up to large panels, in monochrome and limited colour. They run on 3.3V logic, talk over SPI, and hold an image with zero power — energy is spent only while the image changes, and a full refresh typically takes one to three seconds with a visible flicker as the particles settle. Partial refresh can update a small region faster, but it leaves ghosting that a full refresh must clear.
Use it for: a room number plate, a plant monitor that updates every ten minutes, a price tag, a notice board, anything battery-powered that changes rarely and must be readable in sunlight. Do not use it for anything animated, for a live graph, or for a screen anyone needs to read in the dark — without a front light, e-paper in a dark room is a blank grey slab.
The five questions that decide it
Work through these in order. The first question that has a hard answer usually decides the display.
1. How often does the content change? Continuously or with animation means LCD, OLED, or TFT. A few times an hour or less opens the door to e-paper.
2. Where does the power come from? A wall adapter removes most of the argument for e-paper. A small battery removes most of the argument for a backlit TFT. A coin cell leaves you with a character LCD without backlight, an OLED showing mostly dark content, or e-paper.
3. What is the lighting? Direct sunlight favours e-paper or a transflective LCD. A dark room favours OLED. A bright lab with windows is where cheap TFTs go unreadable — budget for a high-brightness panel or pick OLED.
4. How far away is the reader, and how much must they see? A 16x2 LCD is readable from a metre; a 1-inch OLED is not. Count the characters and the graphics you actually need, then pick the smallest display that fits them — bigger screens cost power, pins, and money.
5. Does anyone need to touch it? If yes, a TFT with a resistive touchscreen is the straightforward choice. A character LCD or an OLED needs separate buttons, which is often the better design anyway: buttons are cheaper, more reliable, and easier to explain than a touchscreen.
Interfaces and wiring: I2C, SPI, and parallel
The interface decides how many pins the display costs and how fast it can update:
| Interface | Wires | Speed | Typical displays |
|---|---|---|---|
| I2C | 2 (SDA, SCL) | Slow | Small OLEDs, small e-paper |
| SPI | 4 (MOSI, SCK, CS, DC) | Fast | TFTs, larger OLEDs, e-paper |
| Parallel 4-bit | 6 | Medium | Character LCDs |
I2C is the easiest wiring and the slowest — fine for a 128x64 OLED that updates a few times a second, too slow for a full-colour TFT animation. SPI is the standard for TFT and e-paper. Parallel is what character LCDs use, and it costs the most pins.
The voltage warning that kills displays: most OLED, TFT, and e-paper modules are 3.3V logic. A 5V Arduino Uno driving 5V signals into a 3.3V display can damage it — sometimes at once, sometimes after a few days of "working fine". Check the module's logic level before wiring, and use a level shifter or a 3.3V board (ESP32, or a 3.3V Arduino) where the module requires it. The multimeter guide shows how to verify the actual logic level on your board, and the datasheet reading guide shows where to find it in the module's documentation.
Power budget: a worked example
Display power is not a footnote — on a battery project it is usually the largest load. Work it out before you order:
A 2000mAh battery pack, a microcontroller drawing about 80mA while awake, and three display options:
- TFT with backlight (~100mA typical): total draw about 180mA, so the pack lasts roughly 2000 / 180 ≈ 11 hours. Fine for a mains-powered demo, hopeless for a week-long logger.
- OLED showing mostly dark text (~20mA typical): total draw about 100mA, so the pack lasts roughly 2000 / 100 = 20 hours — nearly double, from the display alone.
- E-paper updating every 10 minutes: the display draws near zero between updates, so the total is close to the microcontroller's own draw — and if the microcontroller sleeps between updates, the pack can last weeks. The display stops being the problem at all.
These are order-of-magnitude figures for planning, not datasheet values — always measure your own module with a multimeter on the real content you will show, because an OLED full of white text and a TFT with the backlight dimmed can swap places. The rule that survives is: the backlight is the battery's enemy, and e-paper removes it entirely.
Three worked decisions
A battery-powered weather station on a balcony. Content changes every ten minutes, it must be readable in direct sun, and the battery should last weeks. E-paper wins: near-zero holding power, superb in sunlight, and a ten-minute refresh is far inside its comfort zone. A TFT would need a huge battery; an OLED would be unreadable in the sun.
A handheld game console. Full-colour sprites, 30 updates a second, a rechargeable battery, and a dark room. A 2.8-inch ILI9341 TFT wins: it is the only option here that does colour and motion, and the backlight cost is acceptable because the battery recharges nightly. An OLED this small cannot show the game; e-paper cannot animate it.
A soil-moisture readout on a desk. Two numbers and a status word, mains-powered, read from a metre away. A 16x2 character LCD wins: the cheapest option, trivial to wire, readable at a distance, and no library or RAM surprises. A TFT here would be spending money and battery on colour nobody needs.
Common mistakes
- Driving a 3.3V display with 5V logic. The most common way a new display dies. Check the module's logic level and level-shift where needed.
- Forgetting the backlight in the battery maths. A TFT backlight at 100mA is usually the biggest load in the project — include it in the power budget from the start.
- Promising a full-colour animated UI on a small microcontroller. A 240x320 frame buffer does not fit in an Arduino Uno's RAM. Check the library's memory notes before you design the interface.
- Choosing e-paper for anything that moves. A one-to-three-second refresh with flicker is not a live graph. Match the refresh to the content.
- Leaving a static OLED menu on for days. Burn-in is permanent. Blank the screen after a timeout or shift the image.
- Ordering the display before checking library support. A display with no maintained Arduino or ESP32 library is a reverse-engineering project, not a display. Confirm the library and a working example exist for your board before you buy.
- Trusting "typical" current figures. Measure your own module showing your own content — OLED current depends on how much white is on screen, and TFT current depends on the backlight setting.
Frequently asked questions
Can I use a 5V Arduino with a 3.3V OLED or TFT?
Yes, with a level shifter on the signal lines, or by choosing a module that includes one on board. Do not connect 5V logic directly to a 3.3V display — it can damage the module.
Which display is easiest for a first project?
A 16x2 character LCD on an Arduino: six wires, a built-in library, and text that either appears or it does not. If you want graphics, a 128x64 SSD1306 OLED over I2C is the next step — two wires and a well-supported library.
Why is my TFT washed out in sunlight?
The backlight is competing with the sun and losing. A higher-brightness panel, an OLED, or e-paper will do better outdoors. Dimming the room is not a fix you can ship.
Can e-paper show colour?
Some panels can, in limited colours — usually black, white, and one accent colour such as red or yellow. Full-colour e-paper exists but refreshes even more slowly and costs more. Treat e-paper as a monochrome technology unless your panel's datasheet says otherwise.
How do I stop OLED burn-in?
Do not show the same static image for hours. Blank the display after a period with no interaction, reduce brightness, and shift the image by a pixel or two periodically. For a demo, a screen timeout is usually enough.
Does the display affect which microcontroller I need?
Yes. A character LCD or small OLED runs happily on an Arduino Uno. A full-colour TFT with a touchscreen and a complex UI usually wants an ESP32 or similar, for the RAM and the speed — and the choice of display can push you from one board to another, which is why the display belongs early in the design, not last.
Limitations
This guide covers the four display families most student projects use, with the modules and libraries that are common at the time of writing. Display modules change quickly: a specific module may use a different controller than the one named here, and its datasheet — not this guide — is the authority for its voltage, current, and timing. Current figures quoted are typical values for planning; measure your own module before promising battery life. Touchscreen behaviour, viewing angles, and outdoor readability vary between individual panels, so test the real part in the real lighting before you freeze the enclosure design.
Where to go from here
- Best 10 LED Display Electronics Projects — display-centred project ideas to build on.
- How to Use a Multimeter for Circuit Debugging — measure your display's real current draw and verify logic levels.
- ADC Resolution vs Accuracy: What Matters — the sensor side of the readout your display will show.
- Debugging I2C with a Logic Analyser — when an I2C OLED does not answer, this is how you find out why.
- KiCad PCB Design for Student Projects — lay out the board once the display and its connector are chosen.
- More electronics fundamentals in the Electronics / E&TC branch hub.
Building a project that needs a display and not sure which one fits your board, battery, and budget? Message Projectech on WhatsApp (wa.me/918275719193) with your display shortlist, your microcontroller, your battery size, and your deadline — you will get a quotation stating the scope, the price, and the delivery timeline for the built-to-order project.