Bei dem Sensor soll man laut Datenblatt (s. Bild u. Code) duch Schreiben
in zwei "unlock register", gefolgt von der neuen I2C-Adresse, die
Adresse ändern können. Dass es eine gerade Adresse sein muss, hab ich
auch beachtet und die Code-Beispiele stammen von der Webseite des
Herstellers.
Das Problem: Die I2C-Adresse ändert sich nicht. Der Code wird zwar ohne
Fehlermeldung ausgeführt, aber sonst passiert nix. Was kann man tun?
I2C verwendet so gut wie immer 7-Bit-Adressen. Wenn in einer
Beschreibung Adressen > 127 auftauchen, liegt eine 8-Bit-Darstellung
vor, die das Schreib/Lesebit in die Adresse integriert.
Mit großer Wahrscheinlichkeit erwartet Deine Wire-Bibliothek aber
7-Bit-Adressen ohne Schreib/Lesebit.
Du musst also die verwendeten Adressen durch zwei teilen.
Daß Du keine Fehlermeldung erhältst, ist kein Wunder; wer sollte die
erzeugen und wohin ausgeben?
Frank E. schrieb:> Der Code wird zwar ohne Fehlermeldung ausgeführt, aber sonst passiert> nix. Was kann man tun?
Das ist doch schon sehr verdächtig.
Wenn der Baustein sich angesprochen fühlen würde, müsste er mit einem
Acknowledge auf dem Bus reagieren.
Statt auf die Bits zu gucken, könntest du das auch einem I2C-Scanner
überlassen, der dir sagt, auf welchen Adressen irgendein I2C-Slave
reagiert. Den Code dafür auf deinen µC zu schieben, ist eine Sache von
ein paar Sekunden.
Wolfgang schrieb:> Frank E. schrieb:>> Der Code wird zwar ohne Fehlermeldung ausgeführt, aber sonst passiert>> nix. Was kann man tun?>> Das ist doch schon sehr verdächtig.> Wenn der Baustein sich angesprochen fühlen würde, müsste er mit einem> Acknowledge auf dem Bus reagieren.>> Statt auf die Bits zu gucken, könntest du das auch einem I2C-Scanner> überlassen, der dir sagt, auf welchen Adressen irgendein I2C-Slave> reagiert. Den Code dafür auf deinen µC zu schieben, ist eine Sache von> ein paar Sekunden.
Hab ich schon gemacht, der I2C-Scanner liefert immer nur 224 und darüber
kann ich auch messen. Da ich aber 3 von den Sensoren verwenden möchte,
habe ich auf diese Adressänderung gesetzt, die nicht funktionieren will
(auch mit 7-Bit Adresse 120 und kleiner nicht).
Ich werd' jetzt mein Glück mit Software-I2C versuchen: 1 gemeinsame
Taktleitung und 3 getrennte SDA's, sind dann zum Glück nur 2 Pins mehr
als sonst :-(
>Da ich aber 3 von den Sensoren verwenden möchte,>habe ich auf diese Adressänderung gesetzt, die nicht funktionieren will
und wie hättest du einen dieser drei exklusiv ausgewählt?
dummschwaetzer schrieb:> und wie hättest du einen dieser drei exklusiv ausgewählt?
In den man die 3 x initialisiert mit ihrer jeweiligen Adresse.
sensor1.init(Adresse_1)
sensor2.init(Adresse_2)
sensor3.init(Adresse_3)
Und dann jeden Sensor DIREKT via Sensor*. anspricht.
Das macht man doch mit anderen Teilen auch so.
Frank E. schrieb:> Ich habe als neue Adresse 220 versucht, Standard ist 224 und bleibt> unverändert.
Original-Chip auf Original-Board? Oder irgendein Clone, bei dem das
EEProm weggespart wurde?
Frank E. schrieb:> Ich werd' jetzt mein Glück mit Software-I2C versuchen: 1 gemeinsame> Taktleitung und 3 getrennte SDA's, sind dann zum Glück nur 2 Pins mehr> als sonst :-(
TCA9548A, PCA9546A &co erschlagen das Problem auch ohne Zusatz-Pins.
Frank E. schrieb:> Da ich aber 3 von den Sensoren verwenden möchte,> habe ich auf diese Adressänderung gesetzt, die nicht funktionieren will> (auch mit 7-Bit Adresse 120 und kleiner nicht).
Häng einen Logikanalysator auf den Bus und guck dir genau an, was
passiert.
Kommt bei den Zugriffen für die Adressänderung ein Ack?
Wenn du auch noch sehen willst, wer SDA runter zieht, kannst du dazu
einen Widerstand zwischen Master und Slave in die SDA-Leitung hängen und
mit dem Oszi die L-Pegel angucken.
Frank E. schrieb:> Ich habe als neue Adresse 220 versucht, Standard ist 224 und bleibt> unverändert. :-(
Und du bist ganz sicher, dass deine Wire-Implementation keine 7-Bit
I2C-Adressen nach I2C-Standard verwendet?
Zumindest die Standard Arduino Implementation verwendet 7-Bit Adressen
und kann folglich mit Zahlen über 127 nichts anfangen.
https://www.arduino.cc/reference/en/language/functions/communication/wire/
Wolfgang schrieb:> Hier ist ein Beispiel, wo die I2C-Routinen ein fertiges 8-Bit> Adressbyte> (7Bit Adresse und R/W-Bit) erwarten.> https://www.danielealberti.it/2019/09/gy-us42v2-e-arduino-sensore-di-distanza.html
Ja, das ist ganz genau der Code, der auch auf der Herstellerseite
gezeigt wird und von dem aus ich meine Gehversuche mache. Nur, wie
bereits geschrieben, das "address change example" hat genau Null
Wirkung.
Wahrscheinlich bin ich auf einen Clon hereingefallen, obwohl die
Bestückung der Platine äußerlich identisch aussieht. Allerdings ist mein
PCB schwarz, nicht Magenta.
Frank E. schrieb:> Ich habe als neue Adresse 220 versucht, Standard ist 224 und bleibt> unverändert. :-(
falsch Standard ist 224 >> 1 es hat schon seinen Grund warum nur gerade
Adressen erlaubt sind. Wire erwartet 7 Bit + RW. Das haben adere ja
schon geschrieben.
Wenn du schon mit 8 Bit Werten arbeiten willst probier mal
Wire.beginTransmission(old_addr >> 1);
dann wirds vermutlich gehen
Schlaumaier schrieb:>> und wie hättest du einen dieser drei exklusiv ausgewählt?>> In den man die 3 x initialisiert mit ihrer jeweiligen Adresse.>> sensor1.init(Adresse_1)> sensor2.init(Adresse_2)> sensor3.init(Adresse_3)>> Und dann jeden Sensor DIREKT via Sensor*. anspricht.>> Das macht man doch mit anderen Teilen auch so.
Ist mir immer noch ein bischen unklar. Du hast am Anfang 3 Sensoren mit
derselben Adresse. Wie willst du da genau einen davon auswählen?
Frank E. schrieb:> Ja, das ist ganz genau der Code, der auch auf der Herstellerseite> gezeigt wird und von dem aus ich meine Gehversuche mache.
Was für Bibliotheksroutinen verwendest du für die I2C Zugriffe. Sind das
die aus der standardmäßigen Wire Bibliothek vom Arduino Framework oder
ist das etwas selbstgestricktes?
Wenn du sagst, dass du versuchst, den Sensor über die Arduino Wire
Bibliothek unter 224 anzusprechen, ist das IMHO falsch, weil die
Bibliothek I2C-Adressen nach I2C-Standard (7-Bit) erwartet. Guck mit
Oszi oder LA auf das Ack-Bit, ob der Sensor sich von deinen Versuchen
überhaupt angesprochen fühlt.
Das oben von mir verlinkte Beispiel zur Adressänderung benutzt
I2C-Funktionen, die vom Sprachgebrauch her nicht dem I2C-Standard
entsprechen, sondern als Adressparameter 8 Bit Werte erwarten (=
I2C-Adresse << 1).
https://www.danielealberti.it/2019/09/gy-us42v2-e-arduino-sensore-di-distanza.html
Dieser Beispielcode ist, wie bereits weiter oben geschrieben, auch auf
der Originalseite des Sensor-Herstellers angegeben. Die dort enthaltene
Funktion zum Ardesswechsel funzt einfach nicht.
Ich habe den Code in keiner Weiser verändert. Ich habe auch die im
Beispiel angegebene SoftI2C-Lib installiert und verwendet.
Frank E. schrieb:> Dieser Beispielcode ist, wie bereits weiter oben geschrieben, auch auf> der Originalseite des Sensor-Herstellers angegeben. Die dort enthaltene> Funktion zum Ardesswechsel funzt einfach nicht.
ok du hast alles richtig gemacht. Dann ist das halt so und du musst dir
einen anderen Baustein suchen. Vieleicht findest du ja auch einen der
mit 8 Bit Adressen umgehen kann.
Warum schaust du nicht mal in die Arduino Hilfe zu Wire.
https://www.arduino.cc/reference/en/language/functions/communication/wire/begintransmission/
Dort steht ganz klar dass die 7 Bit erwarten.
> Wahrscheinlich bin ich auf einen Clon hereingefallen, obwohl die> Bestückung der Platine äußerlich identisch aussieht.
So wird das wohl sein.
dummschwaetzer schrieb:>> Das macht man doch mit anderen Teilen auch so.>> Ist mir immer noch ein bischen unklar. Du hast am Anfang 3 Sensoren mit> derselben Adresse. Wie willst du da genau einen davon auswählen?
Die ICs wird man vor dem Bestücken programmieren oder auf der
Leiterplatte Prüfstecker vorsehen müssen, jeweils zwei zu sperren.
Für industrielle Serienproduktion ist es üblich, Bausteine bereits vor
der Bestückung zu programmieren.
Hier übrigens noch ein Zitat aus dem Datenblatt:
I2CXL-MaxSonar-EZ Default Address
The representation of the sensor address will be different depending on
the addressing scheme your master device uses.
The chart below shows the default address for the I2C-MaxSonar-EZ
sensors under different addressing implementations.
Elsewhere in this datasheet a 8-bit read/write addressing scheme is
assumed.
Frank E. schrieb:> Ich habe den Code in keiner Weiser verändert. Ich habe auch die im> Beispiel angegebene SoftI2C-Lib installiert und verwendet.
Hast du irgendein Gerät, um zu gucken, was auf dem Bus passiert, wenn du
versuchst den Baustein anzusprechen (=Antwort mit Ack auf SDA oder
nicht)?
> Ich habe als neue Adresse 220 versucht, Standard ist 224 und bleibt> unverändert. :-(
Mit diesem Funktionsaufruf geht es vermutlich. Aber saudumm geschriebene
Funktion.
changeAddress(224>>1, 220, 0)
Hier mal eine Rückmeldung.
Ich habe für die versuchten Adressänderungen immer den Original-Code von
der Webseite des Herstellers benutzt.
Da gibt es ein schönes Beispiel-Programm, in dem die Distanz (es handelt
sich um Ultraschall-Entfernungsmesser) zunächst von der Standardadresse
abgefragt wird, dann folgt ein Befehl zur Adressänderung, ein erneutes
Abfragen und zuletzt der Reset zur Standardadresse.
Ich glaube ja nicht, dass die Leute, die diesen Code erstellt haben,
dumm sind oder Unsinn schreiben. Bei ihnen hat es anscheinend
funktioniert ... bei mir (scheinbar) nicht. Jeglicher Leseversuch von
anderen als der Standardadresse war erfolglos.
Bis hierhin wäre die Rückmaldung ja sinnlos, also ist doch etwas
passiert:
Als ich aus lauter Verzweiflung mal eine I2C-Scanner-Software auf meinen
Arduino load und die 3 Ultraschall-Sensoren an den I2C-Bus anschloss,
erlebte ich echt mein "blaues Wunder"! Alle drei Sensoren wurden
plötzlich unter jeweils unterschiedlichen Adressen gefunden! Keine der
Adressen war eine, die ich versucht hatte zu vergeben, auch nicht um 1
größer oder kleiner oder z.B. exakt die Hälfte.
Ich habe nicht die geringste Ahnung, wie es dazu kam. Aber egal, keine
der 3 Adressen beisst sich mit meinen anderen Busteilnehmern und ich
nehm' sie erstmall einfach so, wie sie sind ... :-)
Thread beobachten
Seitenaufteilung abschalten