Mist, flixter! Die Prototypen1-Anlage für die Werkstatt funktioniert in allen Belangen, nun sollten die ersten drei Prototypen2 erstellt werden für den Einbau im Haus, aber nix: es steckt ein Wurm drin! Die Anlage besteht wie beschrieben aus der zentralen Steuereinheit – Arbeitsname: ,,kell" – und den beiden Rundplatinen ,,rollk" und ,,rollp", die huckepack übereinander montiert sind. Als Letztes wurde das Steuerprogramm für den ,,rollk" einprogrammiert, dessen PIC tut auch was, aber leider nicht das Erwünschte. Und dabei ist dessen Prog quasi nur eine nur wenig geänderte Teilmenge desjenigen Progs, welches im Steuer-PIC prima seine Arbeit verrichtet. Die Hardware funktioniert bestens, ist mehrfach getestet, aber im Prog tummelt sich ein Wurm! Voll der Horror das! Im Simulator wurde mehrfach simuliert, und dort läuft alles so wie vorgesehen. Nur im PIC klappts nicht. Is klar, dass die Programm-Entwicklungs-Version die Nummer 13 trägt!
Grüße, picass

Es kann schon enervierend sein, nach der Nicht-Funktion in einer Schaltung den Fehler zu suchen!
Dieses gilt ganz sicher auch für den Fall, dass gar kein Fehler vorhanden ist. Tatsächlich war ich über meinen Versuch gestolpert, sorgsam vorzugehen und nach wichtigen Teil-Arbeitsschritten diese gleich zu prüfen, um nicht später in einer angewachsen und komplexeren Umgebung ganz kalt erwischt zu werden. Also wurde beim Erstellen der benötigten Gruppierung – bestehend aus gesamt drei Boards  - zunächst das Erste geprüft, der ,,kell-pic" und auch gleich das darauf laufende Prog. Alles Paletti. Dann das Duo ,,roll-pics", und vor dem Huckepack-Zusammenbau diverse Grundfunktionen jeder Platine. Alles gut. Dann der Huckepack-Bau und das Aufbringen des angepassten Progs und natürlich sollte dieses Huckepack-Duo sofort geprüft werden. Nix gut ! Das war echt nicht gut! Die Hardware war eher unverdächtig, aber das Prog machte, was es wollte, insbesondere verweigerte es die vorgesehene sofort anfängliche Sleep-Phase.

Muss gestehen, dass es mich erfolgreich verwirrte, weil im Simulator alles prima war, und es mir nicht gelingen wollte, den Fehler zu packen. Bis mir nach Einfügungen im Prog und dem Einbau von Kontroll-Leds es so nach und nach dämmerte, dass....
Der empfangende PIC im ,,Roll-Duo" sollte für den Test-Anfang nur auf zwei Ereignisse hin tätig werden, auf zwei Tastendrücke. Der war aber weit fleissiger als erwartet, schließlich schlummerte weiter hinten im Prog die schon für später vorgesehene Routine, welche den Port-Eingang abfragte.
Und dann hatte ich die Rechnung ohne den Wirt namens MAX gestellt! Weil ja nur das frische ,,roll-duo" quasi als frisches Teilprodukt auf evtl. frische Fehler untersucht werden sollte, wurde auch nur dieses Duo in Betrieb genommen. Will sagen: Das Dilemma begründete sich, weil sowohl der Bus als auch die Schaltzentrale als dritte Schaltung nicht mit im Bunde dabei waren. Der unbebusste Eingang des MAX war offen und lag wegen der MAX-Einstellung auf ,,0". Das produzierte dann eine ,,1" vom MAX zum PIC, und dieser arme, aber gute Kerl hielt das für ein Daten-Eingangssignal, wachte - kaum dass er überhaupt in den Schlaf gefallen war - auch sofort schon wieder aus seinem Schlummer auf und schon legte die für später vorgehaltene Bus-Abfrage-Routine los. Und die wartete nach dem Wecksignal auf das erste Daten-Bit und wartete und wartete.......

Hätte ich doch gleich das Dreierpack zusammengefügt, wäre dieser Schlammasel an mir vorüber gegangen. So hatte mir ausgerechnet das Bemühen um sorgfältiges Vorgehen und gründliche Kontrolle von Teilergebnissen diesen Bus- Strich durch die Rechnung gemacht.
Grüße, picass