<< zurück Zur Übersicht weiter >>

 

 

Das Gurkoskop


Baku bastelt nützliches Gurkizubehör!


1.Warum?
2.Erste Anforderungen und Lösungen
3.Die Displaylösung
4.Verwegenes Systemdesign
5.Vor den Test haben die Götter die Testumgebung gesetzt
6.Ajax der Große oder ein Scheuermittel
7.Genug der Theorie! Wirf an das Brateisen!
8.Stromversorgung
9.Das Rätsel der Uptime
10.Währenddessen
11.Gurki down!
12.Es gibt nix Gutes, ausser man macht es!
13.Gurki weltweit
 

1. Warum?

Ganz einfach: Weil es das nicht zu kaufen gibt!

Deswegen muss man entweder a.) Kompromisse machen oder b.) es selber bauen.
(Wobei man natürlich auch wieder Kompromisse machen muss, aber nicht ganz so viele und nur welche, für die man selbst verantwortlich ist, nach Möglichkeit...)

Beim Bau von Gurki war mir ja schon aufgefallen, daß so eine Maschine,  die nur für einen Zweck gebaut ist, dringend eine diesem Zweck entsprechende Benutzeroberfläche braucht. Auf der man jederzeit mit einem Blick und vor allem ohne erst irgendeinen Rechner hochfahren zu müssen sehen kann, wie dem Gurki ums Herz ist und was er so weggeschafft hat. 
OK, gibt es schon! Die sog. 'Casemodder' basteln sich ja auch gerne irgendwelche Displays an ihre Rechner, um damit irgendwas anzuzeigen. Nun ist mein case ja aber schon gemodded, und nach eingängiger Lektüre der einschlägigen Foren kam ich zu der Überzeugung, daß dieser Personenkreis weder einer deutschen Schriftsprache über Grundschulniveau hinaus mächtig ist, noch irgendwas zur Lösung meines Problems (oder nein, viel besser: zur Erfüllung meiner Wünsche) beitragen kann. 
Irgendwelche krötigen Text-LCDs können vielleicht 15jährige beeindrucken, nützen mir als Lesebrillenbenutzer aber überhaupt nichts, und bunte OLEDs aus Schnickschnacktelefonen sehen zwar toller aus, lassen sich aber auch nicht ablesen und sind dafür nach 2 Jahren Dauerbetrieb garantiert in Mors.

 



2. Erste Anforderungen und Lösungen

Das soll also
  • An der Wand hängen, über dem Schreibtisch, mit einem (dünnen) Kabel von Gurki (unter dem Tisch) abgesetzt 
  • Aus 3m Entfernung ablesbar sein
  • Unabhängig von der Umgebungshelligkeit (von normalem Tageslicht bis ganz dunkel) 
  • Aber auch einfach abzuschalten, wenn es beim schlafen nervt
  • Kein Geschnick und Geschnack, Zahlen und Fakten will ich wissen
  • Ein wenig cool darf es auch sein
  • Und wie immer muss erstmal verbaut werden, was da ist...

Am drängendsten war natürlich die Displayfrage. Nun bin ich ja als 'Displayman' bekannt, und so schlummern in meinem Museum verschiedenste Anzeigeteile aller Art, die auf eine nützliche Wiederverwendung hoffen. Ich erinnerte mich bei diesen Überlegungen schnell an eine besondere Art der Anzeige, die ich, dank der aufopfernden Sammeltätigkeit einiger wohlwollender&verständnisvoller Kollegen, in rauhen Mengen vorrätig habe, und mit der ich immer schon mal was machen wollte. 
Nixieröhren, Dekatrons und E1T habe ich zwar auch noch zu liegen, aber die sind alle zum einen zu 'retro' für diesen Zweck, zu aufwändig in der Ansteuerung (und deswegen schwerlich -iSdW- an die Wand zu hängen) und auch garnicht so einfach abzulesen. 
Profane 7-Segmentanzeigen sind zu profan, Bildröhren und alphanumerische Displays über das simple Ziel hinausgeschossen. So fand sich fast wie von alleine:


3. Die Displaylösung

Heißt:  

hp 5082-73xx

Man möge mir diesen Exkurs verzeihen, aber das ist wirklich Technik, die begeistert. Zumindest für die damalige Zeit. Aber lasst euch von folgender Animation verzaubern:


 

Nein, das ist keine billige 7-Segmentanzeige! Die Ecken der Ziffern werden hübsch abgerundet, damit es nicht so doof aussieht! 20 kleine Leuchtdioden sind auf ein Keramiksubstrat gebondet, dazu ein kleiner Steuerchip, der sich um alles kümmert! Man braucht nur 4 Bit an Daten reintun, mit der 'Latch' Leitung zu wackeln, dann speichert dieser kleine Kerl die Daten und macht daraus schöne Ziffern. Die Teile die ich habe, machen sogar aus den Tetraden (vulgo: Nibbles) A bis F tatsächlich A bis F! (Muss ich nochmal in die Animation aufnehmen...)  Die 5082-7359, von der das Bild oben stammt, hat ein klares Gehäuse. Sieht cool aus, ist aber schwer abzulesen. Deswegen habe ich die 5082-7340 für das Gurkoskop genommen, die gleiche megageile 'Technologie' (vulgo: Technik), aber in einem durchgefärbtem Gehäuse, um den Kontrast zu erhöhen: (Das folgende Bild wurde am Oregenool-Gurkoskop aufgenommen und durch wundersame Tricks der Fotoanimationsbearbeitung zu einem kleinen animierten GIF zusammengefrickelt. Ein Stativ ist dabei eine unabdingbare Voraussetzung, ebenso eine rein manuelle Einstellmöglichkeit an der Kamera)


Das früheste Datenblatt von diesen Prachtstücken, das ich besitze, datiert auf das Jahr 1976. 

 


4. Verwegenes Systemdesign

So weit war der Plan also schon ganz gut, allerdings... 
Bin ich ja auch oft auf Reisen... 
Und da könnte ich natürlich meine Liebste daheim anrufen, damit sie mir die Zahlen vom Gurkoskop voläse. Na, die würde mir schön was husten, hat sie doch insgesamt nur ein mäßiges Interesse an meinen Zahlenspielereien! Ich könnte natürlich auch einen VNC-Zugang auf den Gurki konfigurieren, aber VNC aus dem Internet zugänglich??? Ich kenne da zwar keine Lücken, aber jemand anderes höchstwahrscheinlich schon... Außerdem sollte man niemals mehr Einfall(t)store öffnen als unbedingt nötig. Und ich will Gurki ja garnicht 'remoteadministrieren', sondern will nur wissen, wie die Dinge stehen, um meiner Liebsten im allergrößten Notfall zu sagen: "Zieh' mal den Stecker aus der Drahtkiste unter dem Schreibtisch!!!" und die absehbare Gegenfrage "Welchen?" mit "ALLE!" beantworten können. Und nebenbei sind in Saudi-Barbarien sowieso alle Ports außer 80 schon mal grundsätzlich gesperrt.
Eine Art 'wirtuelles Gurkoskop' wäre nicht schlecht. So eine Art Webcam vor dem Gurkoskop, über das Internet abrufbar... Könnte man alles fertig kaufen! 
Was für ne blöde Idee!!! Einen Videostream um genau 9 Bytes (pro Sekunde, wenn es hoch kommt) an Daten anzuzeigen. Es wäre zwar unglaublich modern, und man könnte sicher noch einen Button 'Gefällt mir', wo dann jeder Hirni auf der ganzen Welt seine überaus irrelevante Meinung zu Gurkis Wohlbefinden abgeben könnte, einbauen! Wow! Voll cool krass modern, Web 2.1! Was für eine Scheiße...

Ich will doch nur das Gurkoskop sehen.
So befiel mich dann die Idee, das Gurkoskop zu wirrtualisieren. Ein Apache läuft sowieso schon auf Gurki, da muss einfach nur noch was drauf, was die Anzeige des Gurkoskops möglichst naturgetreu wiedergibt.
OK, ok, ok... Einige einfache Textfelder hätten es auch getan, aber das ist nicht das Gurkoskop. Es soll schon so aussehen wie das Original. Nun war mir das Grundsätzliche dafür ja schon von meinem Besucherzähler, den ich mit beliebigen historischen Anzeigeelementen ausstatten kann, bekannt, deswegen erschien die Idee durchaus realisierbar.

Der Gurkoserver, in der mir vertrauten zeitlosen Programmiersprache C++ (und komme mir keiner mit Plattformabhängigkeit! Ich will den sehen, der in Java eine plattformunabhängige CPU-Temperaturanzeige realisiert... siehe dazu Kapitel 5.) sammelt die Daten und schiebt sie über eine möglichst einfache Schnittstelle an das zu bastelnde Gurkoskop.

Ausserdem werden die Daten in Echtzeit 'irgendwie' in den Apache getan, von wo sie dann an irgendeinen Browser 'geservt' werden, der dann dem interessiertem Betrachter eine (weitgehend) naturgetreue Emulation des Gurkoskopes anzeigt. Am besten natürlich auch mit den jeweils aktuellen Daten... 
Daß diese Übergabe über eine XML-Datei passiert, ergibt sich allerdings erst aus Kapitel 6. 
Ein anständiger Bastelprozess ist selbstredend keineswegs so linear, wie er hier dargestellt wird.

 


5. Vor den Test haben die Götter die Testumgebung gesetzt

Oder: Wie Baku nach vielen Jahren mal wieder auf I/O-Ports am PC zugriff...

 

Da ich einige Basteltage Zeit hatte, bevor das Gurkoskop begonnen werden konnte (Ich musste auf ein Teil warten, das ich *kaufen* musste! Buäh! Weil der Bestand dieses genialen kleinen Käfers, von dem ich normalerweise immer einige in meinen Bastelschachteln habe, bei einem vorigen Projekt auf 0 gesunken war) beschloss ich, als erstes mal mit dem Gurkoserver anzufangen, weil ich den ohnehin bräuchte, und er könnte schon mal Testdaten liefern. Also keine Testumgebung, sondern das Oregenool, in einer für die Testdatengenerierung abgespeckten Version.
Die Schnittstelle zum Gurkoskop ließ ich erstmal beiseite, denn von einer Windoofs-Applikation über die serielle Schnittstelle mit einem ATMega zu kommunizieren habe ich schon gefühlte tausendmal gemacht, und dort erwartete ich nichts, was vorab zu testen wäre.

Die anzuzeigenden Daten zu erheben war ein Klacks, alles schon mal irgendwie irgendwo gemacht. Als einzige wirkliche Überraschung blieb: - TADAA - 

Die CPU-Temperatur!

Wie lustig ist das denn? Normalerweise findet man zu solch banalen Dingen Informationen im Internet zuhauf. Bei der Temperatur scheint das allerdings anders zu sein... Manche sagen, man könne sie manchmal vom BIOS bekommen, andere verweisen auf die 'Windows Management Instrumentation WMI', das geht aber alles nur manchmal und von Mainboard zu Mainboard unterschiedlich, und um mit dem WMI zu arbeiten, muß man sich erst das entsprechende SDK runterladen und installieren. Nächte voller Arbeit, dabei will ich doch nur die Temperatur anzeigen!
Die Linux-Gemeinde hat es da einfacher, dort gibt es eine C++ Library, die alle gängigen I/O-Chips, die auf gängigen Motherboards die Temperatur messen, kennt und nach Eingabe der entsprechenden Zielkoordinaten (Chiptyp und I/O-Adresse) auch die Temperatursensoren auslesen kann, wobei es natürlich dem Motherboardhersteller überlassen bleibt, an welchen Temperaturkanal er welchen Sensor angeschlossen hat. Muss man eben wissen, wenn man die Temperatur wissen will...

Zum Glück fand ich das kostenlose Programm SpeedFan, welches nicht nur die Temperaturen und Lüfterdrehzahlen anzeigt und Mails verschicken kann, wenn einstellbare Grenzwerte überschritten werden, (und noch vieles, vieles mehr!) sondern sogar anzeigt, welchen I/O-Chip auf welcher Adresse es gefunden hat und benutzt! BINGO!

Die Datenblätter der I/O-Chips von Gurki und meinem richtigen Rechner runterladen war dann eins, den Hardwarezugriff dank 'giveio.sys' auch für normale Programme ohne das ganze Treiber- und WDM-Tüdelüt freizugeben ein anderes (Ein Dank hier an mikrocontroller.net), und -ZWACK- mittels weniger Programmzeilen konnte ich bei beiden die CPU-Temperatur auslesen.
Jaja, ich weiß! Das ist BÖSE!!! Direkte Hardwarezugriffe!!! Schmach und Schande über mich! Ich könnte gar alle Lüfter abschalten und so meinen Computer grillen! Oder die Festplatte mit einem Passwortschutz versehen oder ganz, ganz schlimme Sachen machen. Das darf man garnicht! Hardwarezugriff ist so böuse! Man kann ganz schlimmes damit machen!!! Muss man aber nicht.

Höhö! Interessant ist an dieser Stelle, daß man beim alten VC6 noch Inline-Assembler bemühen musste, um auf Ports zuzugreifen, seit VS2005 aber die Funktionen 'inX' und 'outX' wieder eingeführt wurden, die mich in ihrer Syntax sehr schwer an das gute alte 'inportX' von TurboC unter DOS erinnern. 
Ohne 'giveio' kacheln die natürlich richtig ab, aber mit gehts.

So wurde dann aus all dem Gehühner:

//ITE (Gurki ) 
__outbyte(0xa15,0x29); //Select Register SYSTIN in Bank 0
b = __inbyte( 0xa16 );
m_DataCPUTemp = b;

Und:

//Winbond CPU temperature
__outbyte(0x295,0x4e);
//Select BANKSEL
banksel = __inbyte( 0x296 );
//Read Bankselect
b = banksel &= 0xf8;
b |= 0x01;
//Select bank 1
__outbyte(0x295,0x4e);
//Select BANKSEL
__outbyte(0x296,b);
//Select Bank 1
//Read CPUTIN

__outbyte(0x295,0x50);
//Select CPUTIN in Bank 1
b = __inbyte( 0x296 );
//Read CPUTIN
m_DataCPUTemp = b;

Und der Gurkoserver zeigte die richtigen Werte an, bei beiden Rechnern. Oder zumindest die selben, die auch SpeedFan und das Herstellertool anzeigen:

Die Anzahl der Files stimmt auch (Unterverzeichnisse werden als 1 File gezählt, Systemdateien nicht).
Die Felder 'DiskFree' und 'Uptime' habe ich erstmal so genannt, sie könnten auch die CPU-Last und die Anzahl der belegten Handles anzeigen. Das wird sich noch herausstellen, aber die Information, die ich wirklich sehen will, ist schon mal da. 
Zu erwähnen wäre noch das Feld 'Ambient Temp. '. Dafür ist bei einigen Mainboards ein Sensor vorgesehen, der die Umgebungstemperatur messen soll. Bei keinem meiner Rechner zeigt SpeedFan allerdings einen realistischen Wert an, wie denn auch?.. Wie will man *in* einem PC die Umgebungstemperatur messen? Geht doch garnicht ohne externen Messfühler! Vollspacken! 
Deswegen wurde die Funktion auch in meinen beiden Rechnern nicht implementiert... 
Wissen würde ich sie hingegen schon gerne! Denn dann könnte ich sehen, ob die Temperaturschwankungen von Gurki noch ausreichend mit der Arbeitszimmertemperatur korrelieren oder ob eine aussentemperaturunabhängige Temperaturerhöhung eingetreten ist. Dann müsste nämlich mal wieder das Gitter hinter dem Lüfter abgesaugt werden, weil sich da Staub und Katzenhaare abgelagert haben, eine ziemlich tödliche Kombination für Kühlanlagen aller Art!

Und wenn man schon am Elektronik an Gurki ranfrickeln bei ist, kann man da auch noch einen richtigen Aussentemperatursensor einbauen, und die Daten an den GurkoServer zurückschicken. Ich habe in meiner Bastelkiste noch einen einzelnen DS18B20Z von Dallas gefunden. Der kommt da rein! 

Das sind dann sogenannte 'Change Requests', wenn man während eines Designs Ideen hat, was man NOCH alles damit machen könnte. Aber das ist ja reine Bastelei! Völlig unprofessionell! Geht ja gar nicht! Wer soll denn das bezahlen!
Nun gut... Im Hobby darf ich das ja noch. 
Ah, na! Da wird mir langsam klar, warum ich das hier mache...

Und nein, ich habe NICHT das große Rätsel der CPU-Temperaturmessung gelöst. Aber ich kann Gurkis Temperatur messen. DAS war die Aufgabe, und sie zu lösen hat einen Abend gedauert. OK, die Dokumentation kostet mich jetzt noch einen Abend, aber funktionieren täte es auch ohne...

 


6. Ajax der Große oder ein Scheuermittel

So weit war der Plan also schon ganz gut, die weitere Wartezeit habe ich mir mit Internetspielereien vertrieben.  Ziel war es, die vom Gurkoserver ermittelten Werte anzuzeigen. Kein Thema, PHP und variable Bildchen anzuzeigen habe ich schon mal gemacht. Weiterhin sollten diese Bildchen auch einigermassen, d.h. der Aufgabe entsprechend, aktuell sein und automatisch aktualisiert werden. Und da ging das los... 


Ich hatte schon viel von AJAX gehört! Sogar GOOGLE arbeitet damit! WOW! Was für eine beeindruckende Technik, ach was, TECHNOLOGIE! Jawoll! Bakuskop jetzt mit AJAX-TECHNOLOGIE!

Nee, was hab' ich gelacht...


AJAX erlaubt es JavaScript, irgendwann eine Datei vom Server zu holen. Wenn der Benutzer was gemacht hat, oder wenn z.B. eine Sekunde rum ist. Bevorzugt wird eine XML-Datei vom Server gezogen, weil es für XML 1A-Parser in Javascript gibt. Der Gurkoserver schreibt in ein XML-File, das dann jede Sekunde von den Clients angezeigt wird.

und in das XML-File geschrieben wird:

<gurki>
<t1> 44 </t1>
<t2> 13 </t2>
<t3> 1 </t3>
</gurki>


Ich mein, das ist nicht die schlaueste Lösung, ganz sicher nicht. 
Aber es geht für den Zweck. Und auch nur, wenn man Javascript eingeschaltet hat. 

Deswegen auch das gurkoskop.php:
Im Falle der Nichtverfügbarkeit von Javascript wird auf diese Seite umgeleitet. Dort wird jedwede Anzeige vom Server generiert, deswegen gibt es auch nur den Stand zur Zeit der Abfrage. Wenn man den aktuellen Stand wissen will, muss man auf 'aktualisieren' klicken.

Bleibt ja jedem unbenommen, was er lieber mag.

 


7.Genug der Theorie! Wirf an das Brateisen!

Platz ist auf einer Europakarte, also erstmal die Infrastruktur löten.

Ach so... Den Schaltplan hatte ich natürlich schon weitestgehend vorher gemalt, aber nachdem die Eckdaten gesetzt waren, war das auch kein Thema mehr. Beim Zusammendröseln der ganzen Drähte und kleinen Käfer (von denen einige sogar auf dem Rücken liegen) ist ein Schaltplan eine große Hilfe, erspart viel Verdruss und Grübelei. In meinem Alter weiß man auch zu schätzen, wenn man irgendwo was nachkucken kann und sich nicht alle Verbindungen merken muss...

Der Schaltplan also: 
16 hp 5800-73xx
8 Leuchtdioden 
1 FT232RL (Den musste ich noch kaufen, deswegen die Wartezeit)
1 ATMega8 (Im TSOP, habe ich noch etliche von liegen aus einem  alten Projekt (BACU9600))

Der ATMega im TSOP war kein Thema, ich habe zwar auch noch welche im DIP rumliegen, aber weil der FT232 sowieso die Dead-Bug-Technology (DBT) erfordert, kann die Vorderseite den Displays und allem anderen vorbehalten bleiben, was nach vorne muss. Ein Taster z.B., um das Gurkoskop auszuschalten, wenn man schlafen möchte. Und ein LDR, der die Helligkeit der Anzeigen an die Umgebungshelligkeit anpasst. Da zwang sich die beim DisplayTester entwickelte Technik förmlich auf. Lochraster mit schwarzer Pappe. Sieht auch nicht so schlecht aus. Die schwarzen Fassungsstreifen habe ich gleich mitbestellt. 
Als LDR habe ich dann noch ein besonders stattliches Exemplar aus der Bastelkiste ausgewählt, denn das wenige, was zu sehen ist, sollte schon irgendwie 'groovy' (Ein Wort, dass ich bestimmt seit 30 Jahren nicht mehr benutzt habe!) sein. 

Was ich nicht wusste, habe ich erstmal offen gelassen.  Dann zuerst die einfachen Sachen aufgebraten und getestet:

Und löppt, dat Mopped

Den Mega8 mit 6-Pin Baku-ISP noch drauf:

Erstes Testprogramm geflasht et voila:


Das Gedrösel tut schon was, z.B. dass die toten Käfer mit den paar Drähten dran meinen Befehlen gehorchen :-)

Hinten schon mal vorverdrahten:

Und dann die Schieberegister (man unendliche Porterweiterung) und den Rest reinhauen:

Löt, Löt, Brat, Brat!
Seit ich eine fette Brille zum SMD-Löten brauche, fasziniert mich diese Welt besonders! Ich mein, das macht ja auch Spaß!


Die Drähte da um den Masseanschluss vom LDR rumzurouten. Und dann läuft die Testsoftware auch noch, und an allen Ausgangsbeinen von den Schieberegistern wackelt es im Takt!  

Manch einer wird sich fragen, wie man scheißnormale SO16-Gehäuse mit 50mil (1,27mm) Raster auf 100mil (2,54mm) Lochrasterplatten löten kann. Ist ganz einfach! Man muss nur die Lötaugen mit der kleinen Proxxon-Kreissägescheibe in der Mitte durchsägen, dann passt das wunderbar:

Ein Taster wollte noch gefunden werden, aber nachdem das Thema Stromversorgung (siehe Kapitel 8) ausreichend gelöst war, konnte der vorsorglich für einen Schaltregler freigehaltene Platinenplatz auch verbraten werden: 

Endlich konnte ich mal den schwarzen Schurter-Knackfrosch zum Aufkleben benutzen, der schon seit vielen Jahren (samt passender Printbuchse!) in meiner Tasterkiste schlummerte:

Keine Ahnung, wo ich den jemals herbekommen habe, aber die Anschlussbuchse passt aufs Lochraster und die Kabeldurchführung lässt sich mit Kalmring sein Enkel sein Zahnarztwerkzeug auch nach Mitternacht ganz ruhig ins Lochraster fräsen:

Und auf der rechten Seite bildet er, zusammen mit den LEDs, ein hübsches optisches Gleichgewicht zur USB-Buchse und dem Kabel. 

Ja toll! Da sollte eigentlich ein richtiger Schalter hin! Ich hatte den schon ausgesucht, mit einem roten Knebel! Aber der war SO kacke auf Lochraster zu montieren, und sah an keiner Stelle auch nur annähernd gut aus. So eine blöde Knackfroschtaste hat aber auch Folgen: Selbst wenn sie den ganzen Displaystrom schalten könnte, dann wäre das Display nur an, solange ich draufdrücke. 
Ganz toll! Kann ich mich auch gleich über meinen Rechner einloggen, der daneben steht...

Deswegen habe ich einen PMOS High-Side-Schalter eingebaut. 

Und den Schalter/Taster über einen Portpin abgefragt, der Rest ist dann Software, man könnte sogar einen Bewegungsmelder anschliessen.
Man konnte die Displays zwar auch vorher schon per Software über die Blanking-Pins dunkeltasten, aber auch völlig geblankt nehmen die 16 hp5082-7349 noch so gerne ihre 700mA auf! 
Ich hatte das schon im Datenblatt gelesen, wollte das aber nicht wirklich glauben. Gut, wenn man den Plan B dann trotzdem schon im Hinterkopf gehabt hat. Ganze Stromversorgung abschalten, und alle Interfacepins in den Tri-State schicken. Wieder mal zwei Klatschen mit einer Fliege schlagen!
Passt, Herr Baurat! Bakuskop verbraucht weniger als 10mA, wenn alle Lampen aus sind. 

 


8. Stromversorgung

1,2A nehmen die Anzeigen, gemessen unter Normalbedingungen. Das hatte ich befürchtet. (Um ehrlich zu sein: Nach Lektüre des Datenblattes hatte ich kaum anderes erwartet, aber die Hoffnung stirbt bekanntlich zuletzt...)

Mein erster Entwurf hatte ja auch eine Hohlsteckerbuchse  für die Stromversorgung, und eine Standard-RS232 auf 9Pin-DSub. Ich hatte extra viel Platz für einen Schaltregler freigelassen, Glättungskondensatoren und Gleichrichter sogar!
Mach ich aber nicht mehr. Davon abgesehen, daß die meist knausrig ausgeführte Signalanpassung nur die Signale versaut, hat ja heute auch kaum mehr einer eine anständige serielle Schnittstelle. Und bevor ich da irgendwen mit Prolific-Chips serielle Schnittstellen über USB emulieren lasse, dann mach ich das lieber selber. Mit FTDI.
USB-seriell-Interfaces machen nur mit FTDI Spass und funktionieren am Ende gar noch.

Cool ist obendrein, daß  aus dem FT232R  (bei richtiger Programmierung) auch noch 6MHz rauskommen, da kann man den Quarz vom Prozessor sparen, nebst den Bürdekapazitäten. Und dann liefert USB auch noch 5Volt! Bis zu 500mA!
...

Ja Fuck! Ich brauche aber 1200mA!
Da geht USB nicht!
Außer man nimmt 3 USB-Ports parallel, wie das viele Festplatten machen. Dann muss man aber an jedem Port mit einem eigenen FT232 500mA Stromverbrauch anmelden. Eigentlich...

Ich mach das so: Hinten auf dem Gurki-Board ist ein USB-Anschluss. Da zwacke ich eine USB-Verlängerung dran, die hinten aus dem Gurki ca. 50cm lang ist. Den USB-Pluspol löte ich direkt über eine 2A-Sicherung an die +5V von Gurkis Netzteil. Das ist eh nicht ausgelastet. Über die offenen Lötstellen schrumpfe ich Schlauch!
Nuja.
Ich habe es an meinem aktiven Hub ausprobiert: Die Spannung geht zwar in die Knie, aber das Gurkoskop läuft wider jeder Spezifikation auch daran. 5V rultz!

Aber das ist ja auch mal wieder das schöne am Basteln: Wenn man die Spezifikationen _genau_ kennt, kann man die Normen ignorieren. Zum Glück ist das Gurkoskop ja nicht für den Massenmarkt gedacht, ansonsten hätte ich da wohl ein Wandwarzennetzteil samt Hohlsteckerbuchse und Schaltregler reindesignen müssen um die USB-Spezifikationen zu erfüllen, oder 3 FT232R, die mit 3 USB Kabeln an einem Rechner hängen und jeweils 500mA Stromaufnahme proklamieren. Dann hätte ich den einsamen Schurter-Knackfrosch aus meiner Tasterschachtel nicht verbauen können... Stattdessen aber besser schon mal gleich einen Anwalt beauftragen...

Nun bedingt aber die Applikation des amtlichen Gurkoskopanschlusses einen Eingriff in die Gurki-Hardware, und dazu möchte ich lieber den Gurki abschalten. Nicht, daß ich mir nicht zutrauen würde, diese Operation auch bei offenem Herzen durchzuführen, wenn es sein müsste, aber wie ich mich kenne, fällt dann wieder irgendwas rein, oder der Netzstecker rutscht raus, so wie bei der Wandmontageaktion, das Filesystem ist im Arsch und es macht lästige, unnötige Arbeit. Tut ja nicht Not.

Aus Gründen, die im folgenden Kapitel näher erläutert werden, habe ich dieses Thema um einige Tage zurückgestellt...


9. Das Rätsel der Uptime


Eine der herausragenden Eigenschaften von Gurki soll ja seine Verfügbarkeit sein. 'Hochverfügbarkeit' ist das erste Serververkaufsargument, es gibt ganze Seiten im Internet, die sich mit nichts anderem beschäftigen als: Wer hat den längsten laufenden Rechner. Natürlich bin ich da mit meiner einsamen Wahl von Windoofs XP als Gurkibetriebssystem völlig raus, weil ein anständiger Mensch sowas schon garnicht tut. Auf einen richtigen Hochverfügbarkeitsserver muss irgendein -ix, -ux oder wenn man richtig Heldenhardcore will, ein VMS!

DAS sind die wahren Betriebssysteme!
Ich bin aber nur doof, und nehme das, was gerade in meiner Bastelkiste liegt, ist ja ein Bastelprojekt, und ich habe auch in meiner knappen Freizeit nicht die Zeit, 'professionell' zu spielen. Zahlt mir nämlich kein Schwein...
So also XP SP3.  
Ende der Vorrede.

Einführung für Laien: 'Die 'Uptime' (groß geschrieben, weil es dafür keinen adäquates deutsches Wort gibt)  ist die Zeit seit dem letzten Start des Rechners, genauer gesagt, seines Betriebssystems.

Naiv, wie ich manchmal bin, dachte ich mir, das wäre ja schön, die 'Uptime' auch anzuzeigen, so quasi -ja, ich gebe es zu- als Penislängenanzeige.
Also flugs das Internet angeschmissen, um herauszufinden, wie man unter Windows XP die 'Uptime' herausfindet. 
Ganz einfach: In der Konsole (von alten Herren manchmal immer noch liebevoll 'das DOS-Fenster' genannt) 'systeminfo' eingeben und Enter drücken, schon wird man von einer Fülle völlig nutzloser und uninteressanter (von unverständlich ganz zu schweigen) Informationen totgeschlagen. Der Kommandozeilenprofi gibt deswegen nicht nur:

systeminfo


ein, sondern

Systeminfo | Find "Up Time"
(Note: In this command, Up Time must be enclosed in quotes and must be initial uppercase.)

Ja schön. Nun möchte ich aber nicht die Systembetriebszeit (germanischer Übersetzungsversuch für 'Uptime') auf dem DOS-Prompt (höhö) oder der Konsole angezeigt bekommen, sondern sie per C++-Programm im Gurkoserver auslesen, um sie auf dem Gurkoskop anzuzeigen. 
Und natürlich ist mir die Lösung, ein 'Kommandozeilenprogramm', in diesem Falle 'systeminfo' unsichtbar zu starten, und dessen Textausgabe in eine Pipe umzuleiten, die ich vorher im Gurkoserver aufgemacht habe, um mir da nachher die benötigte Information rauszufrunseln, viel zu sehr durch die Brust ins Auge gefickt, als dass sie mehr als Plan D sein könnte. 

Zu diesem Zeitpunkt GLAUBTE ich noch, dass es irgendwo einen Systemaufruf in der Windows-API geben müsse. Oder vielleicht sogar in der MFC: CTime::GetSystemUptime(), oder sowas. Ist aber  (Nach meinem derzeitigen Stand der Forschung) nicht. 

Einschlägige Internetforen raten, GetTickCount() zu verwenden, das liefert die Zeit seit Systemstart in Millisekunden zurück. Cool. Ein DWORD. 32 Bit ohne Vorzeichen, das langt genau für 49,7102696296 Tage. Gurki hat gerade etwas mehr als 49 Tage und 7 Stunden auf der Uhr, also werde ich einen Teufel tun, und ihn jetzt runterfahren. Viel zu gespannt bin ich, was die diversen Möglichkeiten der 'Uptimeanzeige' morgen anzeigen werden, und wie grosse Bereiche des von tausendschlauen Vollklappspaten, die gute (oder besser: 'gut gemeinte') Ratschläge abgeben bevölkerten Internets ich wieder einmal als völlig überflüssig abhaken kann. 
Ja. Ich habe es gemessen. Aber dazu später.

Fortgeschrittenere Menschen (sind im Internet dann schon weniger) raten zur Verwendung des 'Performance counters'. Der zählt zwar mit der 'Performance Frequency' hoch, ist dafür aber auch 64Bit breit, so dass ein Überlauf auf meinem Hauptrechner erst in etwas mehr als 100 Jahren zu erwarten ist, und das finde ich persönlich durchaus tolerabel. Auf Gurki sind es einige 1000 Jahre, weil die 'Performance Frequency' nur bei einigen Megahertz liegt. Klingt aber, summa summarum, schon einladender. 
Ein Überlauf dieses Zählers ist zwar auch sicher zu prognostizieren, aber er wird zu einer Zeit stattfinden, zu der er mich überhaupt nicht mehr interessieren wird.

Als letzte Möglichkeit fand ich noch den letzten Schreibzeitpunkt von 'pagefile.sys'.
Der wird von der Systemuhr generiert, und die läuft auf einer 1A RTC, die sich sogar per NTP auf die amtliche Zeit synchronisieren lässt.

Mich dünkt an dieser Stelle, dass niemand in dieser ganzen verkackten Welt ein Windows XP länger als 49,7 Tage laufen lässt. Und die Uptime von UX-Systemen gemessen wird, indem man sich aus einem Konsolenprogramm die passenden Ausgaben rausfischt. Aber WIE die Zeit wirklich gemessen wird, weiß kein Schwein.

Und wenn SpeedFan morgen bei der Uptime weniger als 49 Tage anzeigt, dann weiss ich auch, warum.
Alfredo Milano Controlletti kocht auch nur mit sehr leichtem Wasser.

 

Seufz...
Immer, wenn ich mich mit Betriebssystemen und weit verbreiteten Applikationen beschäftige, habe ich das Gefühl, die hätten alle Lack gesoffen. Nicht, das ich glaube, das ich das alles viel besser könnte als die, aber wenn ich so eingeschränkt bin, dann halte ich doch wenigstens mal die Kresse...

Der Beweis ist mittlerweile erbracht: Comparettis Zähler bricht nach 49,7 Tagen auf 0 zusammen, ganz wie ich es erwartet habe, kannste knicken, Deppen am Werk...  Den Performance-Counter und die Echtzeituhr von Gurki trennen mittlerweile ca. 5 Minuten. Ist schon nicht schlecht nach 50 Tagen. Und, um mal ganz ehrlich zu sein, auch nicht wirklich relevant, wenn man die Uptime nur in Stunden anzeigt. Das ergibt den ersten wirklich spürbaren Fehler nach zappazappazapparrrring...  600 Tagen. Da unterscheiden sie sich dann im letzten Digit. Das macht aber nichts, weil die Uptimeanzeige am Gurkoskop sowieso nach 9999h (->416 Tagen) überläuft. 
Vorher kommt bestimmt nochmal der Heizungsmann, und ich muss Gurki runterfahren oder sowas...

Was mich bei der ganze Geschichte so deprimiert ist die Tatsache, daß, wie bei der CPU-Temperaturmessung, im Jahre 2011 derart banale Dinge noch nicht amtlich und endgültig gelöst sind und sich erwachsene Menschen wie ich abendelang den Kopf darüber zerbrechen müssen, was denn nun eigentlich wo und wie gemessen werden kann.

Nachklapp: Als ich neulich in der Raucherecke einem 1000schlauen 'Datenbankexperten' von diesem Problem (und Gurkis Uptime von 49 Tagen) erzählte, lächelte er nur milde und meinte herablassend: Das ist ja nicht lang!
Nuja. Ich hatte auch nicht erwartet, dass er die Thematik überhaupt nur ansatzweise versteht...

Da ich persönlich Herablassung überhaupt nicht abkann, insbesondere nicht von wenigdimensionalen Kohlenstoffeinheiten, tröstete ich mich (rein innerlich, weil ich so voll professionell bin während der Arbeitszeit) damit, daß er, obwohl er manchmal mit seiner Harley-Davidson, die ein verchromtes Bierfass auf dem Gepäckträger hat (in dem selbstredend kein Bier ist), in der Firma vorfährt, einer der langweiligsten Organismen in unserer Biosphäre ist. Worin mir jeder, der ihn kennt, zustimmt. 
Und er ganz sicher auch nicht nur ansatzweise den blassesten Schimmer hat, wie die Uptime seiner Server gemessen wird...

"Da logge ich mich als root ein und gebe 'Uptime ?' in die shell(*) ein..." lautet seine allumfassende Antwort... Oder so ähnlich.

Ich weiß das ja auch nicht, irgendwie möchte ich eben bei Meßwerten wissen, was ich von ihnen zu halten habe, da kann ich meine Kinderstube wohl nicht verleugnen.

Fazit:
GetTickCount() geht nur 49,7 Tage.
PerformanceCounter geht lang genug, ist aber ungenau.
Pagefile.sys wird beim Systemstart angelegt und trägt unendlich lange die Systemzeit zum Systemstart mit sich. Und die kann genau gehalten werden. Somit ist das das Mittel der Wahl.

Kleiner Haken: Das File lässt sich ums verrecken nicht öffnen, um die Zeit abzulesen (Nein, auch nicht, wenn man das Flag setzt, daß man nur die Attribute ansehen will...). 'FindFile' hilft da, muß man aber auch erstmal drauf kommen und sich vorher eine halbe Stunde wundern, warum das andere nicht geht...

Zum Schluss:
weiß ich jetzt also, was meine 'Uptime'-Anzeige wirklich anzeigt.


 

10. Währenddessen

ich noch so vor mich hin grübelte, beschloss ich, das nur die Tat der Rede Wert sei. Und bratzelte und codete schon mal weiter:
(Coden ist ja wie löten, nur dass es a.) nicht so stinkt, und man sich b.) seine Bauteile selber schreinern kann. Oder schustern. Oder basteln. Und man einfach alles löschen kann)

Zuerst codete ich also das Gurkoskop in C für den ATMega8 im Gurkoskop. Dann codete ich weiter am GurkoServer in C++, der ja schon die Temperatur und alles andere erfolgreich auslas, damit er das auch zum Gurkoskop schickt, über die COM-Schnittstelle, den der FTDI-Treiber für das Gurkoskop aufmacht. Auf Gurki und auf meinem richtigen Rechner natürlich. Dann noch das AJAX-Teil auf dem Webserver in JavaScript.

Dazu noch einen  dyndns-free-account eingerichtet und den dyndns-updater runtergeladen und installiert. Ein Release vom Gurkoserver gebaut und auf Gurki installiert, et voilá!

Der Watz kann in seinem Büro das (rudimentäre) Gurkoskop ansehen! (Wenn er Javascript einschaltet, die statische PHP-Version fange ich erst an, wenn die dynamische rundläuft...)

Exkurs:
Manchmal denke ich, vieles wird auch überbewertet.
Der Prozess, z.B.
Der Prozess verhält sich zur Idee so wie Kohlenmonoxid zum Menschen.

Der Prozess ist der verzweifelte Versuch der Nichtskönner, die Verhaltensweisen der Könner nachzuahmen. Da sie aber nichts können, geht das in die Hose. Da sie aber niemals zugeben können, dass sie nichts können (weil sie sich sonst auch besser im Interesse der überlebensfähigen Menschen baldmöglichst selbst töten sollten), glauben sie an den Prozess. Hallelujah!
'Agile Prozesse!'
Man muss das Wort 'agil' nur 'richtig' verstehen... 

Und während man in Villa Riba noch den Prozessen folgt,
wird in Villa Baja schon der Zahlungseingang gefeiert!
Pöööönaaale! Ohoo! 

Scheiß auf den Prozess.
Das Ziel zählt. 


 

11.Gurki down!

Nachdem also die ersten 49,7 Tage um und meine Uptime-Betrachtungen abgeschlossen waren, (ich hatte kurzerhand die drei naheliegenden Möglichkeiten der Laufzeitmessung implementiert und deren Ergebnisse verglichen. Wie unprofessionell! Aber Versuch macht kluch!) konnte ich Gurki endlich runterfahren, um den Baku-Power-USB zu basteln. Das ging so flink, daß ich dabei sogar vergaß, Fotos zu machen. 
Der geneigte Leser, der wirklich bis hier durchgehalten hat, kann es sich aber ohnehin selbst vorstellen: Ein USB-Kabel mit einer Typ-A-Kupplung, die direkt auf Gurki geht, hinten abgeschnitten und in Gurki direkt auf einen der Frontside-USB-Anschlüsse geklemmt. Bis auf die +5V, die gehen über eine ins Kabel eingeschrumpfte SMD-Sicherung (Die habe ich von einer alten Festplattenelektronik abgelötet) direkt ans Netzteil. Alles schön isoliergeschrumpft und mit oregenool TyWrap an tragenden Teilen festgestrapst. 
Wie erwartet lief der ganze Quargel sofort, allein das Gurkoskop stürzte manchmal beim Ein- und Ausschalten der Anzeige über den Taster ab. Kein Wunder, 1,2A bei diesen dünnen Drähtchen, das gibt beim Schalten böse Spikes, da kann der arme Professor schon mal aus dem Tritt kommen. 1 Mikrofarad in teuer Tantal zur Stützung der Prozessorversorgung schufen verlässliche Abhilfe. Hatte ich auch noch von der BACU9600 über.

Seit diesem letzten Einschalten läuft Gurki also durch. 

Und das Gurkoskop kann man ein- und ausschalten, wie man will. Man kann es auch jederzeit abziehen und wieder anstechen, nach 4 Sekunden ist es da.
Höhö, das war ja auch noch so'n Ding:
FTDI rultz! 
Der Treiber übersteht das abziehen und wiederaufstecken des USB-Steckers im laufenden Betrieb bravourös. Natürlich muss der Gurkoserver damit klar kommen, und nicht etwa modale Dialoge oder unbehandelte Exceptions werfen, wenn die Schnittstelle nicht da ist... 
Prolific trägt es da reproduzierbar aus der Kurve, so mit 'schwerer Ausnahmefehler' und so, mit Scilabs habe ich es noch nicht ausprobiert. 

 

12.Es gibt nix Gutes, ausser man macht es!

So ward dann am Ende Gurki nebst Gurkoserver und Gurkoskop. 
Ein agiler Prozess! HÖHÖ!
Also das Gurkoskop:


Der Gurkoserver:

(Das Feld 'Test' habe ich eingebaut, um an das Gurkoskop spezielle Steuerbefehle zu senden, die die LEDs ein- und ausschalten sowie auf den Displays die Zeichen von 0-F darstellen, zwangsweise und unabhängig vom Rest der ganze Geschichte. Das war nötig, um die Fotos für das wirrtuelle Gurkoskop zu machen. Und JA! dieses Feature ist in der Schnittstellendokumentation beschrieben. Sonst weiss ich in einem Jahr ja selber nicht mehr, wie ich das gemacht habe. Das hat allerdings weniger als eine Minute gedauert...)
Ob der Gurkoserver ein GUI (Oder wie manche Deppen gene sagen: 'eine GUI') haben soll, stand jederzeit außer Frage. Natürlich will ich, wenn ich Gurki auf dem Bildschirm habe, nicht erst zum Gurkoskop sehen müssen oder gar einen Browser öffnen müssen.

Und das wirrtuelle Gurkoskop:

 

Und sogar CSS habe ich noch lernen müssen. Damit die Anzeigen hübsch nebeneinader sitzen und alles am rechten Fleck ist.
Immerhin, immerhin! War dies das erste mal, daß ich ein eine wirkliche Anwendung für CSS hatte. Bislang ist es mir immer nur als Kröte untergekommen, die ungeschickt entworfenes XML irgendwie lesbar machen musste...

Heute Abend habe ich noch die PHP-Version der wirtuellen Gurkoskopes gebastelt und dabei wieder einmal festgestellt, wie bekloppt die Welt ist... PHP und Javascript sind eine Qual für jemanden, der zumindest einigermassen versteht (und verstehen will!) was die Maschinen tun. Besonders angekotzt hat mich die überaus schwache Typisierung in diesen Webdesignerdeppensprachen. Das ist wie BASIC für Waschweiber, die nicht wissen, was der unterschied zwischen 123 und "123" ist. 

<An dieser Stelle folgt kein Bild der PHP-Version, weil es GENAU so aussieht wie die html/Javascript/AJAX-Version, sich nur nicht automatisch updated. Und die Leuchtdioden blinken nicht, ist eben statisch...>


13.Gurki weltweit

Am Ende habe ich noch ein wenig dengeln müssen, weil die vielen Reisen bevor standen, und 'Kompromisse machen' z.B. die Helligkeitsregelung nicht implementieren, für die der große LDR ja eigentlich eingebaut wurde samt ADC-Routinen. Aber was solls. Kann ich ja nachholen, sollte es jemals wieder an Relevanz gewinnen. Automatische Helligkeitsregelung ist für eine Uhr zwar ganz gut, für das Gurkoskop aber ziemlich schwul. Wenn man es nicht sehen will, kann man es ja auch ausschalten. Oder abziehen. Oder aus dem Fenster werfen, ganz nach belieben. Immerhin habe ich dem feisten LDR als hübschen Designelement noch zu einem Leben ausserhalb meiner Bastelschachteln verholfen. 

Aber dafür geht das Gurkoskop in Tabuk:

Und in Bangkok:

Und sieht überall auf der Welt (in diesem Falle Paris) auch auf dem Blackberry geil aus:

 

Und funktioniert.

Warum habe ich das eigentlich alles gemacht?
In meiner spärlichen Freizeit?

Wahrscheinlich aus dem gleichen Grund, aus dem Männer im stehen pinkeln...

Anmerkung: Anhand der Anzeige kann man auch ablesen, in welcher Reihenfolge die Aufnahmen gemacht wurden... 


<< zurück Zur Übersicht weiter >>