If you’re a hardware designer, the hardest part of any project is always the part with human interaction. An IoT sensor will dutifully report temperature and air quality data, but if there’s no way for a human to interpret those readings, that piece of hardware is no better than a brick.
One of the best ways to give data to a user is with a display. This can be anything from a single LED blinking out Morse code to a high-resolution TFT display. Blinking a LED is easy, but TFTs not so much: there are decisions to be made about the size, power consumption, and most importantly how to drive that display with a microcontroller. This is where a lot of product designers stumble, and it’s easy to see why. Displays are hard, and that’s with a bevy to tools at hand to make development easier.
In this two-part series, we’re going to take a look at different types of displays, specifically categorized by how a microcontroller or small computer can drive them. Before we get into that, check out Panelook — an online exchange for LCD panel manufacturers — to see exactly how many options are out there. Everything is there, from old graphical gas plasma display glowing in their own orange abundance to almost full-color e-ink displays. Any one of these can work in a hardware project, but the trick is knowing how to drive them.
Displays and how to use them
There are an incredible variety of display technologies available to hardware designers, from simple LEDs to character LEDs to Sharp Memory displays that have the low power and sunlight readability of e-ink while still retaining fast refresh rates.
While all of these displays perform the basic task of providing the user with information, they’re not really what you’re looking for when designing a consumer product. All products are judged against their competitors, and you will inevitably need a large, high-resolution, full-color display.
With that observation in mind, let’s dive into driving LCD displays. They come in nearly every size and shape imaginable, and there certainly are a lot of ways to control them.
While all LCDs are inherently digital — somewhere in the display there’s a microcontroller in charge of switching individual pixels on and off — this doesn’t necessarily mean the input of all LCDs are digital. Some are analog. Yes, like a really old TV.
Think of an old, turn-of-the-century portable DVD player. While these aren’t seen much today, the technology behind them relies on an analog LCD. The rest of the portable DVD player isn’t that much different from the one in your living room, and it all outputs a video signal to an LCD. This signal is most likely component (YPbPr) or composite video.
Yes, if you really wanted to, you could build a product around an analog LCD. Don’t. It’s more trouble than it’s worth.
SPI and I2C
Into the realm of digital displays.
Most commonly remembered from old Nokia brick phones, SPI and I2C displays are usually small — under three inches or so — and are a very good choice for small hardware designs. They offer enough pixels for a usable interface, and they’re generally low power.
These displays communicate with a microcontroller either through a Serial Peripheral Bus (SPI) or and I2C bus (which stands for Inter-Integrated Circuit. These protocols are the bred and butter of connecting different electronic devices on the same circuit board, and there are significant differences. In short:
- SPI is fast, but (generally) it requires three dedicated pins on a microcontroller. You won’t be connecting dozens of SPI devices up to the same controller.
- I2C is slower, but devices on the bus can be daisy-chained. Just two pins on a microcontroller allow for up to 127 I2C devices.
While both I2C and SPI displays exist, the ability to refresh a display quickly is more important than the ability to drive multiple displays. Therefore, SPI displays are far more common. They’re also incredibly popular, with many breadboard project showing off these cheap and bright displays.
Direct CPU Control
Where analog video operates by sending pixel information directly to a display (one pixel at a time, with ‘v-blanks’ and such), SPI and I2C displays operate on commands and data. With these displays, the microcontroller tells the display, ‘draw a red pixel at location 40, 25’. With this, the microcontroller can draw any pixel at any time.
SPI and I2C displays do this by receiving data serially, with each command or data packet being a fixed length. There’s another type of protocol, generally called a ‘CPU’ or ‘MCU’ protocol, and more specifically called a ‘6800 LCD’ or 8080 LCD’ interface. Sidenote: the 6800 and 8080 in these names come from families of microcontrollers produced in the 1980s.
With these ‘CPU’ interfaces, the commands and data packets are broken up over a parallel connection. This means all the data is split up over eight, sixteen, twenty-four, or even thirty-six different pins on a microcontroller. Those are just the data pins. In addition to these, there are also read signals, write signals, and command signals.
The advantage to these ‘CPU’ or ‘MPU’ displays is that they are significantly faster than even a SPI display. For every pixel in a SPI display, a microcontroller has to toggle a single pin on and off eight times, if the display is only using 256 colors, or sixteen times, for 32,000 colors. With a parallel interface, all of those bits blink on and off at once, ultimately resulting in a higher frame rate.
The benefits of a CPU display is a faster refresh rate and potentially greater color depth, with the drawback of using significantly more pins on a microcontroller. They’re also much more difficult to interface with a microcontroller, and are less supported among popular graphics libraries and drivers.
Here, we’re reaching the end of what types of displays can be controlled by a simple battery-powered microcontroller in the next part of this series, we’ll be taking a look at larger and faster displays, with more pixels and more colors. This, as always, requires a faster processor but it’s something that will make your hardware project pop.