Home › Guides › LCD & OLED Displays Explained

LCD & OLED Displays Explained: How Each Technology Works and How to Choose One

Almost every electronics project eventually needs to show something: a temperature reading, a menu, a warning, a graph, or a simple message saying that it is working. The display is the part of the project that the user actually looks at, so choosing it well matters far more than beginners usually expect. A display that is hard to read in daylight, that eats up too many microcontroller pins, or that needs a library you cannot get working will hold back an otherwise good project. This guide explains the two display technologies you will meet most often, LCD and OLED, how each one actually produces an image, how they connect to a microcontroller, and how to choose between them for a real project.

No electronics background beyond the basics is assumed. If you are still getting comfortable with voltage, current and resistance, start with our electronics circuits basics guide first, then come back here. Once you understand how a display works, the next step is usually a build: our ESP32 projects for beginners guide puts displays into working projects, and our data logger explained guide shows why a small screen is so useful on a device that records measurements over time.

What a display actually has to do

Every display, whatever its technology, has the same basic job: turn electrical signals from a microcontroller into a pattern of light that a human can read. The microcontroller does not send a picture in the way a computer sends a video to a monitor. Instead, it sends commands and data to a small controller chip built into the display module, and that controller switches individual picture elements, called pixels, or pre-shaped character segments on and off. The difference between display technologies is almost entirely about how those pixels make light, or block it.

That distinction shapes everything else: how bright the screen looks, how well it reads in sunlight, how much power it uses, how wide the viewing angle is, and how much it costs. It also decides which interface makes sense, because a display with a few dozen characters to update needs far less data than a full-colour screen that must redraw thousands of pixels many times a second. Keep that idea in mind as we go through each technology, because it explains most of the practical differences you will see in the shop.

How an LCD works: shaping light that is already there

An LCD, a liquid crystal display, does not produce its own light. Instead, it controls light coming from somewhere else, usually a backlight behind the panel, by twisting it through a layer of liquid crystals. Liquid crystals are a curious state of matter: they flow like a liquid, but their rod-shaped molecules can be lined up in an orderly way like a crystal. When an electric field is applied across a tiny cell of liquid crystal, the molecules rotate, and that rotation changes how the cell treats polarised light.

A typical LCD sandwiches that liquid crystal layer between two polarising filters, set at right angles to each other. On its own, light passing through the first filter and then through an undisturbed liquid crystal layer gets its polarisation twisted so that it can pass through the second filter, and the cell looks bright. Apply a voltage to the cell, and the molecules line up with the field instead, the twist disappears, the light is blocked by the second filter, and the cell looks dark. Each cell is therefore a tiny electrically controlled shutter for light, and a display is just a large organised array of those shutters.

Character, graphic and TFT LCDs

The simplest LCD modules you will meet are character displays. A familiar example is the 16-column by 2-row text display, where each character position is a fixed grid of dots, typically five dots wide and eight tall, and the controller turns dots on and off to form letters, digits and a few symbols. You cannot draw arbitrary pictures on a character display, apart from a handful of custom characters, but for readings, menus and status messages that limitation rarely matters, and the simplicity is a real advantage.

Graphic LCDs remove that limitation by giving you control of every individual pixel in a rectangular grid, so you can draw lines, icons, bar graphs and custom fonts. They need more data and more program memory than character displays, because the microcontroller must hold or generate a picture of the whole screen, but they are still modest by modern standards. TFT LCDs, thin-film transistor displays, are the colour screens used in phones, instruments and small embedded panels. Each pixel has its own tiny transistor switch, which allows fast, precise control of a red, green and blue sub-pixel, producing full colour and smooth graphics. A TFT is far more capable than a character or monochrome graphic LCD, and it needs a faster interface and considerably more processing power to drive it.

The backlight, and why LCDs struggle in bright light

Because an LCD only shapes light, it needs a light source, and in almost all small modules that source is a backlight made of white LEDs behind the panel. The backlight is often the largest power draw of the whole display, which matters on battery power. It also explains a familiar weakness: in bright sunlight, the backlight must compete with daylight reflecting off the screen, and cheaper panels wash out badly. Transflective LCDs, which reflect some ambient light back through the panel as well as using a backlight, cope better outdoors, but the plain transmissive panels used in most hobby modules are at their best indoors or in shade. On the other hand, an LCD keeps its image without the pixels themselves ageing unevenly, and a static display can sit showing the same reading for years without damage, which is a genuine strength for instruments and control panels.

How an OLED works: pixels that make their own light

An OLED, an organic light-emitting diode display, works on the opposite principle. Each pixel is itself a tiny light source, made from thin layers of organic material sandwiched between two electrodes. Pass a current through a pixel, and the organic layers emit light directly. There is no backlight, no polariser trickery and no liquid crystal shutter: light comes from the pixel itself, and only from the pixels that are switched on.

That single fact explains most of what people like about OLEDs. A black pixel is simply a pixel that is off, so it emits nothing at all, which gives OLED screens their famously deep blacks and high contrast. Viewing angle is wide, because you are looking at light sources directly rather than through layers that change behaviour at an angle. The panel can also be very thin, and it can switch quickly, which makes motion look clean. Small monochrome OLED modules, often with a grid of pixels such as 128 by 64, are extremely popular in hobby electronics for exactly these reasons: they are bright, crisp, easy to read, and need only a few wires.

PMOLED and AMOLED, in plain language

Small OLED modules are usually PMOLED, passive-matrix OLED, where rows and columns of electrodes address the pixels directly, one row at a time, scanning through the whole display many times a second. This is simple and cheap, and it works well at small sizes. Larger colour OLED screens, like those in phones, are AMOLED, active-matrix OLED, where each pixel has its own transistor to hold its state, much like a TFT LCD. Active-matrix driving allows bigger, brighter, faster screens, but it is more complex and expensive to make, and it needs a more powerful driver. For a beginner or a small project, the distinction matters mainly as a guide to size and price: if the module is small, monochrome and cheap, it is almost certainly passive-matrix, and that is perfectly fine.

The trade-offs: burn-in and brightness

OLEDs have two weaknesses worth knowing about before you commit to one. The first is that organic pixels age as they emit light, and pixels that are driven hard or left showing the same bright image for a very long time age faster than their neighbours, leaving a faint ghost of the old image, known as burn-in or image retention. For a project whose display changes regularly, this is rarely a practical problem, and it can be managed by dimming the screen, blanking it after a period of inactivity, and avoiding a bright static logo left on permanently. The second weakness is peak brightness in direct sunlight: a small OLED is bright and readable indoors, but under strong sun it can still be hard to read, and driving it harder to compete with sunlight accelerates ageing. Neither weakness disqualifies OLEDs, but both should shape how you use one, particularly for an outdoor or always-on instrument.

LCD versus OLED at a glance

Put side by side, the choice comes down to what the display shows and where it will live. An LCD, especially a character LCD, is the steady workhorse: cheap, widely available, tolerant of a static image left on indefinitely, and simple to drive. Its weaknesses are the backlight power draw, narrower viewing angles on cheap panels, and washed-out appearance in bright light. An OLED is the crisp, high-contrast option: deep blacks, wide viewing angles, no backlight to power, and a modern look even in a tiny module. Its weaknesses are cost at larger sizes, gradual pixel ageing with static images, and limited sunlight readability.

Power deserves a careful note, because beginners often assume OLED always wins on batteries. It depends entirely on the image. An OLED showing mostly black with a little white text uses very little light-producing power, because most pixels are off. An OLED showing a mostly white screen, or a bright full-colour picture, drives most of its pixels hard and can use more power than an equivalent LCD. An LCD, by contrast, uses roughly the same backlight power whatever it shows, because the backlight is on whether the pixels are bright or dark. So for a dark-themed readout that updates occasionally, OLED is usually the efficient choice, while for a bright, always-on screen, a simple LCD may be steadier and cheaper to run. Judge by your actual screen content, not by slogans.

There is also a practical point about reading the display from across a room or at an angle. Character LCDs have large, chunky digits that read well from a distance, which is why they remain common on industrial equipment. Small OLEDs have beautifully sharp text up close, but their characters are physically small, so they suit a handheld device or a bench instrument better than a wall-mounted readout. Think about where the user will stand, how far away they will be, and whether they need to read the screen while wearing gloves or safety glasses, before you fall in love with a particular module.

Interfacing: how the microcontroller talks to the display

Whatever the display technology, the microcontroller communicates with it through one of a small number of standard interfaces, and understanding these will demystify most display wiring diagrams. The display module almost always includes a controller chip that does the low-level work of switching pixels, so your program talks to that controller, not to individual pixels directly. Your job is to send it commands, such as clear the screen or move the cursor, and data, such as the characters or pixels to show, over the right wires, in the right order, at a voltage the module expects.

The parallel interface: simple, but hungry for pins

The oldest common display interface is parallel, where each bit of a byte travels on its own wire at the same time. Classic character LCDs can be driven with eight data wires plus a few control wires, or in a four-bit mode that sends each byte as two nibbles and saves four pins. Parallel interfacing is easy to understand and needs no special peripheral on the microcontroller, just ordinary digital outputs, but it consumes a lot of pins, which is why it has largely been replaced on small modules by serial interfaces. It still appears on larger TFT panels, where the sheer volume of pixel data makes parallel or dedicated display interfaces worthwhile. If you meet a parallel display, the logic gates explained guide is useful background, because the control signals, enable pulses and register selection follow the same digital logic ideas.

I2C: two wires, many devices

I2C, pronounced eye-squared-see, is a two-wire serial bus: one wire carries the clock signal, usually labelled SCL, and the other carries data, labelled SDA. Every device on the bus has an address, so the microcontroller can talk to a display, a sensor and a memory chip over the same two wires, addressing each one in turn. Small display modules often add a tiny I2C adapter chip to a character LCD, or include I2C support in the display controller itself, which reduces the connection to just power, ground, SCL and SDA. That is an enormous saving on a pin-limited microcontroller, and it is the reason I2C displays are the default recommendation for beginners.

I2C has limits, and they matter for display choice. It is not a fast bus by display standards, so redrawing a large colour screen over I2C would be slow and visibly laggy. For a text display or a small monochrome graphic that updates a few times a second, I2C speed is more than enough. I2C also needs pull-up resistors on both signal wires, although many modules include them, and devices on the same bus must not share an address. Keep wire lengths short, especially on a breadboard, because long, noisy I2C wiring is a classic source of flaky displays that work on the bench and fail when moved.

SPI: faster, at the cost of more wires

SPI, the serial peripheral interface, is the faster serial option. It typically uses four signal wires: a clock (SCK), a data-out line from the microcontroller (MOSI), a data-in line back to it (MISO, often unused on displays, which only receive), and a chip-select line (CS) per device, plus a data-or-command line (DC) and sometimes a reset line on display modules. Because data moves in step with a dedicated clock and, in most display use, in one direction only, SPI can transfer pixel data much faster than I2C, which makes it the natural choice for colour TFT and larger OLED graphic displays, and for any screen with animation or frequently updating graphs.

The cost is pins and wiring complexity: each extra SPI device needs its own chip-select line, and the extra control lines add up. SPI is also less forgiving of sloppy wiring at high speeds, so short, tidy connections matter even more. Even so, for a colour display the trade is worth it, because an I2C colour screen would spend so long redrawing that the project would feel unresponsive. Many display controllers support both I2C and SPI, selected by jumpers or solder pads on the module, so read the module documentation before wiring: the same board can behave completely differently depending on how its interface is configured.

Choosing an interface for your project

As a rule of thumb, choose I2C for a small text or monochrome display where wiring simplicity and pin count matter most, and choose SPI for a colour or fast-updating graphic display where speed matters most. Choose parallel only if the module you need offers nothing else, or if you have pins to spare and want the simplest possible logic to follow. Whichever interface you pick, check three things before you buy: that your microcontroller has the necessary peripheral or enough free pins, that the display logic voltage matches your board or can be safely level-shifted, and that a maintained software library exists for the display controller. A display with no working library can still be driven by writing your own driver from the controller datasheet, but that is a project in itself, and for a first build it is a distraction you do not need.

Choosing a display for your project, step by step

Start with the content, not the catalogue. Write down exactly what the screen must show: how many lines of text, whether you need numbers only or also icons and graphs, whether colour carries meaning, and how often the content changes. A temperature logger that shows one reading and a timestamp needs a character LCD or a tiny OLED; a weather station with graphs and icons needs a graphic display; a menu-driven controller with touch input needs a colour TFT with a touch panel. Matching the display to the content first prevents both disappointment, when a text display cannot draw the graph you imagined, and waste, when an expensive colour screen spends its life showing two numbers.

Next, consider the environment. Will the display live indoors on a bench, outdoors in sunlight, in a cold workshop, or inside a dusty enclosure? Bright light favours larger, high-contrast characters and argues against small, dim screens. Cold slows LCD response, making characters appear to smear when they change, while OLEDs generally cope better with cold. Dust and moisture argue for a display mounted behind a clear window rather than exposed, and for sealed buttons instead of a touch screen that a wet glove cannot operate. Industrial users learned these lessons long ago, which is why character LCDs survive in control panels: they are readable, robust and replaceable.

Then work through the electrical constraints: supply voltage, logic level, pin budget and power budget. Many small display modules are built for 5 V logic, while many modern microcontrollers run at 3.3 V, and connecting a 5 V display directly to 3.3 V inputs, or driving a 3.3 V display from 5 V signals, can damage one side or the other. Level shifters are cheap and easy to use, but you must plan for them. Similarly, count your pins honestly: a display that needs six pins may be fine on a large board and impossible on a small one that already carries sensors and outputs. And if the project runs on batteries, estimate the display power honestly, including the LCD backlight, and decide whether the screen can sleep or dim when nobody is looking at it.

Finally, weigh size, cost and software support together. A bigger screen is easier to read but harder to fit in an enclosure and usually more expensive. A cheaper module with no documentation or library can cost far more in time than a slightly dearer module with a good library and examples. Check that the library supports the features you need, such as custom fonts, graphics primitives or touch input, and that it is maintained for your microcontroller family. If you are building on an ESP32, the ESP32 projects for beginners guide covers board selection and libraries in a way that applies directly to display choice, and the data logger explained guide shows how display, storage and sensors fit together in one device.

Common problems, and how to think about them

Most display problems fall into a small number of categories, and working through them in order saves a lot of frustration. If nothing appears at all, suspect power and wiring first: is the module actually receiving its supply voltage, is ground genuinely common between the board and the display, and are the signal wires on the pins your program expects? If a character LCD shows a row of dark boxes, the display has power but the contrast is wrong or the controller has not been initialised, so adjust the contrast control and then check the initialisation code. If text appears garbled or in the wrong position, suspect the interface: a wrong I2C address, a missing pull-up resistor, a chip-select line that is never asserted, or a data-or-command line wired to the wrong pin will all produce confident-looking nonsense.

If the display works but flickers, dims or resets when something else switches on, suspect the power supply: displays, especially backlit LCDs and larger OLEDs, can draw sharp bursts of current, and a weak supply or long thin power wires will let the voltage sag. Give the display its own short, direct power feed, add the decoupling capacitor the module documentation recommends, and keep power wires away from noisy switching loads where you can. And if a display works on the bench but fails in its enclosure, suspect mechanical causes: a loose connector, a ribbon cable under strain, or a screen pressed against a case that shorts something. Displays are physical objects as well as electronic ones, and they fail physically more often than beginners expect.

One last habit is worth building early: keep the display code separate from the measurement code. A function that takes a reading and formats it for the screen, called from the main loop, is far easier to debug and reuse than display commands scattered through sensor code. When the display misbehaves, you can then test it in isolation, feeding it fixed test strings, without wondering whether the sensor or the screen is at fault. That separation is the same discipline that makes a data logger reliable, and it pays off on every project that grows beyond a single sensor and a single screen.

Frequently asked questions

Further reading: start from electronics circuits basics for the underlying circuit ideas, logic gates explained for the digital logic behind display control signals, and ESP32 projects for beginners to put a display into a working build.