Die I2C-Kommunikation mit einem Eeprom sollte eigentlich keine große Sache sein. Mittlerweile bin ich mir da nicht mehr so sicher. Der I2C-Bus 0 wird in der Bootphase dazu benutzt, um HAT-Produkte, die mit einem Eeprom ausgestattet sind, zu identifizieren. Dies nicht wissend habe ich, typisch Deutsch wie ich bin, die Verwendung dieses Busses anvisiert. Glücklicherweise hatte ich Lötbrücken vorgesehen und konnte so auf den Bus 1 ausweichen.
Ich als eingefleischter C-Freak bin natürlich in die nächste Falle getappt, 8 Longints auf 32 Byte zu verteilen, das war aus meiner Sicht nicht mit Schwierigkeiten verbunden. Bis zu dem Zeitpunkt als der erste Lauf meines Scriptes mich eines besseren belehrte. Offensichtlich war meine Vorbereitung auf die Verwendung der pigpio-Bibliothek doch nicht so gründlich, wie es notwendig gewesen wäre. Es hat lange gedauert, bis ich verstanden habe, dass die Crashes, die sich im Durchlauf entsprechender Bibliotheks-Funktionen ereigneten, nichts mit der Bibliothek selbst zu tun hatten, sondern auf der Verwendung eines unzulässigen Datenformats zu tun hatten, eine Python-Liste mit 32 Byte kann eben nicht durch ein Array von 32 Byte abgebildet werden, das ist ein fataler Fehler, der leider nicht sofort augenfällig wird.
Die Crashes sind stets an den Stellen entstanden, an dem die pigpio-Bibliothek die zu übertragenden Daten z.B. an die sendall-Funktion der socket-Bibliothek übergeben wollte, also außerhalb meines von mir erstellten Scriptes. Dazu kam noch anderes merkwürdiges Verhalten, was ich aber nicht weiter beschreiben will. Irgendwann hatte ich den Bogen heraus und es kam zu keinen weiteren Crashes mehr. Zwischenzeitlich hatte ich mal die smbus2-Bibliothek versucht, bin aber nachdem ich feststellen konnte, dass die smbus2-Bibliothek nur magere Fehlermeldungen absetzen konnte (wenn überhaupt) wieder reumütig zur pigpio-Bibliothek zurück gekehrt. Einen letzten Test hatte ich dann auch noch mit der zu Python gehörenden ureigenen smbus-Bibliothek gemacht. Den Erfolg eines Schreibversuches durch einen Leseversuch zu belegen, ist mir nicht gelungen.
Ich hab mich dann daran gemacht, die Internas der pigpio-Bibliothek zu studieren, was in VS Code nicht gerade lustig ist, Ja, einen "echten" Fehler hat die Bibliothek tatsächlich, der hat aber nichts mit meinem Problem zu tun. Die pigpio-Bibliothek ist alles andere als pythonistisch, was mir persönlich eigentlich egal ist, kommt sie doch mit Merkmalen daher, die sie mir als eingefleischter C-Freak äußerst sympathisch erscheinen lassen. Das eigentliche Problem ist aber die IDE, die so gar kein Verständnis dafür aufbringt. Kurzum, nach dem die pigpio-Bibliothek auf pythonistisch getrimmt war, konnte ich mich dem Studium der Bibliothek selbst widmen.
Heraus gekommen ist dabei aber eigentlich nichts, was zum dringend benötigten Erfolg geführt hätte. Einzig die Dokumentation der pigpio-Bibliothek ist schon phantastisch gegenüber der smbus2-Bibliothek. In der pigpio-Bibliothek fehlen aber leider an verschiedenen Stellen die Beschreibungen der returns, die ursächlich aus der Anwendung der socket-Bibliothek kommen. Jetzt kommen aber die Zweifel auf, ob das Eeprom in meiner Schaltung noch lebt. Dem entgegen steht der Test im Terminal, welche I2C-Clients verfügbar sind. Ein Versagen dieses Tests hätte die Motivation den IC auszutauschen sicherlich begründet, aber angesichts eine Pitches von 0,5 mm sank diese rapide wieder ab.
Der Versuch, im Internet die üblichen Verdächtigen zu finden, die sich mit dem Betrieb eines Eeproms in Verbindung mit einem Raspberry Pi auskennen, war bei mir bisher nicht erfolgreich. Ich kann zwar in den U.S.A. einen Händler finden, der ein entsprechendes Breakout mit MCP3208 und Eeprom anbietet - die Bibliothek, die er dazu anbietet, beschränkt sich auf den MCP3208, das Eeprom wird geflissentlich nicht behandelt.
Der Vorteil einer I2C-Kommunikation gegenüber SPI fällt nicht sonderlich ins Gewicht, wenn die Bauteile eng beieinander sitzen. Die Komplexität einer I2C-Kommunikation ist wesentlich größer, als die einer SPI-Kommunikation. Da ich meine Zusatzplatine ohnehin einer Revision unterziehen möchte, ziehe ich auch den Wechsel der Kommunikationsart in Betracht. Zunächst werde noch einen Versuch wagen, die Bit-banging-I2C-Kommunikation der pigpio-Bibliothek einzusetzen, die ich beim Studium der Bibliothek entdeckt habe, es sei denn, es findet sich hier im Forum eine andere Lösung.
