Zerlegt: Billig-Akku-Ladegerät

Veröffentlicht am 12. August 2016 von Chris

So, es gibt ein neues Spielzeug, das als Rattenschwanz auch gleich Zubehör braucht.

Bei meinen anderen Kameras war immer ein externes Ladegerät dabei, bei der neuen leider nicht mehr. Die Akkus werden bei der Lumix zwar in der Kamera über USB geladen, aber nur, wenn sie abgeschaltet ist. Das ist mehr als schade. Leider kann man die Kamera über USB auch nicht versorgen. Sie zieht am nur um die 6 mA und zeigt beim Einschalten eine Meldung an, dass der Akku nicht mehr geladen wird. Warum nur?

So braucht man für den Betrieb an der Steckdose wieder einen Battery-Dummy, der die Kamera dann wieder nicht richtig aufs Stativ passen lässt. Zudem hat sich der Stecker am Dummy meiner SX280 als etwas wackelig herausgestellt – ab und an geht die Kamera einfach aus. Mit Versorgung aus dem USB könnte die Kamera auf interne Versorgung zurückfallen, falls nichts mehr von draußen kommt. Ok, das Powermanagement ist vielleicht etwas aufwändiger, aber das sind einmalige Entwicklungskosten. Hätte, könnte, müsste, sollte.

Wie auch immer, ich habe grundsätzlich mehrere Akkus dabei, wenn länger unterwegs bin. Da ist das Laden nur in der Kamera unpraktisch. Aber zum Glück gibt es den Aftermarket:

Ich frage mich immer wieder, wie man das für so wenig Geld produzieren kann. Die Stromversorgung findet über eine Micro-USB-Buchse statt. Laut Typenschild 1 A bei 5 V rein, 500 mA bei maximal 8,4 V raus. Nachdem der Originalakku ein bisschen über 1 Ah hat, wird mit 0,5 C geladen. Klingt ganz ok.

Clever am Design: die obere Gehäusehälfte besteht nur aus der Akkuschale, der Rest kann gleich bleiben. Ich würde fast wetten, dass es den gleichen Lader auch für Nikon, Canon, Sony etc. gibt.

Nur was ist da drin? Auf jeden Fall ein Schaltwandler und ein Laderegler. Was solls:

Ok, dann eben beides in einem gänzlich unbeschrifteten Chip. Eingangsfilterung ist zumindest mal keine vorhanden (C5 zählt nicht), die Induktivität macht zusammen mit Q3 und D1 den Aufwärtswandler. RJ3 ist dann wohl die „Sicherung“. Da die Schaltung, an der der Akku direkt hängt, wirklich einfach ist, hier mal der in ein paar Minuten abgepinselte Schaltplan:

Das Diodensymbol sollte eigentlich eine Schottky sein. R8 und C12 stellen einen Snubber dar, vielleicht ist das Teil EMV-technisch doch nicht katastrophal (man wird ja wohl noch träumen dürfen). R9 dient wohl als Grundlast für den Schaltwandler, damit dieser nach dem Abschalten in absehbarer Zeit gegen 0 geht. Bei τ = 2,2 Sekunden sind es immerhin knapp 11 Sekunden, bis der Elko nahezu leer ist. Besser als nichts.

Nachdem Li-Ion-Akkus mit CC-CV geladen werden müssen, sollte eigentlich sowohl eine Strom- und Spannungsregelung vorhanden sein. Q1 dient wohl eher dazu, den Akku nach dem Laden zu trennen, weniger der Stromregelung. Ich vermute, das diese indirekt über die Spannung am Schaltwandler geregelt wird.

Abgesehen davon, dass der IC kein Marking hat, sieht die Schaltung auf den zweiten Blick nicht ganz so dubios aus, wie ich zunächst befürchtet hab. Ob sich mein Gefühl bestätigen wird, werde ich wohl erst wissen, wenn der erste Akku abgebrannt ist (was durch dessen Schutzschaltung hoffentlich nicht passieren wird).

Was kommt raus? Im Leerlauf (also ohne Akku) habe ich an den Anschlüssen etwas um die 11 V gemessen, die einbrechen, sobald ein Akku dran hängt. Sobald ein Akku eingelegt wird, bricht sie natürlich ein. Ladeendspannung habe ich bei 8,38 V gemessen, also 4,19 V pro Zelle. das ist IMHO ganz ok.

Zu guter Letzt: habe eigentlich erwähnt, wie wenig ich so gelb-„grüne“ LEDs mag? Die im Lader ist zwar nicht ganz so schlimm, aber auch nicht ganz so schön. Nachdem in der Grabbelkiste mittlerweile eine größere Stückzahl in sattem Grasgrün herumliegt, konnte ich es nicht lassen:

In Natura kommt das grün natürlich noch ein bisschen besser raus.Jetzt muss nur noch der Lightguide schön matt werden 😉

Ganz Problemfreie Software?

Veröffentlicht am 10. August 2016 von Chris

Einen Nachtrag muss ich zur GPS-Geschichte meiner Canon-Kamera noch machen: der Support hat mir versichert, dass die A-GPS-Daten auch bei der fehlenden Anzeige des Gültigkeitsdauer an das Modul weitergegeben werden. Das wollte ich zunächst nicht so wirklich glauben, aber auch nicht beweisen. Die „Gute“ soll zu bleiben.

Einen Unterschied der beiden Kameras habe ich noch gefunden: Aufgrund von Problemen bei der Akkulaufzeit während Videoaufnahmen gab es mal ein Firmware-Update. Die „gute“ hat es, die andere nicht. Nachgezogen habe ich noch nichts, aber es wäre noch einen Versuch wert – allein um zu sehen, ob das Verhalten konsistent ist und um auszuschließen, dass die Firmware der „guten“ einen Knall hat.

Um das vermeintliche Problem mit den Assist-Daten zu checken, habe ich mehrfach die TTFF (time to first fix), also die Dauer vom Einschalten des Empfängers zum Ermitteln der Position, gestoppt. Mit und ohne A-GPS-Daten. Um verlässliche Ergebnisse zu erhalten, gab es mehrere Messläufe. Zwar unter dem Dachfenster aber mit freiem Blick in den Himmel. Die Scheibe ist nicht metallisiert, hat also nicht allzu viel Dämpfung. Das Tablet braucht an der Stelle (ok, mit genauer Zeit und Hilfsdaten) nur wenige Sekunden für einen Fix.

Die Messung selbst ist etwas nervig – die Kamera schaltet nach 30 Sekunden das Display ab und man sieht nicht mehr, ob ein Fix zustande gekommen ist. Eine Anzeige der Details zum Status des Empfängers hat sich der Hersteller nämlich gänzlich gespart. Das Drücken zu automatisieren habe ich mir gespart. Also blieb nichts anderes übrig als alle 25 Sekunden irgendeine Taste zu drücken. Um gleiche Ausgangsbedingungen zu schaffen wurde vor jeder Messung der Akku entnommen und ungefähr 10 Sekunden gewartet.

Nach längerem Warten war ich zumindest etwas schlauer: ohne Hilfe bis zu 17 Minuten, mit zwischen 4 und 7 Minuten. Aufgrund der nicht sonderlich großen Reihe und den nicht idealen Bedingungen sind die Werte allerdings mit Vorsicht zu genießen. Für verlässliche Messungen müsste das Ganze unter freiem Himmel, bei gutem Wetter und gleichbleibender Satellitenkonstellation durchgeführt werden – mal schauen, ob dafür die nächsten Tage Zeit übrig bleibt.

Auch wenn der TTFF – verglichen mit anderen Empfängern – einigermaßen bescheiden ist, scheint A-GPS zu funktionieren. Mein Anfangsverdacht Nr 2 hat sich also verhärtet: jemand in der Software hat es verkackt. Könnte schlimmer sein, aber schön ist es trotzdem nicht.

Über Spannungen und deren (Einschalt-)folgen

Veröffentlicht am 28. Juni 2016 von Chris

Was ist cooler als ein Logic 16 von Saleae? Natürlich ein Logic Pro 16!

Neben den 16 Kanälen, die (bei 4 Kanälen) mit bis zu 500 MS/s samplen können (100 MS/s bei 16 Kanälen) kann man selbige auch analog aufzeichnen lassen. Das macht die Sache zwar langsamer und es benötigt sehr viel Speicher, aber es bieten sich interessante Möglichkeiten. Nein, es wird kein Oszilloskop daraus. Auch wird es kein Datenlogger. Das Gerät eröffnet wie ich finde eine neue Geräteklasse – einen Hybriden, der es ermöglicht, für Oszilloskope zu breite Busse digital zu analysieren und dabei – wohl bemerkt in den gegebenen Grenzen – auch das Analogverhalten der Signale anzusehen.

Es gibt einen Anwendungsbereich, für den der Pro wie geschaffen ist: Power-up-Sequenzen. Als Bastler kennt man sie nicht, weil man sie nicht braucht. In komplexeren Systemen gibt es oft viele Spannungen, deren Einschaltreihenfolge und teilweise auch die Art des Einschaltens von großer Wichtigkeit ist, da sonst Komponenten entweder nicht richtig funktionieren oder sogar Schaden nehmen. Nehmen wir einfach mal ein Handy: Beim Einschalten bekommt die CPU nicht einfach Strom, zunächst muss das Power Management hochfahren, das den Rest regelt. Anschließend bekommt der Arbeitsspeicher Strom, dann der Prozessor. Dann kommt der Takt. Danach kann langsam die Peripherie hochgefahren werden – Sensoren, Audio, Display und alles andere.

Um es sehr einfach zu umreißen: Würde das Display bzw. dessen Hintergrundbeleuchtung als aller erstes Strom bekommen, würde man als allererstes – weil der ganze Rest noch gar nicht läuft – irgendwelchen Mist auf dem Display sehen. Bei meinem alten China-Scope (Unitrend 2042) war das zum Beispiel der Fall. Wertig wirkt das nicht.

Um das GPS-Modul etwas besser kennenzulernen, sollte man wissen, wann es wo welche Spannung braucht. Mittlerweile habe ich auch den letzten Fädeldraht angelötet. Um keine Kurzschlüsse am Konnektor zu erzeugen, kratzte ich (schweren Mutes) die Flex zum Empfänger auf und verging mich an ihr – mal hoffen, dass der Draht und die Flex hält:

Das GNSS-Modul ist zunächst getrennt – um zu sehen, welche Spannungen die Kamera zur Verfügung stellt. Zu Beginn der Messung ist die Kamera vom Strom getrennt und wird anschließend über das Akkufach versorgt und bleibt für den Benutzer auch aus. Trotzdem tut sich was:

An Pin 1 – im Foto oben (wie in den Posts von gestern) links liegen 3 V an. Pin 2 ist GND und daher in diesem Kontext uninteressant. Pin 3 hat 3,3 V. Pin 4 bis 7 floaten vor sich hin – das dürften alles Datenleitungen sein. An Pin 8 liegen wiederum 2,43 V an.

Im nächsten Screenshot sieht man die Stärke des Pro:

Cursor A1, B1 und C1 liegen so gut wie möglich aufeinander. A2 zeigt die Verzögerung von Pin 3 zu 1 und 8, wobei man darüber streiten kann, ob hier tatsächlich eine Sequenz gefahren wird – schließlich sind es nur knapp 120 µs Unterschied. Was man mit einem normalen Logic Analyzer nicht gesehen hätte – und mangels Kanälen an einem Oszi auch nicht ist das Verhalten beim Hochfahren der Spannungen aller Kanäle. Bei Pin 1 dauert das ca. 6,35 ms, bei 3 und 8 ca 8,8 ms, wobei Pin 8 etwa eine drittel Sekunde früher komplett hochgefahren ist. Ich wollte aber niemanden mit Cursorn erschlagen.

Auch nach einer Viertel Stunde ändert sich nichts. Das Modul wird also dauerhaft mit Strom versorgt. Das ergibt auch Sinn – um einen schnellen GPS-Fix zu erhalten, ist es wichtig, dass die Uhr im Empfänger dauerhaft läuft. Die Auswirkung auf die Betriebsdauer des Akkus spürt man so gut wie gar nicht, weil man den Unterschied nicht kennt 😉

Schaltet man die Kamera ein, zeigt sich folgendes Bild:

Es ändert sich lediglich was an Pin 5 – das ist der UART-Tx (zum GNSS-Modul). Im „Stüpfel“ weiter rechts, werden ein paar Byte übertragen:

Leider kann man keine Analyzer auf Analogsignale anwenden – das fehlt dem Logic noch. auf Pin 6-8 sieht man leichtes Nebensprechen – ob es tatsächlich an den Signalen oder meinem bescheidenen Aufbau liegt, kann ich nicht sagen, vermute aber letzteres.

Wenn man in den Kameraoptionen die GPS-Funktion abschaltet, tut sich erst einmal nichts. Im Gegenteil, alle Stromversorgungen bleiben an. Allerdings ist nicht sicher, ob es einen Enable gibt und dieser auf Kameraseite ein Open Drain mit Pull-up im Modul ist.

Interessant ist ebenfalls, dass die Kamera auch nach dem Ausschalten noch eine ganze Weile mit dem Modul zu kommunizieren versucht. Entweder ist es der klägliche Versuch, das Modul in den Tiefschlaf zu schicken oder etwas anderes. Auf jeden Fall bleibt der UART noch relativ genau 30 Sekunden aktiv, bevor er abschaltet. Die Versorgungsspannungen bleiben aber – wie erwartet – danach aktiv.

So, nun einmal mit Modul – wieder zunächst das Anklemmen der Versorgung im Akkufach:

Ok, ein leichter Unterschied. Die Versorgungspins bleiben wie erwartet gleich. Pin 4 dümpelt nach wie vor vor sich hin (hätte ich ihn wirklich anlöten müssen?) Pin 5 hat nun auch hier seine 1,8 V. Da muss wohl ein Pull-up im Modul verbaut sein. Pin 6 ist nun auch aktiv. Nach dem kleinen Knick bei ca. 0,75 s steigt die Spannung übrigens von 1,7 auf 1,8 V – vielleicht der Pull-Up des Prozessors der Kamera? An Pin 7 liegen nun dauerhaft 1,8 V an. Entweder der Ausgang eines GNSS-internen Spannungsreglers oder Interrupts oder sonstwas?

Nach nicht ganz einer Sekunde ist der Spuk auf jeden Fall vorbei, die Kamera ist wieder im Tiefschlaf. Was vorhin nicht zu sehen war: Bis auf der Versorgung an Pin 3 werden alle abgeschaltet. Das muss für die Uhr im Empfänger sein.

Um nicht mit ganz so vielen Screenshots zu spammen, hier mal Power-up und Power-down zusammengefasst und dazu die absoluten Zeitstempel. Wer rechnen will, gerne:

A1: 0,604856 s (versteckt hinter B1)
B1: 0,604999 s
A2: 0,611305 s
B2: 1,560646 s
C1: 1,560977 s

Kommen wir nun zum Einschalten der Kamera mit Modul:

Das meiste ist bereits bekannt, ich hab nach wie vor keine Ahnung, was Pin 4 macht. Vielleicht wird er ja high, wenn es einen GPS-fix gibt? Nächste Frage. Nun gibt es auch auf Pin 6 und 7 ein Signal. Pin 6 ist augenscheinlich der Rx vom Application Processor, also Tx vom GNSS. Der bisschen breitere Block an Pin 5 ist das Hochladen der Almanach-Daten. Die sporadischen Stüpfel an Pin 6 die Bestätigung davon. An Pin 7 liegen konstant 1,86 V an. Sieht entweder nach dem Ausgang eines Spannungsreglers oder doch einem anderen Signal aus. Bis jetzt konnte ich dort nichts beobachten.

Was die Spannung an Pin 8 macht ist mir ehrlich gesagt auch nicht klar. Sie springt auf 1,6 V hoch um kurzzeitig wieder auf die ohne Modul beobachteten 2,41 V zu schalten, wieder runterzugehen und dann doch wieder kurz auf 1,6 V zu springen. Die kurze „high-Phase“ fällt mit den ersten zwei gesendeten Blöcke zusammen. Diese waren das „Hello world“ des Chipsatzes (siehe vorletzter Blogpost). Vielleicht gehört das zur Initialisierung. Wenn man bedenkt, dass hier mutmaßlich der Spannungsregler stärker belastet wird und dadurch einbricht: tolle Initialisierung.

Um vielleicht doch noch herauszufinden, wofür Pin 4 und 7 sind habe ich im Menü Geotagging ein- und ausgeschaltet – ohne Auswirkung auf auf die Signale.

Nachdem die Kamera nun seit 1 Milliarde Samples bei 1 MHz, also etwas mehr als 16 Minuten, keine Regung beim GNSS-Icon zeigte, muss ich leider davon ausgehen, dass entweder der Empfänger oder die Kamera einen Schuss weg hat. Das Mistding versucht anscheinend noch nicht einmal, Satelliten zu suchen.

Aus den Traces habe ich die UART-Daten extrahiert und einem NMEA-Parser zum Fraß vorgeworfen. Mehr als leere RMC- und GGA-Botschaften kam nicht heraus. Hmpf – da ist wohl wirklich nix zu reißen – und nun auch nichts mehr zu verlieren. Mit meiner Lieblingslötspitze (der Hohlkehle) geht es an das Shielding.

Nanu, da ist ein Bauteil nicht ganz so, wie es sein sollte:

Etwas mit der Pinzette gezupft und das andere Pad vom Kondensator war abgehoben. Bzw. blieb eher auf der Leiterkarte hängen. Ich bin mir sehr sicher, dass das nicht ich war. Beweisen kann ich es aber nicht. Wieder notdürftig angelötet tut sich… …nichts.

Das Oszi spricht: beide Quarze schwingen. der oben im Bild mit 32 kHz, der unten mit ca. 16,4 MHz. Klingt plausibel.

Jetzt ist auch sicher, welcher Chip verbaut ist – ein MTK3339AV. Google spuckt zwar kein Datenblatt aus, aber das Teil wird mit ähnlicher Antenne flächendeckend verkauft. Adafruit hat ein Datenblatt zu einem Modul mit diesem Chipsatz.

Der Versuch, das Teil zum Laufen zu bekommen wäre damit (vorerst) beendet, leider.

Drei verschwendete Abende? Nein. es war auf jeden Fall interessant, das Modul zu erforschen, auch wenn es sich schlussendlich als Kaputtnik herausgestellt hat.

Strg+Z

Veröffentlicht am 26. Juni 2016 von Chris

Argh! Am liebsten würde ich jetzt so lange auf Strg+Z hämmern, bis ich die Kamera nicht zerlegt habe. In wieder mal jugendlichem Leichtsinn habe ich den Bildsensor vom Objektiv getrennt und den Reflektor vom Display gerissen. Mann, bin ich dumm!

Denn: Die Kamera lebt! Einzig der fehlende Blitz wird beim Einschalten bemängelt.

Es wäre die perfekte Opferkamera geworden, für nichtmal nen Zehner. Könnt ihr euch vorstellen, wie ich mir gerade in den Allerwertesten beiße? Keine Ahnung, warum das Teil vorher nicht komplett einschaltete (Doch, die 6. Stelle der SNR ist eine 4). Irgendein Dösbaddel hat die Flex zur Hintergrundbeleuchtung abgerissen – und ich möchte nicht ausschließen, dass ich dieser welcher war. *seufz*

Naja, zumindest kann man versuchen, das Beste aus der Situation zu machen – zum Beispiel den GNSS-Empfänger weiter erforschen. Es wäre interessant, ob, wann und wie die Almanach-Daten in den Empfänger kommen. Erster Versuch: Einfach mal die alte EED-Datei drauf und gucken was auf dem UART passiert. Kurz: Nix. Ok, vielleicht lädt die Kamera clevererweise nur die Daten, wenn sie auch gültig sind. Also einfach mal das Datum auf irgendwann 2014 (im gültigen Bereich) gesetzt und neu gestartet.

Here we go:

Eine halbe Sekunde Upload. Bei einer Byte-Länge (mit Pause) von ca. 95 µs sind das ca. 7 KiB. Also wohl ein Auszug aus der Datei. Näher hab ich es mir noch nicht angeschaut.

Ok, nun ein völlig abstruses Experiment. Versuchen wir doch mal eine aktuelle EED-Datei, heute frisch vom Canon-Server geladen. SD-Karte rein, Datum umgestellt, Neustart. Der Logic Analyzer zeichnet wieder einen Transfer auf und die Kamera zeigt im A-GPS-Screen den Gültigkeitszeitraum richtig an. WTF!?

Canon, ich glaube, wir haben ein Problem! Ein persönliches sogar!

Als „Beweis“ habe ich ein Video gemacht. Die SD-Karte enthält bis auf die Bilder nichts, was GPS-Infos tragen würde. Meine richtige Kamera lädt keine Daten mehr. Sie ist in dieser Hinsicht also kaputt. Keine Ahnung warum, weil abgesehen von diesem Fehler funktioniert Geotagging ohne Probleme.

Jetzt wäre natürlich der Gedankengang nahe, eine Transplantation durchzuführen: Engine aus der Bastelkamera in die „Produktivkamera“. Nein. Nicht, weil ich fürchte, dass die Kamera dann im Einsatz nicht mehr so stabil läuft – ich vermute eher, dass der Flash neben dem Killflag für A-GPS auch Kalibrierdaten für den Autofokus (obwohl es der dumme mit Kontrastgrenze ist), Bildstabilisierung und ähnliche Korrekturdaten (Tote Pixel) der Kamera enthält. Es wäre ziemlich großer Mist, diese zu „verlieren“.

Jetzt muss Canon ran! Garantie ist vorbei, aber das ist ganz offensichtlich ein Fehler, für den ich nichts kann. Ich hätte gerne eine Erklärung!

Und es wäre nicht das erste Mal, dass sich eine PowerShot ohne meine Hilfe verabschiedet. Bei meiner A95 haben sich die Bond-Drähte vom Sensor gelöst und die A2100 bekam Alzheimer und wusste nicht mehr, wie sie hieß. Beide hat Canon auch nach der Garantie- bzw. Gewährleistungszeit kostenlos repariert, nervig ist es aber trotzdem. Die 300D von meinem Vater habe ich selbst wieder in Gang gesetzt. Mit einem Reißnagel. Vier von 6 Kameras sind somit im Eimer, wobei ich die 400D wegen Unzulänglichkeiten in der Software bzw. einem Objektivfehler auch nicht mehr wirklich nutze. Bleibt also nur die aktuell (noch) intakte 600D von meinem Paps. Vielleicht sollte ich doch mal über einen Systemwechsel nachdenken. Schade, denn ich mochte sie eigentlich ganz gern. Bis auf die Akkulaufzeit bei der SX280 im Videomodus und den nicht sauberen 60 fps-Aufnahmen…

The strangest deal

Veröffentlicht am 26. Juni 2016 von Chris

Gestern war es mal wieder so weit. Friedrichshafen ruft!

Dieses Jahr war die HAM Radio gefühlt wieder besser besucht, obwohl das Wetter nicht ganz so stabil war wie die Jahre zuvor.

An ein paar Ständen gab es wie auch die Jahre zuvor kaputte Digiknipsen. Darunter auch „meine“ Canon SX280. 15 Euro für eine kaputte Kamera? Ein Argument zum Handeln gab es: der Blitz fehlte. Also den Händler anquatschen und 10 Euro geboten. „Aber da fehlt der Blitz!“ – „ok, dann 8 Euro“. Gut, wenn er meint, dann bekommt er halt nochmal 2 Euro weniger als ich ihm eigentlich geben wollte.

Warum ich sie wollte? ~~Zum einen bietet Canon keine Almanachdaten mehr an, zumindest keine aktuellen mehr.~~ Wenn ich weiß, welcher Chipsatz verbaut ist, lässt sich vielleicht eher etwas finden. Zudem hat das Objektiv zwar eine Delle, scheint ansonsten aber noch intakt zu sein. Immerhin hat es Kleinbild-Äquivalent verrückte 28-500 mm Brennweite. Die Blende ist dann zwar ziemlich zu und die Abbildung nicht mehr ganz so perfekt, aber für den angepeilten Verwendungszweck an der Raspberry Pi-Cam, who cares? Ich hatte schon ein Canon EF-Objektiv am Pi. aus 200 mm Brennweite werden knapp 3000 mm KB-Äquivalent. Den Mond muss man damit ziemlich feinfühlig ansteuern und trotzdem haut er recht schnell ab. Leider ist das Objektiv bei offener Blende nicht ganz so knackig, zum Schließen selbiger braucht’s allerdings zusätzliche Hard- und Software…

Aber ich schweife ab. Don’t turn it on, take it apart? Naja, vorher möchte ich zumindest sehen, was die Kamera noch macht, schließlich habe ich alle Betriebsmittel daheim. Resultat: Der Bildschirm bleibt dunkel, das Objektiv fährt nur kurz aus, dann ist wieder Stille. Aber immerhin tut sich etwas.

Also, auf den Apparat! Alle Schrauben gelöst, braucht man nur noch sanfte Gewalt um die Gehäusehälften voneinander zu trennen. Die Innereien sind erstaunlich aufgeräumt – GPS und WLAN sind erwartungsgemäß Module, wodurch der kleine Schwester SX270 einfach die beiden Platinchen mit Funk fehlen.

Funkmodule der Canon SX280, links: WLAN, rechts: GPS

Auf dem WLAN-Modul ist WYSBCVCXA eingraviert. Eine kurze Suche ergibt: Es ist ein Modul von Taiyo Yuden – nicht die ganze Leiterkarte sondern nur das kleine Teil mit Blechdeckel. Alles außenrum stammt augenscheinlich von Canon, zumindest deutet der Aufkleber auf der Rückseite darauf hin. Im inneren werkelt ein Marvell 88W8787, der mit dem Prozessor über SDIO kommuniziert. Bluetooth und 2,4G-WLAN kann grundsätzlich über die die gleiche Antenne arbeiten, auch scheint das Modul die entsprechenden Bauteile für den Betrieb zu besitzen. Müsste ich nur noch die Anschlussbelegung herausfinden, dann wäre das tatsächlich etwas für den Raspberry Pi. Noch ein kurzer Ausflug: Warum macht man ein Modul auf ein Modul und nicht zumindest den Funkchip direkt auf das eigene Modul? Ganz einfach, und manche kennen es vielleicht schon von den ESP8266-Modulen: Zertifizierung. So muss nur das eigentliche Funkmodul durch die vollständige Zerti. Die Antenne und das andere Außenrum muss man zwar trotzdem noch checken, aber das geht bedeutend schneller und günstiger.

Beim GPS-Modul (oder korrekter: GNSS) sieht es leider nicht ganz so gut aus. Auf dem Shielding steht zwar, dass es ein GYCFDMAXX von Canon sei aber bis auf Typenzulassungen findet man nichts im Netz, die Daten auf der Oberseite kommen rein aus der Produktion und das Shielding herunternehmen gefährdet die Elektronik darunter. Nebenbei: wen die Kerben an der Patchantenne irritieren – das war nicht ich mit dem abgerutschten Schraubendreher – das muss so! So werden die Antennchen bei der Produktion getrimmt.

Also keinerlei Infos. Ublox, Broadcomm, Sirf, SkyTraq, Qualcomm, Mediatek oder noch was exotischeres? Keine Ahnung. Da ist mehr Detektivarbeit vonnöten. Im Foto oben sieht man noch leicht die Flex vom Modul – die zwei linken Leiterbahnen sind etwas dicker – das MUSS die Stromversorgung sein. Ich definiere links einfach mal zu Pin 1. Nachdem Pin 2 auf die große Fläche geht, müsste das die Masse sein. Pin 1 ist also die Versorgung. Beim Rest bleibt die Ahnungslosigkeit. Klassischerweise sprechen GNSS-Chips UART oder I²C. Manche auch USB, was aber eher für PC-Empfänger und R&D-Zwecke verwendet wird. Jedes Interface benötigt aber lediglich zwei Leitungen, das Modul ist allerdings mit 8 angebunden. Bei UART kann noch RTS und CTS dazukommen. Was ich mir noch vorstellen könnte wären ein Enable, Interrupt, 32 kHz-Takt oder ein 1-Pulse-per-Second-Signal.

Es hilft nix, da muss ein Messgerät ran – Ich hab da mal was vorbereitet:

Hab ich erwähnt, wie aufgeräumt das Design in der Kamera ist? Zu meinem weiteren Erstaunen ist die kleinste Bauteilgröße 0402. Ich hätte erwartet, dass Canon im Jahr 2013 schon alles mit 0201 zupflastert. Schön für Bastler, da ist das Umbauen deutlich angenehmer.

Folgende Bauteile sitzen auf der Leiterkarte:

Elpida B2064B3PB-8D-F – RAM
Macronix MX29GL256FHX01 – Flashspeicher (kein eMMC)
Analog Devices ADV7528 – HDMI-Transmitter
Renesas (?) R2A30447 – Motortreiber (?)
4957 323A – ???

Vom eigentlichen Prozessor sieht man nichts. Er ist unter dem RAM versteckt – Stichwort Package-on-Package. Zum R2A30447 konnte ich nichts eindeutiges finden, aber Bauteile mit ähnlichen Bezeichnungen sind alles Motortreiber. Zudem deuten die dickeren Widerstände, größere Kupferflächen (um die Wärme wegzubekommen) und die Nähe zum Objektivkonnektor sehr explizit darauf hin. Neben dem Motor für das Objektiv und den Blitz könnte der Chip auch die Aktuatoren für Blende und Voicecoils für den Autofokus und Bildstabilisator ansteuern. Was der Chip mit der Gravur 4957 323A macht, konnte ich nicht herausfinden. Ich vermute, dass es ein IMU, also Accelerometer und Gyroskop ist. Accelerometer, um die Orientierung der Kamera (zum automatischen Drehen der Bilder, was Canon noch immer nicht „richtig“ in den Exif-Daten ablegt) und als Komponente für den Bildstabilisator verwendet. Was noch auffällt: Links unten im Bild befindet sich ein Footprint für einen unbestückten Konnektor. Hmmmm, könnte das vielleicht der Debug sein? 🙂

Zurück zum GNSS – Solderporn gefällig?

Eigentlich gar nicht so spekakulär – wie gesagt: die Widerstände sind im 0402-Package. Pin 1, die mutmaßliche Versorgung ist hier rechts. Im letzten Bild sieht man: an ihm hängt auch das Oszi. Pin 4 konnte ich nicht richtig anlöten, weil es anscheinend auf keinen Widerstand unten führt. Vielleicht der in der zweiten Reihe? keine Ahnung. auf jeden Fall kommt jeder Pin an den Logicanalyzer.

Sobald die Kamera Strom bekommt regt sich auch etwas:

Kanal 4 und 5 sieht sehr interessant aus und der Screenshot oben ist schon verräterischer als ich beabsichtigte:

We got signal! UART 115200 Baud, 8N1. Die Signale auf Kanal 5 sind offensichtlich Glitches durch Nebensprechen.

Der GNSS-Receiver meldet:

$PMTK011 MTKGPS*08\r\n$PMTK010 001*2E\r\n

…

$PMTK010 002*2D\r\n

Wir haben es mit sehr großer Wahrscheinlichkeit mit MediaTek zu tun, der NMEA 0183 spricht. So weit, so gut.

Auf der Suche nach Mediatek und Almanac bin ich auf eine Seite von Gizmochina gestoßen. Darauf ein Link auf http://ftp.epo.mediatek.com. Allerdings ist der Server offline. Aber zumindest gibt es eine Fährte. Auf der Suche nach Mediatek und epo fand ich die Sourcen eines Updaters für Android. Man muss etwas wühlen, aber schlussendlich läuft es auf folgende Ressource hinaus: http://epodownload.mediatek.com/EPO.DAT. Datei heruntergeladen, und neben die aktuelle CAGM01.EED der Kamera gelegt (Die Datei befindet sich auf der Speicherkarte im Ordner \DCIM\CANONMSC\GPS\) – zumindest die Dateigröße ist gleich. BeyondCompare sagt: Inhalt ebenfalls identisch. Ich habe ein Bingo!

Ok, im Nachhinein hätte ich das auch einfacher haben können. Denn, meine Fritzbox kann Netzwerkverkehr mitschneiden. Der Vollständigkeit halber habe ich das nun auch nachgeholt.

Kurz und knapp baut die Kamera auch eine Verbindung und sendet folgenden Header:

GET /rmds/ic/agps/cagm01.eed HTTP/1.1

HOST: gdlp01.c-wss.com:80

CONNECTION: close

Funktioniert auch im Browser. Als Antwort kommt, wie erwartet, die Datei von oben. Nur zeigt die Kamera noch immer „Gültigk.zeitr. d. A-GPS-Dat.: –.–‚– – –.–.‘–“ an. (warum eigentlich so stark abgekürzt, da wäre noch elendig viel Platz auf dem Bildschirm…)

Vielleicht funktioniert auch nur die Anzeige des Gültigkeitszeitraum nicht?! Naja, zumindest der TTFF liegt irgendwo bei 2 Minuten – ich bin mir also nicht sicher.

In den Untiefen meiner Festplatte konnte ich ältere Versionen der Datei finden. Mit richtiger Dateizeit. Hmmm – was macht wohl die Kamera damit? Also eine von 2014 kopiert, die Karte in die Kamera gelegt und siehe da: ich habe für den damaligen Zeitraum A-GPS-Support. Was passiert nun, wenn ich aktualisiere? Die Kamera behauptet was zu laden, nach dem Update steht aber der alte Zeitraum auf dem Display. Zurück am PC: Ja, die Datei wurde nicht überschrieben.

Bleibt eine Frage: Warum? Drei Ideen hätte ich:

Canon hat nur eine zeitlich begrenzte Lizenz von Mediatek oder deren Zulieferern für die Daten (Die Datei wird für andere Produkte auf dem Server aktualisiert oder wurde schlichtweg vergessen)
Jemand in der Software-Entwicklung hat es verkackt
Canon will, dass eine neue Kamera mit integriertem GPS-Empfänger (die es nicht gibt) gekauft wird

Für den zweiten Fall könnte man sich vertrauensvoll an den Support wenden. So motiviert wie ich sämtliche Consumer-Produkte-Hersteller mittlerweile kennengelernt habe, wird ein Standardschreiben zurückkommen: „Wir haben das Problem weitergeleitet. Ob und wann eine Fehlerkorrektur zur Verfügung steht, können wir zum aktuellen Zeitpunkt allerdings nicht sagen“. Wenn die Person, die diesen Textbaustein geschrieben hat, je Verwendung einen Cent bekommen hätte – sie oder er wären reich. Sehr sogar. 🙁

Und nun: sorry für die Länglichkeit. Wer hat es bis hier geschafft? Schreibt einfach einen kurzen Kommentar!

Darf ich mal kurz…

Veröffentlicht am 6. Juni 2016 von Chris

…mich hier über die Praktiken mancher Hersteller aufregen?

Nachdem ich demnächst auf einer Hochzeit fotografieren soll, die diesjährige Urlaubsplanung größtenteils steht und ich bei der Musik von CloZee ziemliche Lust bekomme, ein Video zumindest von letzterem zu machen, liebäugel ich mit einer neuen Spiegelreflex.

Für Canon ist zumindest ein gutes Objektiv noch da (allerdings nicht ganz reisetauglich) und die 760D erfüllt, obwohl sie der Billigmöller unter den EOSen ist, meine Erwartungen nahezu komplett. Leider keine 60 fps-Videos und nix über 1080p. Wer schon einmal mit höherer Framerate aufgezeichnet hat, will es nicht mehr missen. Flüssigere Bewegungen sind das eine, der deutlich größere Vorteil ist allerdings, mit der Wiedergabegeschwindigkeit (ohne größere Artefakte) arbeiten zu können.

Auf der Suche nach einem Zweitakku, der mir im Original mit um die 50 Euro zu teuer ist (wenn man weiß, wie billig der Krempel in der Produktion ist, wird einem nachhaltig schlecht), wurde die Suche auf Drittanbieter ausgedehnt. 15 Euro. Teilcodiert? Keine Restlaufanzeige? Fehlermeldung in der Kamera? Lässt sich nicht im Originalladegerät laden?

Die Begeisterungskurve machte einen deutlichen Knick nach unten. Stimmt, das habe bei einem der aktuelleren G-Modelle auch schon gelesen.

„Früher“ gab es halt keine Garantie mehr, wenn ein Fremdakku die Kamera beschädigte.

Heute braucht man wie bei Tintenpatronen Dongel, weil sich die Hersteller mit dem zwangsläufig benötigten Zubehör subventioniert oder einfach nur den Gewinn maximieren will. Es gibt keine technische Gründe, einen Kryptographie-Chip in eine nicht sicherheitsrelevante oder anderweitige kritische Komponente einzusetzen. Zumal der Mist früher oder später eh überwunden wird. Ok, bis dahin hat der Originalhersteller Strecke gemacht, danach ist es nur noch Gängelung.

Der Vergleich hinkt zwar etwas, aber bei DVDs gibt/gab (gab, weil sie langsam aber sicher von der Blu-ray beerdigt wird – die sind in der Beziehung IMO ein bisschen besser) es auch eine für mich völlig unverständliche Gängelung: wie lange dauert es üblicherweise vom Einlegen der Disc bis man den Film starten kann? Zwar nicht so lange wie im Kino, aber bei den meisten läuft erst nichtüberspringbare Werbung. Bei einer Scheibe, die man früher für über 20 Euro gekauft hat. Besorgte man sich den Film auf andere Wege, war man sofort im Menü oder der Film lief direkt los (so die Erzählungen). Der ehrliche Verkäufer ist also der Dumme. Wegen damals noch schwacher Abmahnindustrie hat der Raubkopierer (bis auf dem moralischen Aspekt) doppelt „gewonnen“.

Was hilft bei den Kameraakkus? Boykott? Hateletter? Oder einfach mit dem wegklicken von „Fehler-„Meldungen leben und warten bis entweder die Zubehörindustrie die Crypto geknackt hat oder es einen Hack für die Kamera gibt (in Zeiten von Green Lantern und CHDK nicht unwahrscheinlich)?

Ich weiß noch nicht. Vielleicht bleibe ich beim Urlaub auch einfach bei der Point and Shoot. Die hat zwar ihre Schwächen, kann aber direkt geotaggen (warum das die Nachfolger auch nicht mehr können ist mir ebenfalls ein Rätsel) und hat einen etwas größeren immer-dabei-Faktor.

Flashen für faule

Veröffentlicht am 13. Mai 2016 von Chris

Und gleich noch einer hinterher:

Hintergrund für das gerade eben gebloggte visacon ist meine akute Faulheit. Weil am aktuellen Mikrocontroller-Projekt die Pins vom ISP anderweitig verwendet werden sollen, musste ein Bootloader auf den AVR. Die Wahl fiel auf Peter Danneggers FastBoot, den ich mit einem anderen Initstring kompiliert habe. Zunächst wollte die 64-Bit-Version von fboot.exe nicht damit sprechen. Für AVRDUDE gibt es zwar einen Patch, der hat es in fast 5 Jahren aber nicht in in die offizielle Version geschafft. Ich habe es versucht, mit Cygwin und MinGW, aber ich bin offenbar zu blöd, diese Software zu kompilieren.

Also habe ich UpdateLoader von Luani verwendet. Das hat eine ansprechende GUI und funktioniert auch prächtig mit meinem abweichenden Passwort, nur hat das Teil einen Nachteil: Es nimmt als Argument nur eine HEX- oder INI-Datei an. Keine wirkliche Scriptingfähigkeit. Ok, Sourcen sind vorhanden, aber ehrlich gesagt wenig Zeit und Lust, mich in Pascal und dessen Entwicklungswerkzeuge einzuarbeiten.

Bleibt die Frage: was macht UpdateLoader anders als fboot? Der Logic Analyzer liefert Erkenntnisse: Leo-Andres war so clever und stellt dem Passwort das Steuerzeichen \r voran. In der Protokoll-Beschreibung vom Bootloader steht auch, dass für die Bestimmung der Baudrate ein high-bit und vier low-bits erwartet werden. im Standardpasswort „Peda“ macht das das „a“ (binär 01100001). Was passiert nun, wenn ich meinem Passwort ein „a“ voranstelle – also nur bei der Verwendung von fboot.exe?

>fboot /C7 /B115200 /IaXYZ /P"program.hex"
COM7 at 115200 Baud: Connected
Bootloader V2.1
Target: 1E9403 fbDEF
Buffer: 512 Byte
Size available: 15872 Byte
Program program.hex: 00000 - 00533 successful
CRC: o.k.
Elapsed time: 0.64 seconds

läuft.

Nur muss ich jedes Mal PuTTy beenden, das Netzteil ausschalten, fboot anwerfen, Netzteil einschalten, PuTTy wieder starten. Muss ich? Nein.

PuTTy kann Profile – und man kann ihm sagen, einen bestimmten Fenstertitel zu verwenden:

Das ganze als Profil abgespeichert, schon kann man das Programm nach seinen Wünschen per Kommandozeile lostreten:

start putty.exe -load "meinprofil"

Warum das alles? Natürlich um PuTTy ganz einfach beenden zu können:

taskkill /fi "IMAGENAME eq putty.exe" /fi "WindowTitle eq meintitel" /f

Okay, dass man fürs Starten und Beenden ggf. unterschiedliche Bezeichnungen braucht, ist nicht so edel, genauso könnte die Gegenstelle den Fenstertitel verändern. Aber es funktioniert. Debug-Anzeige geht auf und das Flashen kann gestartet werden. Nur muss für das Flashen ein Reset vom Mikrocontroller ausgeführt werden. UpdateLoader kann dazu die DTR-Leitung toggeln, fboot nicht. Aber wofür habe ich mein neuestes Tool geschrieben, wenn nicht für das?

Das Rigol-Netzteil kann außer laut sein auch über den PC gesteuert werden:

visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1; OUTP OFF"

Der Befehl wählt Kanal 1 aus und schaltet ihn sogleich ab. Mit ON statt OFF passiert (oh Wunder) genau das Gegenteil.

es gibt nun also eine kleine BAT-Datei auf meinem Rechner:

taskkill /fi "IMAGENAME eq putty.exe" /fi "WindowTitle eq meintitel" /f
visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1; OUTP OFF"
timeout 1
visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1" W "OUTP ON"
fboot /C7 /B115200 /IaXYZ /P"program.hex"
start putty.exe -load "meinprofil"

Der Timeout-Befehl gibt dem Elko auf der Leiterkarte Zeit sich zu entladen. Bis jetzt funktioniert das Ganze wie ’ne Eins.

Jetzt sollte nur noch Atmel Studio nach dem erfolgreichen Build… Moment:

Warum es dafür keinen Wiki-Artikel gibt? Steht doch oben, weil ich faul bin.

visacon

Veröffentlicht am 13. Mai 2016 von Chris

Messautomatisierung ist etwas tolles und – wenn man sich damit einmal grundlegend beschäftigt hat – vor allem sehr einfach. Nur leider braucht man in den meisten Fällen irgendeine Entwicklungsumgebung, um mit über VISA mit den Instrumenten zu sprechen. Es gibt zwar noch NI MAX oder Hewlentsight IO Libraries Suite, mit letzterem kann man zwar auch automatisieren aber für manche Anwendungen ist es einfach etwas unpraktisch.

Für manche Anwendungen würde eine einfache Batchfile absolut ausreichen, nur daraus VISA sprechen? Ich habe zumindest kein Programm gefunden. Mit VBS/JScript bzw. dem, was der Windows Scripting Host hergibt, geht es wohl auch nicht so einfach.

Man darf sich nicht über Dinge beschweren, die man selbst machen könnte. Also habe ich ein kleines Kommandozeilen-Programm geschrieben: visacon.

Es verwendet das, was National Instruments mit dem Bollwerk an Treibern mitbringt – die beiden Assemblies NationalInstruments.Common und NationalInstruments.VisaNS. An dieser Stelle sei noch darauf hingewiesen, dass ich nicht der Urheber dieser DLLs bin und auch keinerlei Rechte daran besitze. Der Compiler hat sie einfach gelinkt und im Release-Verzeichnis abgelegt.

Das Programm ist einfach gestrickt – es versucht die angegebene Ressource zu öffnen und führt dann Write- und Query-Befehle aus – die Syntax ist wie folgt:

visacon.exe <resourcename> ((W|R) „<cmd>“)+

Wer der Regulären Ausdrücke nicht mächtig ist: als ersten Parameter muss man den Resourcennamen (natürlich ohne spitze Klammern) angeben, danach W für einen Write-Befehl oder Q für einen Query-Befehl. Im Anschluss daran den jeweilig auszuführenden SCPI-Befehl. Die letzten beiden Argumente kann man beliebig oft wiederholen. Alle Ergebnisse der Queries werden in der Konsole ausgegeben. Tritt ein Fehler auf, wird die zugehörige Exception ausgespuckt.

Benötigt werden funktionierende VISA-Treiber, .NET 4.0 und die Kommandozeile.

Viel Spaß damit!

Aus Fehlern (nichts) lernen

Veröffentlicht am 5. Mai 2016 von Chris

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:

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

Veröffentlicht am 28. April 2016 von Chris

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.

hobbyelektronik.org blog

…schon wieder so ein dämlicher Blog

Archiv der Kategorie: Elektronik