TFT Display

Still playing with the Apollo3 port, I realised that I hadn't tried using Inferno with this touchscreen breakout board that I acquired many years ago. I've done things with my bare metal framework, but not with Inferno.

Another SPI device

Like the e-ink display I used earlier, this display can be driven via an SPI bus. It also features a parallel bus mode, but the emphasis is on using SPI in the tutorial. Also, it's a lot more economical in terms of wiring to use SPI for simple, slow graphics.

As with the e-ink display driver, the bare metal code was converted to C and dropped into the framework of a device driver with a thematically appropriate file name, devili9341.c, since it interacts with the ILI9341 display driver. This device driver exposes a data file in the /dev/display directory. I reused the #v kernel device identifier for the display since I'm not likely to be using a VGA display with this board.

As with the UC8159 driver for the e-ink display, the data file exposed by the device's file server accepts pixel data, preparing the display when the first pixel is written to it and tidying up when the last pixel is received. Something more complex could be used to allow text output or graphics primitives to be used. There isn't enough RAM to hold a framebuffer that can be copied to the display, so caching graphics isn't an option. The display has its own RAM, in any case.


The Artemis module on a carrier board, connected via an SPI bus to a TFT display.

Still, with pixel-level access to the display, programs like a Mandelbrot set generator can be written to take advantage of its bright, colourful output. It supports 16-bit colour with a RGB565 format (or RGB16 in draw.m terminology) so photos are reproduced very well.


David Boddie
12 December 2023