klaute's blog

Chaostreff Heilbronn - LEDCube

2011-10-15T19:24:00.000+02:00

Das erste Projekt im Hackerspace (Incubator) des Chaostreff Heilbronn.

Mehr Informationen gibt es hier

Altera Quartus 11.0 Tools, Ubuntu 11.4, USB-Blaster

2011-10-12T20:38:00.003+02:00

Wer mit Ubuntu 11.4 (x86) und der Software Quartus II Version 11.0 Build 157 04/27/2011 SJ Web Edition von Altera arbeitet, um z.B. sein DE0-Nano Board mit "Leben" zu befüllen wird schnell feststellen, dass diese Kombination leider ohne manuellen Eingriff, direkt nach der Installation der Altera Software, nicht funktioniert. Quartus II stürzt direkt nach dem Start mit einem Segfault (zumindest bei mir) ab. Und weder mit dem grafischen Programmer noch mit den Tools auf der Kommandozeile kann auf das DE0-Nano, welches sich am System als USB-Blaster ausgibt, zugegriffen werden. Da ich persönlich lieber auf der Konsole und mit Quartus II (aus vielerlei gründen) nur ungern arbeite, gehe ich hier nur auf die Konfiguration der Kommandozeilen Tools ein, um diese zur korrekten Arbeit zu bringen. Meine Altera Software habe ich mittels dem Altera-Installer unter ~/bin/altera/11.0 installiert.

1. Die ~/.bashrc anpassen

Als erstes muss selbstverständlich der Pfad zu den Binaries der PATH-Variable hinzugefügt werden. Weiterhin benötigen diverse Quartus Tools die Umgebungsvariable QUARTUS_ROOTDIR um korrekt arbeiten zu können, daher habe ich auch diese in meine .bashrc eingefügt.

export PATH=$PATH":~/bin/altera/11.0/quartus/bin:~/bin/altera/11.0/nios2eds/bin:~/bin/altera/11.0/quartus/sopc_builder/bin"

export QUARTUS_ROOTDIR="~/bin/altera/11.0/quartus ~/bin/altera/11.0/nios2eds/sdk_shell"

2. UDEV Zugriffsrecht auf den USB-Blaster einrichten

Ich habe die Datei "/etc/udev/rules.d/40-altera-usbblaster.rules" mit dem folgenden Inhalt angelegt:

BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6001", MODE="0666", SYMLINK+="usbblaster", GROUP="plugdev"

Startet man danach das System neu oder führt einen Reload von UDEV durch, kann auf den USB-Blaster zugegriffen werden. Die Voraussetzung dafür ist natürlich, dass dieser in der Liste der USB-Geräte auch angezeigt wird.

user@host:~$ lsusb -d 09fb:6001
Bus 002 Device 013: ID 09fb:6001 Altera

UDEV kann mit den entsprechenden Rechten mittels service udev reload dazu angewiesen werden die Konfiguration neu zu laden.

3. JTAG Daemon

Dieser Daemon muss laufen, um korrekt auf die JTAG-Chain per USB-Blaster zugreifen zu können. Gestartet wird dieser mit jtagd. Natürlich kann man diesen Daemon auch permanent laufen lassen.

4. Testen der JTAG-Verbindung

Beim Aufruf von jtagconfig wird als Standard die Option --enum ausgeführt. Es werden alle diejenigen Devices angezeigt, die an der JTAG-Chain hinter dem USB-Blaster hängen.

user@host:~$ jtagconfig
1) USB-Blaster [2-1.2.2]
020F30DD

5. Quartus Programmer testen

Der Quartus Programmer muss selbstverständlich auch auf den USB-Blaster zugreifen können. Das kann mit dem folgenden Aufruf getestet werden.

user@host:~$ quartus_pgm --list

Info: *******************************************************************
Info: Running Quartus II Programmer
    Info: Version 11.0 Build 157 04/27/2011 SJ Web Edition
    Info: Copyright (C) 1991-2011 Altera Corporation. All rights reserved.
    Info: Your use of Altera Corporation's design tools, logic functions
    Info: and other software and tools, and its AMPP partner logic
    Info: functions, and any output files from any of the foregoing
    Info: (including device programming or simulation files), and any
    Info: associated documentation or information are expressly subject
    Info: to the terms and conditions of the Altera Program License
    Info: Subscription Agreement, Altera MegaCore Function License
    Info: Agreement, or other applicable license agreement, including,
    Info: without limitation, that your use is for the sole purpose of
    Info: programming logic devices manufactured by Altera and sold by
    Info: Altera or its authorized distributors. Please refer to the
    Info: applicable agreement for further details.
    Info: Processing started: Sat Oct 8 18:10:02 2011
Info: Command: quartus_pgm --list

1) USB-Blaster [2-1.2.2]

Info: Quartus II Programmer was successful. 0 errors, 0 warnings
    Info: Peak virtual memory: 82 megabytes
    Info: Processing ended: Sat Oct 8 18:10:02 2011
    Info: Elapsed time: 00:00:00
    Info: Total CPU time (on all processors): 00:00:00

Die Tools quartus_pgm und quartus_pgmw (die grafische Version) sollten nun den USB-Blaster korrekt erkennen und ansteuern können.

Da aber nun das übertragen der synthetisierten Logik nicht genug ist und ich den Build-Vorgang mit einem kurzen Makefile automatisiert habe, möchte ich dass natürlich nicht vorenthalten. Voraussetzung für den korrekten Betrieb sind die oben genannten Einstellungen, dass man sich beim Start im Verzeichnis des Quartus-Projektes befindet und das die Haupt-Datei des Projektes identisch mit dem Projektnamen ist (alles natürlich Case-Sensitive).

#
# Makefile to build FPGA/CPLD synthesis with altera tools.
#
# Licensed under GPL v3.0 (15.10.2011)
# by Kai Lauterbach (klaute at gmail dot com)
#

TARGET=test

MAPPER=quartus_map
MAP_OPTIONS=--read_settings_files=on --write_settings_files=off $(TARGET) -c $(TARGET)

FITTER=quartus_fit
FIT_OPTIONS=--read_settings_files=off --write_settings_files=off $(TARGET) -c $(TARGET)

ASSEMBLER=quartus_asm
ASM_OPTIONS=--read_settings_files=off --write_settings_files=off $(TARGET) -c $(TARGET)

STA=quartus_sta
STA_OPTIONS=$(TARGET) -c $(TARGET)

PROGRAMMER=quartus_pgm
PGM_OPTIONS=-m jtag -c USB-Blaster -o "p;$(TARGET).sof"

compile: clean map fit asm sta

map:
    $(MAPPER) $(MAP_OPTIONS)

fit:
    $(FITTER) $(FIT_OPTIONS)

asm:
    $(ASSEMBLER) $(ASM_OPTIONS)

sta:
    $(STA) $(STA_OPTIONS)

program:
    $(PROGRAMMER) $(PGM_OPTIONS)

clean:
    rm -rf db/ dse/ incremental_db/ sim.do $(TARGET)ig.archive.rpt $(TARGET).asm.rpt $(TARGET).bsf $(TARGET).cdf $(TARGET).done $(TARGET).dse.rpt $(TARGET).fit.rpt $(TARGET).fit.summary $(TARGET).flow.rpt $(TARGET).inc $(TARGET).map.rpt $(TARGET).map.smsg $(TARGET).map.summary $(TARGET).mif_update.rpt $(TARGET).pin $(TARGET).sof $(TARGET).sta.rpt $(TARGET).sta.summary $(TARGET).tis_db_list.ddb $(TARGET)_assignment_defaults.qdf wave.do $(TARGET).archive.rpt

XMega evaluation board

2011-07-25T15:19:00.001+02:00

Ich beschäftige mich nun schon seit mehr als einem Jahr mit der XMega-Reihe von Atmel. Das Verwenden eines XMegas hat in vielen Bereichen deutliche Vorteile gegenüber eines kelineren Bruders aus der Mega-Reihe. Darunter fallen die höhere (maximale) Taktfrequenz von bis zu 32MHz, der Mehrkanal DMA-Controller, AES- und DES-Kryptografie per Hardware, höhere Kapazitäten für Flash/EEPROM/SRAM, höhere Auflösungen bei den ADC, digital zu analog Konverter (DAC) sind hinzugekommen und ein recht flexibles Event-System. Das einzige Manko ist, dass der Möglichkeit zur Programmierung per ISP-Schnittstelle weg gefallen ist. Es muss hier die neu hinzu gekommene PDI-Schnittstelle oder einfach JTAG Abhilfe schaffen.

Da mir die Möglichkeit fehlt die Chips per PDI zu flashen, erledige ich dies mit einem AVR Dragon per JTAG und AVRDUDE, was keinerlei Probleme macht. Das einzige Problem, dass ich persönlich mit den XMegas habe ist die Bauform. Ein TQFP-Gehäuse ist nicht einfach nur mal so auf eine Lochrasterplatine aufgesteckt und kurzerhand verlötet. Glücklicherweise gibt es bei eBay jedoch Adapterplatinen für ein paar wenige Euro, die nur mit Stiftleisten versehen werden müssen und dann wie üblich weiterverwendet werden können. Das Bild oben zeigt so eine Adapterplatine, mit einem aufgelöteten ATXMega192A3.

Und da in meinem Fall die grundlegende Schaltung meistens identisch ist, habe ich diese einmalig in Eagle erstellt und darauf nun komplett auf einem 60x60mm großen Stück Lochrasterplatine aufgebaut. Das zweite Bild zeigt das ganze dann als fertig aufgebaut. Verfügbar sind die folgenden Schnittstellen an mehreren Steckerleisten, sowie zwei Status-LED und einen Reset-Taster.

JTAG (oben links)
1x I²C/TWI (oben rechts)
1x I²C/TWI mit weiteren IO-Leitungen (rechts mitte)
2x 20Pin IO-Steckerleiste (links unten, oben mitte)
2x UART (links mitte)
1x 14Pin Spannungsversorgung (unten rechts)

Die Spannungsversorgung habe ich hier bewusst extern belassen, so dass beide Platinen einfach ausgetauscht werden können (siehe rechtes Bild). Die Maximale Eingangsspannung liegt hier bei 25V und an den Ausgängen liegen die Eingangsspannung und die Spannungen 5V, 3,3V und 1,8V an. Der Maximalstrom liegt bei jedem der Regler bei ca. 1A. Eine LED zeigt an, das dass System in Betrieb ist.

Als nächstes habe ich angedacht noch eine weitere Platine zu erstellen, welche die beiden ausgeführten UART-Schnittstellen, des Evaluation-Boards, zu USB und RS232 konvertieren. Die Einzelteile liegen schon bereit...

A small and proprietary AVR C-Library to play Wavefiles...

2011-07-01T16:32:00.005+02:00

Projekte bei denen Wavedateien abgespielt werden gibt es viele. Bei den meisten ist die dazu implementierte Funktionalität jedoch ein fester Bestandteil der Firmware und dadurch nur oft schwer zu verstehen und oft auch nicht gerade einfach in seine eigenes Projekt zu übernehmen. Zudem ist je nach verwendeten Mikrocontroller die Ausgabemöglichkeit der Audiodaten unterschiedlich, was aber unter Umständen nicht auf den ersten Blick ersichtlich ist. Die erste Alpha-Version der hier vorgestellten Library, welche auf GitHub verfügbar ist, besitzt im Moment die im folgenden beschriebenen Eigenschaften.

Eigenschaften der Library:

Die Library läuft momentan nur auf AVR-Controllern der Mega-Reihe (getestet mit ATMega328p).
Es werden nur Wave-Daten unterstützt die im Flash oder EEPROM abgelegt sind (muss per Preprozessor-Einstellung festgelegt werden).
Die Wave-Daten müssen im PCM-Format (8Bit, Mono, 8kHz Sampling-Rate) und ohne den 44Byte Header im Flash oder EEPPROM abgelegt worden sein.
Die Daten werden per Pulse Width Modulation (8Bit) an den Pins PD5 und PD6 ausgegeben. Die Basisfrequenz liegt hier bei 62,5 kHz.
Timer0 wird dazu verwendet das PWM-Signal (Fast PWM Modus) zu generieren.
Timer2 wird dazu verwendet die Wave-Daten Byte-weise, im Takt der Sampling-Rate, an die beiden Output Compare Register (A/B) des Timer0 zu übergeben.

Funktionen der Library:

Die Library besitzt zudem Funktionen mit denen es möglich ist, die Hard- und Software zu initialisieren und den Abspielvorgang zu starten, stoppen und pausieren. Wenn die Preprozessor-Einstellung für Flash angegeben wurde, kann ein im Repository liegendes Shellscript im tools Verzeichnis dazu verwendet die benötigte C-Datei für die Firmware zu erzeugen (es wird SoX benötigt). Zu beachten ist dabei, dass aufgrund des in C intern verwendeten Datentyps (16Bit signed integer) für den Index von Arrays, die Maximale Anzahl von Samples in der Wave-Datei den maximal möglichen Index von 32767 nicht überschreiten darf.

Ablauf der Ausgabe:

Der Vorgang zum abspielen gestaltet sich wie folgt. Der Timer0 (8Bit) wird so eingestellt, dass dieser mit einen Vorteiler von 1 (voller CPU-Takt) im nicht invertierenden Fast PWM-Modus läuft und der TOP-Wert für den Zähler des Timers ist dabei der Wert 0xff. Der Counter des Timers läuft also immer von 0 bis 255, was eine Frequenz von 62,5kHz, ergibt.

Ist bei einem Zählvorgang der TOP-Wert erreicht bzw. überschritten, findet ein Überlauf statt, der veranlasst, dass beiden Pins PD5/6 auf High gesetzt werden. Der Counter fängt wieder bei 0 an hoch zu zählen.

Auf Low werden die beiden Pins gesetzt wenn jeweils ein Vergleichswert zum aktuellen Counter-Wert erreicht wird. Diese beiden verwendeten Vergleichswerte sind im Fall des Timer0 die Register OCR0A/B. Durch diesen Vergleichswert kann also die Zeit in 256 Schritten festgelegt werden, wie lange das PWM-Signal, innerhalb einer Periode, auf High oder Low gesetzt ist.

Der zweite Timer (Timer2) ist auch ein 8Bit Timer, der jedoch nich im PWM-Modus läuft. Er wurde so eingestellt, dass er mit einem Prescaler von 8 auf 2MHz läuft und bei einem Vergleichswert von 250 (eingestellt über das Register OCR2A, was exakte 8kHz ergeben und somit die Unterstützte Samplingrate der Wave-Daten von 8kHz entspricht) einen Interrupt auslöst der eine Interruptroutine aufruft. Gleichzeitig wird der Counter des Timer wieder auf 0 gesetzt, der darauf wieder hoch zählt. In der eben genannten Interrupt-Routine wird je nach Konfiguration der Lib, ein Byte nach dem anderen, entweder aus den Wave-Daten aus dem Flash oder EEPROM nachgeladen und in die beiden oben genannten Vergleichsregister OCR0A/B geschrieben. Dies führt dazu, das der Timer0 nachdem nächsten Überlauf, durch erreichen des Counter-Wertes 0x00, das Tastverhältnis direkt ausgibt.

Dieser Wechsel des PWM-Verhältnisses, im Takt der Sampling-Rate, ergibt eine Veränderung der mittleren Ausgangsspannung des PWM-Signals und ist damit (wenn auch recht kantigen) das wiederhergestellte Ausgangssignal aus dem die PCM-Kodierte Wavedatei erzeugt wurde. Dies liegt daran, da bei der Pulse Code Modulation, ein Audiosignal mit einer festen Sampling-Rate (in unserem Fall 8kHz) abgetastet wird. Die Abtasten bedeutet schlicht, dass in einem festgelegten Takt der momentan anliegende Spannungswert an der Datenleitung (in unserem Fall 8Bit-Wert breit) abgefragt wird. Es ergibt sich also eine folge von Werten, aus denen das erfasste Signal wieder rekonstruiert werden kann.

Das ganze oben beschriebene Vorgang ist natürlich nur recht kurz und simpel beschrieben. Er soll lediglich nur einen Überblick über den Vorgang geben. Fehler und Ungenauigkeiten können also enthalten sein und ich bin über jede Anregung oder Korrektur dankbar.

Verwendete Hardware:

Als Hardwarebasis zum testen verwende ich ein Minimexle der Version 3, bei dem ich ein anderes Quarz (16MHz statt 18,432MHz) und einen anderen AVR (ATMega328p statt einem ATMega88) verwende. Durch den AVR mit größerem Flash-Speicher (32kB) sind die weiteren Möglichkeiten in der Firmware wesentlich weniger eingeschränkt als beim Mega88. Zudem besitzt das Minimexle ein Display mehrere Taster und einen Summer. So kann hier die Funktionalität der Lib durch ein simples Benutzerinterface angeboten und auch ohne angeschlossene Kopfhörer etc. die Wave-Daten abgespielt werden können.

Und dadurch, dass beim Minimexle jeder der beiden verwendeten PWM-Kanäle mit einem RC-Tiefpass (erster Ordnung) ausgestattet ist, bevor diese an 3,5" Klinken-Buchsen ausgeführt werden, können einfache Lautsprecher, wie man sie aus PC-Gehäusen als PC-Speaker kennt, oder sehr einfache Kopfhörer sollten ohne Probleme an diese Buchse angeschlossen werden.

Warnhinweis:

Von der Verwendung von aktiven Kopfhörern, Stereoanlagen, Verstärkern oder ähnlichem rate ich jedoch aufgrund der Signaleigenschaften des PWM-Signals dringend ab. Es versteht sich von selbst, dass ich keinerlei Verantwortung für Schäden jeder Art durch Verwendung dieser Software übernehme.

Ausblick:

Für die Zukunft ist angedacht, den Header der Wave-Dateien zur Konfiguration der Timer heranzuziehen, weitere Sampling-Raten zu unterstützen und die Anzahl der verwendeten Timer auf einen zu reduzieren. Zudem soll der zu verwendende Timer auswählbar sein und falls die PWM-Pins, dieses Timers, anderweitig verwendet wurden, ein Software PWM-Modus verfügbar sein der für beliebige Pins, an einem beliebigen Port, betrieben werden kann, usw...

Weitere Links:

Grundlegendes zur Tonerzeugung mit Hilfe von Mikrocontrollern. - http://www.mikrocontroller.net/articles/Klangerzeugung
Umwandlung von Wave-Dateien in C-Code - http://www.mikrocontroller.net/topic/132749
Converting PCM to PWM audio. - http://www.eetindia.co.in/STATIC/PDF/200809/EEIOL_2008SEP19_SIG_TA_02.pdf?SOURCES=DOWNLOAD

mbed to brain machine

2011-04-06T23:01:00.009+02:00

Motiviert durch ein Video zum Brain Machine Kit, kam mir die Idee eine mbed to brain machine zu bauen. Eine Brain Machine soll, laut Beschreibung, dass Gehirn des Trägers durch audiovisuelle Stimulation (mit Beta-, Alpha-, Theta- und Delta-Wellen) in verschiedene Bewusstseins-zustände versetzen. Die Hardware besteht im wesentlichen aus einer ausgedienten 3D-Brille, einem Spannungsregler, Transistoren, LED's, diversen Widerständen, einer 3,5mm stereo Klinkenbuchse und natürlich dem mbed NXP LPC1768 Entwicklungsboard. Die Spannungsquelle ist in meinem Fall ein 9V Block. Von der Idee zur brain machine dauerte es in etwa 2 Stunden. Die Frequenzen der LED's und Töne müssen natürlich noch entsprechend justiert werden, aber auch jetzt ist der im Video beschreibene Effekt schon deutlich wahrzunehmen.

Wie auch bei dem oben genannten Kit werden zwei LED's mit Hilfe der Brille vor den Augen fixiert. Die mir zur Verfügung stehende Brille hat zwei spezielle Plastik-Folien als Gläser, diese können einfach mit einem Bohrer der etwas kleiner als der Durchmesser der LED's ist durchbohrt werden. An den LED's habe ich einfach je ein kurzes Stück zweiadriges Flachbandkabel verwendet. Die Stiftleisten am Ende erleichtern Später das zusammen bauen.

Beim Aufbau der Lochraster Platine kommt es nur darauf an, dass das mbed Board aufzustecken ist, ohne dass unerwünschte Verbindungen zu anderen Bauteilen zustande kommen. Ich habe hier nur einen Teil der am mbed Board vorhandenen Pins für das Aufstecken auf Buchsenleisten (im Bild rechts grün markiert) vorgesehen. Auf die Steckerleiste (blaue Markierung) werden die beiden LED's aufgesteckt. Die Platine wird dann einfach mit Kabelbindern auf der Brille befestigt.

Die Schaltung ist recht simpel. Die beiden Transistoren sind mit den Pins 21 und 22 und die beiden Leitungen des Klinkensteckers mit dem Pin 23 und 24 zunächst direkt verbunden. Bei Gelegenheit werde ich diese hier online stellen.

Natürlich gibt es auch dieses mal wieder ein Video dazu.

Edit (2011-04-09 14:36): Die Frequenzen sind nun abgestimmt und es wird nun eine Brainwave Folge, wie sie in diesem Dokument abgebildet ist, abgespielt. Die Synchronisation der Signale werden ggf. noch verbessert und die Firmware, sowie ein Schaltplan, ist nun unter http://mbed.org/users/klaute/ verfügbar.

HackStick Update

2011-03-20T21:18:00.002+01:00

Heute geht es um ein Projekt das nun seit mehr als einem Jahr ohne nennenswerten Fortschritt in der Ecke lag, dem "HackStick". In meinem letzten Post habe ich darüber berichtet, dass ich den ursprünglich eingesetzten ATMega8 durch einen ATMega168 ersetzen würde. Das ist längst geschehen und nich mehr aktuell. Nachdem die Ideen für viele neue Features in der Firmware nur so sprudelten, musste unbedingt zunächst ein neuer Mikrocontroller her, um den gestiegenen Anforderungen gerecht zu werden.

Der zuvor verwendete Mega168 war mit seinen 16kB Flash und den vorhandenen 1kB SRAM schon zu jeweils etwa 80% gefüllt. Was aber leider keine weiteren großen Schritte zulies. Abhilfe schafft "der Neue". Ein ATMega328P-PU. Dieser besitzt im Vergleich zu dem vorher verfügbaren Flash, RAM und EEPROM jeweils die doppelte Kapazität. Also 32kB Flash, 2kB SRAM und 1kB EEPROM. Die Bauform und Pinbelegung ist dabei zu der Mega8 Reihe identisch (P-DIP28).

In der Firmware sind jedoch ein paar kleinere Änderungen notwendig gewesen um die USART-Schnittstelle verwenden zu können. Hilfrech ist hierbei die aktuelle UART Library von Peter Fleury. Unter Ubuntu 10.10, mit einem avr-gcc-4.3.5 und der avr-libc-1.6.8-2 musste jedoch das ein oder andere Register, sowie die Interrupt Vektoren, angepasst werden. Leider ist mit dieser Library das Senden von Daten per USASRT (out of the Box) mit dem Mega328p nicht per Interrupt möglich gewesen, was aber an dieser Stelle nicht weiter stört und mich daher auch nicht genötigt hat zu prüfen, warum dieses Feature nicht funktioniert.

Ein weiteres Software-Update hat der Bootloader erfahren, dass ohne Probleme verlief. Lediglich die Fuse-Bits mussten angepasst werden, da ich nicht bei jedem Flashen der Firmware das EEPROM neu beschreiben wollte. Lediglich die Konfigurations-Einstellungen des Bootloaders, sowie eine kleinere Anpassung im Code, mussten durchgeführt werden, um den Bootloader auch aus der eigentlichen Firmware heraus, software-seitig über den AVR internen Watchdog starten zu können. Die vorher vorhandene Möglichkeit den Bootloader zu starten, indem ein Jumper vor dem Einstecken gesetzt wird, bleibt dabei bestehen.

Neben diesen beiden Updates von Firmware-Teilen und der generellen Umstrukturierung, haben sich jedoch noch weitere neue Features ergeben. Die Liste ist lang und daher soll die folgende Liste nur einen Sichpunktartigen Überblick bringen.

Setzen, Aanzeigen und Senden aller USB-spezifischen Daten über das TTY. Mit USB-spezifischen Daten sind alle USB Descriptoren, Strings, Vendor-/Device-ID, USB Daten und Sequenzen von zu sendenden USB Daten gemeint.

Ein Interpreter mit dem die oben genannten USB Daten-Sequenzen interpretiert und gesendet werden können. Hier stehen, je nach Datenmenge und Headerinformationen, ca. 794 Byte zur verfügung.

Es kann festgelegt werden ob auf eingehende Daten reagiert werden soll. Die Reaktion darauf wäre das Starten der Interpretation der aktuellen USB Daten Sequenz.

Alle Daten können in das EEPROM gespeichert und daraus geladen werden.

Das Startverhalten der Firmware kann in einem im EEPROM abgelegten Konfigurations-Wort festgelegt werden. Es kann hier festgelegt werden, welche Daten beim Start geladen werden sollen, ob die Sequenz-Daten direkt nach dem Start interpretiert werden sollen und ob auf eingehende Daten reagiert werden soll.

Eine Online-Hilfe mit Beschreibung aller verfügbaren Kommandos.

Wie oben schon erwähnt kann der Bootloader aus der Firmware heraus gestartet werden.

Da die Benutzerfreundlichkeit dieser Features, auf dem TTY, aber leider aufgrund dessen, dass nur unnötig weiterer Speicherplatz im Flash verschwendet werden würde, leidet, habe ich eine kleine GUI geschrieben, um speziell die Sequenzen von USB Daten komfortabler erzeugen und an den HackStick übertragen zu können. Geschrieben ist die Software in Java. Die mit der GUI erzeugten KeyCode-Sequenzen können z.B. bei der Verwendung eines im HackStick festgelegten Hid Keyboard Descriptors, als Tastatureingaben einer Tastatur an den Host gesendet werden. Die Daten werden bei der Erzeugung differentiell in der Sequenz abgelegt. Wer jedoch auf die GUI verzichten möchte kann die im Projekt enthaltene HackStick Klasse auch auf der Kommandozeile zum Übertragen von Dateien verwenden. Zu den Sequenzen muss hierbei gesagt werden, dass der Inhalt der Sequenz-Daten erst in Verbindung mit einem gültigen USB Hid Descriptor für den Host einen Sinn ergeben. So macht es keinen Sinn, KeyCodes an den Host zu senden, wenn der HackStick sich per Hid Maus Descriptor als Maus ausgibt.

Zum Abschluss gibt es, wie so häufig, ein kurzes Video.

Der Stick wurde hier so konfiguriert, dass er sich als Hid Keyboard ausgibt und im EEPROM wurden Daten abgelegt, die gesendet werden sobald der Status einer aktivierten NumLock-Taste vom Betriebssystem an die neu angeschlossene Tastatur übergeben wurde. Das ganze kann beliebig oft getriggert werden in dem diese Taste mehrfach betätigt wird.

Edit (2011-05-04 19:46): Bilder der ersten Platinen gibt es hier.

Edit (2011-06-06 22:57): Seit heute gibt es ein GitHub Repository.

LEDMatrix - aktualisierte Firmware

2010-09-27T07:58:00.002+02:00

Es ist nun schon einige Zeit vergangen seitdem Mike und ich das Projekt abgeschlossen haben. Leider war der letzte Stand der Firmware noch nicht ganz zufriedenstellend.

Das Problem war zum einen, die Stabilität der USB-Verbindung des Microcontrollers zum Linux-Rechner. Genauer gesagt wurde die USB-Verbindung regelmäßig vom PC aus,resettet wenn zu schnell Daten an den AVR gesendet wurden.

Nach mehreren Tests konnte ich jedoch einen neuen Release der Firmware erstellen, welche zum einen die aktuelle Version des V-USB Projektes beinhaltet und zum anderen einige (kleine aber wichtige) Änderungen die das Timing- und Kommunikations-Verhalten verändern.

Die Verbindung ist nun stabil und die USB-Verbindung wird nicht mehr resettet.

Das zweite, größere Problem war, dass der Microcontroller nur per dazwischen geschaltetem USB-Hub an dem Rechner erkannt wurde, der die Matrix steuern sollte. Jeder andere Linux-PC jedoch hatte mit dem direkten Anschließen des Controllers keine Probleme.

Nachdem wir das Problem mit einem weiteren PC, der auch einen Nvidia Chipsatz besitzt, verifizieren konnten, war das Problem also lokalisiert. Auch diverse Forenbeiträge im OBDEV-Forum ergaben ähnliche Erfahrungen mit Nvidia. Genauer gesagt liegt das Problem beim Timing des Modules im V-USB Treiber für die Verwendung von 16 MHz Quarzen. Manche Chipsätze und deren Treiber kommen damit einfach nicht zurecht. Und da das Debugging in dem Fall (jedenfalls für uns) zu aufwendig werden würde, ersetzen wir demnächst das 16MHz Quarz durch eines mit 12MHz.

Dadurch sollten, laut den Foren, alle Probleme mit der Erkennung auf Nvidia-Chipsätzen endgültig beseitigt worden sein.

Die neue Firmware kann wie immer hier heruntergeladen werden.

Dem Archiv habe ich auch den aktuellen Schaltplan als PDF beigefügt.

Acer Aspire 1825ptz - Datenverlust bei Treiberupdate

2010-06-03T19:50:00.005+02:00

Heute geht es unüblicherweise um ein ganz anderes Thema. Habe ich mir doch von ein paar Tagen aufgrund dem Schwächeln der alten Hardware ein neues Notebook geleistet. Ein Acer Aspire 1825ptz mit 4G RAM, 320GB HDD und Windows 7 Home Premium 64bit usw. Nach ein paar wenigen Tagen und dem ernsthaften Versuch meine privaten Projekte auch effizient unter Windows fortsetzen zu können bin ich allerdings auf eine Sache gestoßen, die mich nun doch wieder auf den Boden der Tatsachen zurückgeholt hat.

War ich doch tatsächlich leicht davon überzeugt das Gerät zunächst unter Windows zu betreiben zu können. Zumindest bis das Touchpanel akzeptabel unter Linux unterstützt wird und ich die Zeit dafür gefunden habe. Funktioniert hatte unter Windows auch alles soweit, bis auf eine Kleinigkeit die ich aber gerne verwendet hätte. Das Gerät besitzt einen eingebauten Bluetooth Adapter, wobei Windows aber für 3 der Komponenten des Adapters leider keinen passenden Treiber findet. War ich also der Meinung den Treiber von der

Acer-Support-Seite für mein Gerät herunterzuladen und diesen auch zu installieren. Gesagt getan, auf der genannten Seite kommt man recht bequem und einfach zu seinem Produkt und den verfügbaren Treibern. Sogar deren Auswahl ist eindeutig (zumindest bei meinem Notebook) so dass man keine unnötigen Daten herunter lädt.

Leider war das Ganze ein großer Fehler!!!

Im Laufe der Installation bleibt der Fortschrittsbalken bei etwa 60-70%, mit der Meldung dass der vorherige Treiber deinstalliert wird (oder ähnlich...), stehen und die HDD-LED zeigt einen dauerhaften Festplattenzugriff an. Leider dauerte dieser Zugriff mehr als 10 Minuten, was mich dann doch irgendwie kritisch stimmte. Durch Zufall habe ich darauf gesehen wie das Dropbox-Icon im Tray angefangen hat eine Synchronisation an zu zeigen.

Lange Rede kurzer Sinn, die Installationsroutine hat nicht den alten Treiber deinstalliert sondern sie war dabei ALLE Dateien auf dem System zu entfernen. Bootbar war das System darauf dann nicht mehr, der Windows Bootloader meinte etwas von 0x0000000f und ich müsse nun von einem externen Medium booten und die System-Reparieren Option ausführen.

Zum Glück hatte ich mir zuvor die Recovery-DVD's erstellt und konnte das System wiederherstellen. Die Daten waren leider alle weg und mussten aus Backups wieder hergestellt werden.

Wieder 5 Stunden meines Lebens die ich damit verschwendet habe mich mit unausgereifter proprietärer kommerzieller Software auseinander zu setzen, nur um während des "recover" dann feststellen zu müssen das meine Daten doch nicht mehr herzustellen sind.

Fazit:

Acer sollte da die Installationsdatei vielleicht doch nochmal prüfen, ich bin zumindest auf die Antwort des Supports gespannt...

Schmerzlich habe ich daraus wieder einmal gelernt, nie einem Software-Produkt zu trauen das aus dem Hause Microsoft kommt oder in irgendeiner Form darauf aufbaut oder davon abhängig ist. Es ist absolute Zeitverschwendung...

Edit (2010-06-22 12:11): Acer hat mein Ticket kommentarlos als "erfolgreich geschlossen" markiert. Ein neuer Treiber ist auf der Webseite offensichtlich noch online, dass wäre auch zuviel verlangt...

fnordlicht Ambilight Update

2010-05-27T14:20:00.004+02:00

Nachdem ich das Projekt beim letzten Treffen des CTHN vorgestellt hatte und dort doch noch die eine oder andere Ungereimtheit aufgetaucht ist, habe ich hier einen neuen Patch online gestellt. Der Patch beinhaltet alle Änderungen die nötig sind um den fnordlicht-Support in den VLC-Code ein zu spielen. Eines der aufgetretenen Ungereimtheiten war, dass die Farbe Rot (und darauf folgend Blau) viel zu intensiv ausgegeben wurde. Dies war jedoch über die Einstellungen im AtmoLight-Filter selbst leicht an zu passen. Die Probleme mit der Verbindung zu den fnordlichtern werden durch den neuen Patch entfernt. Es war z.B. zuvor nicht möglich mehrere Dateien hintereinander ab zu spielen ohne den VLC-Player neu starten zu müssen.

Die im Video-Filter vorgenommenen Einstellungen können auch weiterhin nicht, ohne den Video-Stream neu zu starten, übernommen werden. Das scheint ein Grundlegendes "Problem" in den Videofiltern des VLC zu sein. Dank der Zusammenarbeit mit dem AtmoWin Entwickler André Weber ist nun auch die Unterstützung für Windows gegeben, wenn sie auch noch nicht komplett getestet werden konnte...

Zu den genannten Änderungen besitzt der AtmoLight-Filter nun noch die folgenden Erweiterungen:

Unterstützung für das anzeigen einer Farbe wenn der Player pausiert wird oder wenn das aktuelle Video zu Ende ist.

Reset der fnordlichter beim beenden von VLC.

fnordlich-Protokoll: start_bootloader und boot_enter_application wurden für den Reset implementiert.

Die nötigen Konfigurationseinstellungen für die fnordlichter werden im folgenden Video gezeigt.

Mit diesen Einstellungen habe ich, was die Farbgenauigkeit und die Geschwindigkeit der Farbänderungen an geht, recht gute Ergebnisse erzielt.

Zur Demonstration gibt es wieder ein kleines Video. Meine 2 fnordlichter habe ich hinter meinen Fernseher geklebt und zuvor jeweils mit einer Art Diffuser ausgestattet (siehe Bild), die das Licht der LED's etwas besser vermischen. Den Ton habe ich aus Lizenz rechtlichen Gründen entfernt. Zu sehen ist das Musikvideo Shoot to Thrill von AC/DC (Iron Man 2).

Viel Spaß beim zusehen!

Edit (2010-06-04 14:20): Danke André für den Hinweis! Hier nochmal der Link zu den Nightly builds des VLC für diejenigen welche die Kommantare nicht lesen...

Edit (2010-06-26 18:50): Der neue Release des VLC 1.1.0 kann hier herunter geladen werden. Dieser beinhaltet die beschriebenen Änderungen um fnordlichter als Ambilight verwenden zu können.

fnordlicht-"Ambilight" mit VLC

2010-05-12T21:17:00.015+02:00

Seit ein paar Wochen beschäftige ich mich nun mit 2 Fnordlichtmini's, die ich bei einem Workshop des Chaostreff Heilbronn zusammen gelötet hatte. Was ist ein Fnordlicht? Kurz - es leuchtet und kann mit einem entsprechenden Wandler per RS232 oder USB gesteuert werden. Es ist zudem möglich mehrere der Platinen über einen Bus zu verbinden. Diese Fnordlichter können dann einzeln oder im Verbund über die selbe Schnittstelle gesteuert werden.
Eine der Ideen, die auf kamen, war es nun mehrere Fnordlichter als eine Art "Ambilight", wie bei Phillips Fernsehern, ein zu setzen. Bleibt also nur das Problem, entweder die Daten eines Software-Videoplayers oder ein Videosignal auf dem Weg zum TV ab zu greifen. Da mir im Moment die Zeit für die Elektronik fehlthabe ich mich für die Softwarelösung entschieden.

Nach ein wenig "googeln" bin ich dann über das atmo-Modul im VLC-Player gestolpert. Dieses Modul wurde für eine andere Hardware geschrieben, was aber das nicht weiter stört. Da die Entwickler von VLC recht hohe Ansprüche an den in ihrem Repository eingepflegten Code stellen, war es reine Fleißarbeit eine Klasse zur Kommunikation mit den Fnordlichtern zu erstellen. Zudem musste nicht das ganze fnordlicht-Protokol implementiert werden.
Es genügen:

sync
stop
fade_rgb

Detailierte Informationen zum Protokoll können hier nachgelesen werden. In der Konfiguration des atmo-Moduls können nach meinen Änderungen die folgenden Informationen festgelegt werden:

die Anzahl der angeschlossenen Fnordlichter
die Zuordnung der Fnordlicht-Adressen (Channel 0..3) zu den 1-4 Bereichen des aktuellen Frames.

Die 1-4 Bereiche des Frames repräsentieren "einfach" nur die Farbanteile im linken, rechten, oberen und unteren Bildbereich. Es wird auch ein "Summenkanal", aller 1-4 Bereiche, zur Zuordnung angeboten. Der Kombination von Fnordlichtern und Bildbereichen ist also nur durch die Anzahl der vorhandenen Hardware (und der maximalen Anzahl von Geräten an einem Bus) eine Grenze gesetzt.

Hier ein Video das eine Fnordlicht-Kette von 2 Modulen in Aktion zeigt.

Ein erster Patch gegen die aktuelle VLC-Version aus dem Git-Repository kann hier herunter geladen werden.

Edit (2010-05-15): Hier gibt es den Schaltplan für die Verbindung zwischen dem Pegelwandler und dem fnordlicht-Bus...

LEDMatrix - Projektabschluss...

2010-04-07T22:45:00.005+02:00

So, zum Projektabschluss gibt es nun noch ein paar Videos zum Equalizer in Aktion.
Das Erste Video zeigt die, in den Rahmen des MP3-Player, eingebaute Matrix, welche über ein Notebook angesteuert wird. Auf dem Notebook läuft ein aktuelles Ubuntu Linux mit einer von Mike geschriebenen Testsoftware für den Equalizer.

Das zweite Video zeigt den komplett fertigen Player. Es wird Musik abgespielt und die Matrix als Equalizer angesteuert.

Wie immer kann an der einen oder anderen Stelle noch etwas optimiert und geändert werden. Im großen und ganzen jedoch bleibt es nun wie es ist.

Eine neue Sache ist jedoch aufgetaucht, die USB-Verbindung (per V-USB) macht ausschließlich auf dem verwendeten ASRock miniPC Probleme. So sind wesentlich geringere Übertragungsraten und doch sehr häufige Abbrüche der Verbindung zu verzeichnen, sofern das USB-Gerät überhaupt erkannt wird.

Da die Elektronik der Matrix ja aber dem V-USB "standard" entspricht, der verwendete Linux-Kernel bzw. das Kernelmodul auf allen getesteten Systemen identisch ist bzw. sind und weitere Geschwindigkeitsunterschiede der getesteten Rechner letztendlich keine Rolle spielen, scheint das Problem doch an einer anderen Stelle zu liegen.

Sobald ich hierfür eine Lösung gefunden habe werde ich wie üblich davon berichten und ein neues Update der Software bereit stellen. Hier gibt es jedoch wie immer die letzten Änderungen der Firmware...

LEDMatrix - Neue Videos

2010-03-28T23:23:00.007+02:00

Ein paar Tage sind nun vergangen und nachdem die Matrix auf anhieb funktionierte, habe ich ein paar Optimierungen in der Firmware und bei den Tools mit der sie zu bedienen ist durchgeführt. Aber zunächst kurz zum ersten Test der beiden Komponenten, den LED's und der Steuerplatine. Die 64 Kabel der Reihen waren recht schnell an den 8 Steckern befestigt, was an der sehr guten Vorarbeit von Mike lag, der alle Kabel bereits sortiert hatte. So war nach dem alle Kabel eingesteckt und die Steuerplatine mit einem 9V-Block verbunden wurde, direkt die erste Startanimation zu sehen. Allerdings schien etwas nicht zu stimmen, im Ablauf dieser ersten Animation wurde ein Pixel nicht dort angezeigt wo er eigentlich sollte.

Auf so einen Fall bereits vorbereitet, starteten wir vom Notebook aus einen Testzyklus, mit dem jede einzelne LED auf Funktion getestet wird. Das dafür verwendete Perl-Script liegt dem Archiv bei schon länger bei. Es stellte sich schlussendlich heraus, dass uns in einer Reihe (aber damit für alle Ebenen) ein Kabeldreher untergekommen ist. Mehr Probleme gab es keine. Und das bei 441 LED's, 441 Querverbindungen unter den LED-Reihen der einzelnen Ebenen, den 8 Masseleitungen der und dann noch die ganzen Drähte für die Kathoden der LED's meiner Meinung nach keine schlechte Leistung! Insgesamt wurden etwa 100 Meter Kabel, 10 Meter Draht, einiges an Lötzinn verbraucht. Ganz zu schweigen von der von uns beiden hinein investierten Zeit, der Geduld und den Nerven.

Aber nur mit dem Zusammenbau war es nicht getan. Wie oben bereits erwähnt musste das eine oder andere optimiert werden. Die USB-Verbindung zum Beispiel war anfangs, bei höhreren Frameraten, recht instabil. Mit ein paar Änderungen in dem einen oder anderen Timer in der Firmware war dieses Problem aber auch schnell behoben.

Aus diesem Optimierungsprozess der Firmware ergab sich auch eine Erweiterung des USB-Clients. Dieser ist nun mit einer Art interaktiven "Shell" ausgestattet auf der nacheinander Befehle abgesetzt und Frames übertragen werden können, ohne dabei ständig eine neue Verbindung zum Gerät aufbauen zu müssen. Neben dieser großen Änderung gibt es noch 2 andere neue Scripte. Mit dem einen ist es Animationen oder einzelne Frames, aus Mike's shinyLED, in C-Funktionen umwandeln. Diese können dann mit in die Firmware hinein compilieret werden. Das andere kann die Animationen auf der Matrix von der Kommandozeile aus "abspielen".

Wie ich in einem früheren Post schon beschrieben habe kann der Mikrocontroller auch Animationen intern speichern, die per USB aktiviert werden können. Das nächste Video zeigt einen Equalizer. Die einzelnen "Ringe" sind dabei einzelne im Microkontroller gespeicherte Teilframes, die einzeln oder gruppiert aktiviert und deaktivert werden können. Mit aktiviert und deaktiviert ist gemeint, dass diese Teilframes zu dem aktuell angezeigten Frame hinzugefügt oder davon abgezogen werden. Hierfür werden jeweils nur 2 Bytes per USB übertragen., wie für das gruppierte ansteuern. Gruppieren bedeutet, dass mehrere Ringe gleichzeitig aktiviert werden. Zu sehen ist dies in der Mitte des ersten Videos, an der Stelle wo sich die Matrix von innen nach außen füllt und von außen nach innen wieder leert. Am Anfang und am Ende werden die Ringe einzeln aufgerufen.

Im nächsten Video wird per USB jede auf der Matrix sichtbare Veränderung übertragen. Hierzu wird das Script zum testen der Animationen verwendet. Trotz der mit 21x21 Pixel geringen Auflösung könnte ich mir, zu Demozwecken, doch das eine oder andere einfache Spiel darauf vorstellen...

Nach Ostern ist dann die Deadline für das Projekt und dann wird der Sprichwörtliche Hammer fallen gelassen. Es gibt zwar noch das eine oder andere das man machen könnte aber das steht erstmal auf der Wunschliste. Bis Ostern muss also noch Mikes MP3-Player die Matrix als Equalizer ansprechen können, was aber sogut wie fertig ist und dann muss das ganze wieder an seinen vorgesehenen Platz in der Halterung eingespannt werden. Eingespannt?! War da was? - Ja, das Blech wird in einen Rahmen eingesetzt und erfährt damit eine Biegung. Hoffen wir mal das wir alles richtig ausgemessen und geplant haben und es keine größeren Schäden und vor allem Kurzschlüsse gibt... ;)

Sobald das ganze das erste mal komplett da steht, werde ich wieder das eine oder andere Video und Foto online stellen.

Das neue Archiv mit allen Änderungen kann wieder hier heruntergeladen werden.

LEDMatrix - Fertig!

2010-03-17T08:54:00.006+01:00

Ohne Worte...

LEDMatrix - Update

2010-03-11T17:50:00.004+01:00

Aus der letzten Arbeit an der Platine für die LEDMatrix sind zwei "neue" Dinge entstanden.
Zum einen die neue Firmware für den AVR-Controller und zum anderen eine angepasste Version des USBaspLoaders, um diesen auf dem ATMega32 lauffähig zu machen. Zudem besitzt die Platine nun einen Reset-Button und einen Jumper, siehe Bild.

Der Reset-Button kann dazu verwendet werden, den Mikrocontroller neu zu starten (wozu auch sonst). Ist dabei jedoch der Jumper auf die im Bild gezeigte Stellung gesetzt, wird in den USBaspLoaders gesprungen, der sich im Bootloader befindet. Dadurch ist der AVR-Controller nun direkt per USB programmierbar.
Der USBaspLoader startet nur per Reset-Taster. Um wieder in die Firmware für die Matrix zu springen, muss der Jumper umgesteckt und erneut Reset gedrückt werden werden. Alternativ kann die Platine auch aus- und wieder eingesteckt werden. Durch den Verlust der Versorgungsspannung wird kein Reset des Controllers registriert, so das der Bootloader dazu veranlasst wird, direkt in die Matrix-Firmware zu springen.

Bei Gelegenheit werde ich den, im Vergleich zum LEDCube, geänderten Schaltplan des Mikrokontrollers fertig und online stellen.

Das Update für den USBaspLoader kann hier heruntergeladen werden. Die neue Firmware der LEDMatrix kann wie üblich hier geladen werden. Für Details siehe Changelog...

In den nächsten Tagen werden LED's und die Platine vereint. Dabei wird sicher das eine oder andere Video und Bild entstehen. Es ist und bleibt also spannend... mal ganz abgesehen von der stetig wachsenden Verkabelung auf der Platine und unter den LED's ;)

Erste Firmware für die LEDMatrix

2010-02-17T20:35:00.017+01:00

Die Arbeiten an der Steuerplatine für Mike's LEDMatrix sind, wie ich in meinem letzten Post zu diesem Projekt bereits berichtet hatte, abgeschlossen und so musste die Firmware des LEDCube in den letzten Tagen daran glauben. Das Ziel war die Kommunikation mit dem Mikrocontroller per USB, zum Übertragen einzelner Frames, Ansteuern von Animationen/internen Funktionen und gemeinsames Dimmen aller LED's. Zudem sollte beim Start Mikes Start-Animation mit seinem Logo angezeigt werden.

Soweit fertig ist aus dieser Liste alles bis auf das Dimmen der LED's. Dazu müsste jedoch noch das eine oder andere geändert werden, was aber erstmal noch Zeit hat bis die LED's fertig verlötet sind.

Die erste alpha Version gibt es hier. Im Moment ist das ganze allerdings noch etwas experimentell und muss noch ausgiebig getestet werden.
Enthalten ist in dem Archiv die angepasste Firmware, der USBClient zum Testen der Verbindung, Mike's QT Oberfläche shinyLED zum klicken von Animationen. Weiterhin noch die Sourcen des USBaspLoader welcher später als Bootloader eingesetzt werden soll und noch ein paar Scripte und Tools zum konvertieren und übertragen von Animationen.

Das Bild oben zeigt übrigens die Matrix in Aktion. Das ganze ist allerdings direkt an ein Netzteil angeschlossen.

USBaspLoader und der GCC-AVR (4.3.3) in Verbindung mit Ubuntu 9.10 (amd64)

2010-02-10T19:57:00.009+01:00

Habe ich mich doch vor ein paar Monaten dazu entschlossen mein altes 8.10 Ubuntu (32Bit) durch die neue Ubuntu 9.10 (64 Bit) zu ersetzen. Bisher war ich auch weitgehend überzeugt von der Performance und der Verfügbarkeit der Softwarepakete. Sicher gibt es das eine oder andere Problem, wie zum Beispiel das kein Flash Plugin für den Firefox richtig läuft [solved] oder das manche Programme die libSDL verwenden sich nur mit kill -9 beenden lassen...

Alles in allem aber zu verkraften, Programme die nicht funktionieren werden ggf. aus den Sourcen kompiliert und das Problem ist erledigt.

Aber an manchen Stellen gibt es dann das eine oder andere Tool das einen Stunden seines Lebens kostet. So zum Beispiel der GCC (4.3.3) Compiler aus dem gcc-avr Paket.
Dieser beinhaltet laut diversen einschlägigen Foren eine bessere Optimierung des erzeugten Binary Codes. Optimiert wurde also auch die Option, welche beim übersetzen einer Firmware für Microkontroller normalerweise immer verwendet wird. Die Option -Os. Diese wird an den gcc übergeben um die "kleinstmögliche" Firmware zu generieren. Leider geht der löbliche Optimierungswahn der GCC Entwickler hier ganz klar am Ziel vorbei. Der optimierte Binary-Code ist wesentlich größer als der von älteren gcc-Versionen - tolle Sache...

Mein ATMega168 für den HackStick besitzt 16KB Flash Speicher wovon 2KB für einen Bootloader reserviert werden können. In meinem Fall soll im Bootloader die Firmware des USBaspLoader-Projektes laufen um den HackStick direkt per USB flashen zu können.
Da ist es nicht gerade förderlich, dass der gcc nicht dazu überredet werden kann den, in diesem Fall um 140 Byte(!!!) größeren Binary Code auf die ursprüngliche Größe von 2002 Byte zu verkleinern.

Die Firmware des Bootloaders ist durch das Überschreiten der 2048 verfügbaren Bytes natürlich nicht übertragbar. Zum Glück besitzt man ja nicht nur einen Rechner und so konnte ich die Firmware auf einem anderen kompilieren und übertragen, ohne mir einen älteren GCC installieren zu müssen. Über kurz oder lang kommt man aber bei Ubuntu 9.10 (amd64) nicht drum herum.

Schlussendlich ergab sich aus all dem ein Patch gegen die mittlerweile doch in die Tage gekommenen Version der Firmware des USBaspLoader vom 20.3.2009. Zum einen beinhaltet dieser Patch nun den neuesten Release von V-USB und kleinere Änderungen um den USBaspLoader auf einem ATMega168 lauffähig zu bekommen.

Mike's LED Matrix - 1000'de Lötstellen später...

2010-02-09T17:26:00.016+01:00

Das Projekt schreitet voran und nach einer mehr als 13 stündigen Löt-Session sind nun zumindest die Masseleitungen der LED's (Mikes Aufgabe) und die Steuerplatine (meine Aufgabe) fertig. Rechts ein Bild der unverbundenen LED's.
Besonders aufgefallen ist bei den LED's, dass wohl nur 2 Stück von den 441 (500 wurden bestellt) defekt waren oder eher defekt gemacht wurden... ;)

Sobald die Steuerplatine und die LED Matrix in ein paar Tagen verheiratet wurden, werden wir ein Video drehen das die ersten Animationen und Bilder der ersten Tests zeigt. Die originale Firmware des LED Cube's ist ohne Anpassungen auf unserer Platine bereits am laufen und muss nur noch auf unsere Anforderungen (USB Datenübertragung und Regelung der Leuchtintensität der LED's) angepasst werden.

Hier im Voraus ein Bild der fertigen Steuerplatine.

links oben der Spannungsregler mit Power-LED, an dem ein 9V Block angeschlossen ist
links der AVR-Mikrokontroller (ATMega32)
links unten der USB-Anschluss
rechts vom Microkontroller sind die 8 N-MOSFET's zu sehen
die 8 IC's (D-type Latches) steuern die LED's und sind mit den Steckverbindern verbunden

Der 9V Block wird nur zum Testen der Schaltung verwendet. Später wird das Netzteil des Rechners, der die Daten per USB an den Microkontroller übergibt, diese Aufgabe übernehmen.

Dieser Marathon wird Mike und mir sicher ewig ins Gehirn gebrannt bleiben und die Anzahl der zu verarbeitenden Bauteile wird sich in Zukunft auch sicher in kleineren Dimensionen bewegen.

Mehr dazu in Kürze hier...

Mike's LED Matrix

2010-02-04T19:04:00.028+01:00

Seit längerem haben Mike und ich das vorhaben, in die Frontblende dieses MP3-Player's eine LED Matrix ein zu bauen. Diese Matrix soll dann per Microkontroller gesteuert werden, der wiederum seine anzuzeigenden Daten per USB von dem ThinClient aus dem MP3-Player erhält. Es geht bei diesem Projekt übrigens um 441 blaue, ultrahelle 3mm LED's die mit 441 Halterungen in die 5mm Löcher der Blende befestigt werden .

Als Referenzprojekt verwenden wir die LED-Cube und den Borg3d Würfel.

Da die Liste der Bauteile aber bei beiden Projekten teils unvollständig oder nicht zufriedenstellend war gibt es unsere Liste hier online bei Reichelt. Die LED's und die Halterungen wurden jeweils bei 2 anderen Shops online bestellt.

Jetzt könnte man sich fragen wieso man als Referenz eine 3D Anordnung für eine 2D Matrix verwendet. Ganz einfach, bei einem 8x8x8 Würfel gibt es 512 LED's zum ansteuern. Unsere Matrix besitzt nur 21 x 21 = 441 LED's, was übrigens an der Optik in der Frontblende liegt. Es fällt also eine gesamte 8x8 Ebene aus der Würfeldarstellung weg. Zudem wird die 7te Ebene nicht vollständig ausgenutzt, was aber keinen Nachteil ergibt. Die überschüssige 8te Ebene wird dann vor der Inbetriebnahme aus der Software entsprechend heraus gepatcht. Die Ebenen werden einfach Schachbrett-Artig nebeneinander angeordnet. Bei dem rechten und unteren Rand muss jedoch ein wenig getrickst werden.

Als Firmware wird die des LED-Cube's verwendet, da diese gut strukturiert ist, und vor allem einfacher zu verstehen war da der Code extrem kurz, gut dokumentiert und anpassungsfähig ist.

Nun zum ansteuern der Matrix. Sie wird per Multiplexing angesteuert, wie das ganze funktioniert ist sehr gut auf diesen beiden Videos dargestellt. [#1] [#2]
Kurz: Damit wird ermöglicht jede einzelne LED auch einzeln leuchten zu lassen.

Mike arbeitet bereits an einer auf QT basierenden Software mit der man die einzelnen Frames für die Matrix "klicken" kann.
Jetzt fehlt nur noch die Hardware. Bestellt ist alles, aber noch nicht ausgeliefert...

Sobald das Projekt komplett aufgebaut und die Software fertig ist gibt es hier dazu mehr.

Shakes & Fidget Bot

2010-01-27T21:44:00.009+01:00

Schneller als gedacht wäre der SFBot also wieder am laufen gewesen... ;)

Dass alle Aktionen des Spielers seit dem Update per HTTP-GET an den Server gesendet wurden war sofort ersichtlich. Und die Session und das Passwort für den Login, sahen auf den ersten Blick einer MD5-Summe doch sehr ähnlich. Glücklicherweise sieht man einer vermeintlichen MD5-Summe aber auch so gut an, dass die Entwickler des Spiels doch tatsächlich das vom Benutzer eingegebenen Passwort erst in UTF-8 umwandeln, bevor die MD5-Summe daraus gebildet wird...

Der Dekompilier-Vorgang einer SWF-Datei dauert ja nur wenige Sekunden, mal davon abgesehen, dass der dabei herauskommende ActionScript-Code recht gut lesbar ist.

Ich habe zwar noch nie den Code einer Methode zur Bildung einer MD5-Summe gesehen, aber da bereits am Anfang der Aufruf stand, der den übergebenen String in UTF-8 wandelte, war das Problem sofort erkannt!

Der Rest war reine Fleißarbeit...

Das Video zeigt die grundlegenden Funktionen des Bot's.

Für alle die jetzt noch fragen was der Bot denn nun alles kann:
Er erledigt Quest's, kämpft in Dungeons und der Arena, meldet sich zu Gilden-Kämpfen an und wenn nichts weiter getan werden kann, schickt er den Held automatisch in die Stadtwache (arbeiten). Das ganze läuft auf jeder Kommandozeile. Benötigt wird nur ein Java Interpreter.

Veröffentlichen werde ich den Quellcode des Bots allerdings aus vielerlei Gründen nicht!
Gegen horrende PayPal Spenden, um meine Arbeit zu unterstützen, habe ich jedoch nichts einzuwenden. ;)

klaute's HackStick (v0b00000010)

2010-01-22T21:30:00.009+01:00

Lange ist es her das ich über den Stick geschrieben habe, es hat sich auch nicht all zu viel getan.

Die Firmware hat ein paar neue Features bekommen und wurde, gerade was die Performance und Speichernutzung angeht, optimiert.

Eine wesentliche Änderung ist eine kleine Platine die auf den Stick gesteckt wird und die Pegelwandlung von den +5V des AVR's auf die bipolaren Spannungen einer RS232 Schnittstelle angleicht.

Oder kurz und einfach gesagt, ich habe einen MAX232 angeschlossen ;-)

Im Moment arbeite ich an dem Fuzzer und demnächst wird der ATMega8-16PU (8kB flash) durch einen ATMega168-20 ersetzt, wodurch sich der Flashspeicher verdoppelt und die Taktfrequenz von 16MHz auf 20MHz erhöht. Der neue Mikrocontroller sollte ein gutes Stück weniger mit der USB-Verbindung ausgelastet sein als vorher und zudem steht das doppelte an Flash zur Verfügung. Allerdings ist die Firmware mittlerweile ~8 kB groß, was mich auf die Idee zum wechseln gebracht hatte... ;)

Shakes & Fidget Browsergame

2010-01-22T13:14:00.004+01:00

Wer jetzt denkt ich stelle hier ein Browsergame vor, irrt sich. Ganz davor drücken möchte ich mich dennoch nicht. Shakes & Fidget ist eine Online Comic Bilderserie über zwei Figuren die sich humorvoll und planlos ihren Weg durch World of Warcraft kämpfen. Mehr dazu hier. - http://www.shakes-and-fidget.com

Seit einer ganzen Weile gibt es zu dieser Web Comic-Reihe auch ein Browsergame. Da ich aber nicht die Zeit habe das Spiel zu spielen, geht es mir wie auch in vielen anderen Spielen, ich müsste Cheaten, oder mir zumindest einen Weg finden mit selbst den Zeitverlust zu mindern.

Nach ein paar Stunden Entwicklungszeit könnte man ja fast einen Java-Client für die Konsole schreiben, der das Spiel automatisch und wesentlich effizienter spielt als man das als Mensch könnte. Wenn das nicht verboten wäre... ;-)

Das Spiel basiert übrigens auf Flash und kommuniziert(e) plain text über eine unverschlüsselte Socketverbindung mit dem Server.

Vor ein paar Tagen wurde jedoch ein Update des Flash-Clients online gestellt, in dem die Verbindung zum Server auf HTTP umgestellt wurde. Verbessert wurde dadurch nichts merklich, nur das die Bilder noch langsamer geladen werden als vorher.

Aber zum Glück habe ich diesen Bot nicht geschrieben sonst würde das Reverse Engineering schon wieder von vorne losgehen... :D

GarbageBot v0.4

2010-01-12T08:10:00.004+01:00

Wie auf dem Bild zu sehen ist besitzt der Roboter nun 2 weitere LED's, die über denen liegen, welche ich bereits in meinem letzten Blogeintrag über den Bot beschrieben hatte.

Diese beiden neuen LED's können gemeinsam vom AVR-Controller ein-/ausgeschaltet werden und dienen als zusätzliche Lichtquelle um die Reflexionen auf Hindernissen zu erhöhen.

Sie werden jedoch nur bei Nacht oder dämmernden Lichtverhältnissen benötigt, da die Empfindlichkeit der ursprünglichen normalen, roten LED's leider nicht ausreichend hoch gewesen ist um auch bei Nacht sinnvolle Messintervalle realisieren zu können.

Diese normalen LED's wurden jedoch mittlerweile durch ultra-helle rote ersetzt, welche im Vergleich zu den Vorgängern eine viel höhere Empfindlichkeit ausweisen.

Die Firmware besitzt nun auch einen rudimentären Autopiloten und einen Programm-Modus in dem der GarbageBot über die IR Fernbedienung frei konfiguriert/gesteuert werden kann. Ist der Auto-Pilot aktiv, wird die Umgebung im Alleingang "erkundet". Da die Messungen der LED's jedoch noch nicht ganz fehlerfrei ist, sind Kollisionen quasi an der Tagesordnung...

EZ430-Chronos/Tools die man bedingungslos besitzen muss...

2009-11-27T01:05:00.000+01:00

Wer wie ich schon immer eine program-
mierbare Uhr besitzen wollte, am 12. Dezember 2009 ist es soweit.

Texas
Instruments präsentiert die EZ430-Chronos.

Hier noch ein paar Google Video-Ergebnisse.

GarbageBot v0.3

2009-11-12T15:51:00.004+01:00

Kurzes Update zum GarbageBot... Die Firmware wurde überarbeitet und ist nun in der lage die neu angebrachten LED's als Sensoren abzufragen. Unter dem Link wird gezeigt wie man mittels Mikrocontroller, LED's als lichtempfindlichen Sensor (wie z.B einen Fotowiderstand) verwenden kann. Diese Technik bzw. diese Eigenschaft von LED's wird oft in Reaktivlichtern beim Geocaching verwendet.
Das ganze ist in meinem Roboter zwar noch nicht ganz ausgereift, aber mit ein paar weiteren Stunden Arbeit wird der kleine Roboter sicher irgendwann vor einer Wand anhalten, oder sogar einer Lichtquelle folgen...

Beim mechanischen Aufbau des GarbageBot hat sich auch etwas getan. Die Halterungen für die LED's sind dazu gekommen das Gestell ist insgesamt stabiler geworden. Die Hauptplatine ist nun abnehmbar, ohne den Lötkolben auspacken zu müssen. Was noch fehlt im Moment ist eine bessere "Bereifung" der Motorwellen und eine ISP-Schnittstelle für den µC.

Hier noch ein 2tes Bild von vorne.

Und ein Video im dunklen mit den neuen LED-Sensoren/Beleuchtung...

Garbage Bot

2009-10-26T18:35:00.003+01:00

Dieses mal geht es um einen kleinen Roboter, der im Moment noch mehr einem ferngesteuertem Fahrzeug gleicht als einem autonomen Automaten. Es fehlen auch noch verschiedene Sensoren die eine autonome Fahrt durch das Wohnzimmer erst ermöglichen würden.
Der Grundstein dafür ist jedoch gesetzt. Der AVR-Controller erzeugt 2 Software-PWM-Signale um die Drehzahl der beiden Motoren unabhängig voneinander regeln zu können. RC5-Signale von handelsüblichen IR-Fernbedienungen werden empfangen, dekodiert und ausgewertet. Es ist hiermit möglich den Roboter mittels der Tasten 0-9 sowie die Ch+ und Ch- zu steuern.

Der Roboter besteht im Moment aus den folgenden Bauteilen:

2 Stück Lochrasterplatine
ca. 40 cm 1,5 mm² Kupferdraht für das Gestell
Einfacher Kippschalter
4-Adriges Flachbandkabel
mehrere LED's
Spannungsregler 7805
3x 100 µF Kondensatoren
1x 100 µF Elko
1x 4,7 µF Elko
3x 220 Ω Widerstände
16 MHz Quarz
TSOP1738 Photo Modul
12V NiMH Akkupack

Das folgende Video zeigt den Roboter in Aktion...