Statusupdate April

Lange Zeit gab es nun schon keine neuen Beiträge, das wird sich in der nächsten Zweit ändern, denn ich bin zur Zeit mit zwei sehr interessanten Projekten beschäftigt. Das erste Projekt ist die Miniaturisierung eines USB-Repeater. Dazu wird es in die Wafer Level Chip Scale Technologie, sowie in die USB2.0 Spezifikationen gehen. Das Andere Projekt hat mit kapazitiven Touchsensoren zu tun. Vor allem in Betracht auf Sicherheitsanforderungen im Bereich Medizintechnik.

Das Projekt Kaffeeautomat mit WLAN wurde beendet, leider ist die Dokumentation für die Weitergabe an Dritte gesperrt. Bei Gelegenheit werde ich die Arbeit mit einem Gerät eines anderen Herstellers noch einmal durchführen und die Dokumentation diesmal frei zur Verfügung stellen.

Weiterhin habe ich noch ein paar Ideen, die ich in den nächsten Monaten umsetzen möchte, dazu aber später mehr.

Using the ‚Console‘ to talk to the Yún MCU from Python

Playing around with the Yún led me to the problem that I had a Sketch up and running on the MCU that could be controlled from the Arduino serial console. To move the commanding part to a python script all I had to do was to do this communication from the Linux side of the Yún-Bridge system.

To initialize the Bridge all you have to do is call the Bridge.begin(); function in the setup part of the sketch. After that we initialize the Console with Console.begin(). To stop the execution of further commands we can poll the Console to become ready.
void setup() {
// put your setup code here, to run once:
Bridge.begin();
Console.begin();
while (!Console) {
;
}
}
You can now use the print functions as usual:
  if(Console.available()) {
c = Console.read();
.
.
.
}
On the Linux side we have a python script that will conncet to the bridge server and do the same as the Arduino serial console.
import telnetlib, time

tn = telnetlib.Telnet("localhost", 6571)

while True:
print "w"
tn.write("test")
print tn.read_eager()
time.sleep(1)

WLANKaffee Code Repository

Wir haben vom Hersteller der Maschine die Auflage bekommen, die Informationen nicht öffentlich zur Verfügung zu stellen. Daher wird das Projekt und der Quellcode nicht mehr zur Verfügung stehen.

Ich habe den Code für den Arduino auf einer Google Code Projektseite hochgeladen. Der Code ist teilweise ungetestet, da die Kaffeemaschine noch nicht vollständig verdrahtet ist. Diese Arbeit wir nächste Woche beendet. Der Zeitpunkt für den ersten Release ist dann auch der nächste Dienstag.
Aktuell sind für den ersten Release diese Funktionen geplant:

  • Yún
    • Arduino
      • Firmware die über die Console Klasse gesteuert werden kann.
      • Steuerung der Menüknöpfe am HID
      • Drehencoder wird ausgewertet
      • Drehencoder Impulse werden simuliert
    • Linino
      • Python mit Django
      • Webseite mit Benutzerverwaltung
      • Steuerung über Console Klasse des µController
  • Dokumentation
    • Python
      • SPI Protokoll für Display Frames

Arduino Yún, Linux mit Arduino auf einem Board

Für unsere Projektarbeit haben wir entschieden, dass ein Linux fähiges Board und ein Arduino Mikrocontroller zum Einsatz kommen soll. Um das ganze möglichst klein zu halten haben wir den Arduino Yún ausgewählt. Der Yún hat neben den Funktionen, die auch ein Leonardo mitbringt zusätzlich einen voll funktionsfähigen Computer an Board, der mit einem speziellen openWRT Distribution läuft. Das Besondere ist, dass die beiden Geräte miteinander kommunizieren können und somit beide Geräte direkt miteinander verbunden sind. Auf der Linuxseite bietet die Linino Distribution einiges an Funktionalität, wie zum Beispiel eine REST-Full API um die Pins des Arduinos direkt anzusteuern. Eine weitere großartige Funktion wird in der Bridge Bibliothek zur Verfügung gestellt. Die Kommunikation zwischen Mikrocontroller und Programmen auf der Linuxseite.

SSH Konsole des Yún mit Erweiterung für die Kaffeemaschine

In unserem Falle wird der Mikrocontroller die Ansteuerung der Kaffeemaschine übernehmen und bestenfalls den SPI Bus abhören und die übertragenen Displaydaten in einen seriellen Bytestream umwandeln. Die Linuxseite wird die komplette Benutzerschnittstelle bereitstellen, also ein Webinterface mit dem die Kaffeemaschine gesteuert werden kann. Außerdem wird die Webseite den Inhalt des Displays darstellen. Wie die Daten von der Maschine in ein Bild gewandelt werden, habe ich letzte Woche schon beschrieben.

Diese Woche habe ich mich mit dem SPI Interface beschäftigt. Die Displaydaten werden über den SPI Bus vom Benutzerpanel an den Displaycontroller gesendet. Diese Daten können vom Arduino aufgezeichnet werden. Um klein anzufangen, habe ich verschiedene Ansätze ausprobiert. Die Grundvoraussetzung war, dass der Bustakt von 1 MHz eingehalten wird. Dann werden alle 0,1 Sekunden 541 Bytes übertragen. Der genaue Aufbau des Protokolls lässt sich relativ kurz beschreiben. Zuerst bekommt das Display den Wert 0x89 übertragen. In den Datenblättern, die etwas mit dem Display zu tun haben könnten habe ich diesen Befehl leider nicht finden können. Weiter geht es mit dem Byte 0xB4 was laut Datenblatt die Speicherseite 4 als Startadresse angibt. Darauf folgen 134 Bytes mit Bilddaten, bis dann 0xB5 (page 5) übertragen und die nächste Speicherseite ausgewählt wird. Nach weitern 134 Bytes folgt 0xB6 (page 6) und nach weiteren 134 Bytes folgt 0xB7 (page 7). Die abschließende Speicherseite und somit die letzte ‚Zeile‘ des Displays hört auch hier nach genau 134 Bytes auf. Da das Display auf dem Benutzerpanel auf dem Kopf stehend eingebaut ist, sind auch die Daten ‚gekippt‘ Eine einfache Spiegelung hilft das Bild wieder sichtbar zu machen.

Der Arduino Yún

Um mit dem SPI Bus zu arbeiten, ohne die Maschine dabei zu haben, habe ich die Daten eines Frames in ein Arduino-Sketch geladen. Dieser Arduino macht nichts als ein und dasselbe Bild immer und immer wieder alle 0,1 Sekunde über den SPI Bus zu übertragen. Die nächste Aufgabe ist jetzt, die Daten mit dem Yún zu empfangen und zu verarbeiten. Da ich bis jetzt nur einen funktionierende SPI Kommunikation mit Yún als Master und einem Nano als Client zum Laufen gebracht habe, kann ich noch nicht davon berichten, in wieweit sich die Idee mit der Bildgenerierung verwirklichen lässt.

Das SPI Protokoll für das Kaffeemaschinen Display

Dieses Wochenende haben wir im Projektteam die Kommunikation vom Controller auf dem Benutzerboard zum Display genauer unter die Lupe genommen. Da wir keine genauen Informationen über die verwendeten Bauelemente hatten sind wir mit google auf die Suche nach Datenblättern von Displays ähnlicher Bauart gegangen. Die meisten Displays mit SPI Interface verstehen das gleiche Protokoll zum Setzen der Kofigurationswerte und Übertragene der Daten. Die Daten haben wir mit Hilfe des Logic Analyser ja schon das letzte mal aus der Maschine extrahiert. Nach einigen Anläufen haben wir im Datenbaltt eines Displaycontrollers (ST7565R) die Konfiguration des Display RAMs gefunden. Mit dem Wissen wie das Bild, das im Display angezeigt wird zu übertragen ist, gelang es uns den Datenstream so zu formatieren, dass wir das Bild des Displays gespiegelt auf dem Bildschirm sehen konnten. Mit ein wenig Bearbeitung der
Daten ist es gelungen das Bild, das am Display angezeigt wird zu rekonstruieren.

Der Inhalt des Datenstreams in serieller Formatierung

Datenübertragung in der Maschine

Die Maschine kommuniziert einmal mit der Steuerplatine und dann mit dem Display. Dabei ist die Verbindungsleitung zwischen den Platinen mit einem Enable
Signal verehen. Wenn dieses Signal High ist, ignoriert die Steuerplatine die Daten; wenn der Pin auf Low gelegt wird, sind die Daten am Bus für die Steuerplatine.
Vom Controller gehen, neben der Datenleitung MOSI, nicht nach Außen geführte Leitungen an das Display. Es ist also anzunehmen, dass dort auch eine Enable und/oder
Clock Leitung dabei ist. Die Daten, die über den SPI Bus bei dauerhaftem High Zustand auf Enable an der Controllerplatine gehen sind somit aller Wahrscheinlichkeit
nach an das Display gerichtet. Genauer betrachtet wurden jedes Paket 541 Bytes übertragen. Das Display hat eine Bildmatrix von 128 * 32 Pixeln, somit werden
4096 Bit zum Darstellen eines monochromen Bildes benötigt. Die übertragenen Bytes beinhalten diese Datenmenge und zusätzlich noch einige Steuerbefehle.

Das Bild steht noch auf dem Kopf und die Page-Select Befehle sind noch links sichtbar

Display RAM

Wichtig ist dabei zu beachten, dass die Pixelreihen des Display nicht wie erwartet seriell mit Daten bestückt werden, sondern der serielle Kommunikationsport nur vor den parallelen geschaltet wurde. Dadurch ergibt sich die Eigenschaft, dass die Daten ‚Zeilenweise‘ in den Speicher des Displays geladen werden. Zeilenweise
bedeutet dabei, dass der Speicher in 8 bit breite Pages eingeteilt wird. Jede Page wird zuerst ausgewählt und dann von Spalte 0 an aufgefüllt. Dadurch erscheinen die Bilddaten nicht waagerecht, sondern senktrecht und werden so zusammen gesetzt. Nachdem der Aufbau des Speichers bekannt war, konnten wir unsere Software danach ausrichten und haben den Displayinhalt ‚CAPPUCCINO‘ in den sortierten Matrxwerten erkennen können. Jede Zeile oder Page begann mit einem Page-Select Befehl, der getroßt ignoriert werden konnte. Der letzte Schritt war es, die Matrix der Bilddaten in ein PNG zu gießen um es später als Bild in einer Webseite verwenden zu können.

Die rekonstruierte Grafik des Maschinendisplays

Analyse des Protokolls zur Maschinensteuerung

Nachdem jetzt die Übertragung der Displaydaten bekannt ist, müssen noch die vorherigen 10 Bytes der Maschinensteuerung in einen Kontext gebracht werden. Mit Hilfe eines kleinen Scripts habe ich die Logic Analyser Mitschnitte in Kommando- und Bildabschnitte zerlegt. Das Bild wird generiert und die Kommandodaten werden daneben in einer Tabelle abgebildet. Jetzt müssen wir nur die passenden Befehle herausfinden. Dazu gibt es dann nächste Woche mehr.

Reverse Engineering einer Kaffeemaschine

Meine aktuelle Projektarbeit befasst sich mit dem Innenleben eines Kaffee Vollautomaten der Firma Severin, Genauer gesagt der KV8023 S2+. Ziel dieser Arbeit ist es die Kommunikation zwischen Bedienpanel und Kaffeemaschine zu analysieren und gegebenenfalls so zu manipulieren, dass die Maschine über einen Mikrocontroller ferngesteuert werden kann. Dazu habe ich die Maschine erst einmal geöffnet und zwei Flachbaugrupppen gefunden. Eine ist Netzteil, Netzspannung-Schaltung und Controller für die eigentliche Maschine, die andere ist ein Bedienpanel mit einem eigenen ATmega1284P an board. Das Flachbandkabel, mit dem beide Platinen verbunden sind deutet darauf hin, dass die Steuerung der Maschine über ein Bussystem gelöst ist. Wo die eigentliche Intelligenz steckt ist mit eines der ersten Punkte, die es herauszufinden gibt.
Geöffneter Vollautomat Controller des Bedienpanels

Nach einer genaueren Betrachtung des Panels habe ich die Verbindungen der Bauteile in einem Plan aufgestellt. Dieser Plan zeigt alle Steckverbinder, das Displayinterface und die, an den Controller angeschlossene Hardware (Taster, Drehencoder und LED). Eine Erweiterung des Verbindungskabels mittels eines Schneidklemmsteckers erzeugt den Zugriff auf den vermeindlichen Bus. Dieses Kabel ist verbunden mit dem SPI Interface des Controllers, mit dem Display (hier fehlt noch die Belegung der Kontakte).
Ein kurzer Test mit dem Logic Analyser zeigt, dass auf dem SPI Bus tatsächlich reger Betrieb herrscht. Nach einigen Kaffees habe ich jetzt mehrere Minuten Kommunikation mitgeschnitten und werde im nächsten Schritt versuchen die Telegramme auszuwerten und zuzuordnen.
Mitschnitt zweier Telegramme der Buskommunikation
Die Übertragung startet zyklisch alle 0,126 Sekunden, es werden 10 Byte über den Bus mit Enable Low (An) übermittelt. Auf diese Bytes gibt es eine Antwort auf der MISO Leitung. Darauf folgen 540 Bytes ohne Antwort, bei denen der Enable des Flachbandkabels konstant auf High (Aus) liegt. Es liegt nahe, dass es sich hierbei um Daten für das Display handelt, denn auch dorthin ist MOSI des Controllers verbunden. Mit einem Arduino und einem kleinen Sketch kann ich also nächste Woche die 10 Byte Telegramme abfangen und zur Auswertung aussortieren. Dadurch reduziert sich die Menge der Telegramme auf ein Minimum und die Entschlüsselung ebendieser wird hoffentlich leichter fallen.
Um eine Fernsteuerung durchzuführen, muss die Kommunikationsverbindung unterbrochen werden, da sonst das Bedienpanel in die automatisierten Telegramme zusätzliche Telegramme schicken würde. Gleichzeitig muss dem Bedienpanel die Antwort der Maschine vorgespielt werden, da sonst ein Fehler angezeigt wird. Wie sich die Anzeige des Displays manipulieren lässt habe ich mir noch nicht überlegt, da der Enable Eingang des Displays nicht nach Außen geführt wird.

Projektarbeit ASURO

Der ASURO war zentraler Bestandteil der letzten Projektarbeit. Das Ergebnis ist eine Betrachtung der Hardware und eine Umsetzung in Software.

Zusammenfassung
In dieser Studienarbeit wurde die Firmware des ASURO Roboters erweitert. Ziel war es, die Sensorwerte der sechs Sensoren zyklisch abzufragen, um die Werte für den Programmierer direkt zur Verfügung zu stellen. Der Controller des ASUROs besitzt einen AD-Wandler mit sechs Messkanälen, deren Aktivierung in der Software koordiniert und deren Messwerte in die realen Werte umgerechnet werden.

Bei den Sensoren handelt es sich um Reflexionslichtschranken, optoelektronische Sensoren, Taster und Batteriespannung. Von den Reflexionslichtschranken kann auf die Umdrehungen der Räder geschlossen werden; von den optoelektronischen Sensoren kann auf die Helligkeit des Untergrunds geschlossen werden. Die Taster dienen zur Kollisionsabfrage an der Roboterstirnseite und die Batteriespannung dient zur Überwachung der Stromversorgung.

Die Abfrage der Sensoren wurde durch zyklische Auswahl der Messkanäle innerhalb der AD-Wandler Interrupt Service Routine realisiert. Die Werte werden in einem öffentlichen struct dem Rest der Roboter Software zur Verfügung gestellt.

Zusätzlich beschreibt diese Arbeit noch die Verwendung der Softwaresimulation in Atmel Studio und eine Methode für Unittests mit AVR Mikrocontrollern.

Sicherheit im Internet der Dinge (Fonera mit SSL)

Sollte es einmal so weit sein, dass sogar der Kühlschrank mit der Heizung und der Waschmaschine spricht um ein möglichst Strom effizientes Miteinander zu gewährleisten, wird das aller Wahrscheinlichkeit nach über Funk passieren. Doch eine Kommunikation über Funk ist alles andere als sicher und so muss der Sicherheitsaspekt von Beginn an in die Entwicklung internetfähiger Haushaltsartikel mit einfließen. Ich experimentiere zur Zeit mit einem kleinen Linuxboard, das unter anderem eine WLAN-Schnittstelle hat.

Sollte dieses Board einmal zum steuern eines Haushaltsgegenstandes verwendet werden, bleibt zu überlegen, wie die Kommunikation von der Kontrollstelle zum Board gesichert werden kann. Eine Möglichkeit wäre das erstellen eines abgeschlossenen WiFi Netzwerks das nur zur Steuerung der Geräte dient und nicht mit dem Internet verbunden ist. Das führt allerdings nicht dazu, dass das Gerät im Internet erreichbar ist, was unserem Ziel nicht gerecht wird. Eine zweite Möglichkeit ist eine normale HTTP Verbindung mit HTTP Auth zu implementieren. Somit ist schon mal eine einfache Sicherheitsebene dazugekommen und das Gerät steht nicht mehr jedem Internetteilnehmer zur Verfügung. Die nächste Schicht wäre eine Verschlüsselte Kommunikation über HTTPS. Dadurch wird das Passwort nicht mehr sichtbar übertragen und einem eventuellen Mithörer bleibt der Anmeldeprozess verborgen. Ein Passwort ist allerdings selten sicher, wenn man dem Benutzer keine vorgegebenen Grenzen setzt. Deshalb bietet sich die Kombination aus Passwort und Zertifikatslogin an. Dabei besitzt der Client ein Public / Private Schlüsselpaar und ein Passwort mit dem das Zertifikat im Client geöffnet werden kann.

Um eine SSL Verbindung über HTTPS zur Fonera zu ermöglichen, benötigt man einen anderen Webserver als den Busybox httpd. Ich habe mich für den mini-httpd entschieden, der bringt auch die Erweiterung für SLL nämlich matrixssl mit. Im OpenWrt Wiki findet sich eine gute Anleitung, wie man mini-httpd mit SSL durchführt. Anders als in der Anleitung angegeben muss allerdings das Paket mini-httpd-matrixssl anstelle von mini-httpd-openssl installiert werden. Ansonsten kann der Anleitung gefolgt werden. Jetzt steht auf der Fonera nur noch  HTTPS mit einem eigenen Zertifikat zur Verfügung. Der nächste Schritt ist nun ein Frontend zu Anmeldung auf der Fonera zu programmieren.

Unit Tests für Mikrocontroller [Installation und Konfiguration für AVR]

Unit Tests sind im PC Bereich mittlerweile Standard. Allerdings ist es schwierig sie auch für Software im Bereich der Mikrocontroller zu verwenden. Die wenigen Ressourcen, die der Mikrocontroller zur Verfügung stellt sollten idealerweise für die Software verwendet werden, die später dann auf dem System laufen soll, denn alles andere wäre Geldverschwendung. Es gibt dennoch die Bemühungen mit so wenig Wasserkopf wie möglich Unit Tests auch auf Mikrocontrollern zu implementieren.
Ich habe das in meinen Projekten bisher so gelöst, dass ich zusätzlich zum normalen Programmcode Testfunktionen implementiert habe. Alles was nur zu Testzwecken im Code eingefügt wurde habe ich mit Präprozessor-Anweisungen eingekapselt, sodass sie bei einem Release Built nicht beachtet wurden. Dadurch habe ich während der Entwicklungszeit die Testfunktionen zur Verfügung und später im ‚fertigen‘ Projekt wurden die Testfunktionen nicht mehr übersetzt. Das führte neben kleinerem Programmcode auch zu schnellerer Abarbeitung von z.B. Interrupt Service Funktionen im fertigen Projekt. In dieser Artikelserie werde ich die Verwendung von µCUnit anhand des ASURO Projekts erklären.
Das µCUnit Framework liegt als Open Source Projekt auf GitHub und kann von dort als zip-Archiv heruntergeladen werden. Die verschiedenen Beispielprojekte für i386, avr und arm zeigen, wie das Framework verwendet werden kann.
Da jeder Mikrocontroller und jedes Projekt unterschiedlich sein kann, muss das Framework mit Macros angepasst werden. So muss zum Beispiel die Text Ausgabe so implementiert werden, dass Textzeichen über die Serielle Schnittstelle, Netzwerk, oder Dateien ausgegeben werden können. Sollte auf der Projektplattform die printf() Funktion zur Verfügung stehen, kann sie verwendet werden, aber gerade bei kleinen Controllern ist selten genügend Platz um diese Funktionen mit in dem Programmcode aufzunehmen. Es wird zusätzlich noch eine Funktion benötigt, um das System in einen sicheren Zustand zu setzten und es komplett herunter zu fahren. Jeder Ausgangspin der Hardware sollte in einen sicheren Zustand gesetzt werden, um zum Beispiel hohe Ströme durch den Controller zu verhindern. Die Beispieldateien System.c und System.h enthalten Code, der diese Funktionen beschreibt.

Die System.c für den AVR zeigt welche Funktionen vom Framework erwartet werden. Vor allem die Abwesenheit der printf() Funktion muss behoben werden. Da der ASURO schon eine schlanke Funktion zum Ausgeben von Zeichen besitzt, muss hier nur die Funktion zum Schreiben von Strings implementiert werden:

void System_WriteString(char * s) {
while(*s)
{
UARTbyte(*s);
s++;
}
}

Alle weitern Funktionen habe ich direkt aus der Beispieldatei übernommen.

Nachdem die Funktion implementiert ist, könne wir mit dem Aufbau eines Testcases beginnen. Dazu können wir uns an der mitgelieferten Testsuit.c orientieren. Eine Test Suite ist aufgebaut aus dem Haupt Test und den einzelnen Testcases. Der Haupttest initialisiert den Prozessor und führt die einzelnen Tests durch.
Hier wird auch die int main(void) implementiert; die Funktion, die als Hauptfunktion aufgerufen wird.
Das Beispiel zeigt und diese Funktion

int main(void)
{
UCUNIT_Init();
// [...]
Testsuite_RunTests();
UCUNIT_WriteSummary();
UCUNIT_Shutdown();

return 0;
}

Die Funktionen UCUINT_Init() und UCUNIT_Shutdown() sind in der System.c schon implementiert und tun zur Zeit nichts. Die Funktion Testsuite_RunTests() ruft die einzelnen Tests auf:

void Testsuite_RunTests(void)
{
Test_BasicChecksDemo();
Test_PointersDemo();
Test_ChecklistDemo();
Test_BitChecksDemo();
Test_CheckTracepointsDemo();
}

Es werden alle Tests in der Testsuite aufgerufen. Diese Herangehensweise erlaubt es die Tests einzelner Funktionesteile (Testcases) in verschiedene Hauptkategorien (Testsuits) zu unterteilen. Somit erhält man leichter einen Überblick über die einzelnen Funktionstests.
Schauen wir uns zunächst die einzelnen Testcases an. Der BasicCheckDemo() Test führt ein paar grundlegende arithmetische Operationen aus. Alle diese Tests sollten bestanden werden. Zu Beginn eines jeden Testcases werde die darin verwendeten Variablen deklaiert und eventuell initaialisiert. Der nächste Schritt ist den Testcases zu beginnen, mit Hilfe der Funktion

UCUNIT_TestcaseBegin("Name des Testcases");

Danach kommt dann eine eventuelle Generierung von Testdaten oder sonstige Funktionalität. Danach werden die Ergebnisse der Funktionen evaluiert. Hier sieht man die Verwendung der CheckIsEqual Funktion, die wie ihr Name schon sagt, zwei Werte miteinander vergleicht. Am Ende jedes Testcases wird die Funktion

UCUNIT_TestcaseEnd();

aufgerufen um den Testcase zu beenden und das Ergebnis zu speichern.
Weiter Testfunktionen werden in den anderen Testcases vorgestellt. Ich möchte an dieser Stelle noch einmal auf die Evaluierungsfunktion CheckIsBitSet eingehen, da hier direkt die Ausgangspins des Controllers getestet werden können.

PORTB = (PB1 << 1); 
UCUNIT_CheckIsBitSet(PORTB, 1); /* Pass */

Im der Nächstem Artikel betrachten wir dann die einzelnen Funktionen des ASURO und wie wir eine Testsuite für die einzelnen Hauptgruppen und Testcases für alle Unterfunktionen entwickeln.

GPIOs der Fonera

Heute habe ich ein wenig mit den GPIOs der Fonera gespielt. Um später das SoC der Fonera zum Steueren von anderen Hardwareprojekten zu verwenden, habe ich die vier am einfachsten zu erreichenden GPIO Kontakte mit einer Leitung verbunden. Dabei habe ich gleich noch die Kondensatoren nach Masse entfernt. Die bildeten mit dem Widerstand zusammen einen Tiefpass am Eingang und verhindern somit die Signalintegrität bei schnellen Schaltvorgängen.

Fonera mit LED an GPIO Ports

Die 8 IO Ports der Fonera sind teilweise schon von Hardware belegt, es bleiben jedoch fünf freie Ports übrig, die beliebig verwendet werden können. Vier dieser Kontakte sind auf den Steckplatz für SW1 geführt. Für die kleinen Experimente habe ich auch nur diese vier verbunden. Wenn komplexere Aufgaben gesteuert werden sollen, kann auch der serielle Port  der Fonera verwendet werden um mit einer Mikrocontroller Schaltung zu kommunizieren.

GPIO Description
0 TP3
1 pin 5 of SW1
2 WLAN LED
3 pin 1 of SW1
4 pin 2 of SW1
5 RESET (!)
6 RESET button
7 pin 6 of SW1

Zum Steuern der GPIOs kann das Kommandozeilentool gpioctl verwendet werden. Dieses ist standardmäßig bei der openWRT Installation mit installiert worden und kann zum Beispiel über die SSH Verbindung ausgeführt werden.


gpioctl dirout 3
gpioctl set 3

Dadurch wird der Port 3 als Ausgang definiert und eingeschaltet. Der erste Pin von SW1 ist jetzt auf +3,3V. Nachdem die Funktion der GPIOs funktioniert, wenden wir uns im nächsten Artikel der Software zu und schauen, wie die Fonera dazu gebracht werden kann als Gateway für eben diese Schaltung zu agieren.