Borgware-2D

Übersicht

Die Borgware-2D ist eine Firmware für AVR-basierte, zweidimensionale LED-Matrizen, insbesondere die Blinken Borgs. Hauptplattform ist der Borg16-Bausatz. Andere unterstützte Plattformen sind das LED Brett vom Hackerspace FFM oder das ELO Ping-Pong-Board.

Andres Ur-Borg

Borg16 mit Testdisplay

Animationen

Mittlerweile gibt es Zahlreiche Animationen für die Borgs. Hier sind ein paar Beispiele:

Matrix

Feuer

Scroll-Animation für Elemente der Spiele

...und viele weitere

Ein animiertes GIF (3,5 MB) vermittelt einen Eindruck von der Borgware-2D in Action ;)

Spiele

Snake

Tetris

Tetris
- Classic: Das ganz normale Tetris
- First Person Tetris: Statt die Steine zu drehen, dreht man hierbei das Spielfeld um den Stein
- Bastet: Diese Tetris Variante gibt einem stets den Stein, den man gerade am wenigsten gebrauchen kann
Snake
BreakOut
Space Invaders

Quellen

Die aktuellen Quellen liegen bei GitHub. Diese lassen sich mit folgenden Befehlen auschecken:

git clone https://github.com/das-labor/borgware-2d.git
git submodule init
git submodule update

Die letzten beiden Befehle sind notwendig, um die RFM12-Libary als Unterprojekt einzubinden.

Bauen der Firmware

Derzeit unterstützte Build-Plattformen sind Linux, FreeBSD und Windows (via Cygwin). Die Simulator-Unterstützung beschränkt sich momentan auf x86- und x86_64-Architekturen. Für FreeBSD gilt eine Besonderheit: Wenn hier von make die Rede ist, muss unter FreeBSD stattdessen gmake eingesetzt werden. Folgende Abhängigkeiten gelten unter den jeweiligen Systemen:

Abhängigkeiten unter Linux/FreeBSD

Die Paketnamen basieren auf den Debian/Ubuntu-Repositorys. Bitte entsprechend der Nomenklatur der verwendeten Linux-Distribution (bzw. FreeBSD) anpassen.

build-essential (installiert eine komplette GCC-Tool-Chain für den Host)
make (gmake unter FreeBSD)
libncurses5-dev
gcc-avr
avr-libc
binutils-avr
avrdude
freeglut3-dev

Abhängigkeiten unter Windows

WinAVR (inklusive avr-gcc und avrdude)
Cygwin(64)
- make
- gcc-core
- libncurses-devel (Cygwin)
- libncursesw-devel (Cygwin64)
libusb-win32 sofern ein USBasp-Programmiergerät mit avrdude genutzt wird

Konfigurieren

Screenshot der Menuconfig

Ein (Cygwin-)Terminal öffnen, ins Checkout-Verzeichnis wechseln und folgendes einippen:

make menuconfig

Dadurch startet ein Ncurses-basiertes Textmenü, mit dem sich einige Eigenschaften der Zielplattform einstellen lassen. Vorsicht ist geboten, wenn IDEs wie Eclipse zum Einsatz kommen, da sich dort integrierte Terminal-Emulatoren gerne an Ncurses-Ausgaben verschlucken. Um zu verhindern, dass das Ncurses-Menü durch einen normalen Build-Vorgang (via make) aufgerufen wird, muss nach einem frischen Checkout bzw. nach einem make mrproper mindestens einmal make menuconfig in einem normalen Terminal-Emulator aufgerufen werden.

Kompilieren

Um die Firmware nach der Konfiguration für die Zielplattform zu bauen, genügt ein einfaches

make

Die Borgware enhält einen Simulator für Linux und FreeBSD (OpenGL) sowie einen für Windows (Win32/GDI, Cygwin). Der Simulator-Build lässt sich folgendermaßen anstoßen:

make simulator

Das Build-System wählt automatischen den korrekten Simulator. Nach einem erfolgreichen Build liegt ein Binary namens borgsim oder borgsim.exe im selben Verzeichnis.

Handhabung des Simulators

Bitte behaltet im Hinterkopf, dass der Simulator KEIN Emulator ist. Er ermöglicht lediglich, die Borgware-2D als native Host-Anwendung zu bauen, so dass man seinen C-Code mit Hilfe eines Host-Debuggers wie dem GDB inspizieren kann. Der GUI-Thread der Anwendung fragt den simulierten Framebuffer des Borgs alle 40ms ab und zeichnet seinen Inhalt in ein Fenster.

Die WASD-Tasten stehen für die Joystick-Richtungen und SPACE agiert als Feuerknopf. Der OpenGL-basierte Simulator (Linux/FreeBSD) erlaubt es, den Betrachtungswinkel der Matrix über die Pfeiltasten zu ändern (nicht unter Windows).

Aufgrund speziell angepasster Linkerskripte läuft der Simulator derzeit nur unter Linux, FreeBSD und Windows (und dort auch nur unter x86 bzw. x64). Prinzipiell ist der OpenGL-basierte Simulator plattform-unabhängig, allerdings müssen pro Betriebsystem und Architektur entsprechende Linkerskripte vorgehalten und ins Build-System integriert werden. Die Linkerskripte erzeugen beim Binden automatisch eine Datenstruktur für die Spielmenüeinträge und ermöglichen die EEPROM-Emulation im Simulator. Die Abhängigkeit von diesen Skripten ist derzeit das einzige Hindernis in Bezug auf Plattformunabhängigkeit. Patches welcome.