Was man braucht:

AVR-Butterfly, Serielles Kabel, USB auf Seriell Adapter, CrossPack for AVR® Development

Serielles Kabel:

Das serielle Kabel (ich habe meins von einer alten Maus abgeschnitten) muss der Grafik entsprechend angeschlossen werden. Im Falle der hoffentlich standardisierten Beschriftung meines Steckers kommt (wenn man das Butterfly-Modul so hält, dass man die Beschriftung richtig herum vor sich hat) Pin5 des Steckers an den unteren der 3 Pins auf dem Modul, Pin 2 an den Mittleren und Pin 3 an den oberen.

USB auf Seriell Adapter:

Hier hatte ich Glück, dass der Adapter, der damals für einen PC gekauft wurde, am Mac funktionierte. Da die "Adresse" des Adapters im Makefile angegeben werden muss, ist es unabdingbar sie herauszufinden, dies geschah in meinem Fall über die Kommandozeile/das Terminal. Mit

ls /dev

bekommt man den Inhalt des Devices-Ordners zu sehen und hier sollte der Adapter nach installation der Treiber oder evtl. auch einfach so auftauchen. In meinem Fall setzt der Name des Gerätes sich zusammen aus tty, einer Unix spezifischen Kennung, PL2303, welches der Typbezeichnung des Adapters entspricht und einer Zufallszahl, die sich bei jedem an und abstecken des Teils ändert.

CrossPack for AVR® Development:

Vormals hies das Projekt AVR® MacPack, wurde aber aus Lizenzgründen umbenannt. Nichts desto trotz, holt man sich hiermit alles auf den Mac, was man braucht, um den Code zu kompilieren und auf das Modul zu schieben. Die Dateien werden in

/usr/local/CrossPack-AVR-"Datum der aktuellen Version"

abgelegt. Um später sinnvolle updaten zukönnen, gibt es das Verzeichnis auch ohne den Datumszusatz, wo dann Links auf die benutzen Dateien liegen, so dass die Systempfade bei jeder Installation erhalten bleiben und nur die Links auf die aktuelle Installation umgebogen werden. Eigentlich könnte der Ort der Files auch egal sein, denn da avr-gcc und avr-dude in den Systempfad eingetragen werden, funktionieren die Kommandos direkt, ohne ins Verzeichnis gehen zu müssen. Es befindet sich dort aber der Ordner

 /usr/local/CrossPack-AVR/manual

hier liegen einige HTML-Files, die mehr oder minder Hilfreich sind. In jedem Fall ist die Installation des Pakets ein Kinderspiel (pkg-Installer) und falls man jetzt noch weiß, wie der USB auf Seriell Adapter heißt, ist der Rest quasi ein Kinderspiel.

Ran an den Speck:

Ich habe hier mal alles an Dateien zur Verfügung gestellt, was für ein kleines Beispielprogramm notwendig ist. Das ganze wurde im Rahmen eines Projektes an der Uni genutzt und besteht, aus 2 makefiles (makefile.avr und makefile). In makefile muss selbst noch ein bisschen Hand angelegt werden, denn hier muss an entsprechender Stelle der USB nach Seriell Adapter eingetragen werden (makefile ist gut kommentiert und die Stelle nicht zu verfehlen). Neben dem eigentlichen Programm in der main.c ist auch mit butterfly.h und butterfly.c gleich eine Bibliothek mit eingebunden.

Die vorbereiteten Dateien werden in einem Ordner verstaut und das Terminal geöffnet. Hier wechselt ihr in das entsprechende Verzeichnis und kompiliert alles mit

make all

An dieser Stelle hatte ich den Fehler gemacht den Anweisungen in der Doku vom CrossPack zu folgen, die nicht wirklich zum Ziel führte. Nach dem Kompilieren wuseln ungezählte Dateien im Ordner herum. Das eigentliche Produkt ist die main.hex, die nun mit AVR-Dude auf das Modul geflasht wird.

Also Modul per Adapter und seriellem Kabel an den Rechner stöpseln, die Stromzufuhr des Moduls kurz unterbrechen, um es zurück zu setzen (Batterie kurz anheben), jetzt mit dem Befehl

avrdude -p atmega169 -P /dev/tty.usbserial -c butterfly -V -U flash:w:main.hex

das Flashen anstoßen und den Joystick drücken. Anstatt "/dev/tty.usbserial" sollte natürlich die Adresse des eigenen USB auf Seriell Adapter im Befehl verwendet werden. Das Ergebnis sollte in der Kommandozeile schließlich so aussehen, wie im Bild. Wenn AVR-Dude danke sagt, ist alles gut. Jetzt noch den Stick nach oben bewegen, um das Programm zu starten und das Modul sollte nervig piepen.

Damit wäre der erste Schritt geschafft. Von jetzt an geht es um die "wirklichen" Probleme bei der Programmierung etc. Bei deren Lösung wünsche ich viel Erfolg :)

Da ich als Nebenjob PHP hacke und dort Termindruck herrscht etc. hab ich mich für den Job noch nicht ausführlich mit PHP und dem Mitgelieferten PHP-Modul auseinandergesetzt. Erst war ich mit XAMPP für den Mac unterwegs, dann mit dem Apache und PHP-Modul, die bei OS X dabei sind und als mit dieser Konfiguration bei mir irgendwas nicht laufen wollte, bei meine Kollegen hingegen ohne weiteres, bin ich auf MAMP umgestiegen. Damit läuft alles soweit, dass sich auf der Firma prima entwickeln lässt, auch wenn ich es eigentlich nicht so richtig toll finde, wenn ein Apache und PHP schon im Lieferumfang steckt einen externen Webserver zu installieren und Software doppelt auf dem Rechner zu haben.

Somit kam der MySQL-Server zum mitgelieferten Webserver hinzu und so war für kleinere Nebenprojekte privater Natur schon mal alles auf Bordmittel umgestellt. Aus Interesse habe ich mich in der letzten Woche etwas intensiver mit Drupal auseinander gesetzt und bekam hier die Nachricht, dass bei meinen Bordmitteln die GD-lib zu alt, oder nicht installiert ist (ist eine Bibliothek die aus PHP heraus das Erstellen und Bearbeiten von Grafiken ermöglicht). Nach ein bisschen Recherche stellte sich heraus, dass das PHP Modul von OS X abgespeckt ist und dort einiges fehlt (was auch der Grund sein könnte, wieso auf der Arbeit das ein oder andere nicht klappte, wobei ...). Das Netz sagte mir auch, dass man, die GD-lib nicht einfach zum PHP-Modul hinzuinstallieren kann (habe das mal so geglaubt und nicht weiter in diese Richtung gesucht).

Also musste ein neues PHP-Modul mit GD-lib Support her. Hier gibt es 2 Möglichkeiten. Entweder, man besorgt sich von irgendwo eine kompilierte Version, die nur noch an die richtige Stelle kopiert und in der Konfig-Datei angegeben werden muss, oder man kompiliert selbst.

Da ich kompilierungstechnisch und auch was die Innereien von PHP und Apache, sowie deren Zusammenspiel angeht, recht unwissend bin, bedurfte es für mich in beiden Fällen einer Anleitung und eigentlich hätte ich die Methode mit der kompilierten Version bevorzugt. Hierzu stößt man schnell auf entropy.ch. Hier wird ein schönes Installationspaket für eine nicht ganz aktuelle PHP-Version angeboten, das aber leider für OS X 10.4 Tiger bestimmt ist und unter Leopard nicht tut.

Desweiteren gab es einen Build von PHP 2.2.5, der aber nicht mehr zum Download bereit steht. Man bekommt aber noch eine 2.2.X-BetaY. Hier hätte ich wohl oder übel zugegriffen, wenn ich nichts anderes gefunden hätte, aber eigentlich hatte ich nicht vor mir eine Beta zu installieren. Ich hab schon genug mit Bugs in meinem PHP-Code zu tun, da muss ich mir nicht noch Bugs mit PHP auf den Mac holen.

Wie dem auch sei, habe ich auf der Seite von John Malis eine wunderbare Anleitung gefunden, wie ich mir das aktuelle PHP-Modul (5.2.6) auf dem Mac selbst bauen kann und zwar mit GD-lib (und PDO). Das Ganze hat wunderbar geklappt und zumindest Drupal meckert jetzt nicht mehr. Ob das CMS-Monster, mit dem ich beruflich zu tun hat auch mit dem neuen Modul ordentlich arbeitet und MAMP damit entsorgt werden kann, finde ich später heraus.