Project goals

endre has bought a LED display made by Mediotext a while ago from Vatera, with dried out capacitors. The project aims to replace the original microcontroller with Arduino and to develop an Arduino library so that one can make use of the display for various projects.

The display

The display itself is built up with 96x7 5mm red LED pixels made by german firm Mediotext, and has had a 6502 microcontroller that has been replaced with Arduino lately. Award goes to MrT for his excellent reverse engineering work.

Interface

The display is equipped with a DB-9 connector on the top, having the folling pinout:

SHR_CLK

SHR_DAT

RESERVED

+5v

GND

ROW_ID_0

ROW_ID_1

ROW_ID_2

BUZZER

The BUZZER and RESERVED lines are not connected as of now. Line +5v provides enough power to run an Arduino on it, eliminating the need for an external power supply.

Operation

The X and Y axis "addressing" are completely independent and driving them has completely different approach.

X axis: a LED is "addressable" by filling the shift registers with loading all of the 96 LEDs levels (Arduino shiftOut() function) corresponding to a specific row.

Y axis: a row can be selected by pulling the ROW_ID_x levels down. Obviously only one row can be selected at a time.

Blanking: The display can be blanked (for example during the shiftOut update period) with all the lines pulled down.

Arduino code

Remote control branch

The remote-control branch makes the Arduino a dumb framebuffer that can be controlled over a serial connection. Currently, the protocol offers only one command, block update and a speed of 19.200 bps.

Block update command

The block update command deals with 8-pixel horizontal blocks, resulting in 12 × 7 such blocks. The header bits look like the following:

11AAABBB

CCCCDDDD

AAA is the first row to be updated (0-6)

BBB is the first row not to be updated (1-7)

CCCC is the first 8-pixel horizontal block to be updated (0-11)

DDDD is the first 8-pixel horizontal block not to be updated (1-12)

So the first two bytes define the command (11 = block update) and the four boundaries of the rectangle shaped block to be updated. After this header, there should be w × h bytes, where w = BBB - AAA (width) and h = DDDD - CCCC (height). Each of these represent a 8-pixel horizontal block, and the order should be left to right then top to bottom.

Arduino accelerated graphics commands (beta)

The virtual width of the display should be increased to 256 pixels, with two offsets representing the 96-pixel wide window used for the block update command above (ops offset) and the one used for driving the display (display offset). By default, both are zero, resulting in backwards compatibility.

These offsets can be set with the following commands. Since the ops offset is kept at 8-pixel (block) boundaries, 5 bits are enough, these are marked with X below.

001XXXXX

For smooth scrolling, the display offset can take any value between 0-255, thus it's sent on its own after the following bits.

00000010

To get Arduino accelerated smooth scrolling, automated incrementing of the display offset can be enabled and its speed can be set using the following command. XXXXXX denotes a 6-bit value of the speed, all zeroes mean no scrolling, which is the default.

01XXXXXX

For dynamic scrollers, querying the display offset can be necessary, this can be done using the following command.

00000011

This will result in the Arduino sending back the current value of the display offset in a single byte.

Last but not least, commands could be saved in the EEPROM for autonomous (PC-less) operations. The header consists of the command (100000) and 10 bytes of length.

100000XX

XXXXXXXX

This is followed by the number of bytes denoted by the length field, so the length field doesn't take the header into account, only the payload. These are then written into the EEPROM with the header included, so that the Arduino will know how many bytes in the EEPROM are valid. Because EEPROM writes are slow and the Arduino serial receive buffer is limited, the second header byte (the low 8 bits of the payload length) and all the payload bytes are echoed back, and the client should wait for this acknowledgment before sending the next byte.

After reset, the Arduino waits for 5 seconds for serial commands, and if none arrive, it performs PC-less operation in which it reads the commands from the EEPROM and execute them just as if they would've been sent over the serial port. This will probably consist of one or more block update commands separated by set ops offset commands, with a set scroll speed command at the end.

This still leaves space for future commands:

0001XXXX

101XXXXX

Python API

To make things easier, a simple Python API is implemented by the Remote class, having the following methods. Pixels are expressed with tuples having two members, X and Y.

__init__(serial_class=Serial) the only optional parameter can be used for testing, otherwise the /dev/ttyUSB0 (first USB-Serial converter on Linux) will be used using pySerial

get_pixel(pixel) returns the current state of the pixel specified by the only parameter

flush_pixels() if any pixels has changed since the last flush, it updates the affected region

Note: for performance reason, set_pixel calls doesn't take effect until the next call to flush_pixels, but get_pixel already returns the new value

If you need low-level access, the framebuf attribute stores the framebuffer as a flat list of boolean values, from left to right then top to bottom. Reading it should not cause any problems, but writing it is discouraged as the next call to flush_pixels will not know which pixels you changed.