Es geht langsam aber stetig voran mit meinem LED Würfel: Inzwischen ist der eigentliche Würfel fertig! Ich hatte die einzelnen Ebenen ja schon fertig montiert, und jetzt habe ich die acht Ebenen auch zusammengesetzt. Das war gar nicht so schwierig, man muss nur etwas darauf achten, dass der ganze Würfel nicht schief wird. Ich denke, dass ist mir aber ganz gut gelungen. Schlussendlich habe ich den Würfel auch schon auf sein Holzplatte gesetzt. Das war eine extreme Fummelarbeit, denn man muss ja 64 Drähte durch ebensoviele Löcher stecken. Und wenn man dann noch so blöd ist, und die Löcher oben mit einem 5er Bohrer bohrt, unten aber nur einen 3er nimmt, dann bleiben die Drähte auch noch in den Löchern stecken. Das ist extrem unpraktisch. Und es kam noch besser: Als alle 64 Drähte drin waren, habe ich bemerkt, dass ich vergessen hatte, die Löcher für die Kathoden zu bohren 🙁 (Also die Drähte, die jede Ebene mit Strom versorgen). Die habe ich dann schlussendlich von unten gebohrt, wären der Cube schon auf der Platte war. Das ging sogar recht einfach, dass hatte ich mir schlimmer vorgestellt.
Nun kam also der nächste Part: Die Steuerung. Dazu muss erst Mal an jede der Anoden ein Kabel, und auch an alle 8 Kathoden. Macht also 9*8 = 72 Kabel. Damit dass nicht zu unübersichtlich wird, habe ich 8-poliges Flachbandkabel gekauft, 3 Meter. Das war ein wenig kurz, wie sich zeigte: Das reicht für genau 9 Kabel mit ca. 30 cm Länge. Davon geht aber ein nicht unerheblicher Teil dafür drauf die Kabel an zulöten (denn dazu müssen sie ja in die Breite gezogen werden, ich hab leider kein Bild, sorry). Schlussendlich reicht das oberste Kabel gerade noch so bis auf die andere Seite, die Platine muss also direkt neben dem Cube stehen. Naja, sollte sie ja sowieso 🙂 Das zuschneiden und abisolieren der Kabel war ein ganz schöner Aufwand, hat fast eine Stunde gedauert:
Und dann kam die Steuerung, an der ich auch schon eine Weile bastele: Das Herzstück ist ein ATmega 644p, also ein recht großer Microcontroller. Da ich über (nahezu) keinen ISP-Programmer verfüge, und außerdem Ardunio super finde, war mein Plan einen Arduino-Bootloader auf den Chip zu brennen, und danach Ardunio zum Programmieren zu benutzen.
Nur jetzt gehen die Probleme los: Offiziell wird der ATmega 644(p) nicht von Arduino unterstützt, aber es gibt immerhin ein Projekt namens Sangunio, dass diesen Mangel beheben will. Leider scheint die Website verwaist, aber auf GitHub findet man schlussendlich eine aktuelle Version (an der sogar noch gearbeitet wird). Soweit ich beurteilen kann funktioniert die auch wunderbar. Dabei ist auch ein Booloader als .hex-Datei, denn man direkt auf den ATmega brennen kann. Dabei handelt es sich um einen Version von optiboot, einen extrem kleinen Bootloader, der nur 512 Byte (!) belegt, und damit mehr Platz für das eigentliche Programm lässt. Nur wie den Bootloader brennen, ohne ISP-Programmer? Naja, ich habe ja schon einen: In meinem NIBObee ist ein modifizierter USBasp eingebaut, der den dort verwendeten Controller programmiert. Und es sollten sich ja auch andere Controller damit benutzen lassen, oder?
Ja, dass sieht ein wenig abenteuerlich aus, aber es funktioniert einwandfrei. Im Endeffekt habe ich nur die ISP Pins (also SCK, MOSI, MISO und /RESET) an den anderen Controller weitergeleitet, und zur Sicherheit auch noch die Stromversorgung aus dem NIBObee geholt. Nun, ein kleines Problem gab es noch: Der NIBObee meldet sich immer als „NIBObee Intergrated Programmer“ und nicht als „USBasp“. Und ich habe es einfach nicht hin bekommen, avrdude dazu zu bringen, mit dem NIBObee zu reden. Schlussendlich habe ich dann (wie ich hier schon mal beschrieben hatte), den USBasp Treiber installiert, und damit wir den NIBObee dann auch also USBasp erkannt. Fun Fact: Da Windows die Treiber pro USB-Port installiert, kann ich jetzt durch umstecken meinen NIBObee also solchen oder also USPasp anmelden 🙂
Nachdem ich dieses Problem gelöst hatte, konnte ich dann auch endlich den Bootloader installieren, was auch auf Anhieb geklappt hat.
Und nun wollte ich auch endlich mal ein Programm auf den Chip laden. Dazu habe ich einen USP-auf-Seriell Konverter benutzt, den man auf im Bild gerade noch erkennen kann (stammt auch von der Intel-Leibniz-Challenge). Leider wollte das zunächst gar nicht klappen, nur der TX-Pin blinkte drei mal. Also habe ich mal einen Reset-Schalter angeschlossen, und den Chip im richtigen Moment zurückgesetzt. Damit ging es dann 🙂 Den eigentlichen Fehler habe ich erst gestern gefunden: Der Pull-Up-Widerstand an /RESET war leider braun-rot-schwarz (=12 Ohm), und nicht braun-schwarz-rot (=1k Ohm). 🙁 Und gegen einen 12 Ohm Pull-Up ist der Chip wohl nicht angekomen… Mit dem richtigen Widerstand funktioniert jetzt aber auch den Auto-Reset wie er soll.
Leider wollte der Upload aber auch nicht so recht: Mal ging der Upload gar nicht, mal hat er bei „Verify“ abgebrochen, in ganz seltenen Fällen lief er mal durch. Nach ein wenig Recherche war auch der Fehler gefunden: Optiboot benutzt einen Baudrate von 115200 Baud, damit die Uploads schneller gehen. Leider ist dafür ein 16MHz Kristall, wie ich ihn benutzt habe ziemlich ungeeignet, denn der Timing-Fehler beträgt mehr als -2 %. Und dadurch sind die Uploads immer abgebrochen, da es zu Bit-Fehlern kam. Komischerweise hat bei der ILC unsere 115200 Baud ASCII-Art wunderbar funktionert, auch mit 16MHz. War vielleicht Glück.
Nun sollte sich das Problem ja beheben lassen, einfach den Bootloader mit 9600 Baud übersetzen und noch mal installieren. Praktischerweise ist sogar eine Batch-Datei dabei, mit der dass unter Arduino auf Windows (!) klappen soll. Tat es aber nicht, mit ist der Linker immer abgestürzt. Nagut, also meine Ubuntu VM angeworfen, und die USB-Geräte weitergeleitet (klappt richtig gut!), und nach ein paar kleinen Problemen konnte ich dann auch den Bootloader neu übersetzen:
make atmega644p BAUD_RATE=9600 LED_START_FLASHES=1
Leider habe ich es nicht geschafft, mit einem einfachen „make“, die Original-Dateien zu replizieren, aber der neue Bootloader funktioniert wunderbar! Timing-Fehler: 0,1%. Leider braucht der Upload jetzt wirklich seine Zeit…
Fazit: Arduino mit einen ATmega 644p mit 16MHz zum Laufen zu bringen ist nicht ganz trivial, aber durchaus machbar. Wenn man einen 20MHz Kristall benutzt (den der mega durchaus aushält), hat man auch kein Problem mit der Baudrate.
Wenn Interesse an dem neu übersetztem Bootloader (und der angepassten boards.txt) besteht, einfach melden.