PSA: HMC5883L vs. QMC5883L

Mittlerweile bestelle ich ja auch ganz gerne bastelfreundliche Module, darunter zuletzt auch ein GY-271, ein Kompassmodul, das einen Honeywell HMC5883L enthalten sollte. Beim I2C-Detect ist schon aufgefallen, dass die Adresse nicht wie erwartet ist – 0x0D (7-bit) statt 0x1E (7-bit).

Im Datenblatt von Honeywell steht leider nichts vom Package-Marking, also mal auf die Suche begeben.

Wie sich herausstellt, werden mittlerweile auch ganz gerne die nahezu pinkompatiblen und komplett softwareinkompatiblen QMC5883 der Firma qst verbaut. Zum Hersteller konnte ich nichts in Erfahrung bringen. Auch nicht auf baidu.com. Etwas irritierend auch, dass in den Meta-Infos des Datenblatts als Verfasser „Honeywell“ steht. Da war wohl eher der Wunsch Vater des Gedanken.

Wie auch immer, hier mal ein Foto der ICs bzw. Module im Vergleich:


Hier sieht man auch, dass die Beschaltung wohl leicht anders ist.

Auf Datenblätter verlinke ich mal nicht, die findet man sehr einfach im Internet.

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.