Chaostreff Heilbronn - LEDCube

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

Mehr Informationen gibt es hier

Altera Quartus 11.0 Tools, Ubuntu 11.4, USB-Blaster

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

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...

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:

1. Die Library läuft momentan nur auf AVR-Controllern der Mega-Reihe (getestet mit ATMega328p).
2. Es werden nur Wave-Daten unterstützt die im Flash oder EEPROM abgelegt sind (muss per Preprozessor-Einstellung festgelegt werden).
3. 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.
4. Die Daten werden per Pulse Width Modulation (8Bit) an den Pins PD5 und PD6 ausgegeben. Die Basisfrequenz liegt hier bei 62,5 kHz.
5. Timer0 wird dazu verwendet das PWM-Signal (Fast PWM Modus) zu generieren.
6. 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

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

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.