Fünf Tage durch die Hölle der Cross-Plattformentwicklung

Am vorletzten Samstag bekam ich meine Bauteile für die Wetterstation und nach einigen Versuchen ging ich an die Entwicklung der Anwendung. Was folgte waren 5 Tage in der Cross-Plattform Hölle. Doch für alle die das Projekt nicht kennen hier nochmal die Daten:

Es soll eine autonome Wetterstation sein, die regelmäßig Sensordaten abfragt und lokal in einer Datei ablegt, aber auch regelmäßig eine Seite in meiner Webseite aktualisiert. Das ist z.B. die Seite für heute. Das Projekt ist also nicht nur gedacht als reines Sensorabfragen und Aufbereiten auf dem PC – die Seiten werden von der Wetterstation erzeugt und derzeit alle 300 s aktualisiert.

Tag 1

Angesichts dessen, das es für die Bauteile von Tinkerforge Bindings für Delphi/Lazarus gibt, war die Entscheidung für die Programmiersprache schnell gefallen. Delphi „spreche“ ich seit 15 Jahren, Pascal seit fast 30. Lazarus gibt es als Compiler auch für den Raspberry. Der Weg erschien recht klar – erst mal die Anwendung in Delphi entwickeln, zumal ich den Lazarus Debugger als sehr absturzgefährdet in Erinnerung habe, dann auf Lazarus übertragen – hier sind Anpassungen nötig, vor allem weil Lazarus keine eingebaute FTP-Bibliothek hat und die dazugekommene von Synapse andere Befehle haben.

Das Delphi Projekt war in einem Tag fertig – es bestand aus einer kleinen visuellen Oberfläche, um die Erfassung zu starten und die Parameter (für grafische Ausgabe, FTP-Zugang, lokale Verzeichnisse und Dateien und die UID für die Messwert-Geber zu programmieren. Der eigentliche Teil, der die Daten gewinnt, war in einer nicht visuellen Unit ausgelagert, denn geplant war eine Konsolenapplikation – ich würde schließlich den Raspberry Pi nur für diesen Zweck einsetzen und dessen einzige beiden USB-Buchsen sind schön durch Wlan-Adapter und den Brick mit den Bricklets blockiert.

Diese letztere wollte ich in Lazarus wiederverwenden, nur eben in einer Konsolenanwendung. Die Startparameter stehen in einer Einstellungsdatei, die beim Start gelesen wird – Sie ändern sich ja kaum noch, wenn das Projekt mal läuft.

Tag 2:

Nun stand die Portierung auf Lazarus an, aber noch auf dem Windows PC. Da tauchten die ersten Probleme auf. Neben einigen Problemen der FTP-Anwendung die falsche Dateinamen übermittelte, habe ich die meiste Zeit mit dem Timer mich rumgeärgert. Der Timer ist eigentlich eine nicht visuelle Standard Komponente. Er ruft eine Prozedur periodisch auf. Dass Timer auch unter Windows ihre einschränken haben, weiß ich seit ich sie vor 14 Jahren erstmals nutzte – sie taugen nicht für die Messungen von Zeilen die kleiner als 1/18 s sind. Aber für mein Intervall von 1 s sollten sie keine Probleme aufwerfen – nur konnte ich keinen Timer in Lazarus starten wenn ich als Eigentümer „Nil“ für nichts angab. Bei Delphi ging dies problemlos. Der Eigentümer muss aber eine Komponente sein,. Also ging ich einen anderen Weg und schrieb eine Abwendung die auf TCustomApplication basiert einem nicht grafischen Objekt, das akzeptierte der Timer auch bei Lazarus als Eigentümer und dann lief das Programm – doch bis dahin war Tag 2 vorbei.

Tag 3:

Nun ging es an die Übersetzung in Lazarus. Erneut gab es Änderungen, vor allem weil ein Standardpackage für PNG Dateien sich nicht beim Raspberry installieren konnte, schließlich band ich die Unit für PNG Dateien die ich als einzige brauchte manuell ein. Erneut gab es das Timerproblem. Egal was ich machte, er startete nicht. Schließlich versuchte ich andere Möglichkeiten. Anstatt einen Timer zu bemühen machte ich in dem Hauptprogramm eine Endlosschleife mit „Sleep“, doch das war zu ungenau. Auf 10 s eingestellt zeigten die Protokollausgaben einen Aufruf nach mal 3, mal 5 und manchmal 7 s an – nur nicht nach 10 s. Also machte ich nach einigen Versuchern eine endlosschleife in der Form

• Hole die aktuelle Zeit
• Wenn 10 s seit dem letzten Protokollieren vergangen sind dann
•    Starte Messwerterfassung
•    Merke neue Zeit
• sonst mache nichts

Das erzeugt 100% Prozessorlast, bei Sleep waren es noch 10%. Aber es funktioniert. Dank der Langsamkeit des Raspberrys brauchet ich aber einen Tag für die Änderungen. Es reichte noch die Konsolenanwendung in den Autostart zu installieren. Langsam genug gings, denn Lazarus auf dem raspberry Pi läuft gefühlt langsamer als Turbo Pascal unter CP/M. Beim Kompilieren sowieso und beim Eintippen erscheint auch manchmal der Tastendruck erst nach 1-2 Sekunden.

Tag 4:

Während die Konsolenanwendung unter grafischer Oberfläche läuft tut sie es beim Autostart nach dem Booten nicht. Nach dem Umschalten auf den Start nur zur Shell ist klar warum – sie bemängelt das sie nicht den X-Server kontaktieren kann. Ich verwende zwar keine grafische Oberfläche aber die Graphic Unit weil diese das TBitmap Objekt enthält auf dem ich die Grafiken zeichne – ohne das geht es also nicht.  Es nützt dann auch nichts das nach dem Starten der X-Server startet. Zwei Tage später dämmerte mir das ich mir die folgenden zwei tage Arbeit hätte sparen können, wenn ich es dann gleich im LXDR Startmenü installiert hätte.

Also zurück zum Anfang. Wenn ich nicht ohne X-Server auskomme, dann kann ich aus der Not eine Tugend machen. Ich schrieb eine grafische Anwendung – erst mal ein Lazarusklon der Delphi Anwendung, also mit Einstellungsmöglichkeiten. Dann überlegte ich mir auch ob ich nicht gleich die Charts nehmen sollte die Bestandteil von Lazarus sind. Deren Bilder sehen viel besser aus. Ich muss mich nicht um Achsenskalierungen kümmern etc. Zudem traute ich nun nicht mehr dem Timer – ich hatte bisher die Zeit nicht als Datenfeld gespeichert, sondern den Index aus der aktuellen Zeit abgeleitet – kein Problem wenn er eindeutig ist, doch nach dem Schwanken der Zeit bei Sleep mir doch zu riskant. Zudem entfallen so auch Werte die nicht gesetzt waren und die ich bisher kaschieren musste bei den Diagrammen (kamen bei Tests vor wenn der Computer in den Ruhezustand lief oder der Brick den Computer wechselte).

Nach einem halben Tag war alles umgeschrieben und Tests über Stunden zeigten auch das es unter Windows stabil war, das war vorher meine Sorge. Als ich am Band das ganze neu kompilieren wollte – diesmal weil der Raspberry Pi zu langsam ist auf dem Modell 2, gab es schon beim Laden haufenweise Fehler. Der dort installierte Compiler der Version 0,935 kann mit den Einstellungen der Version 1.4 unter Windows nichts anfangen. Ich beschloss die neuste Version zu installieren. Die gibt es aber nicht als Paket, die muss man manuell aus den Quellen kompilieren. Inzwischen hatte ich bei über 30 Grad Außentemperatur keine Lust mehr hin und her zu laufen und auf dem Raspberry Pi SSH aktiviert und einen VNC-Server installiert. Damit ging der Zugriff mit Putty, die Datenübertragungen mit Winscp und ein Remote desktopzugriff. So konnte ich neben dem Erstellen des Lazarus Compilers noch anders tun.

Danach herrschte Ernüchterung: Die Version 1.5 (also sogar noch um eine Version höher als die unter Windows) lud die Quelltexte, kompilierte, beim Start gab es aber eine Schutzverletzung die auf das Chart zurückzuführen war. Damit reicht es es mir für heute.

Tag 5:

Also nochmals umschrieben, diesmal nun über Remote Desktop auf dem Pi2. Da bemerke ich rasch, dass alle Tasten über Alt-Gr nicht gehen. wer programmiert weiß: das betrifft die geschweiften und eckigen Klammern. Häufig verwendet für Kommentare und Feldkennzeichen. Also direkt an den Pi2 – dort gibt es dasselbe Problem. Es liegt definitiv am Compiler, denn in einem Texteditor kann man die Zeichen eingeben und es ist eine deutsche Tastaturbelegung, sonst hätte ich ja auf die Tasten ausweichen können wo sie im englischen Layout liegen. Nach etwas Arbeit ist der Code um die Charts bereinigt und läuft – zur Sicherheit läuft nun der Brick über Nacht mit dem Raspi 2 ,denn ich will sehen ob er wirklich funktioniert.

Tag 6:

Erster Blick morgens auf die Webseite – neuer Eintrag für den 5.7. wird angezeigt. Ein Klick – und tatsächlich. Der Brick läuft noch. Man sieht den Sonnenuntergang und Aufgang an der Helligkeit, im Laufe des Tages erreicht sie einen Maximalwert und nimmt wieder ab, genauso wie die Luftfeuchtigkeit. Sie lag mal bei knapp 60% und ist nun bei 24 %. Also die Exe auf den Raspi 1 kopieren – der stürzt sofort ab. Ob es über den Zwischenweg des Abspeichern unter einem Windows PC lag? Das muss ich noch klären, eigentlich müsste doch eine Binärdatei auch beim alten Raspi funktionieren. Also nochmals Quelltexte aufspielen, Eigenschaften löschen die es im alten Compiler bei Editbuttons nicht gibt  und kompilieren – noch ein Fehler weil der Raspi 1 keine deutsche Oberfläche hat, und das Komma als Zahlentrenner bei den schon erstellten Daten nicht akzeptiert – doch dann gehts. Und so läuft er seit heute morgen, die erste Hälfte des Tags bis 8 Uhr hat der Raspi 2 protokolliert.

Ärgerlich ist, das kein Remote Desktop für den Raspi 1 funktioniert, auch Putty und WinSCP reißen oft ab. Ich vermute das liegt an dem Mini-Wlan Stick, aber mein größerer würde die zweite USB-buchs für die Bricks blockieren.

Tage 7 – ∞

Wie geht’s weiter? Die Wetterstation ist auch als Detektor zu nutzen. Dreimal ging nachts der Druck auf enorm hohe Werte von 1173 mbar hoch – gleichzeitig stieg die gemessene Luftfeuchtigkeit an. Ich vermute meine Katzen haben untersucht was da rumbaumelt. Es leuchtet schließlich eine blaue LED. Ich habe noch morgens am sechsten tag eine Glättungsfunktion eingebaut, sonst gehen die normalen Druckschwankungen z.B. ganz unter. Die täglichen Grafiken sind nur der Anfang. Interessant ist natürlich eine Langzeitauswertung, also wie verändern sich Temperaturen, Belichtungsbedingungen etc. über ein Jahr oder mehrere Jahre. Doch das werde ich sicher nicht auf dem Raspberry erledigen. Dazu muss ich nur die erzeugten CSV-Dateien herunterladen.

Aber ein paar Dinge kann ich noch im Raspi-Projekt veränderten. Zuerst ist mal ein Temperatursensor bestellt. Ich habe mich für den teureren IR-Sensor entschieden wenn auch primär weil die 0,5 Grrad des ersten mir zu grob waren. Der kann neben der Luft- auch die Temperatur eines Objektes messen, das wäre bei mir auf dem Balkon der Boden oder die Hauswand.

Das Barometer muss noch kalibriert werden. Der Brickviewer zeit eine Höhe von 460 m an und der Aufdruck ist für ein Hoch das wir haben auch zu niedrig. An dem Parsen der HTML-Dateien kann man noch ein Paar Gedanken verschwenden auch ich denke ich werde die Ausgabe noch um eine Tagestatistik ergänzten wie detektierter Sonnenaufgang und Untergang, maximaler, minimaler Druck Temperatur und Luftfruchte und Durchschnittswerte. Das muss dann auch wieder der Pi erledigen.

Auch die Erstellungskette will ich nochmal überdenken. Ich habe mir mal CodeTyphon installiert, das ist eine Crossplattform Entwicklungsumgebung. Die Firma macht nicht viel Wind um das verschenkte Produkt: Dokumentation und Hilfe ist vor dem Kauf gleich Null. Das es nützlich sein könnte habe ich auch nur durch einen Foreneintrag gesehen. Es basiert auf Lazarus mit einigen Erweiterungen. Damit könnte ich unter Windows direkt Arm Code für den Pi erzeugen.

Derzeit ist es mir zu aufwendig. Ohne die Laufenden Anpassungen und Funktioniert bei „Lazarus unter Windows ,  aber unter auf dem Raspberry“ Probleme hätte ich es in zwei tagen abschließen können anstatt in fünf. Das isst definitiv zu umständlich und vor allem wenn man direkt an den Raspi 1 muss auch sehr sehr langwierig.