MCP2221 mit C# – aber schnell.

Nachdem die Python-Lib ganz gut funktioniert (ein paar Bugs habe ich bereits gefunden, Fixes stehen noch aus), wollte ich die Implementierung auch in C# umsetzen. Zwar gibt es von Microchip schon eine Lib, allerdings ist diese nicht Native und auch nicht open source und dadurch auf bestimmte .NET-Versionen eingeschränkt.

Um das Rad nicht neu erfinden zu müssen, wollte ich zumindest für die USB-HID-Kommunikation eine fertige Bibliothek verwenden. Bei der Suche bin ich auf HidLibrary gestoßen, die zwar nicht mehr so aktiv gepflegt wird – aber das muss nicht unbedingt viel bedeuten. Ja, auch Software kann mal fertig sein 😉

Heruntergeladen und die ersten Funktionsblöcke geschrieben. Als ersten Test habe ich i2c_detect portiert und laufen lassen. Für 127 Adressen dauert der Scan knapp über 17 Sekunden. Mit Microships MCP2221 I2C/SMBus Terminal sind es nicht ganz 11 Sekunden und mit meiner Python-Lib unter 0,7 Sekunden. Was ist da los?

Im ersten Schritt habe ich mit System.Diagnostics.Stopwatch die Schreib und Lesezeiten gemessen – jeweils braucht die Lib im Schnitt 21 ms, für jeden Probe einer Adresse sind zwei Schreib-/Lesezyklen erforderlich, kommt kein ACK für eine Adresse ist ein weiterer Zyklus für ein i2c_cancel erforderlich. Macht für einen Proben einer nicht genutzten Adresse ca. 126 ms, für 127 Adressen sind das bisschen über 16 Sekunden – kommt also hin.

Visual Studio kann Performance-Analysen und der schuldige ist schnell gefunden:

Es hängt also am HidLibrary.HidDevice::IsConnected bzw. EnumerateDevices.

Auf GitHub gibt es (Stand November 2018) auch Bugs zum Thema Performance.

Die Tickets existieren seit 2011, 2014 und 2016 – also besteht offenbar kein Interesse, das zu fixen. Ein User namens kaczart hat eine Lösung gefunden.

Um im ersten Schritt nicht zu viel zu verbasteln, habe ich einfach mal „IsConnected“ ein einstweiliges „return true;“ verpasst. Nun benötigt ein Schreibvorgang um die 3,4 ms und ein Lesevorgang knapp 2,3 ms. Unterm Strich dauert der Scan nun 2,5 Sekunden. Besser aber noch nicht gut genug.

In anderen „Projekten“ hat mir in Sachen Timing gerne mal der Debugger in die Suppe gespuckt, also mal als Release ausgeführt und Tadaa: 0,78 Sekunden. Fast so schnell wie die Python-Implementierung.

Um es nochmal genau zu wissen habe das „return true;“ aus HidDevice::IsConnected wieder entfernt und als Release ausgeführt: 14 Sekunden.

Der Hund liegt also definitiv in der Lib begraben. Workaround, Fixen, nach Alternativen suchen oder selber machen (oder einfach eine Weile abhängen lassen und etwas anderes machen)?

Mal sehen.

Was der MCP2221 sonst noch kann

Es gibt Dinge, die Zeit verschwenden, nicht richtig funktionieren und schlussendlich nicht einmal einen Sinn ergeben. Manche nennen das sogar Hobby.

Nachdem mir im Zuge der MCP-USB-Bridges keine Python-Implementierung so richtig gefallen habe, bin ich gerade dabei, selbst eine zu schreiben und mehr oder weniger ausgiebig zu testen.

GPIOs, ADC funktionieren so wie es aussieht genz gut, heute war der DAC dran.
So richtig toll ist er nicht, aber besser als nichts. Um Seine Leidensfähigkeit zu zeigen, musste ein kleines Beispiel her.

Warum nicht einfach so etwas ähnliches wie einen Hellschreiber implementieren? Nur halt extrem ranzig.

In Python geht das ordentlich schnell und einfach:

txt = "Hallo Welt!"

vals = [22,20,18,16,14,12,10,8]

meh = []
for c in txt:
    meh.extend(font[ord(c)-32])
    meh += [0]

for col in meh:
    for reps in range(4):
        curcol = col
        for y in range(8):
            if curcol & 1 == 1:
                dev.dac_setvalue(vals[y])
            else:
                dev.dac_setvalue(0)
            curcol >>= 1
            time.sleep(0.003)

Die Font liegt in als Liste vor, die alle wichtigen Zeichen ab dem Leerzeichen enthält. Vals beinhaltet die Analogwerte der jeweiligen Bits der Zeichen (in der Höhe). Der Text wird sprichwörtlich in eine Bitmap umgewandelt und einfach über den DAC rausgejagt. Damit die Zeichen etwas besser lesbar sind, werden sie 4 mal wiederholt. Die kurze Pause ist nötig, weil sich sonst der MCP verhaspelt.


Ist das nun Kunst oder kann das weg? 😉

Es geht weiter

Zugegebenermaßen: es passiert hier so wenig, dass man in Hinblick auf den vorletzten Post schon fast von falschen Versprechen ausgehen könnte. Aber: Es passiert nicht nichts, es geht einfach nur verdammt langsam voran. (warum muss ich nur an das Zitat „es ist nicht undicht, es läuft über“ denken…?)

Um zu zeigen, dass es nicht ganz Schall und Rauch ist:

Aber das ist nicht alles. Bis wann die Software und der zugehörige Artikel fertig ist, kann ich noch nicht versprechen. Ein paar Wochen halte ich für realistisch 🙂

Das „Custom Programming Tool“ in Atmel Studio

Schon länger gibt es in Atmel Studio die Möglichkeit, ein eigenes Programming tool zu verwenden:

Hat mich bis jetzt nie wirklich interessiert, da ich entweder über einen in-circuit-Programmer (der direkt unterstützt wird) flashe oder FastBoot manuell startete.

Zu viele Klicks bzw. Tastaturakrobatik. Also doch mal mit dem bereits Vorhandenem spielen.

echo „foo“ macht was es soll:

Prima, also kann ich einfach die burn.bat im Projektverzeichnis einfügen und los geht’s!

Nope. Da passt wohl das Arbeitsverzeichnis nicht. Aber wie kommt man ins aktuelle Projektverzeichnis? Zunächst versuchte ich mich an den Platzhalter der „External Tools“. Allerdings wurde „$(ProjectDir)“ zu leer ersetzt.

Hmpf. Für die Buildautomatisierung gibt es noch die Build Events – klickt man dort auf „Edit #-build …“ und dann auf Show Macros, bekommt man eine längere Liste an Platzhaltern:

echo „$(MSBuildProjectDirectory)“ zeigt das aktuelle Projektverzeichnis 🙂

also schnell „$(MSBuildProjectDirectory)\burn.bat“ eingegeben und ab dafür!

Jaa-eein. Die Batch-Datei wird zwar ausgeführt, aber im falschen Arbeitsverzeichnis. Mist.

Eine kurze Suche bei Stack Overflow lässt in das richtige Verzeichnis wechseln:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat

It verks!!1!

Jetzt steht in der dämlichen Batchdatei halt noch der feste Pfad zum Binary und es wird immer die Debug-Config über den UART geschoben. Ein bisschen mehr Makro-Magic und ein %1 an der richtigen Stelle (die zu flashende Datei) mit folgendem Command erledigt den Job:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat „$(Configuration)\$(OutputFileName).hex“

Da in der burn.bat in meinem Fall eh nicht mehr als ein Aufruf von fboot.exe ist, kann die Batch-Datei auch komplett weggelassen werden:

cmd /k pushd $(MSBuildProjectDirectory) & fboot /B57600 /C1 /P“$(Configuration)\$(OutputFileName).hex“

Jetzt müsste man nur noch die Ausgabe des Build und des Custom programming tool gleichzeitig anzeigen können, dann wäre ich richtig happy 😉

PS: Bitte beim Copy & Paste der Befehle die Anführungszeichen manuell ersetzen, WordPress macht sie typografisch korrekt aber funktional kaputt.

Es bewegt sich was

Aber leider etwas langsam.

Ich hab aktuell ein paar Baustellen offen. Zum einen bin ich daran, ein Reverse Engineering an einem Autoradio durchzuführen, um Fehler – die der Hersteller tunlichst nicht fixen will – zu beseitigen. So gut wie alle relevanten Teile des Schaltplans sind rekonstruiert, dabei wurden sogar noch ein paar Designfehler entdeckt.

Leider blockt mich gerade ein wenig die Tatsache, dass die meisten Datenblätter unter NDA liegen und die I2C-Kommunikation zwischen Application Processor und Audioprozessor nicht ganz trivial ist.

Baustelle 2 ist beim Prozeda-Decoder. Nachdem die Anfrage reinkam, ob das auch mit einem Raspberry Pi funktioniert, dachte ich mir: Warum auch nicht? Mit echter Hardware auf dem Tisch, die mir freundlicherweise von einem Besucher bereitgestellt wurde, konnte ich mir ein paar Dinge nochmal genauer ansehen. Es gab auf jeden Fall einen Erkenntnisgewinn, jetzt muss ich es „nur noch“ dokumentieren.

Für den Minichirp gibt es hoffentlich auch bald ein Update, nachdem die ersten Versuche an der Hard- und Software vielversprechend sind. Nur so viel: der aktuelle Projektname lauter „ChirpRF“.

Als ob das nicht schon genug wäre, möchte ich jetzt endlich diese verdammte Wetterstation angehen, nachdem es im Sommer an den nRF-Modulen bzw. deren Durchdringung gescheitert ist, soll es jetzt ein CC1101 richten. Um mit diesem und den Sensoren schneller zu Rande zu kommen, gibt es zusätzlich Randprojekte: USB auf I2C und SPI. Das allerdings mit den Wandlerchips von Microchip, zu denen ich eine gewisse Hassliebe pflege. Beide funktionieren (irgendwie), es fehlt aber auch hier noch die Doku.

Es wird also nicht langweilig. Bis dahin für euch leider mal wieder Warteschleifenmusik…

Reibung

Ohmannohmann, damit hätte ich nicht gerechnet.

Die Installation vom Wiki hat schon länger ein Update nötig, 1.25 liegt auch schon länger auf dem Server, aber unbenutzt. Nun habe ich mich mal wieder dran gewagt. Die absolute Minderheit gab es aktualisiert im Repository von Mediawiki, die Mehrheit nicht. Zwar würde die Seite auch ohne die anderen Erweiterungen halbwegs funktionieren, aber wenn man sich einmal an Komfort gewöhnt hat, will man ihn nicht wieder abgeben.

Die Anzeige der aktuellsten WordPress-Posts habe ich selber mal gehackt. Das gibt es in dieser Form nicht zum herunterladen. Den Code habe ich auf die neue Extension-API angehoben und noch ein paar mehr Funktionen eingebaut. Nun muss man nur noch den Ort der Config-Datei und den externen Basispfad angeben. Über Parameter im Pseudo-HTML-Tag lassen sich Optionen mitgeben. Die Auswahl von Kategorien muss ich noch implementieren. Wenn das funktioniert, wird der Code freigelassen.

MathJax – schöne Formeln! Nur leider ist das Sammelsurium aus über 30000 PNG-Dateien eine Seuche. Aufgrund der Clustergröße macht das aus Netto 10 MB stolze 150 MB. Durch den Overhead von FTP dauert der Upload gefühlt Stunden, dafür dass es im Endeffekt nur von einer Minderheit genutzt wird (standardmäßig spuckt es entweder HTML oder SVG aus) – absoluter Bullshit. Also die ganzen Dateien in eine Zip geworfen und ein PHP-Script geschrieben, das sie – aufgerufen mit dem Pfad als Parameter – wieder ausspuckt. Die Javascript-Datei, die auf die Bilder linkt angepasst und fertig ist der Lack. Ja, Zip ist dafür nicht ideal aber gut genug, bis mir etwas besseres einfällt.

Dann wäre da noch Highslide. Was für ein instabiles Flickwerk – nicht Highslide selbst, sondern die Integration. Die Bilder werden über reguläre Ausdrücke aus dem fertigen HTML extrahiert, anhand des Dateinamens (oder Links) die „Vollversion“ ermittelt und dann mit search & replace (genau genommen regex replace callback) ersetzt. Das ist so ziemlich das inkompatibelste was man machen kann. Dementsprechend habe ich das bei jedem kleinen Update patchen dürfen. Jetzt will ich es – wenn möglich – ein bisschen eleganter implementieren. Zur Not von Null weg.

GeSHi Syntax Highlight. Aktuell noch das größere Sorgenkind. MediaWiki hat 2015 auf Pygments umgestellt. Schön für sie und vermutlich die Performance aber hier gibt’s leider kein Python. Richtigen Ersatz habe ich noch nicht gefunden. Aber die Suche geht weiter.

Vielleicht schaffe ich das Update ja bis zum Geburtstag von der Homepage Anfang April.

Übrigens, als Randnotiz: die Homepage ist teurer geworden. Lt. Hetzner durch den starken Dollar – org-Domains werden durch die ICANN verwaltet und dadurch in USD gehandelt. Statt 12,90 Euro sind es jetzt 15,35 Euro im Jahr. Bringt einen nicht um aber immerhin eine Steigerung von 19 %. Dafür könnten sie ja zumindest Cronjobs und/oder Python in den kleineren Tarifen freischalten 😉

Flashen für faule

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:

putty_fenstertitel

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:

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

visacon

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!

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.

Symlinks im Webhosting-Paket

Manchmal vermisse ich die bash in meinem Hosting-Paket.

Mit ihr würde so manches deutlich einfacher gehen. Ok, Mittlerweile macht WordPress die Updates fast von selbst, bei Mediawiki ist der Prozess ohne bash schon eher manuell.

Früher [tm] musste ich immer das komplette Mediawiki erst herunterladen um dann das dekomprimierte Paket wieder auf den Server zu schieben. Bei einigen tausend Einzeldateien ist der Overhead und die damit verbundene Uploadzeit recht groß. Hetzner sei dank geht das mit dem ansonsten nicht so überragenden WebFTP angenehmer: Runterladen, .tar.gz in zip verwandeln, die eine Datei hochladen und in der KonsoleH entpacken lassen. Das spart schonmal Zeit.

Etwas nervig sind da noch die Mediendateien und die Erweiterungen (Besonders MathJax glänzt mit abertausenden Dateien) in der Wiki. Jedes Mal umkopieren – kann man machen, ist aber unnötig. Symlinks sind toll und gerade für diesen Zweck geschaffen. Mit der bash ist das ein Befehl und viel Zeitersparnis Nur leider kann man diese nicht per FTP anlegen. Muss man auch nicht. Ich sehe zwar schon wie sich bei einigen die Fingernägel in die Schreibtische bohren, aber: PHP kann das 😉

…und es ist genauso einfach wie auf der Konsole:

<?php
$ret = symlink(„ziel“, „name_des_symlinks“);
echo $ret === true ? „true“ : „false“;

Zack feddisch.

Nur an einer Stelle muss man wirklich aufpassen: der FTP-Client erkennt den Symlink nicht als solches. Löscht man das Verzeichnis (oder ein beliebiges übergeordnetes) betritt (zumindest FileZilla) das Verzeichnis des Symlinks und räumt auch dort auf.