Breathing new life into an old LCD shield

Background

The latest generation of inexpensive microcontrollers have some capabilities that can be utilized in a variety of ways. One of them is the ability to quickly write parallel data with optional DMA (direct memory access) to drive the operation. The Raspberry Pi Pico not only has lots of exposed IO, but it contains a very flexible IO state machine that can run simple 'PIO' programs to manipulate IO with precise timing. The good folks at Pimoroni reminded me of this recently with the release of their Tufty2040 product. The board features a RP2040 MCU along with a lovely ST7789 IPS 240x320 color LCD. The bold move they made was to take the extra effort to connect it on an 8-bit parallel bus instead of the usual 1-bit SPI. This change allows the LCD to rewrite its entire content more than 60 times per second. To clarify, the RP2040 has no video output, but inexpensive LCDs like the ST7789 have their own internal video RAM and can be told what to display with a series of 'move cursor' and 'write pixel' commands. Send those commands fast enough and you can produce smooth animation and even video.

Taking it further

I bought a Tufty2040 as soon as it became available and think it's a great product. Two things got me thinking about doing some additional experimentation with the idea of parallel displays:

- Pimoroni's software for the Tufty2040 is focused on MicroPython and I prefer to work in native code (Arduino)
- I have an old Arduino UNO display shield with a parallel LCD (ILI9486 320x480):



I wrote my own display library (bb_spi_lcd) that already supports a lot of display controllers, but 8-bit parallel support is something new. Using the RP2040 to drive the ILI9486 sounded like a worthwhile challenge.

RP2040 PIO

Setting up the state machine of the RP2040 and writing code for it is a non-trivial exercise that's not the focus of this post. For my use case, I 'borrowed' the 2-line PIO program from Pimoroni (with full attribution) and wrote my own support around it. Here's the entire PIO program for driving a parallel LCD:

            //     .wrap_target
    0x6008, //  0: out    pins, 8         side 0
    0xb042, //  1: nop                    side 1
            //     .wrap

The code simply writes 8 bits of data to sequential GPIO pins and then toggles the "side" pin which is the write clock (LCD_WR) input.

There's additional code needed to configure the pins, set up DMA etc., but that's the heart of writing data 8-bits at a time on the RP2040.

Wiring

To make use of the UNO display shield, I created a tinned protoboard adapter. I used the same wiring scheme as the Tufty2040, but you can use almost any GPIO pins as long as the 8 data pins are sequential numbers.


The pins for the LCD are connect as follows:
LCD_CS = GPIO10
LCD_RS = GPIO11
LCD_WR = GPIO12
LCD_RD = GPIO13
LCD_D0..D7 = GPIO14...21
(and connect GND, 5V and 3V to the appropriate pins on the Pico)

Putting it to the test

My personal favorite way of testing MCUs and displays is to throw a good GIF animation at them. Here's the code to set up the display. I created a 'named display' feature in bb_spi_lcd which makes it easier to initialize popular devices. In this case, I made one for this setup called "DISPLAY_KUMAN_35". It assumes that the GPIO pins are wired as above.


The code is located in the parallel_shield_demo sketch on the display library repo: bb_spi_lcd
If I haven't done a new release of the library yet (so that it shows up in the Arduino library manager), it's because it's still in development, but you can do a clone of the repo and use it in its pre-release state.

Here's the video of it in action:



Comments

Post a Comment

Popular posts from this blog

Surprise! ESP32-S3 has (a few) SIMD instructions

Intro Espressif Systems released their ESP32-S3 SoC a few years ago, but only recently have they released more documentation and support of its full capabilities. Without any changes to your code, the S3 runs about 15% faster than older ESP32 CPUs at the same clock speed. It has a 'hidden' capability that's more difficult to use, but can be worth the effort if you need more speed. This article is aimed at programmers who are already familiar with SIMD instructions on other platforms. I've been optimizing code with SIMD for more than 15 years on Intel, Arm and DSPs (even Cadence's), so when I heard that the S3 had SIMD instructions, I immediately went searching for documentation. When the S3 became available to buy, there was only a promise of documentation and support. In the 2+ years since then, not much has changed. At the end of 2023, Espressif released a document describing the new instructions: S3 Technical Reference Manual The document has a decent level of d
Read more

How much current do OLED displays use?

Image
Those little OLED displays are everywhere, and there's a good reason. They're inexpensive, easy to program and they look good. I wanted to explore how much current they draw so that I can plan better for battery powered projects. Questions I want answered: How much idle current is drawn when the controller is off versus on (blank display)? What's the minimum current to see text indoors? What's the maximum current when all pixels are on at their brightest? How does display size affect current draw? How does active data writing affect current draw? It's obvious they use more, but how much current do grayscale and color OLEDs use? How practical are OLED displays compared to common LCDs for battery powered projects? Materials: Cheap multimeter (manual scale, assumed accuracy +/-10% at worst) Various OLED displays (72x40, 96x16, 128x32, 64x32, 128x64-0.96", 128x64-1.3") Arduino compatible microcontroller ( Adafruit nRF52840 Feather Express )
Read more

Fast SSD1306 OLED drawing with I2C bit banging

Image
What The  SSD1306  OLED displays are very popular with hobbyists due to their low cost and easy interfacing. The majority of the ones sold expose a two wire interface (TWI) aka I2C. The default speed for I2C is 100Khz and the "fast" mode is 400Khz. These are the 2 standard speeds supported by most AVR Arduinos. An I2C clock rate of around 800Khz is also possible on AVR MCUs, but not supported directly by the Wire library. The I2C standard recently added some higher speeds (1Mhz and 3.4Mhz). The 3.4Mhz version uses a slightly different protocol. At 400Khz, using the I2C hardware and the Wire library, I was able to refresh the display around 23.5 frames per second (FPS) with my code. Why I have already written a SSD1306  library for both Linux and Arduino, but I wanted to drive the display from an ATtiny85 and learn about the I2C protocol in the process. The ATtiny85 doesn't have I2C hardware built in, so it needs to be emulated in software using GPIO pins. There
Read more