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!?!

Introducing FrontCalc

Seit Windows Vista ist der Windows-Taschenrechner mit seinem „Programmierer-Modus“ relativ brauchbar. Eines stört mich jedoch schon immer: Bevor ich in der Taskleiste lange herumklicke oder ihn mit Alt-Tab suche, öffne ich mir sehr häufig einfach einen neuen (Tastatur-Hotkey).

Viel einfacher und praktischer wäre es, ihn ständig im Vordergrund zu haben, sodass man z. B. das Bitfeld ständig vor Augen hat. Zwischendurch habe ich mir mit eda_preview beholfen, aber warum sollte ich jedes mal zwei Programme starten, das eine suchen und das „Stay on top“-Flag  setzen? Das geht doch einfacher.

Mit C# ist zwar mit Kanonen auf Spatzen geschossen, aber arg viel mehr als  10 Zeilen braucht man für das Unterfangen nicht.

Das Progrämmchen FrontCalc (Quellcode und .exe) startet calc.exe, wartet kurz (warum genau die Wartezeit erforderlich ist, weiß ich nicht genau) und setzt dann das TOPMOST-Attribut.

Trotzdem oder gerade deswegen wird erkennt u. a. avast die Anwendung als „verdächtig“. Wer mir oder der EXE nicht traut, kann sie auch gerne selber bauen. Das C#-Projekt sollte man als Konsolenanwendung erstellen, in den Projekteigenschaften aber wieder auf (Ausgabetyp:) Windows-Andwenung umstellen, damit kein  Konsolenfenster aufpoppt.

Himbeere

Ich habe mir für den Sommer wieder zu viel vorgenommen – zumindest bin ich in Sachen Energieerfassung nicht sonderlich weiter gekommen.

Es liegt zumindest nicht (hauptsächlich) an der Motivation – eher daran, dass ich momentan in erstaunlich vielen Dingen eingespannt bin. Wo haben sich in den letzten Wochen anscheinend viele PCs dafür entschieden, kaputt zu gehen oder anderweitig Aufmerksamkeit zu einzufordern. Dass das Zeit frisst muss ich wahrscheinlich nicht erwähnen.

Wie dem auch sei, der Hauptgrund dafür, dass des nicht so recht voran geht ist, dass ich die Energieerfassung auf eine andere Plattform umziehen will.

Zwar ist die Leistungsfähigkeit des Mikrocontrollers nicht nicht ganz ausgeschöpft, dennoch komme ich bei manchen Dingen an gewisse Grenzen. Sei es die Datenhaltung oder die Kommunikation mit dem Datenbankserver (die nicht zuletzt durch Dyndns bzw. dem Routers hier nicht 100% zuverlässig ist). Auch beim Userinterface gibt es ein paar nicht ganz optimale Dinge.

Aber bevor ich noch lange um den heißen Breit rede: ein Raspberry Pi soll es werden. Dieser soll später (wenn ich mehr Gefühl für Linux und die Heizungsregelung habe) auch die Zentralheizung sowie Solaranlage regeln.
Ich weiß, dad Teil ist für die Anwendung schon fast Perlen vor die Säue, dafür aber unschlagbar günstig (und noch dazu sehr energieeffizient).

Der Netzwerkanschluss des größeren Modells lädt zusätzlich noch ein, das Teil im Hausnetz viele und von außen wenige Informationen zugänglich zu machen bzw. E-Mails zu verschicken (oder per VoIP gar einen Rundruf zu machen), wenn irgendwas nicht stimmt. Ferner dürfte es mit der internetfähigen Zentralheizung sogar möglich sein, Wetterprognosen in die Regelung einfließen zu lassen – sodass z. B. vor einem kalten Tag die Wärmepumpe in der Nacht (im Niedertarif) das Wasser im Puffer stärker erwärmt als vor einem warmen Tag, bzw. in der Nacht gar nicht abläuft, wenn der Folgetag sonnig (-> Solaranlage) ist.

Momentan sind es noch Gedankenspiele, aber die Möglichkeiten verleiten eben dazu 😉

Wasserfalldiagramm für die Fritz!Box

Beim Einrichten von Fritz!Boxen komme ich manchmal an den Punkt, dass irgendwas in der näheren Umgebung das DSL stört.

Praktischerweise hat AVM eine Anzeige des Spektrums ins Browser-Frontend eingebaut, mit dem man die Störungen gut erkennen kann.
Allerdings hat die Anzeige einen Haken: Manche Störungen sind nur kurzzeitig – schaut man also in dem Moment der Störung nicht hin, hat man sie verpasst.

Aus diesem Grund habe ich mir ein kleines Bookmarklet geschrieben, das ein schönes Wasserfalldiagramm auf die Seite zaubert:

Die Ansicht scrollt mit der Aktualisierung der Spektrumsanzeige (etwa im Sekundentakt) Pixelweise nach oben weg.

Einfach den nachfolgenden Link in die Bookmarkleiste ziehen, in das Webfrontend (Internet -> DSL-Informationen -> Spektrum) der Fritz!Box navigieren und auf den Bookmark klicken.

Nachdem WordPress (oder ich) zu doof ist, Bookmarklets richtig umzusetzen: guckst du hier!

Funktioniert im Firefox 6, Chrome 13 und Internet Explorer 9, ist aber noch etwas ausgegoren (löst beim Ausführen auf anderen Seiten Fehler aus).

Was mir beim Programmieren aufgefallen ist: entweder habe ich oder AVM nicht sauber programmiert – eine der Anzeigen treibt die Speicherauslastung von Firefox massiv in die Höhe…

Gnarg!

Puh. Zwei Wochen sind vorbei, 100m Leitungen verbaut und noch kein Ende in Sicht. Die Züge fahren zwar schon (sogar das segmentweise Schalten des Gleisstromes funktioniert), die Beleuchtung lässt allerdings noch immer auf sich warten.
Unter anderem deswegen, da die bereits für Anfang letzter Woche erhoffte LED-Lieferung aus China immer noch ausbleibt.
Das wäre nicht zu schlimm, wenn nicht immer wieder Murphy’s Law zuschlagen würde:
Zur Verbequemisierung der Anlagensteuerung wurde ein DCC-Decoder zur Steuerung von Weichen und Beleuchtung gebaut. Auf dem Steckbrett hat alles prima funktioniert – auf der Lochraster: naja, ihr wisst schon.
Die Anfangs geschätzten 60 Meter Fahrstromleitung waren um fast genau 2×10 Meter zu kurz. Da die entsprechenden Leitungen im Baumarkt fast das Vierfache der Bestellung gekostet hätten siegte der Schwabe in mir und wir verloren zwei weitere Tage….

Erschwerend kommt hinzu, dass sich nun „endlich“ der Sommer gemeldet hat. Leider mit solch einer Gewalt, dass es unterm Dach angenehme 32°C hat. Ob es unter der Tischplatte besser oder „besser“ ist, möchte ich momentan nicht einschätzen.

Für morgen haben wir uns vorgenommen, wesentlich früher loszulegen (und somit der Hitze am Tag zu entgehen) und einen großen Schritt weiterzukommen.
Ich werde es mir wohl mit dem Oszilloskop und Notebook samt Logic Analyzer und Programmiergerät unter der Tischplatte „gemütlich“ – die Tischhöhe ist zwar für den Modellbahnbetrieb ideal, aufrecht sitzen kann man darunter allerdings nicht.

Jetzt aber genug entfrustet für heute. Mal sehen/hoffen, was der morgige Tag bringt.