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.

Python lernen

Python ist des Raspis (in)offizielle Scriptsprache.

Auf dem Weg zur Modellbahn-Lichtsteuerung, deren „Großhirn“ auf dem Raspberry Pi laufen soll, führt also kaum ein Weg vorbei.

Für die ersten Schritte habe ich auch auf dem Pi gearbeitet, aber irgendwie kann ich mich mit dem Terminal noch nicht so richtig anfreunden. Nachdem bis jetzt alles auch auf dem PC läuft, geht es auf der großen Kiste weiter. Bis jetzt habe ich SciTE verwendet (eine schon etwas betagte Version, irgendwie kann ich mich nicht davon trennen…). Da in der Installation keine vernünftige Code Completion integriert ist war der Browser mit Stackoverflow nie weit entfernt. Auf der Suche nach einer etwas besseren Entwicklungsumgebung bin ich auf Python Tools for Visual Studio gestoßen. Installiert, gestartet und läuft. Man muss noch nicht einmal print(„Hello World“) eingeben. So muss eine Entwicklungsumgebung sein! 😉

(Schöne) Warteschleifenmusik

Heidewitzka, wie die Zeit vergeht. Die Wochen(enden) rasen vorbei und ja, hier gibt es leider weiterhin vergleichsweise wenig. Das liegt allerdings nicht daran, dass ich keine Lust hätte. Neben den zeitlichen Problemen spielt noch eines dazu: nach dem versumpfen des Datenloggers möchte ich keine angefangenen und niemals in einer Form weiter gemachten Projekte/Artikel mehr online stellen.

Zugegebenermaßen ist es bei der Energieerfassung ähnlich, aber: das Teil bekommt wahrscheinlich ein ordentliches Upgrade mit Raspberry Pi (oder einem anderen Embedded-Board). Der AVR ist zwar nett, weil man ihn nicht so schnell in die Knie zwingt – die Uptime ist genau ein Jahr, Unterbrechungen gab es nur durch Routerausfall (wodurch sich der AVR irgendwann wegen fehlendem Traffic resettet) und Stromausfall. Abgesehen davon verrichtet das Teil seit nun 4 Jahren fast ununterbrochen seinen Dienst. Die Reset-Taste hätte ich mir sparen können.

Für die meisten ist wahrscheinlich interessanter, was für Projekte & Artikel in Planung sind – da kann ich schon ein paar Dinge versprechen:

Es kommt ein Artikel zur „Maximalminimierung“ der Schaltung im VBus-Decoder. Der Wiki-Markup davon hat momentan knapp 12 KB und es wird noch mehr. Allerdings ist der Aufschrieb noch nicht ganz fertig und ein paar Dinge komisch/doppelt/nicht gut beschrieben. Sicher ist aber, dass das Teil kommt. Eventuell sogar mit einem Schmitt-Trigger-für-Dummies-Modus – heißt: Spannungswerte rein, „optimale“ Schaltung raus.

Zweite Dauerbaustelle (sogar schon einmal hier erwähnt): Eine Lichtsteuerung für eine Modellbahn. Ich bin immer noch schwer mit der Firmware beschäftigt, Teile der Hardware sehen schon ganz passabel aus und die Dokumentation wächst. Ersteres ist in der Struktur zwar „gewachsen“, aber nicht zwangsläufig im negativem Sinne. Der Funktionsumfang ist deutlich größer als ich am Anfang für möglich gehalten habe – (sowas ähnliches wie) PWM mit 10 Bit Auflösung bei > 100 Hz und 40 Kanälen. Die einzelnen Kanäle lassen sich absolut und relativ sowohl linear als auch logarithmisch (letzteres noch nicht optimal) setzen. Die Änderungen sind als Gruppen und in Transaktionen möglich. Dazu kommt noch ein Fader (ebenfalls transaktionsfähig, momentan aber nur lineares Fading). So wie es aussieht, passt auch noch ein Sequencer in die Firmware. Die Kommunikation läuft über ein eigenes Protokoll „oberhalb“ von RS485. Wie gut das mit der Kollisionsvermeidung und -Erkennung funktioniert, muss ich noch herausfinden.

Dritte Bausteille: Ich hab bei mir in der Arbeit einen elektrisch höhenverstellbaren Tisch für daheim ergattern können. Leider bewegt die Elektronik ihn nur um einen Zentimeter. Erste Idee war, alles neu zu machen, damit aber ein Ende in Sicht ist, soll bei dem Teil erst einmal die Grundfunktion wiederhergestellt werden. Also: Reparatur und etwas Reverse Engineering. Artikel ist schon in der Entstehung, allerdings noch nicht sonderlich fortgeschritten.

(Nichts) Neues

In den letzten Monaten war es zugegebenermaßen etwas weniger Inhalt (vor allem) im Wiki und hier im Blog gegeben, als ich „beabsichtigt“ habe.

Beabsichtigt in der Hinsicht, dass ich mir mal in den Kopf gesetzt habe, etwa jeden Monat einen Artikel im Wiki zu schreiben und einmal pro Woche hier etwas zu posten.

Gerne hätte dazu auch eure Meinung – ist das gesteckte Ziel gut, zu viel oder vielleicht sogar zu wenig?

Wie auch immer, ich kann mich in letzter Zeit glaube ich nicht über Langeweile beschweren.

Mein im Februar erwähntes Praxissemester war richtig klasse und leider viel zu schnell vorbei. Neben den vielen technischen und fachlichen Dingen habe ich auch viele tolle Menschen kennen gelernt – falls jemand von ihnen das hier liest: Nochmals Vielen Dank für die tolle Zeit!

Alle anderen Leser werden hoffentlich verstehen, dass ich hier nichts über die Firma und das was ich dort gelernt oder gemacht habe, schreiben werde.

Mit dem Ende meines Praktikums gab es gleich eine weitere berufliche Änderung – wenn man es so nennen will: Seit 1.09. habe ich ein Kleingewerbe. Hat mit hobbyelektronik.org in erster Linie nichts zu tun, da ich momentan eigentlich nur Computer repariere. Der Gewinn wird aber teilweise in die Erweiterung meines „Labors“/Equipments fließen, was sich hoffentlich positiv auf die vorgestellten Projekte auswirkt. Höchstwahrscheinlich wird es noch einen zweiten Geschäftsbereich geben, der für die Zielgruppe dieser Homepage interessant ist – zu viel kann und möchte ich auch hier nicht verraten.

Neu seit September ist auch, dass ich nun ein extra Arbeitszimmer habe. Der Dank für das dafür geht an meine Schwester, die es mir freundlicherweise überlassen hat. Kann aber sein, dass es dabei um ein vergleichsweise kurzes Intermezzo handelt, da ich mit dem Ende meines Studiums in (hoffentlich) einem Jahr direkt in der Arbeitswelt lande und mir eine eigene Wohnung leisten kann.

Den Rest vom September (oder besser: das was davon übrig geblieben ist) habe ich mit allerhand Kleinigkeiten verbracht. Jetzt hat mich das Studium wieder, wobei dieses Semester (theoretisch) ruhiger als die letzten ist. Was allerdings ein wenig an meiner Ruhe nagt, ist die Studienarbeit, bei der ich den Zeitplan und Arbeitsaufwand noch nicht vollständig abschätzen kann.

Auch bastelseitig habe ich momentan ein paar Baustellen.

Seit einiger Zeit ist in unserem Haus einen elektronischer Stromzähler, der ein RS485-Interface besitzt. In diesem Zuge habe ich eine Schaltung auf dem Tisch liegen, die die Daten von Stromzähler, Solaranlage und Wärmepumpe entgegennimmt und verarbeitet. Ich hab keine Ahnung, was mich beim Design geritten hat aber es „passt“ als weiteres Sandwich auf die aktuelle Energieerfassung. Eigentlich wäre das Board der ideale Zeitpunkt gewesen, mit der Hardware zur Vernetzung auf den Rasperry Pi zu wechseln. Vielleicht gibt es ja eine Revision, deren Design besser zum Pi passt.

Zweite Baustelle ist ein kleines Labornetzteil. Von den Eckdaten lange nicht so dicke wie das von Robert und aufgrund der vielen Teile von Farnell nur bedingt nachbaufähig, aber wenn es das kann, was ich mir erhofft hatte, ein ganz nettes Gerät.

Nummer drei und vier haben etwas mit Licht zu tun. Wie vor ein paar Posts schon gezeigt, habe ich ein (ok zwei bzw. vier, wenn man die kleineren noch dazu nimmt) OLEDs herumliegen. Licht könnte ich den Displays schon entlocken, fehlt nur noch eine Anwendung. Ich hab schon etwas im Kopf, aber hier leider noch ein wenig Geheimniskrämerei.

Nummer vier ist ein „kleiner“ LED-Treiber für die Modellbahn meines Cousins. Beim Neubau seiner Bahnanlage letztes Jahr haben wir die Häuser auf LED umgestellt. Besonders an der Sache ist, dass jedes Haus seinen eigenen „Lampendraht“ hat. Bei aktuell über 80 Häusern kommt da schon ein bisschen etwas zusammen. Idee dahinter war, die Beleuchtung möglichst realistisch zu gestalten, also die Beleuchtung am „Abend“ nacheinander einzuschalten. Aber selbst das individuelle Einschalten war mir etwas zu wenig. Dimmen wäre doch deutlich schöner. Gleichzeitig soll es aber nicht allzu teuer sein. Irgendwelche PWM-ICs fallen somit aus. Gleichzeitig sollen natürlich so viele Ausgänge wie möglich bedient werden. Mittlerweile wurde ich das Ganze mit einem XMega oder einem MSP oder Stellaris Launchpad erschlagen (ich hab mit dem Zeug noch immer nichts ernsthafteres gemacht), habe aber aauch noch ein paar AtMega 8 herumliegen, die auch nicht moderner werden. Um es kurz zu machen: Mein Ziel sind 32 LEDs mit 12 Bit PWM-Auflösung halbwegs flackerfrei betreiben. Neben der PWM soll der Mikrocontroller Beleuchtungsprogramme durchfahren und Befehle per UART entgegen nehmen können. Ich weiß, das ist halbwegs sportlich, sollte aber im Bereich des möglichen sein. Teile der Anwendung laufen auch schon, bei den „Beleuchtungsprogrammen“ habe ich das Zeug mal zur Seite gelegt. Die gewünschten Funktionen sind leider nicht ganz so trivial zu programmieren, wie ich es mir erhofft hatte.

AVR Dragon und Xmega A3

Eigentlich wollte ich die Tage damit anfangen, ein wenig mit ATxmega-Mikrocontrollern herumzuspielen und habe mir extra dafür einen AVR Dragon gekauft.

Bis ich heute Abend Platine A mit Platine B verbinden wollte. Nach Auswahl des Controllers und dem Versuch, eine Verbindung aufzubauen, kam folgende Meldung:

[ERROR] Got error setting up PDI mode: 
Device is not supported in this emulator mode. 
Debugger command setParameter failed., 
ModuleName: TCF (TCF command: Device:startSession failed.)

Aha, so ist das also. Dabei habe ich beim Kauf extra noch auf der Atmel-Website geschaut, ob meine Chips kompatibel mit dem Programmer sind, aber sind sie eben nicht. Zumindest nicht per PDI. Der JTAG-Port ist natürlich „verbaut“ und kann nicht wirklich benutzt werden. Ich würde wetten, dass der fehlende Support (wie so oft) eine Kastration in der Software ist. Zumindest finde ich es frech, dass von Atmel keine Angabe gemacht wird, dass ICs nur teilweise unterstützt werden. Hätte ich das gewusst, hätte ich mir gleich den JTAGICE3 gekauft. So bleibe ich wahrscheinlich auf meinem Dragon (da als Student gekauft und Rückgabefrist vorbei) sitzen.

WAT

Ich bin gerade dabei, das Wiki hier etwas zu erweitern.

Eine meiner Wunschfunktionen ist es, direkt auf Dateien verlinken zu können – standardmäßig wird ja immer auf die Datei-Seite der Wiki verlinkt, wo man zwar die letzten Revisionen sieht, aber ehrlich: wen interessiert das?

Wie dem auch sei, die Parser-Extension ist eigentlich relativ schnell geschrieben, trotzdem musste ich dabei an Gery Bernhardts Kurzvortrag „WAT“ denken.

PHP geht zwar schnell, ist aber oft nicht unbedingt schön. Nicht ohne Grund gibt es in den Heise-Foren bei nahezu jedem Artikel über PHP einen riesigen Flamewar über die Sprache. Zugegebenermaßen, an einigen Stellen ist die Sprache ziemlich großer Mist – als kleiner Beweis sei dieses hier angeführt:

if("1" == 1)
{
	echo "aww shit!";
}

Ratet mal, was da raus kommt… (kleiner Tipp, es fängt mit „aww“ an und hört mit „shit!“ auf). Um typenstarke Vergleiche anzustellen, muss man === (oder !==) verwenden. Das muss man wissen und so ziemlich jeder ist durch dieses Schlagloch schon durchgefahren.

Was mich aber bei Weitem mehr ankotzt ist folgendes: Fehlerbehandlung. PHP hat ja ganz klein ohne Objektorientierung angefangen und ist dann nach und nach gewachsen. Leider gab es damals noch keine try/catch-Blöcke und man musste alle Fehler über @-Modifier und anderweitige Fehlerüberprüfungen abfangen. Dieser Zopf wurde bis jetzt nie so richtig abgeschnitten und man muss auch heute noch mit @ abfangen.

Dieser Codeblock kann aufgrund zweier Dinge wunderschön gegen die Wand fahren:

try {
	$file = wfFindFile($input, array('time' => false, 'ignoreRedirect' => false));
	$filename = "";

	if($file !== null)
		$filename = $file->getURL();

	return "<a href=\">" . $input . "</a>";

} catch(Exception $ex) {
	echo "oops!";
	return false;
}

(zur Info: in $file wird bei Erfolg ein Objekt zugeordnet)
Eigentlich würde man ja denken, dass bei wfFindFile – da im Erfolgsfall ein Objekt zurückgegeben wird – entweder ein Objekt oder null zurückgegeben wird. Wird es nicht, aber das ist ein (meiner Meinung) Fehler der MediaWiki-Programmierer. Mein Fehler war, darauf zu vertrauen und typenstark mit null zu vergleichen. Hätte ich typenschwach ($file != null) verglichen, hätte das Ding funktioniert.

Nun kommt aber der richtig große Mist: in $file steckt, wenn’s dumm kommt, kein Objekt sondern false. Bei einem Boolean wird es natürlich etwas schwierig, die Methode getURL(); aufzurufen. Anstatt dass nun die Exception ausgelöst wird, tritt der alteingesessene Errorhandler auf den Plan und wirf den Anker von Bord.

WAT!?!