F14: Wireless LED Display

Abstract

The Wireless LED Display is a 128x32 RGB LED array that displays text and graphics that a user can control over a Wi-Fi interface from a client PC.

Team Members & Roles

Charles MacDonald - Hardware design, display driver
Wilson Luc - Python GUI client software, data protocol design
Will Zegers - Wi-Fi driver

Introduction

The initial goal for the project was to drive an array of 32x16 RGB LED panels for the purpose of display informational messages. Functionality was expanded to include a Wi-Fi interface, software power control, and a scalable panel system.

Display timing (Standard 8 color mode)

For an array of four 32x16 panels forming an aggregate 128x32 display:

• SPI clock is 24 MHz, corresponding to 42ns per bit shifted out.
• Display is composed of 128 columns by 16 rows by 3 bits each for 6144 bits total.
• Each row takes 16us to shift out (128 x 3 x 42ns)
• It takes 256us (16 x 32us) to shift out an entire frame.
• Each pair of rows are lit (LEDs turned fully on) for 32us while the next row is being shifted in.
• For an update rate of 1ms (1000us), the first 256us of 1000us is the time at which the LEDs are lit, for the remaining 768us they are turned off.

Ideally the display task should be invoked per row at a resolution eight times that of the display update period (e.g. 125us rather than 1000us) such that the row pairs are lit at equidistant intervals in time instead of bunched together at the beginning of a single display update. However the current FreeRTOS configuration uses 1ms as the minimum time interval.

Generalizing these timings, it takes 32us to update a single 32x16 panel. Thus within a 1ms time interval about 16 panels could be updated. However another factor into overall timing is the overhead display rendering and graphics conversion.

Display rendering

To simplify the process of display rendering, which is inherently done at the pixel level, graphics are stored in a two-dimensional array of pixels the same size as the panel array (e.g. 128x32 bytes for four panels), using a byte per pixel. Each byte contains three bits indicating the on/off state of the red, green, and blue LEDs. This format facilitates simple and efficient rendering, but the resulting pixel map ("pixmap") is not in a format that can be shifted out over the SPI interface.

Instead a conversion routine scans the pixel map and produces an array of bitplanes ("bitmap"). The bitmap collects all the red, green, and blue pixel states in strides of 32 bits, reordering the data in a format suitable for the panel. While converting the entire buffer to this format is costly, it is trivial to do in ARM assembly language which provides efficient (1 cycle) instructions for bitfield extraction and insertion. Thus the performance overhead of the conversion step can be reduced greatly.

Future improvements

• Update software to support 32x32 panels. This should be trivial as the loopback boards were designed from the start to support the fourth multiplexer input which is unique to the 32x32 panel boards.
• Use DMA to transfer bitmap data to the SPI peripheral. The bitmap conversion routine could be rewritten to output the data in linear order, or if that cannot be done efficiently the scatter-gather mode of the DMA controller could be used to reorder the data during transfer. While the size of the linked list would be large, it would also be static and could be stored in the (rather generous) 512K of Flash memory the LPC1758 provides. However, the existing code appears to keep the SPI FIFO full about as well as the DMA controller does too, at the expense of having to manually poll the status flags. In applications where the CPU is more heavily loaded it would be worthwhile to use DMA instead.
• Update the GUI to support remote power-on and power-off events.
• Use the RTC to support automatic power-on and power-off events. (e.g. power down when SCE closes and stay turned off over the weekends and holidays, power-on in the mornings)
• Provide a diagnostics mode to test each individual panel for the purposes of troubleshooting display connectivity issues.
• Use different DIN rails that allow the loopback board's stackable headers to plug directly into the panels, rather than having to be offset vertically such that a short ribbon cable is required to connect the loopback board to the panel.