Kein I2C-Zugriff / bzw. Resonanz von TSL2561 Lichtsensor-Modul

  • Guten Morgen,


    ich versuche seit geraumer Zeit meine automatische Abendbeleuchtung zum Laufen zu kriegen. Ich scheitere aber daran, dass ich das Script (Quellcode später im Text) nicht ausführen kann - allgemeiner Grund: Ich kann nicht in die ic2-Adresse (0x39) des Sensors schreiben.


    Was habe ich gemacht?

    Ich habe die Steckkonfiguration mehrfach überprüft - und habe auch andere Kabel verwendet, um defekte Kabel auszuschließen.


    Ich habe mit dem Multimeter gemessen, ob Strom zwischen dem "Ende" und "Anfang" der Pins des Sensors ankommt - war erfolgreich. Oder ist relevant wieviel Widerstand erzeugt wird?


    Ich habe diverse Testprogramme (begonnen bei i2detect) bis hin zu Programmen aus dem WWW versucht.


    Nun - zur Technik:


    cat /etc/os-release



    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

    NAME="Raspbian GNU/Linux"

    VERSION_ID="10"

    VERSION="10 (buster)"

    VERSION_CODENAME=buster

    ID=raspbian

    ID_LIKE=debian

    HOME_URL="http://www.raspbian.org/"

    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"

    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"


    Ergebnisse meiner Tests:


    $ i2cdetect -l

    i2c-1 i2c bcm2835 (i2c@7e804000) I2C adapter


    Genauso ergänzend:


    i2cdetect -y 1

    0 1 2 3 4 5 6 7 8 9 a b c d e f

    00: -- -- -- -- -- -- -- -- -- -- -- -- --

    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

    70: -- -- -- -- -- -- -- --


    Nun - dieses Testprogramm habe ich verwendet (stammt von der Quelle, von der ich auch den Aufbau her habe)


    Und sobald ich dieses (oder diverse andere) Testprogramme für den o.g. Lichtsensor ausführe, kommt folgender Fehler:


    File "PIR_LED_Stripe.py", line 11, in <module>

    bus.write_byte_data(0x39, 0x00 | 0x80, 0x03)

    IOError: [Errno 5] Input/output error


    Nun meine Frage als besserer Laie - was sind Schritte, die ich noch unternehmen kann um mein Problem zu lösen?


    Ich freue mich auf jede Antwort.


    Herzlichen Dank! :daumendreh2:

  • Die Anleitung scheint für ein frühers System zu sein(Stretch oder Jessie) nicht für das aktuelle Buster


    Was steht in der /etc/modules ?

    Bei mir nur

    i2c-dev


    Was steht in der /boot/config.txt ?

    Bei mir

    dtparam=i2c_arm=on


    dtparam=audio=on (hat aber nix mit i2c zu tun)

  • Wenn das i2cdetect prinzipiell arbeitet, und darauf deutet die Ausgabe hin, dann ist das Problem nicht die Konfiguration von I2C via config.txt etc. Das ist dann ja schon da. Sondern es ist eher wie Tell schon bemerkt hat ein Problem der Verkabelung (SCA/SCL vertauscht?) oder der Hardware.


    Dieses Skript das zu da zeigst ist uebrigens katastrophal schlecht. Das mischt zwei Arten von GPIO Ansteuerung, startet selbstaendig einen Daemon, hat unsinnige Kommentare, raeumt nicht hinter sich auf, und frisst CPU. Das solltest du sofort wegschmeissen.

  • Ich habe zusätzlich (nach dem Motto "viel hilft viel") auch die Informationen aus meiner i2cdetect in die modules geschrieben:

    i2c-dev

    i2c-bcm2835


    Meine boot/config sieht nach neinem Empfinden auch "richtig" aus:


    # Uncomment some or all of these to enable the optional hardware interfaces

    dtparam=i2c_arm=on

    dtparam=i2c1=on

    #dtparam=i2s=on

    #dtparam=spi=on

  • Wenn das i2cdetect prinzipiell arbeitet, und darauf deutet die Ausgabe hin, dann ist das Problem nicht die Konfiguration von I2C via config.txt etc. Das ist dann ja schon da. Sondern es ist eher wie Tell schon bemerkt hat ein Problem der Verkabelung (SCA/SCL vertauscht?) oder der Hardware.


    Dieses Skript das zu da zeigst ist uebrigens katastrophal schlecht. Das mischt zwei Arten von GPIO Ansteuerung, startet selbstaendig einen Daemon, hat unsinnige Kommentare, raeumt nicht hinter sich auf, und frisst CPU. Das solltest du sofort wegschmeissen.

    Danke für die Rückmeldung.


    Die Qualität des Scripts konnte ich als Laie noch nicht bewerten - für mich geht es auch erstmal um eine generelle Funktionalität. Die Selbstoptimierung würde ich dann im Anschluss angehen.


    Also meine Vermutungen warum es nicht geht werden langsam rarer. Ich dachte


    a) ich habe schlecht gelötet (aber ich kann Stromfluss zwischen den Enden aller vier Pins messen)

    b) ich habe falsch gesteckt (habe ich mehrmals überprüft - auch SDA/SCL ist korrekt)

    c) Irgendeine Konfiguration ist falsch (scheint aber ja auch alles zu passen)

    d) Das Bauteil ist schlichtweg kaputt. Hier wäre vermutlich ein Neukauf die einzige Option...

  • Das problem bei I2C ist, dass stromfluss alleine nur bedingt aussagekräftig ist. Weil das zeitlich veränderliche Signale sind, wo noch andere Einflüsse zum tragen kommen können.


    Andere (oder mehrere derselben) I2C Geräte auszuprobieren ist ein weg. Die Investition in ein Oszillographen oder Logikanalyser ein anderer.

    Edited once, last by MistyFlower59469 ().

  • Okay - dann werde ich mir das Bauteil wohl einfach nochmal bestellen um auch dieses als Grund für den Defekt auszuschließen.


    Wie schwierig ist es denn, mehrere I2Cs parallel anzuschließen - bzw. wo finde ich hierzu gute Recherchegrundlagen?

  • In jeder Einführung zu I2C. Zb dem Original Phillips Dokument. Es ist speziell für dies Fall gemacht, weshalb es auch sehr einfach ist, mehrere ICs anzuschließen.

  • Hallo weonde,


    solange sich mehrere Stücke Hardware in der I2C-Adresse unterscheiden, kannst Du im Prinzip beliebig viele davon anschließen. Aber soweit bist Du noch nicht, solange Du mittels i2cdetect noch nicht mal ein einziges Teil am I2C hast entdecken können.


    Von mir gibt es hier einen Thread, wie ich mich zwei BME280 angenähert habe.Da ist eine Schaltung enthalten, wie man die I2C-Adresse einstellen kann (so es vorgesehen ist). Aber auf diese Weise ist der I2C-Adressraum recht reduziert.

    Dann gibt es andere I2C-Sensoren, deren I2C-Adresse man softwareseitig (einmalig) einstellen kann.


    Alles Weitere muss Dir in jedem Fall das Datenblatt verraten.



    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Edited once, last by Andreas ().

  • Hallo,


    ich habe mittlerweile weitere Tests mit einem anderen I2C-Gerät durchgeführt (AZDelivery 0,96 Zoll OLED Display).


    Ich habe die absolute Minimal-Konfiguration gewählt:

    Original-USB-Kabel und vier (ebenfalls neue) Stecker für das Display.


    Es funktioniert leider weiterhin nichts - und langsam setzt wirklich Frust ein. Was könnte denn noch alles zu prüfen/falsch/kaputt sein?

  • Der Pi kann auch kaputt sein. Ich habe einen hier, an dem ich das I2C gegrillt habe.


    Meiner Meinung nach kann man solche Projekte ohne Diagnostik nicht wirklich sinnvoll fahren. Es gibt preiswerte und gute Logikanalyser für ~60€, oder auch kleine billige Oszis mit denen man wenigstens erkennen kann, ob überhaupt was auf der Leitung passiert.


    Die Eingänge des Pi sind recht wenig robust. Das liegt an seiner Herkunft (set top box, kein Produkt für Endkunden). Echte Microcontroler wie der Arduino sind viel robuster. Und daher bei solchen Projekten auch mal einer Fehlverkabelung oder statischer Aufladung tolerant gegenüber. Der PI zickt dann schonmal. Kann man scheisse finden. Aber nicht ändern.


    Wenn du selbst in diese Diagnostik nicht investieren willst, such dir jemand in der Nähe, der sie hat. Und da mal drauf schauen mag.

  • Ich fürchte, dass auch hier nach veralteten Anleitungen ein Treiber (=Modul) nunmehr mehrfach geladen wird und verschiedene I/O Adressen vergeben werden.


    Da sich auch die I2C Module geändert haben und nur mehr Device-Tree-Overlay verwendet werden soll, ist nur die am aktuellen System installierte "Anleitung", das ist die Datei /boot/overlays/README, gültig. Dort sind auch die einkompilierten default-Einstellungen ersichtlich.


    Imho gilt derzeit (Pi-OS) in config.txt:

    dtparm=i2c=on

    dtoverlay=i2c1 [default GPIO 2,3]


    Alles andere gehört raus/deaktiviert


    Wenn am Pi 4 mehrere/andere I2C Master verwendet werden sollen, stehen i2c3 bis i2c6 (mit der in README ersichtlichen GPIO Kombination) zur Verfügung.



    Servus !

    RTFM = Read The Factory Manual, oder so