AVR, ferngesteuert

Die AVRs der 0/1-Serie verwenden zum Programmieren und Debuggen UPDI, welches etwas vereinfacht gesprochen ein auf UART basierendes Protokoll ist.

Dementsprechend hat es nicht lange gedauert, bis es pyupdi entstanden ist. Mit diesem Tool bzw. Library reicht eine serielle Schnittstelle vom PC (mit TTL-Level) und ein Widerstand, um Programmcode auf den Mikrocontroller zu bekommen.

Neben den Programmierfunktionen bietet die Schnittstelle ebenfalls die Möglichkeit zu Debuggen. Zu dem Funktionsumfang gehört gleichermaßen das Auslesen und Schreiben von Registern. Warum das nicht einfach nutzen, um direkt über den PC die Ports und Peripherie-Module des Chips zu verwenden?

Das Schreiben und Lesen im Adressraum der CPU sind gut dokumentiert, der einzige Haken ist, dass eine etwaig geflashte Firmware weiterläuft und einem die Suppe versalzen kann (oder andersrum). Zum Debuggen gehört natürlich auch, die Ausführung der CPU anzuhalten, wozu ich allerdings keine Dokumentation bzw. Informationen finden konnte. Aber macht nichts, einiges vom Protokoll ist ja bekannt und ein bisschen Reverse Engineering bin ich ja nicht abgeneigt. Unterm Strich ist es anscheinend recht trivial: Es muss ein Key geschrieben werden und in ein „reserviertes“ Control-Register eine 1 zum Anhalten und eine 2 zum Ausführen schreiben.

Mehr Details und ein kurzes Demo-Video ist im updizombie-Repository zu finden.

Aus Fehlern (nichts) lernen

Oh Mann, bin ich doof.

Am Samstag kamen meine Leiterkarten deutlich früher als erwartet. Darunter ein Board, auf dem ich einen SMD-Quarz verbaut habe.
Am Tag könnte ich sie nicht zusammenbauen, weil ein Umzug angesagt war, also wurde es in die Nachtstunden verlegt. Das Bestücken klappte dank ordentlich Flussmittel und passender Lötspitze (nichts geht über eine Hohlkehle!) gut und schnell.

Nachdem ich mich erst wieder erinnern musste, wie man den AVR-Programmer richtig einstellt damit er richtig funktioniert, ging auch der Zugriff auf den Mikrocontroller – bis ich die Fuses auf externe Taktversorgung durch Quarz einstellte. Sch…e! Warum mag der nicht mehr? Der Quarz wurde mit Heißluft aufgebraten und vielleicht hat er es nicht überlebt – mit einem fliegend aufgelisteten bedahteten hat es schließlich geklappt:

touchpad_quarz

 

Wie auch immer – einen Quarz habe ich auf die Weise noch nie kaputt bekommen.

Der Griff zum Datenblatt bestätigt es: die Padzuordnung war falsch. Bei den MQ- und MJ-Quarzen gibt es vier Pads und nur zwei gegenüberliegende sind funktional, die anderen beiden sind einfach nur da. Und natürlich war in meiner selbst erstellte Bauteilbibliothek genau dieser Fehler.

Ärgerlich, wenn das passiert. Richtig dumm, wenn es einem zweimal passiert – und genau das war der Fall. Wie das entstanden ist, kann ich h nicht mehr genau sagen. Es müsste schnell gehen, nicht gut genug kontrolliert und das Datenblatt falsch gelesen. Dort ist nämlich sowohl die Ansicht von oben und unten abgebildet. Später im Layout ist der Fehler auch nicht mehr aufgefallen – der DRC meckert kann den dummen User eben nicht erkennen.

Nachdem der Rest des Aufbaus bis jetzt sehr gut funktioniert (bis auf den Quarz funktionieren alle bisher getesteten Features), deshalb wird es keine zweite Runde Leiterkarten geben.

Demnächst gibt es dann auch mehr von dem Projekt mit dieser Leiterkarte.

Arghduino

An der ein oder anderen Stelle habe ich schon einmal erwähnt, dass ich kein besonderer Fan von Arduino bin. Vielleicht bin ich noch immer etwas voreingenommen und schätze die Annehmlichkeiten einfach nicht, vielleicht liegt es auch an den Erfahrungen, die ich damit hatte.

Die erste Berührung mit der Plattform hatte ich im Studium – mein erster HiWi-Job war, einen Aufbau aus einer Bachelor-Arbeit zu überarbeiten. Sowohl Hard- als auch Software basierte auf Arduino. Keine Ahnung, was sich der Absolvent dabei dachte, aber er versorgte den Mikrocontroller samt Bluetooth-Modul über eine 12 V-Batterie (die auch in Funksteckdosen-Fernbedienungen zu finden sind), der vermutliche Grund: auf dem Board war ein Spannungsregler verbaut und die Batterie schön klein. Dass die meisten Energie des Aufbaus in Wärme verwandelt wurde (selbst die Batterie wurde warm), war wohl egal. Laufzeit: 10 Minuten. Auch die Software war nicht wirklich der Kracher: Das Teil sollte u. a. kapazitive Messungen durchführen und per Bluetooth übertragen. Nur leider war die verwendete Lib so geschrieben, dass sie gerne Mal die anderen Aufgaben länger blockierte. So lange, dass wichtige Ereignisse versäumt wurden.

Was schlimmer war – die Implementierung auf Seiten von Arduino oder des damaligen Kommilitonen – keine Ahnung. Wahrscheinlich eine Mischung aus beidem.

Schlussendlich habe ich das Teil komplett neu gemacht. Die Hardware wurde von der Größe einer Zigarettenschachtel auf die einer Streichholzschachtel geschrumpft und die Betriebsdauer dank Akku auf knapp 8 Stunden erhöht. Dazu gab es noch ein paar Zusatzfeatures, wie eingebauter Laderegler und einen Taster zum Ein- und Ausschalten. Ok, dafür konnte man den Akku nicht mehr richtig herausnehmen.

Muss ich überhaupt über die Software reden? Das einzige was blieb, war die Grundidee. Der Rest wurde komplett neu in „damals“ noch AVR Studio geschrieben. Der Code war kleiner, flotter und zuverlässiger. Nur das Gesamtsystem krankte etwas, aber aus anderen Gründen.

Vor kurzem hatte ich wieder Kontakt mit der Plattform. Es sollten ein paar Motoren angesteuert werden. Arduino und Treiber waren deutlich günstiger als man es selber jemals machen könnte, also wurde es genommen. Ersterer war ein China-Klon mit CH340 statt zweitem Atmel-MCU. Irgendwann habe ich auch herausgefunden, dass das Protokoll doch nicht STK500-kompatibel (mit entsprechender Änderung kann immerhin avrdude damit umgehen) ist und wie in den Bootloader gesprungen wird. Letzteres ist auch gleich potenziell verhängnisvoll für Linux-User: Der Sprung findet statt, indem die DTR-Leitung geschaltet wird – diese ist mit dem Reset über einen Kondensator verbunden. Doof, dass Linux beim Öffnen eines seriellen Ports kurz DTR anschaltet. Noch dümmer, wenn man mit dem Mikrocontroller über Batchfiles kommunizieren will und er dadurch den Port immer wieder öffnet und schließt und man eigentlich Variablen im Chip halten will. Schlussendlich ist ein Schalter zum Auftrennen der entsprechenden Leitung in der Schaltung gelandet.

Für den schrecklichen Aufbau des Kommilitonen und die etwas eigenwillige Schaltung vom Klon kann Arduino bzw. Genuino (oder wie auch immer die Firma heißt) natürlich nichts. Trotzdem habe ich das Gefühl das eher zweifelhafte Aufbauten oft (nicht immer) gemeinsam mit diesen Kits daherkommen, was vermutlich mit der Zielgruppe zusammenhängt. Diese umfasst nach meiner persönlichen Einschätzung oft Leute, die kein tieferes Verständnis für Elektronik haben und denen dadurch die Hardware primär egal ist, Performance eine eher eine untergeordnete Rolle spielt, dafür aber der Einstieg sehr einfach ist und der Aufbau nach kurzer Zeit irgendwie funktioniert. Als Beispiel fällt mir hierfür der „Heimwerkerking Fynn Kliemann“ ein.

Das fehlende Verständnis und oft leider auch Lernresistenz oder gar Komplettverweigerung der Realität (Lesen und Anwenden von Informationen aus von Datenblättern, um nur eines zu nennen) merkt man dann oft in Elektronik-Foren.

Hate the player, don’t hate the game? Leider nicht ganz.

Habt ihr mal versucht eine vernünftige Dokumentation zu den Arduinos zu finden? Ich habe bis jetzt immer suchen und sammeln müssen. Wo sind die Hexfiles der Bootloader? Wie ist das Pinmapping abseits der Wiring-Bibliothek? Klar, einen „normalen“ Arduino-User kümmert/interessiert das nicht, aber was wenn man aus dieser wattierten Welt ausbrechen will? Da ziehen schnell dunkle Wolken auf.

Zugegeben, ich habe auch schon Arduinos (genaugenommen zwei Pro Micros) gekauft, weil die Boards von der Preis/Leistung unschlagbar waren. Abgesehen davon, dass die Hardware teilweise mistig war (HWB fest verdrahtet, obwohl das auch über Fuses geht, 5V-Regler trotz Versorgung über USB, grauenhaften Schaltplan mit falschem Symbol für den Mikrocontroller) und dieser unsägliche Bootloader, obwohl im Auslieferungszustand ein guter mit DFU-Protokoll installiert wäre.

Ein etwas an die Gegebenheiten angepasster DFU-Bootloader kam sehr schnell auf das Board. Nachdem ich Kontakt mit den Jungs in Norwegen aufgenommen habe, funktioniert sogar das Flashen direkt aus der Ende-Februar-2016-Version von Atmel Studio 7 (Rev 790).

Bei der Software – Entwicklungsumgebung möchte ich es nicht nennen – man ist ohne tiefere Eingriffe auf eine Datei beschränkt, was Spaghetti-Code fördert, man sieht nahezu nichts vom Compiler und die Libs sind – wie schon erwähnt – oftmals grausig.

Dabei ist Atmel Studio doch erstaunlich benutzerfreundlich oder zumindest deutlich Angenehmer für den Einsteiger als IAR, Eclipse oder eine bare-metal-Lösung (als Männer noch richtige Männer waren und ihre Makefiles selber geschrieben haben).

Und dann wären da noch Nicht-Innovationen wie der AAduino, der über über diverse Online-Medien (Hack A Day, Atmel Studio Blog, sogar Heise Online um nur drei zu nennen) lief, ohne dass da besonders hervorzuhebende Leistung der Macher zu sehen war – zumindest das Funkmodul hätte komplett auf der Leiterkarte implementiert werden können.

So sehr ich Arduino und viele (nicht alle) nur einen Facepalm vergönne, so hat die Plattform einen ganz großen Pluspunkt: Sie hat Mikrocontroller und DIY näher an die Leute gebracht. Mit allen vor und Nachteilen. Ich bleibe jedoch dabei, davon allerhöchstens die Hardware zu verwenden.