Problematische I2C-Kommunikation mit einem Eeprom

  • 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.

  • Erstmal sorry, ich habe Deinen Beitrag nur überflogen!

    Du schreibst leider nicht, welchen RPi Du verwendest. Am RPi5 gibt es aufgrund eines anderen Chips, soweit ich mich richtig erinnere, Probleme mit pigpio und sollte dort nicht mehr verwendet werden.

    Doch ganz oben, unter dem Titel eingetragen 3B+ / 64 bit :)

  • Moin Batucada2,

    Der I2C-Bus 0 wird in der Bootphase dazu benutzt, um HAT-Produkte, die mit einem Eeprom ausgestattet sind, zu identifizieren

    Und das steht wo geschrieben?

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Und das steht wo geschrieben?

    Moin,

    das ist wie immer, wenn man Tante Google befragt, Gelegenheitsfunde wie entweder HIER oder HIER, ich hab nicht gezielt danach gesucht, vor etwa zwei Wochen fiel ich dann aus allen Wolken. Gestern war es ein letzter Versuch, doch noch eine Anleitung zu finden, die schon einmal zum Erfolg geführt hat. Um dir zu antworten, hab' ich das HIER gefunden:

    Quote

    The automatic configuration is achieved using 2 dedicated pins (ID_SD and ID_SC) on the 40W B+ GPIO header that are reserved for an I2C EEPROM.

  • Warum nimmst du denn nicht einfach C wenn du ein eingefleischter C-Freak bist?

    https://www.kernel.org/doc/Documentation/i2c/dev-interface

    Guten Morgen lieber Tell,

    Danke für den Hinweis. Von dem ich annehme, dass du das dort Geschriebene selbst nicht kennst:

    Quote

    Note that only a subset of the I2C and SMBus protocols can be achieved by the means of read() and write() calls. In particular, so-called combined transactions (mixing read and write messages in the same transaction) aren't supported. For this reason, this interface is almost never used by user-space programs.

    Das hat bei mir den letzten Zweifel ausgeräumt, ob ich unter Python die I2C-Kommunication überhaupt noch weiter verfolgen soll. Jetzt habe ich 2 Möglichkeiten:

    • entweder von der I2C-Kommunication abzulassen und diese durch eine SPI zu ersetzen
    • oder ich entscheide mich dafür, ein C-Objekt in Python zu integrieren.

    Die dritte Möglichkeit, das ganze Projekt in C zu schreiben, schließe ich mal aus, weil ich froh bin, die QT-Klippen umschifft zu haben.

    Ich habe mich jetzt spontan dafür entschieden, jeden weiteren Versuch der I2C-Kommunication ab sofort zu unterlassen und stattdessen eine SPI-Kommunikation aufzuziehen. Na ja, so ganz spontan war es nun doch nicht, ich habe im Verlaufe des Debakels schon nach geeigneten ICs gesucht, die in den beiden Gehäuseformen PDIP8 und SOIC-8 verfügbar sind. Mit PDIP8 könnte ich bei vorhandener Platine einen fliegenden Aufbau inszenieren, den ich später in einem regulären Aufbau mit SOIC-8 versehe.

  • Ich möchte mal auf Wie frage ich nach Hilfe? hinweisen. Es fehlen die grundlegenden Informationen um da helfen zu können. Um welchen Chip handelt es sich denn überhaupt? Link zum Datenblatt wo drin steht wie mit dem Chip über I²C kommuniziert werden muss. Das ist ja nicht bei allen Chips gleich, wie beispielsweise die Adresse festgelegt wird. Ob das ”einfach so” geht, oder ob der Chip ein einleitendes Kommandobyte erwartet, und wenn ja welches. Und dann fehlt das was versucht wurde. Also der konkrete Code und nicht sehr vage Umschreibungen. So wie die Frage jetzt da steht (wobei auch in dem ganzen Text kein einziges Fragezeichen vorkommt) kann man nicht viel mehr sagen, als „irgend etwas machst Du wohl falsch“.

    “On the eighth day, God telephoned his lawyers and began asking all sorts of questions about product liability.” — Tom Holt, Overtime

  • Dass du dich mit deiner säuerlichen Sprache wieder einfindest, damit musste ich rechnen, Herr Oberlehrer, aber scheinbar bist du zu dumm, um dich taktvoll zurück halten zu können. Deine Sprache ist mir sattsam bekannt. Du tust so, als wenn du Hilfe anbieten könntest, davon aber bist du weit entfernt, dies wirklich zu tun. Deswegen hast du ein weiteres Attribut verdient: scheinheiliger Oberlehrer! In der Forumssuche habe ich etliche Seiten zum Thema Eeprom durchgeackert, nicht einmal bist du als Ratgeber aufgetaucht. Behandle mich daher nicht wie einen Rotzjungen, der angeblich keine Fragezeichen kennt. Scheinbar bist du darauf aus, mich aus dem Forum zu vergraulen. Wenn du zu Ende gelesen hättest, zumindest meinen letzten Beitrag zur Kenntnis genommen hättest, dann wäre dir bewusst, dass es keine Fragezeichen mehr gibt.

    Den besten Tipp hab' ich von Tell bekommen, weil er das bestätigt, was ich schon länger vermutet habe.

    Danke lieber Psychopath, du hast meinen Sonntag gerettet 🤣🤣🤣🤣🤣

  • Welche „säuerliche Sprache“? Das war ein sachlicher Hinweis darauf das wichtige Informationen fehlen und welche das unter anderem sind. Ich habe da nichts von „Rotzjunge“ geschrieben. Und im Gegensatz zu Dir habe ich da keine Dummheit unterstellt, oder Scheinheiligkeit, und ich habe Dich auch nicht Psychopath genannt. Das klingt alles ein bisschen „säuerlich“.

    Vielleicht liegt das auch an dem voreingenommenen Bild was Du anscheinend von mir hast. Welche Antwort auf eine Frage könnte ich denn geben ohne das Du gleich reflexartig den „Oberlehrer“ ablehnst? Keine? Dann liegt das nämlich nicht an meinen Antworten, sondern an Dir. Du willst die anscheinend so auffassen das ich der „Oberlehrer“ sein muss. Und Dir nur schlechtes will. Versuch mal Beiträge neutraler zu lesen.

    Ich will Dich ganz sicher nicht vergraulen. Ich wollte helfen die Frage besser, oder überhaupt zu formulieren, so dass sie sinnvoll beantwortwortbar wird. Und nicht nur wegen diesem Thema, denn das die wichtigen Informationen fehlen ist ja nicht das erste mal das Problem. Wäre schön wenn Du das auch in Zukunft bei Fragen berücksichtigen würdest. In Deinem Interesse.

    “On the eighth day, God telephoned his lawyers and began asking all sorts of questions about product liability.” — Tom Holt, Overtime

  • wenn du sachlich argumentieren willst, dann musst du zunächst einmal von den Standpunkten abrücken, von denen du glaubst, das dein Helfersyndrom es dir gestattet, deine Fragen in Form oberlehrerhaftiger Vorwürfe zu äußern. Ich unterstelledir das deine Beteiligung in diesem Faden zunächst einmal gar nicht auf Hilfe ausgerüstet ist, sondern dient nur dazu Stunk zu machen und du weißt offenbar genau, wie du dich dabei in Szene zu setzen hast. Lass dir doch einfach mal das Zitat aus #7 durch den Kopf gehen, dann weißt du, wie dümmlich deine Art auf mich wirkt. Ich unterstelle dir einfach die Absicht, mit deiner dümmlichen Anmache den Faden stören zu wollen, in dem Falle ist es mir wurscht, weil das Thema ohnehin gegessen ist.

  • Solange ich sachlich argumentiere muss ich von gar keinen Standpunkten abrücken. Zumal so einige ”meiner” Standpunkte ja nur aus Deinen Unterstellungen bestehen, davon kann ich nicht abrücken, weil ich die gar nicht habe. Deswegen ja der Vorschlag, dass Du da mal ein bisschen entspannter und unvoreingenommener an die Sache gehst, und nicht immer gleich in die Luft.

    “On the eighth day, God telephoned his lawyers and began asking all sorts of questions about product liability.” — Tom Holt, Overtime

  • Moin Batucada2,

    danke für deine Ausführungen.
    Leider hast du nicht geklärt, welche Pins der GPIO du nutzt, noch hast du gezeigt, was du alles in der config.txt geändert hast.
    Aus diesem Grund kann ich @__blackjack__'s Beitrag #8 nur zustimmen. Bei einem Beitrag mit der Bitte im Hilfe sollte man schon die relevanten Daten bekannt geben.

    Nur eine Kenner der Raspberry Pi-Hardware und der Bezeichnungen dafür, erkennt das der "I2C-Bus-0" oder besser "/dev/i2c-0" die GPIO-Pin 27(GPIO0) und GPIO-Pin 28(GPIO1) gemeint sind.
    Diese Schnittstelle muss auch mit einen bestimmten Eintrag in der config.txt frei geschaltet werden.
    Die normale I2C-Schnittstelle Pin3(GPIO2) und Pin5(GPIO3) zeigt das Verhalten nicht!

    Es wäre also schön, wenn du dein Ziel und deine bisherigen Aufwendungen, mal schreiben würdest. Wenn du noch Hilfe möchtest.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Wer lesen kann, ist klar im Vorteil! Ein alt bekannter Spruch. Wer darüber hinaus das Gelesene auch noch versteht, der ... - Jeder der mag, soll diesen Satz für sich vervollständigen. Mein Eröffnungsbeitrag war eher als die Beschreibung eines Leidensweges gedacht als ein Hilferuf. So hatte ich meinen Beitrag gestartet:

    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.

    Daraus geht eigentlich ganz klar hervor, mit welchem Bus ich mein Unterfangen gestartet habe. Es ist sinnlos, etwas weiter hervorheben zu wollen, was ich schon längst im TO beschrieben habe. Bevor ich das Projekt gestartet hatte, habe ich mir eine Arbeitsgrundlage errichtet. In dieses Papier, das mehr als nur das Nachfolgende enthält, gewähre ich nun die Einsicht in eine Header-Liste des Raspberry.

    Diese Liste und damit das Papier im allgemeinen habe ich nun im Laufe des Projektes gepflegt und immer wieder mit Wissen oder Ergänzungen angefüllt. Daraus sollte eigentlich hervorgehen, dass ich mein Projekt nicht sonderlich blauäugig und hemdsärmelig gestartet habe. Das auch die Datei /boot/config.txt angepasst werden muss, war aber mehr als selbstverständlich, weil dies bezügliche Hinweise massiv zu finden sind.

    Auch die SuFu des Forums konnte da im Laufe des Erfahrungsweges keine erhellenden Momente erzeugen, einzig die Erkenntnis, dass die Vielzahl der hilferufenden Benutzer der I2C-Kommunikation irgendwelches Sensor-Gedöhns (das meine ich jetzt NICHT abwertend) betreiben wollten, kein Ton zu Problemen eines Eeproms auf dem I2C-Bus war dabei zu hören. Wie dem auch sei: wer keine Fragen stellt, kann auch keine Antworten erwarten, darum hatte ich zum Schluss diesen Faden gestartet. Die beste Antwort in der Sache hat Tell geliefert, wenn auch nicht in seiner von ihm beabsichtigten Form. Und wenn man gezielt weiter sucht, bekommt man auch Hinweise, wie man mit Hilfe eines C-Programms ein Eeprom flashen kann, um später die HAT-Identifizierung auszunutzen - na denn, warum ein "niederes" C-Programm benutzen, wenn es doch mit einer "höheren" Programmiersprache wie Python eigentlich doch viel besser gehen sollte? <-- Auf dieses Fragezeichen bitte nicht antworten, ich habe meine Schlüsse gezogen. Es sei denn, jemand hat konkrete positive Erfahrung mit dem Schreiben von Eeproms auf den I2C-Bussen auf dem Raspberry Pi unter Anwendung eines Python-Scriptes gemacht. Ich gehe davon aus, es wird sich niemand melden.

  • Batucada2 Warum sollte das in Python viel besser gehen als in C? Du hast ja pigpio benutzt, und selbst den Python-Code erwähnt, der Sockets benutzt. Um mit der in C geschriebenen Bibliothek zu kommunizieren, die letztlich über I²C mit dem EEPROM kommuniziert. Python hat in dieser Konstellation gar keinen direkten Kontakt mit dem I²C-Protokoll.

    “On the eighth day, God telephoned his lawyers and began asking all sorts of questions about product liability.” — Tom Holt, Overtime

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!