Schachcomputer Reparatur

Nach langer Bloggingpause gebe ich mal wieder ein Lebenszeichen von mir. Einen konkreten Anlass gibt es auch: Ich habe ein tolles neues Spielzeug geschenkt bekommen – einen alten Schachcomputer (Danke Kathi&Josef)! Inklusive großem Magnetsensor Holzschachbrett, Figuren, Computermodul und zwei Programm-Modulen (ESBII und Mephisto II). Vermutlich ist es ein Mephisto ESB II. Baujahr dürfte so Anfang/Mitte der Achziger liegen. Hier ein paar Impressionen:

 

Einschalttest

Leider hatte sich das Netzteil nicht gleich gefunden, so dass wir hier zuerstmal ein wenig Spannungsversorgunsraten spielen müssen. Das Handbuch schweigt sich dazu leider aus. Im Netz habe ich zumindest für das Grundmodul was gefunden, allerdings war mal von 6.5V DC und mal von 8.5V AC die Rede. Ich nehme an DC dürfte es tun – immerhin kann man das Grundgerät auch mit 4 AA Zellen betreiben. Mit einem Baumarkt-Steckernetzteil habe ich das Ding bei 9V in äußerlich zufriedenem Zustand. 6V schienen nicht zu reichen und 7.5 führten zwar zu Funktion, aber extrem müde glimmenden LEDs – also 9V. Nun leuchtet die grüne LED in der Ecke und zwei Rote blinken fröhlich. Hm – was mag das heißen? Also schreiten wir zum Äußersten: Blick in die Anleitung werfen. OK, das ist normal. Das Ding will uns sagen, dass wir nun die Figuren aufstellen sollen. Gesagt, getan und hier sind sie:

Aber hoppla – was will mir die LED bei H4 sagen?

 

Diagnostik

Laut Anleitung sollten nur dort LEDs blinken, wo die Aufstellung noch fehlerhaft ist. Und im Großen und Ganzen war das auch so – fehlt noch eine Figur, blinkt es dort (nach jedem Reset). Und wenn ich eine Figur mitten aufs Brett stelle blinkt es dort auch – weil es leer sein sollte. Also glaubt der Compi wohl, da stünde eine Figur. Bevor wir aber zum Werkzeug greifen erstmal ein systematischer Test. Mit der "List" Taste kann man eine Stellungskontrolle durchführen. D.h. nach jedem Tastendruck wird auf dem Display und per LED angezeigt, welche Figuren sich nach Meinung des Computers wo befinden (bzw. sollten). Auch hier das gleiche Bild: H4 ist mit einer dem Compi unbekannten Figur besetzt.

Nächster Test: Alle Felder rund um H4 mit Figuren bestücken uns sehen, ob er sie detektiert. Ja, tut er. Hier z.B. für G3:

Habe dann noch systematisch alle Felder getestet, die nichts enthalten sollten und bis auf H4 gab es keine weiteren Probleme. Die akustische Prüfung hat auch nicht viel gebracht: Für alle Felder hört man ein sehr leises klick wenn man die Figur vom Feld entfernt. Bei H4 scheint es auch zu gehen, wenn ich auch den Eindruck habe, dass es erst ab dem 3. Versuch wirklich hörbar wurde - kann aber auch Einbildung sein. Wie auch immer – Diagnose: defekter Reed-Kontakt.

Frisch ans Werk

Die Bodenplatte wird nur von ein paar Holzschrauben gehalten, die waren schnell entfernt. Nun kann man die Schublade herausnehmen und ein weiteres Abdeckbrett entfernen, so dass man freie Sicht auf die Unterseite der Platine bekommt:

Und 16 Schäubchen später dürfen wir die Oberseite bewundern:

Überraschung: da sind je zwei Reedkontakte pro Feld! Das hätte ich nicht erwartet. Zudem sind sie parallel geschaltet. Soll das sicherstellen, dass auch leicht verschobene Figuren erkannt werden? Keine Ahnung. Jedenfalls habe ich alle 64 durchgemessen und alle waren offen – außer H4.
Und weil ich (a) ein Glückspilz bin und (b) alles kaufe/horte, das mal zu einer Bastelei gut sein könnte und nicht viel kostet habe ich tatsächlich Reedkontakte da! Ja, Judith – die sind wirklich mal zu was gut!  :-))))
Nach eingehender visueller Inspektion war ich mir 100% sicher, welcher der beiden Kontakte hängt und getauscht werden muss. Also raus damit, nachmessen, den anderen auslöten und den ersten sowie einen neuen wieder rein. Alles zusammenbauen und – Trommelwirbel – es geht wieder!
Hier zum Beweis ein kleines Probespiel (nicht lachen, waren nur mehr oder weniger zufällig Züge, zum Testen):

Alles was jetzt noch fehlt ist eine kleine Politur mit Öl oder anderer Holzpflege und dann ist er wie neu! Die nächste Herausforderung besteht nun darin das Ding wenigsten einmal in die Knie zu zwingen. Ich bin nämliche kein so begnadeter Schachspieler. Oder vielleicht könnte man einen Roboterarm bauen, der z.B. GNUchess gegen den Mephisto antreten lassen kann? Reizvoll, aber nicht heute...

"Bastelparadies"

Hi zusammen :-)

Nachdem hier längere Zeit Flaute war, wieder mal ein kleiner Eintrag. Ich bin ja im Mai umgezogen und habe endlich ein eigenes Büro/Bastelzimmer. Nach anfänglichem Provisorium ist es jetzt soweit fertig und richtig gemütlich geworden. Es erfolgen ein paar Fotos zur "Dokumentation" ;-). Ich freue mich schon auf viele Stunden ausgelassenen "Makens" und "Hackens" und auf hoffentlich viele daraus resultierende interessante Posts.

Das ist der Blick auf die Arbeitsplätze: Links Büro/Computer, rechts Bastetlisch mit Zusatzregal für das wichtigste Equipment (Oszi Hameg 1505 analog, Computeroszi 32 MS/s, 4-Kanal Labornetzteil, Heißluft-Rework-Lötstation, Lötstation). Darüber hinaus gibts bis unter die Decke jede Menge Stauraum für mein ganzes Bastelzeug.

Das ist die Area zum Relaxen und Chillen, Kaffe-Trinken oder einen 18-jährigen Single Malt genießen. Gleichzeitig auch unsere Gästecouch, auf der es sich ganz bequem schläft. Wer also, Lust hat, zum Basteln übers Wochenende zu kommen - nur zu ;-).

Hier nochmal eine Großaufnahme des Bastelbereiches. Das Netzteil hat so große Filtercaps und einen riesigen Ringkerntrafo drinnen, dass es beim Einschalten in 50% der Fälle den FI-Schalter raushaut. Daher der Einschaltstrombegrenzer in der Steckdosenleiste ganz links - funktioniert super (NTC in Serie zum Verbraucher und Relais parallel zum Primärkreis). Auch eines meiner fast fertigen Projekte ist zu sehen :-) - Blogpost dazu ist noch im Entwurfstadium. Vielleicht schaff ichs demnächst.

So Leute, das wars auch schon wieder. Ich weiß - ein kurzes Intermezzo, aber immerhin. Es würde mich freuen, wenn hier bald wieder mehr Leben herrscht. Ach ja, einen coolen Namen fürunser Blog brauchen wir auch noch.

PS: Ach ja, ich hab vergessen zu erwähnen, dass ich als Bastelplatzbeleuchtung eine 2700 Lumen Röhre montiert habe. Wenn man die anschaltet sticht es in den Augen, aber dann gehts ;-).

Die etwas andere Himbeere: Raspberrypi

Und so melde ich mich aus einer langen Blog-Abstinenz wieder zurück: mit einer Himbeere der anderen Art, "Raspberrypi". Seit einigen Monaten ist der Hype um diese Frucht ungebrochen und nach langer Wartezeit konnte ich einen von Farnell element 14 bekommen. Kurz gesagt ist der Pi eine Linuxbox in Kreditkartenformat - ein vollwertiger Computer mit hohem Bastelpotential. Der Preis ist unschlagbar: 40€ für Bestellung aus UK inklusive allem.

Der Pi ist eigentlich als Billigcomputer gedacht, um Kindern den Einstieg in die Programmierung, auch in ärmeren Ländern, einfach und kostengünstig zu ermöglichen. Die Erfinder und Gründer der Raspberrypi-Foundation hatten dabei aber die Maker-Community unterschätzt. Da der Pi GPIO Pins und die einschlägigen Schnittstellen (UART, I2C, SPI) zusätzlich zu HDMI und USB direkt herausführt kann das 32bit leistungsstarke Board auch für aufwendigere Embedded-Projekte super eingesetzt werden. Die Rechenleistung, vor allem der GPU, ist sehr viel leistungsstärker als die eines 8 Bit Micros.

Aber zunächst mal die Fotos:

 

Kurzer Überblick über die technischen Daten (in diesem Post geht es um Modell B):

	Model A	Model B
SoC	Broadcom BCM2835 (CPU, GPU, DSP, and SDRAM)
CPU:	700 MHz ARM1176JZF-S core (ARM11 family)
GPU:	Broadcom VideoCore IV, OpenGL ES 2.0, 1080p30 h.264/MPEG-4 AVC high-profile decoder
Memory (SDRAM):	128 Megabytes (shared with GPU)	256 Megabytes (shared with GPU)
USB 2.0 ports:	1	2 (via integrated USB hub)
Video outputs:	Composite RCA, HDMI
Audio outputs:	3.5 mm jack, HDMI
Onboard storage:	SD, MMC, SDIO card slot
Onboard network:	None	10/100 Ethernet (RJ45)
Low-level peripherals:	8 × GPIO, UART, I²C bus, SPI bus with two chip selects, +3.3 V, +5 V, Ground
Power ratings:	500 mA (2.5 W)	700 mA (3.5 W)
Power source:	5 volt via MicroUSB or GPIO header
Size:	85.60 × 53.98 mm (3.370 × 2.125 in)
Operating Systems:	Debian GNU/Linux, Fedora, Arch Linux

Zusätzlich führt das Broadcom SOC auch Anschlüsse für ein TFT-Panel und einen CMOS-Kamerachip heraus (die zwei Flexprint-Buchsen). Sowohl ein passendes TFT als auch ein leistungsfähiges Kameramodul wird es als Zubehör zu kaufen geben. Es gibt auch bereits ein Erweiterungsport mit einem AVR drauf, um zusätzlich HW-Schnittstellen und ADCs und DACs bereitzustellen (Gert-Board).

Hier ein kleines Video, in dem ihr den Raspberry in Aktion sehen könnt:

Aktuell habe ich Debian Squeeze laufen (mit Sofware floating-point support - trotzdem erstaunlich flott und usable; komplexere Webseiten sind etwas lahm). Es ist eine "Raspian"-Distribution mit HW-Floating-Point-Unterstützung des SoC in Vorbereitung, die um einiges performanter laufen soll. Auch Übertaktung bis auf ca. 900 MHz wurde bereits erfolgreich durchgeführt.

Ok, das war's fürs Erste :-). Bin gespannt auf eure Kommentare - und ich kann nur sagen: Diese Himbeere rockt und hat eine  fruchtige Zukunft vor sich!

Neues von der Akku-Front

Genug mit der Ecken-Messerei, vorerst zumindest.

Zwei bei Ebay geschossene Laptop-Akkus habe ich an der Werkbank seziert, die Elektronik entsorgt und mit den Zellen hübsche 7.2V Päckchen gemacht.

Und dann war da noch das Scheduler-Problem. Aus meinem Terence-Projekt hab ich den Code wieder aufgewärmt. Die Idee funktioniert folgendermaßen:

• Einen Timer konfigurieren, der stur nach oben zählt. Über den Prescaler des Timers lässt sich das Verhältnis von CPU-Frequenz zu Zähl-Frequenz einstellen.
• Jedes mal wenn der Timer überläuft, wird ein Interrupt ausgelöst und die dazugehörige ISR (Interrupt-Service-Routine) aufgerufen.
• In dieser ISR wird die aktuelle ADC-Messung ausgelesen, in einen Struct geschrieben, danach ein neuer ADC-Kanal eingestellt und eine neue ADC Konversion getriggert.
• Der Timer wurde so eingestellt, er mit einer Frequenz von 1024 Hz aufgerufen wird, also im Abstand von ca. 1ms. Die Schaltung hat vier Kanäle, damit liegt alle 4ms eine vollständige Messung, d.h. ein vollständig befüllter Struct vor.
• Vom Main wird der Struct ausgelesen, etwa alle 40ms. Um Race-Conditions zu vermeiden, also eine Veränderung der Werte während des Lesens, habe ich einen Lock-Mechanismus eingebaut.

Nebenbei stellte ich fest, dass die Arduino-Funktion  analogRead() richtig zeitintensiv ist. Hat man also zeitkritische Anwendungen empfiehlt sich die beschriebene Konstruktion mit ISR-getriggerter ADC-Messung zu verwenden.

So, die bereits beschriebene Schaltung an das Arduino-Board geflanscht, Display dazu und Akku angeschlossen. Nebenbei bin ich noch auf einen fundamentalen Fehler in der Schaltung gestoßen - die Masse der meisten Schaltungsteile ist fälschlicherweise auf GND gelegt. GND ist hinter dem Shunt definiert, was bedeuten würde, dass sich das Niveau bei Stromfluss zum Akku-GND verschiebt, und somit die Spannungs-Messungen falsch wären. Da musste nochmal das Löteisen ran. Korrigierten Schaltplan poste ich nach.

Eine Frage war immer noch offen: Wie verhält sich die Akku-Spannung, während eines Lade-Bursts? D.h. wie schnell fällt die Akku-Spannung wieder ab, wenn der Lade-Strom nicht mehr fließt. Das unten stehende Diagramm zeigt das Ergebnis:

Auf Y1 die Spannungen. Ist der Strom negativ, fließt er in den Akku, die gemessenen Spannungen werden der Lade-Spannung (rot) zugeordnet. Positiver, bzw. null Strom entspricht der Akku-Spannung (grün). Y2 - wer kommt von selber drauf? Strom (blau).
An der X-Achse die Werte des Zyklus-Zählers - ein Zyklus entspricht ca. 1ms.

Fast eine Sekunde braucht der Akku, bis die Spannung wieder auf den tatsächlichen Wert abgefallen ist. Will man also während des Ladens die Akku-Spannung messen, muss die Ladung für eine Sekunde ausgesetzt sein. Relevant wir dies unter Umständen, wenn balanciert werden soll.

Ein weiteres Problem, wird noch deutlich: Das Laden / Entladen wird über zwei MosFet-Transistoren gesteuert, über welche abhängig vom Strom Spannung abfällt. Am Akku liegt deshalb eine Spannung an, welche mal höher, mal niedriger ist. Wie soll nun von einem Ladegerät die obere Spannung genau eingestellt werden?

Dazu wären ein paar Messungen fällig. Im Datenblatt ist der Widerstand der verwendeten IRF9Z24N mit 0.175 Ohm angegeben. Damit würde bei einem Ladeschlussstrom von 150mA etwa 0.05V abfallen. Aber ist das wirklich so?

Mal sehen. Hab natürlich ein Back-Up Konzept im Ärmel: Ein Netzteil bauen, Mikrocontroller-gesteuert und über Serial oder SPI mit dem Akku-Controller kommunizieren. Teile dazu hätte ich alle da. Aber ich komme ein wenig vom Thema ab. Wollte ja eigentlich einen Roboter bauen (nachdem ich das Navi ja nicht mehr brauche...).

...und sie leben!

 Als ich Sonntag Morgen am Wohnzimmer vorbei in die Küche schlurfte, merkte ich (so halb) dass irgend etwas anders war. Hatte sich da auf dem Tisch etwas verändert? War die Unordnung von mir hinterlassen worden? War es gestern so spät? Die Synapsen etwas mit Koffein geschmiert, verflog langsam das Dunkel in dem diese Gedanken verschwanden. Die Scan-Maschine geisterte durch meinen Kopf - sie war anders.
Beim näheren Hinschauen sah ich es: Da war ein GP2D02 Sensor auf dem URM37! Wo kam der her?

Nein, ich glaube nicht mehr an das Christkind. Doch in letzter Zeit fiel mir immer öfter auf, dass Programme plötzlich funktionierten, oder Kabel richtig gesteckt waren, obwohl ich am Vortag noch Fehler drin hatte.
Was geht hier vor? Passiert Euch das auch öfter? Habt Ihr auch manchmal den Eindruck Euer Rechner hat einen besonders guten oder besonders schlechten Tag? Dinge verändern sich, ohne Euer Zutun? Programme verschwinden oder tauchen auf? Ich glaube, das ist kein Eindruck, ich glaube sie machen das selbst.Und die Scan-Maschine hat sich einen neuen Sensor aufgepflanzt. Sie verändert sich, entwickelt sich weiter... sie - lebt?

HA! Gebt es zu - beinahe hättet Ihr es geglaubt, stimmts? Bei den Fummeleien mit dem URM37 ist mir eingefallen, dass ich noch ein paar von den GP2D02 rumliegen hatte. Dieser Sensor ist ein Distanzsensor der nach dem Triangualtionsprinzip arbeitet. Eine Sendediode, eine Empfangsdiode. Je stärker die Empfangsdiode leitet, desto näher ist das Objekt. Die messbare Distanz liegt zwischen 5 und 70 cm (laut Datenblatt 80cm). Der große Nachteil jedoch ist, dass der Output des Sensors nicht linear ist, d.h. die Auflösung in Größerer Distanz ist sehr niedrig und steigt mit sinkendem Abstand (siehe Graphik - Abstand auf X, Sensor-Out auf Y1).

Im Netz hab ich genügend Stoff gefunden, wie man sich am Besten einen Look-Up Table baut, um mit möglichst wenig CPU-Power die Umrechnung von Ausgabewert zu Distanz zu bekommen. Im wesentlichen funktioniert das so, dass man für bestimmte Abstände den rohen Sensor-Output aufzeichnet (blaue Linie) dann eine Funktion plottet (gelb) und die Parameter dieser Funktion so trimmt, dass der Fehler (least Squares - grüne Kurve) möglichst klein wird. Den Optimierungs-Bereich habe ich auf 10 - 70 cm eingestellt. Messungen in größeren Distanzen sind extrem ungenau und streuen stark.
Ich hab dann ein kleines Python-Script geschrieben, dass mit den gefundenen Funktionsparametern ein Header-File schreibt, das einen Look-Up Table enthält.
Damit ist eine Funktion realisierbar, welche die gemessene Distanz in [mm] ausgibt, nachdem man den Sensorwert rein steckt. Wenn jemand an Einzelheiten Interesse hat, stelle ich gerne alle Files zur Verfügung (weiß jemand, ob ich das Zeug an diesen Blog tackern kann?).

Danach bin ich wieder Ecken scannen gegangen, genauer gesagt - eine Ecke:

Die Ecken aus Sicht des URM37 sehen etwas schöner aus, dafür verrundet er die Geraden der Wand ein wenig stärker.
In Sachen GP2D02 zeigt die Ecke zwar eine deutliche Charakteristik, aber ein Sensormodell zu realisieren stelle ich mir extrem Schwierig vor - zumal auf einem Micro. Vielleicht könnte man den Sensor dazu gebrauchen, den Boden vor einem Roboter zu scannen und Stufen, etc. zu detektieren. Um ernsthaft an dieser Stelle weiter zu machen wären mehr Tests nötig. Unterschiedliche Oberflächen, Formen, Abstände, usw.

Doch hier mach ich die Biege und tüftel an den Akkus weiter. Ich brauche ein ordentliches Scheduling. Meiner Meinung nach liegt hier eine Schwäche im Arduino Konzept, da es keine direkte Unterstützung für Interrupt-Services gibt.

Übrigens - was mir gerade auffällt: der Look-Up Table sieht anders aus als gestern und der LCD-Text hat auch ein anders Layout...

Brauch mal ne Pause...

Das kann nicht gut sein, wenn man schon von Akkus träumt, wenn man in der Mittagspause Schaltpläne auf Servietten malt und bei schönstem Sonnenschein in der Werkstatt rumhängt.

Also dacht ich mir: Mach mal zwischendurch was anderes. Hab ich auch getan und den URM37 Ultraschall-Sensor aus der Kiste geholt, von dem ich zwei zum Abschied von meinen Arbeitskollegen bekommen habe (neben einen Haufen anderer Sachen - danke nochmal!)
Auf der Suche nach Beispielen stellte ich fest, dass die Seite von yerobot.com nicht erreichbar war, die Software von Miles Burton kleinere Bugs hatte und in der Doku ein Fehler in einer Formal war. Also alles ganz normal und kaum eine Stunde später spuckte das Teil die ersten Messungen aus. Die ersten Tests verliefen ganz gut und ich fragte mich, wozu der Servo-Ausgang gut ist.

In einem gut sortiertem Haushalt findet man immer ein Servo in irgend einer Schublade, und in der Werkstatt war schnell ein Winkel gezaubert. Der hausinterne Stardesigner Laurenzo de G kreierte das ultimative Testfahrzeug dazu und fertig war die monstermäßige Scan-Maschine.

 

Kann der Sensor Ecken scannen? Im Diagramm unten sind ein paar Sprünge zu erkennen. Der Scan stammt aus einer Ecke, drei mal abgetastet. Ich bin mir nicht mehr sicher, ob sich das Testfahrzeug dabei bewegt hat oder nicht, da die Wiederholgenauigkeit zu wünschen übrig lässt...

Beim Blick in die Software fällt auf, dass eine Menge Delays drin stehen. Außerdem sind die Abtast-Zeiten für kurze Distanzen sehr schnell und verlängern sich dann mit zunehmendem Abstand. Deshalb werde ich mir die Software nochmal vornehmen und vielleicht mein altes Scheduling-Konzept ausgraben, welches ich im Terence-Projekt entworfen hatte.

So ein bisschen Abwechslung macht schon Spaß!

JTAGICE-MKII clone

Ich habe ein neues Spielzeug: einen chinesischen Clone des AVR JTAGICE-MKII. War im Vergleich zum Atmel Original ziemlich günstig (ich hab noch weniger bezahlt, als die Sure-Homepage angibt...). Der Versand aus China dauerte ca. einen Monat und vor ein paar Tagen habe ich das Päckchen dann beim Zollamt gegen einen kleinen Obulus (Einfuhrumsatzsteuer) in Empfang genommen – Freude!

Viel habe ich noch nicht damit gemacht, aber ich wollte Euch das Ding trotzdem schon mal kurz vorstellen. Sieht von außen exakt aus, wie das Original:

I

Im Innern findet sich dann eine ganz ordentlich aussehende Platine: 

 

Ein wenig herumtracen ergab, daß die beiden Header oben rechts wohl JTAG Header für die beiden ATmega128A Chips sind, die auf dem Bord stecken (auch wenn ich noch nicht alle Pins zugeordnet habe). Ich hab die gleich mal bestückt. Leider habe ich kein zweites JTAG Gerät, sonst hätte ich auf diesem Weg vermutlich ein Firmware-Backup machen können (Hey Chris, Du brauchst doch bestimmt auch eins - oder? ;-)  ). Und mein Versuch, das Ding dazu zu bringen, die eigene Firmware auszulesen ist erwartungemäß gescheitert ;-)

First Light

Immerhin habe ich schon mal einen ersten Funktionstest gemacht: Arduino Flash auslesen im ISP-mode mit avrdude:

  avrdude -p m328p -c jtag2isp -P usb -U flash:r:flash.bin:r

...das ging wie eine Eins :-))

Was ich bisher nicht hingekriegt habe, ist das JTAGICE unter Avrstudio4 in Betrieb zu nehmen. Allerdings weist einiges darauf hin, daß das ein Problem mit der Virtualbox ist und nicht mit dem Gerät selbst. Muß das bei Gelegenheit mal mit einem nativen Windows probieren. OK – gelöst: war ein temporärer Schluckauf bei der Treiberinstallation. Nu gehts und ich habe bereits die Firmware mit AVR-Studio auf den neusten Stand gebracht. Im Gegensatz zu vielen anderen China-Clones läuft dieser nämlich mit der original Atmel Firmware.

Für einen richtigen Test muß ich mir aber erstmal irgendwas aufbauen – vielleicht mit meinem STK500. Der Arduino ist so out of the box weniger geeignet, denn da muß man erst einen Kondensator amputieren oder mindestens einen Trace kappen (je nach Modell) bevor der bei DebugWire mitspielt und dazu hatte ich heute keine Lust. Also muß ich nun wirklich was zum debuggen finden – zu dumm, daß meine Programme nie Bugs haben ;-)

Update

Inzwischen hab ich einen ATmega16 aus der µC Schachtel geholt und in das STK500 gesteckt. Noch den JTAG-Adapter drauf und ein bisschen herumprobiert und schon konnte ich ein kleines C-Programm via JTAG flashen und auch mit der Kombination avarice/gdb eine Debugging-Session starten. Funktioniert tatsächlich recht gut!  :-)

Jetzt muß ich nur noch meine rudimentären gdb Kenntnisse auf Vordermann bringen, dann ist kein Bug mehr vor mir sicher ;-)