Induktiver Sensor antwortet nicht auf I2C

[Jonatan (jonatan31)]

Moin,

Ich baue gerade eine Platine, welche einen Abstand im Mikrometer Bereich 
messen soll.
Hierfür habe ich mir die Methode ausgesucht, die Induktivität einer 
Spule in ein digitales Signal zu wandeln, die sich ja verändert, wenn 
ein Metall-Target der Spule näher kommt.

Hierfür gibt es den LDC1612 von TI, der genau diese Umwandlung in einer 
sehr hohen Auflösung durchführen kann.
Ich habe diesen Sensor zusammen mit einem S32k144 Mikrocontroller (auf 
dem FreeRTOS läuft) und der entsprechenden Peripherie auf eine Platine 
gebaut.

Nun habe ich versucht den LDC mit einer I2C Nachricht anzusprechen, 
erhalte jedoch ausschließlich NACK.

Die Versorgungsspannung ist sauber, genau wie das Ground.
Die Clock liefert ebenfalls ein für den LDC richtiges Signal.

SDA und SCL werden vom Mikrocontroller ebenfalls richtig angesteuert, 
wie man im angefügten Auszug meines Logic Analyzers sehen kann.

Es lässt sich nicht ganz ausschließen, dass der LDC tatsächlich richtig 
kontaktiert, ich habe jedoch bereits 5 LDCs aufgelötet, mit Lötofen, mit 
Heißluftfön und mit Lötkolben, je ohne Erfolg.

Ich habe keine Idee mehr, wo der Fehler noch liegen könnte und bin 
dementsprechend für jede Hilfe dankbar.

Lg, Jonatan


[1] Paper zum Sensor 
https://www.sciencedirect.com/science/article/pii/S2405896322029093?ref=pdf_download&fr=RR-2&rr=9d592cb91d5c9758

[2] Paper zur anwendung des Sensors 
https://www.sciencedirect.com/science/article/pii/S0378775317310686

[3] Datenblatt des Sensors 
https://www.ti.com/lit/ds/symlink/ldc1614.pdf?ts=1772380657724&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FLDC1614

[H. H. (hhinz)]

Und wie hast DU ihn beschaltet?

[Andras H. (andras_h)]

ADDR pin high oder low? 0x2B versucht? Manche verstehen den RW bit auch 
inklusive adresse manche nicht. Mal versuchen 0x2A oder 0x2B durch 2 
teilen.

Schematic posten wird auch helfen.

[Helmut -. (dc3yc)]

Keine Prosa schreiben. Das versteht man nicht. die Sprache der 
Elektronik ist der SCHALTPLAN!

[Helmut -. (dc3yc)]

Andras H. schrieb:
> Mal versuchen 0x2A oder 0x2B durch 2
> teilen.

Wenn ich das DaBla lese, eher mal 2 nehmen!

[Ron-Hardy G. (ron-hardy)]

Andras H. schrieb:
> Mal versuchen 0x2A oder 0x2B durch 2
> teilen.

nicht doch besser *2?

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

PULL am SCL ?

[Jan (dunno)]

Pull-ups an SDA und SCL vorhanden und sinnvoll dimensioniert..?

Wie sehen die Signale am Oszi aus? -> der LSA ist Imho erst der zweite 
Schritt, nachdem klar ist dass die Flanken schön sauber sind, 
Anstiegszeit passt etc.

[Mario M. (thelonging)]

Helmut -. schrieb:
> mal 2 nehmen!

Genau. Der LA zeigt nur 0x15 als 7-Bit-Adresse. Das ist falsch.

[H. H. (hhinz)]

Mario M. schrieb:
> Helmut -. schrieb:
>> mal 2 nehmen!
>
> Genau. Der LA zeigt nur 0x15 als 7-Bit-Adresse. Das ist falsch.

ACK! Das übliche Missverständnis...

[Jonatan (jonatan31)]

Ich verstehe nicht ganz, was das Problem ist.
Soll ich statt 2a jetzt 54 als adresse senden?
Falls ja, wieso zeigt der logic analyzer eine falsche bzw. halbierte 
Adresse an?

Edit: Ich habe jetzt die Adresse um ein bit geshiftet und auch die 
einstellung gefunden um es richtig anzeigen zu lassen. Mit 54 als 
Adresse also 2a um 1 geshiftet bekomme ich aber immernoch NACK.

[Wastl (hartundweichware)]

Ein ganzes Betriebssystem um einen Sensor zu lesen. Boaaahh...

Zeige bloss nicht den Sourcecode des Programms, der könnte
die Leser und potentiellen Helfer verwirren.

[Hans W. (hanswieland)]

Jonatan schrieb:
> Soll ich statt 2a jetzt 54 als adresse senden?

Nein, du sollst 0x2A als Adresse senden.

Da die Adresse in den oberen 7 Bit des ersten Byte steckt, hat das erste 
Byte den Wert 0x54. Aber nur beim Lesen. Bei Schreibzugriffen hat das 
erste Byte den Wert 0x55.

> Mit 54 als Adresse also 2a um 1 geshiftet bekomme ich aber
> immernoch NACK.

Dann lasse einen Port-Scanner laufen. Bei Arduino ist das ein der 
Beispiel-Sketche.

Du könntest auch einen PC mit I²C Adapter dran hängen und damit scannen. 
Das ist besonders einfach unter Linux mit den i2c-tools und einem 
ATtiny85 als Adapter. Siehe angehängte Firmware.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

Im Layout ist das routing für SCL (pin 1)  und SDA (pin 2) nicht 
besonders optimal, das sollte man auf jedenfall mal mit einen Oszi statt 
LA schauen wie die signal integrity ausschaut.

BTW: Layout mit eingeblendeten Pin-nummern wäre sehr hilfreich wenn ein 
Fremder da ein Review machen soll, Schaltplan ohnehin.
Und für meinen Geschmack sollte man floatende Pins im layout vermeiden, 
auch wenn das Datenblatt es gestattet, z.Z. zähle ich zwei Pins ohne 
Beschaltung.



Das mit der device-adresse wird je nach Hersteller unterschiedlich 
beschrieben, mal zählt man das RnW-bit mit rein, mal nicht, da ist es 
besser man sucht sich im Datenblatt die konkrete Waveform raus und 
vergleicht diese ab startbit von links nach rechts. (siehe Anhang).

Die Darstellung des LA mit Datenwechsel genau zur aktiven Flanke des SCL 
ist IMHO verwirrend. Auch da checken, was das Scope zeigt und ebentuell 
tatsächlich mal Hold und setup-Zeiten ermitteln.

[Rainer W. (rawi)]

Jonatan schrieb:
> Logic_Analyzer.png

Im Datenblatt steht zur I2C-Adresse:
"I2C Address selection pin:
when ADDR=L, I2C address = 0x2A,
when ADDR=H, I2C address = 0x2B."

Wie hast du den Address selection pin (ADDR) beschaltet und warum 
verwendest du für die Abfrage die Adresse 0b0010101, also 0x15. Das kann 
nicht funktionieren.
Die I2C-Adressen besitzen in Einklang mit der I2C-Spezifikation 7 Bit 
(Figure 11 im DB).

Sonst hilft ein I2C-Scanner.

Andras H. schrieb:
> Manche verstehen den RW bit auch inklusive adresse manche nicht.
Bei TI umfasst die Adresse A6..A0. Das sind 7 Bit entsprechend der 
I2C-Spezifikation. Das RW-Bit hat nichts mit der Adresse zu tun, außer 
dass es im gleichen Byte wie die Adresse zum I2C-Slave übertragen wird 
(s. die bereits genannte Figure 11 im DB).

[Wastl (hartundweichware)]

Rainer W. schrieb:
> Wie hast du den Address selection pin (ADDR) beschaltet

Kann man aus seinem Schaltplan entnehmen.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

>> Wie hast du den Address selection pin (ADDR) beschaltet
> Kann man aus seinem Schaltplan entnehmen.

Hab's mal als Ersatz für den TO zusammengestückelt; ADDR liegt an GND.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dann muss es so aussehen wie im Anhang.

BTW: was ist denn aus dem Problem aus dem 
Beitrag "Unerwartetes Signal einer 40Mhz Clock" geworden?

[Jonatan (jonatan31)]

Moin,

Der ADDR pin ist auf Ground, wie man in meinem Schaltplan lesen kann.

Ich habe jetzt nach dem angehängten Schema alle Adresssen, also von 00 
bis 7F durchprobiert und bei keiner einen ACK bekommen.

Somit muss der Fehler, wenn ich das richtig sehe, an anderer Stelle 
liegen.


Ich benutze ein Betriebssystem um es zu lernen, nicht weil es nötig ist 
und dementsprechend macht es wenig Sinn meinen Code hier zu posten, weil 
das Signal ja das richtige ist und der Mikrocontroller nunmal nichts 
macht, außer das Signal zu generieren.

Schaltplan habe ich auch noch mal engehängt, falls der im Thread 
untergeangen ist.

Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal 
aber im Toleranzbereich des LDC. Ich werde die Widerstände ersetzen aber 
glaube nicht, dass das Problem hierdurch behoben wird.

[Jonatan (jonatan31)]

Lothar M. schrieb:

> BTW: was ist denn aus dem Problem aus dem
> Beitrag "Unerwartetes Signal einer 40Mhz Clock" geworden?

Ich habe herrausgefunden, dass die Clock nicht das Problem ist und das 
unerwartet Signal nur an der zu niedrigen Auflösung meines Oszis lag, 
wie in Beitrag "Re: Unerwartetes Signal einer 40Mhz Clock" beschrieben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jonatan schrieb:
> Es lässt sich nicht ganz ausschließen, dass der LDC tatsächlich richtig
> kontaktiert
Wenn der SDA-Pin am LDC nicht angelötet ist, dann siehst du allein wegen 
des Pullups auch ein NAK, obwohl der LDC gar keines "sendet". Oder 
andersrum: dieses Oszi-Bild siehst du auch ganz ohne LDC.

Ich würde da mal an VCC, GND, CLK und die I2C-Pins 5 Fädeldrähte 
dranlöten (eine gute Lupe tut da Wunder) und schauen, ob das Ding dann 
kommuniziert.

Jonatan schrieb:
> Ich habe herrausgefunden, dass die Clock nicht das Problem ist
Das dort "an anderer Stelle" zu suchende Problem ist also dieses hier 
mit der I2C-Kommunikation?

[Wastl (hartundweichware)]

Jonatan schrieb:
> Ich habe jetzt nach dem angehängten Schema alle Adresssen, also von 00
> bis 7F durchprobiert und bei keiner einen ACK bekommen.

Dann würde ich doch mal die Adressen 0x80 bis 0xFF durchprobieren.

Bis jetzt hat niemand einen relevanten Sourcode von dir gesehen.
Wer weiss was da drin passiert.

Überlege grundsätzlich deine Schreibweise von Adressen. Was du
schreibst sind "Dezimalzahlen", was du möglicherweise meinst sind
Hexadezimazahlen. ABer so genau weiss das niemand.

[Jonatan (jonatan31)]

Lothar M. schrieb:

> Ich würde da mal an VCC, GND, CLK und die I2C-Pins 5 Fädeldrähte
> dranlöten (eine gute Lupe tut da Wunder) und schauen, ob das Ding dann
> kommuniziert.


Das habe ich bereits versucht, aber um diese größe Drähte an den Chip 
dran zu löten reichen meine Lötfähigkeiten nicht aus. Ich werde es 
nochmal probieren, bezweifle aber das ich damit auf einen grünen Zweig 
komme.

Wie gesagt habe ich es ja auch schon mit den verschiedensten Methoden 
den Chip mehrfach aufgelötet. Ich habe auch mit einer Lupe nachgesehen 
und bin mir recht sicher, dass die Pins alle kontaktieren.

Lothar M. schrieb:
> Jonatan schrieb:
>> Ich habe herrausgefunden, dass die Clock nicht das Problem ist
> Das dort "an anderer Stelle" zu suchende Problem ist also dieses hier
> mit der I2C-Kommunikation?

Ja genau.
Ich dachte ich hätte das Problem identifiziert mit der scheinbar 
fehlerhaften Clock und wollte deswegen dieses Problem beheben mit 
besagtem Thread.
Das zugrundeliegende Symptom war aber schon die ganze Zeit der NACK den 
ich über I2C beobachtet habe.
Daher jetzt dieser breiter aufgestellte Thread.


Mir ist nicht ganz klar wie ich die Adressen 0x80 bis 0xFF 
durchprobieren soll, denn die Adresse hat ja nur 7 bit, wie ich schon 
korrigiert wurde.
Wenn ich die 8 bit inklusive R/W nehme um die Adressen 0x80 bis 0xFF zu 
probieren erhalte ich auch nur NACK.

Welchen Teil meines Sourcecodes möchtest du denn gern sehen bzw. was 
möchtest du daraus lesen?
Der Code ist wirklich ein ziemliches Schlachtfeld, da ich mich mit 
embedded C wirklich nicht gut auskenne und auch ein anderes viel 
komplexeres Projekt zweckentfremdet habe.

[Rolf (rolf22)]

Hans W. schrieb:

> Da die Adresse in den oberen 7 Bit des ersten Byte steckt, hat das erste
> Byte den Wert 0x54. Aber nur beim Lesen. Bei Schreibzugriffen hat das
> erste Byte den Wert 0x55.

Falsch? 0x54 = Schreiben, 0x55 = Lesen.
Jedenfalls steht im Datenblatt R-notW.

Ich verstehe nur nicht, warum man über so ein Thema groß diskutieren, 
einen LA bemühen oder über Signalgüte nachgrübeln muss. Man kann doch in 
wenigen Sekunden alle Möglichkeiten für das zu sendende Byte 
ausprobieren. Erst wenn das nicht zum Erfolg führt, sind andere 
Überlegungen sinnvoll.

[Wastl (hartundweichware)]

Jonatan schrieb:
> Mir ist nicht ganz klar wie ich die Adressen 0x80 bis 0xFF
> durchprobieren soll, denn die Adresse hat ja nur 7 bit, wie ich schon
> korrigiert wurde.
> Wenn ich die 8 bit inklusive R/W nehme um die Adressen 0x80 bis 0xFF zu
> probieren erhalte ich auch nur NACK.

Das hängt ja davon ab wie das im Sourcecode realisiert ist. Genau
darauf kommt es an wenn man von I2C-Adressen spricht.

Deswegen möchte "man" gerne sehen wie das bei dir ist. Ist denn
bei deinem Controller SDA und SCL auf Open-Drain gesetzt? Alles
Unwägbarkeiten da keiner sieht was du wirklich machst.

[Jonatan (jonatan31)]

Nun gut, dann versuch ich mal die relevanten Teile meines Sourcecodes zu 
präsentieren:

Beim S32k gibt es ein MasterTransmitDataRegistry (MTDR) in welches man 
bis zu 4 * 10 Bit schreiben kann, die dann nach dem First in First Out 
Prinzip vom I2C Treiber des Chips in I2C gewandelt und gesendet werden.

Da ich ja aktuell erstmal nur ein erstes ACK erzwingen möchte, schicke 
ich aktuell nur den Befehl zum schreiben (also die ersten 3 bit als 0x4) 
und dann die Slave-Adresse an die ich gern schreiben würde (also 0x2A). 
Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die 
Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben, tue ich das 
auch noch.

Ergibt also folgenden Code:

MTDR = (0x4<<8)|(0x2A<<1);

Dieser Code wird ausgeführt, nachdem ich die Clocks und den LPI2C des 
Mikrocontroller initalisiert habe.


Die Clock wird wie folgt initalisiert, wobei ich hier nur den 
vorgeschrieben Code benutze, der mit diesem Mikrocontroller schon 
gelaufen ist.

void clock_init(void) {

    //Setup crystal oscillator
    SCG->SOSCDIV = SCG_SOSCDIV_SOSCDIV1(1) | SCG_SOSCDIV_SOSCDIV2(1); //SOSCDIV1 = 1, SOSCDIV2 = 1
    SCG->SOSCCFG = SCG_SOSCCFG_RANGE(3) | SCG_SOSCCFG_EREFS(1); //High frequency range external crystal
    while(SCG->SOSCCSR & SCG_SOSCCSR_LK_MASK); //Ensure SOSCCSR is unlocked
    SCG->SOSCCSR = SCG_SOSCCSR_SOSCEN(1);    //Enable oscillator
    while(!(SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK));  //Wait for the clock to be valid

    //Setup PLL
    while(SCG->SPLLCSR & SCG_SPLLCSR_LK_MASK); //Wait for register to be written
    SCG->SPLLCSR &= ~SCG_SPLLCSR_SPLLEN_MASK;  //Disable PLL

    SCG->SPLLDIV |=   SCG_SPLLDIV_SPLLDIV1(2) | //SPLLDIV1 divide by 2
                      SCG_SPLLDIV_SPLLDIV2(4);  // SPLLDIV2 divide by 8

    SCG->SPLLCFG = SCG_SPLLCFG_MULT(24); //SPLL_CLK = ((8 MHz / 1) * 40) / 2 = 160 MHz

    SCG->SPLLCSR |= SCG_SPLLCSR_SPLLEN_MASK; //Enable PLL
    while(!(SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK)); //Wait for PLL to be valid

    SCG->SIRCDIV = SCG_SIRCDIV_SIRCDIV1(1) | SCG_SIRCDIV_SIRCDIV2(1);

    //Normal run mode (80 MHz)
    SCG->RCCR = SCG_RCCR_SCS(6) | SCG_RCCR_DIVCORE(1) | SCG_RCCR_DIVBUS(1) | SCG_RCCR_DIVSLOW(2);

    while (((SCG->CSR & SCG_CSR_SCS_MASK) >> SCG_CSR_SCS_SHIFT ) != 6); //Wait for clock source = SPLL

    SystemCoreClockUpdate();
}

Dann wird noch LPI2C initalisiert mit den entsprechenden Clockzyklen um 
auf eine Geschwindigkeit von 100kHz zu kommen:

void LPI2C_init(void)
{
    PCC->PCCn[PCC_LPI2C0_INDEX] |= PCC_PCCn_PCS(2)        /* Clk src: SIRCDIV2_CLK */
                                | PCC_PCCn_CGC_MASK;       /* Enable clock for LPI2C0 */


    LPI2C0->MCFGR1 =   LPI2C_MCFGR1_PRESCALE(2)    /* Prescale = 4*/
                       |LPI2C_MCFGR1_IGNACK_MASK;    /* Ignore NACK*/

  /* SCL_freq = Input_freq / (2^PRESCALER * (CLKLO + CLKHI + 2))*/

    LPI2C0->MCCR0 = LPI2C_MCCR0_CLKLO(12)
                | LPI2C_MCCR0_CLKHI(6)
                | LPI2C_MCCR0_SETHOLD(6)
                | LPI2C_MCCR0_DATAVD(3);



    LPI2C0->MFCR = LPI2C_MFCR_TXWATER(0)  /* Transmitter Water mark set to 0*/
                  |LPI2C_MFCR_RXWATER(3);  /* Receiver Water mark set to 3*/

    LPI2C0->MCR |= LPI2C_MCR_MEN_MASK /* Enable LPI2C as master */
            | LPI2C_MCR_DBGEN_MASK;

}

Ich bin mir nicht sicher, ob du das wolltest, aber das ist im Prinzip 
der relevante Code, der für I2C zuständig ist.

Wie der S32 dann weiter mit den Informationen im MTDR umgeht, weiß ich 
nicht. Ich beobachte nur, dass die Informationen dann gesendet werden.

[Wastl (hartundweichware)]

Jonatan schrieb:
> Ich bin mir nicht sicher, ob du das wolltest, aber das ist im Prinzip
> der relevante Code, der für I2C zuständig ist.

In deinem Kauderwelsch ist wieder kein einziger Hinweis zu
erkennen wie du mit den I2C-Adressen umgehst. Schon die Tatsache
dass du nicht verstehst was hier gemeint bzw. verlang ist lässt
darauf schliessen dass du sehr wenig verstehst.

Dass die Hardware im Prinzip funktioniert haben wir an deinem
Analyzer Bild gesehen.

[Dergute W. (derguteweka)]

Moin,

Jonatan schrieb:
> Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal
> aber im Toleranzbereich des LDC.

Bloss nicht herzeigen, die sind streng geheim.
Wenn du deinen Loetkuensten am Sensorchip nicht so recht vertraust, 
kannste ja mal mit Tuedeldraht irgendein anderes, moeglichst popeliges 
I2C-Device (Irgendein Temperatursensor oder ein kleines 
Flash)drantuedeln und gucken, ob du mit dem dann I2Cmaessig ueber deine 
Software quaken kannst...

Gruss
WK

[Jonatan (jonatan31)]

Dergute W. schrieb:
> Moin,
>
> Jonatan schrieb:
>> Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal
>> aber im Toleranzbereich des LDC.
>
> Bloss nicht herzeigen, die sind streng geheim.

Ich werde ein Bild davon machen, sobald unser Oszi wieder frei ist. Ich 
muss auch erst einen USB stick auftreiben, sonst wird wieder gemault das 
ich kein Screenshot vom Oszi mache ;)


> Wenn du deinen Loetkuensten am Sensorchip nicht so recht vertraust,
> kannste ja mal mit Tuedeldraht irgendein anderes, moeglichst popeliges
> I2C-Device (Irgendein Temperatursensor oder ein kleines
> Flash)drantuedeln und gucken, ob du mit dem dann I2Cmaessig ueber deine
> Software quaken kannst...
>

Das ist eine sehr gute Idee, das werde ich gleich mal probieren!

[Rolf (rolf22)]

> Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die
> Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben

Geht nicht: Du kannst gar keine 7 Bit in das MTDR schreiben, man kann in 
die Register des Controllers nur Vielfache von 8 Bit schreiben. Dein 
Code beschreibt das Bit 0 immer (egal ob mit oder ohne Shift), nämlich 
mit null.

Und da haben wir nun den Punkt: Die anderen Poster haben an Daten auf 
dem I2C-Bus gedacht. Nun verrätst du aber erstmals, dass du gar nicht 
auf den I2C-Bus schreibst, sondern in Controller-Register. Was 
letztendlich auf dem I2C-Bus passiert, bestimmt der Controller. Ich bin 
ziemlich sicher, dass der sich selbst um das R/W-Bit und den ganzen Rest 
kümmert, dafür hat er ja die CMD-Bits. Jedenfalls sehe ich beim 
schnellen Überfliegen des Datenblatts null Komma nichts von dem R/W-Bit 
und für die Adresse heißt es immer nur "address byte" (was ohne 
gegenteilige Erklärung bedeutet, das die Adresse in Bit 0 bis 6 liegt 
und Bit 7 null sein muss.)

[Jonatan (jonatan31)]

Rolf schrieb:
>> Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die
>> Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben
>
> Geht nicht: Du kannst gar keine 7 Bit in das MTDR schreiben, man kann in
> die Register des Controllers nur Vielfache von 8 Bit schreiben. Dein
> Code beschreibt das Bit 0 immer (egal ob mit oder ohne Shift), nämlich
> mit null.

Das stimmt, daran habe ich nicht gedacht.


Wie dem auch sei, ich kann freudig berichten, dass ich nach dem fix mit 
der geshifteten Adresse nun einen Profi den Chip habe auflöten lassen 
und es jetzt funktioniert, ich bekomme ein ACK!

Scheinbar war eine Kombination von vorherigen Fehlern in Kombination mit 
einem schlechten auflöten des Chips Ursache des Problems.

Damit hat sich das Problem gelöst, danke für die Hilfe!

Lg, Jonatan

[Rainer W. (rawi)]

Wastl schrieb:
> Kann man aus seinem Schaltplan entnehmen.

Stimmt - jetzt wo du das sagst, sehe ich, dass der TO den auch irgendwo 
im Verlauf des Threads angehängt hat.
Also wird sich der Sensor wohl auf der I2C Adresse 0x2A angesprochen 
fühlen.

Rolf schrieb:
> Man kann doch in wenigen Sekunden alle Möglichkeiten für das zu sendende
> Byte ausprobieren.
Nichts anderes macht ein I2C-Scanner. Allerdings wird der für 127 
mögliche Adressen nicht mehrere Sekunden brauchen ;-)

Wastl schrieb:
> Dann würde ich doch mal die Adressen 0x80 bis 0xFF durchprobieren.

I2C-Adressen 0x80 bis 0xFF gibt es nach I2C-Spezifikation und nach 
Auffassung von TI nicht. Außerdem sagt der Logikanalysator doch 
eindeutig, was der Master als erstes Byte auf den Bus legt, so dass sich 
jede Diskussion und Glaskugelleserei darüber erübrigt.

Wastl schrieb:
> Dass die Hardware im Prinzip funktioniert haben wir an deinem
> Analyzer Bild gesehen.

Falscher Schluss - offensichtlich hat nur der Master die richtigen 
Signale auf den Bus gelegt und es LAG es an der Hardware, genauer an der 
Löterei. Für das Verständnis wäre es natürlich förderlich zu wissen, 
welcher Pin verhindert hat, dass der Slave ordnungsgemäß arbeitet.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

>> Dass die Hardware im Prinzip funktioniert haben wir an deinem
>> Analyzer Bild gesehen.
>
> Falscher Schluss - offensichtlich hat nur der Master die richtigen
> Signale auf den Bus gelegt und es LAG es an der Hardware, genauer an der
> Löterei.
Yup.
> Für das Verständnis wäre es natürlich förderlich zu wissen,
> welcher Pin verhindert hat, dass der Slave ordnungsgemäß arbeitet.

Welcher Pin ist wurscht, man kann hier nur eine Aussage über den Slave 
an sich machen. Und die Gehäusezeichnung sieht arg nach "keine Pins 
sondern lediglich Pads an der Unterseite" aus: WSON-12 ... "Small 
Outline No Lead (SON)" (siehe Anhang). Pin-abstand: 1.27 mm. Also 
reflow-löten, Heissluft von oben; board von unten heizen könnte helfen, 
ist aber IMHO bei dem kleinen Fliegendreck eher verzichtbar.

Wenn der Master wie der LA sagt korrekt sendet, aber keinerlei Antwort 
vom Slave kommt, dann zeigt das lediglich das der Slave als 
Kommunikationspartner nicht vorhanden ist. Kann sein das SDA nicht 
korrekt verbunden ist, oder SCL. Oder der Slave nicht korrekt gepowert 
wird oder im Reset festhängt.

Da kann man versuchen direkt mit spitzen Messspitzen durchzuklingeln, 
falls vorhanden JTAG-Boundary-scan nutzen, die Stromaufnahme zu 
beobachten, mal den Chip runterlöten und schauen, ob sich was vom 
Verhalten ändert etc. pp..

[Rainer W. (rawi)]

Bradward B. schrieb:
>>> Dass die Hardware im Prinzip funktioniert haben wir an deinem
> ...
Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier 
die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link 
auf den betreffenden Beitrag) zu unterschlagen.

Beim Zitieren gehört es sich, die Quelle anzugeben.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

offtopic

> Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier
> die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link
> auf den betreffenden Beitrag) zu unterschlagen.

„Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern 
kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, 
das eine vom anderen zu unterscheiden.“


> Beim Zitieren gehört es sich, die Quelle anzugeben.

Mumpitz, die Wiedergabe einer zeitlich vorhergehenden Aussage ist 
lediglich eine Brücke im Gedankenfluß.
Schau dir bspw. die erste "Lebenshälfte" dieses Forums ans oder die 
Wikipedia an, da wird nicht der Lese-fluß durch komplett unnötiges "Auch 
Hinz und Kunz hat dazu einen rausgeknallt ..." unterbrochen.

offtopic off

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Bradward B. schrieb:
> Schau dir bspw. die erste "Lebenshälfte" dieses Forums ans oder die
> Wikipedia an, da wird nicht der Lese-fluß durch komplett unnötiges "Auch
> Hinz und Kunz hat dazu einen rausgeknallt ..." unterbrochen.
Schau dir die erste Lebenshälfte der Menscheit an. Da haben wir Felle 
toter Tiere um uns gewickelt, haben in Höhlen gehaust und sind mit 30 
Jahren gestorben. Dann haben wir uns weiterentwickelt. Und was die 
Weiterentwicklung angeht müsste man von einem, der sich einen Nick aus 
einer Raumfahrtserie angeeignet hat, doch einiges erwarten können. Aber 
vermutlich ist dessen Raumschiff mit dem Faustkeil geschnitzt worden.

> Schau dir bspw. ... die Wikipedia an
Nicht alles, was hinkt, ist ein Vergleich. Im Wikipedia könnte z.B. 
jeder beliebige andere User deinen Kommentaren die fehlenden Links 
hinzufügen.

Rainer W. schrieb:
> Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier
> die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link
> auf den betreffenden Beitrag) zu unterschlagen.
Es gibt noch mindestens einen ähnlich hartnäckig ignoranten User. 
Lustigerweise kann der Lieutenant Junior Grade die Zitatfunktion 
verwenden, wenn es in seinem Interesse ist, wie der 
Beitrag "Re: [V] Bei Kleinanzeigen gefunden: Oszilloskop Hameg 312 für 20 EUR" zeigt. In diesem 
Thread findet man dann auch noch den anderen zitatmäßig 
faustkeilschwingenden Höhlenbewohner.

[/ot]

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> Schau dir die erste Lebenshälfte der Menscheit an. Da haben wir Felle
> toter Tiere um uns gewickelt, haben in Höhlen gehaust und sind mit 30
> Jahren gestorben. Dann haben wir uns weiterentwickelt. Und was die
> Weiterentwicklung angeht müsste man von einem, der sich einen Nick aus
> einer Raumfahrtserie angeeignet hat, doch einiges erwarten können. Aber
> vermutlich ist dessen Raumschiff mit dem Faustkeil geschnitzt worden.
>
>> Schau dir bspw. ... die Wikipedia an
> Nicht alles, was hinkt, ist ein Vergleich.

Ja eben.

Es geht hier nicht um das Verfassen einer Dissertation nach den Vorgaben 
einer Prüfungskommision, es geht hier um die Wiedergabe eine 
persönlichen Aussage eines freien Autors. Und wenn der das Herumgereite 
auf der inflationäre Wiedergabe von Nicknames in den allermeisten Fällen 
als unnötig und sogar störend empfindet ist das eben so.
Als Konsequenz folgt daraus das Weglassens des unnötigen Zierates.

Hogwh!

PS: Over and out (Ihr findet sicher einen anderen, der Euch geduldig 
erklärt wie man Bauteile mit "No lead package) elektrisch fehlerfrei 
bestückt. (falls daran überhaupt Interesse besteht))

[Rainer W. (rawi)]

Bradward B. schrieb:
> Und wenn der das Herumgereite
> auf der inflationäre Wiedergabe von Nicknames in den allermeisten Fällen
> als unnötig und sogar störend empfindet ist das eben so.

Du hast immer noch nicht verstanden, dass es sich eben nicht nur um die 
"inflationäre Wiedergabe von Nicknames" handelt, sondern auch um einen 
Link auf die Quelle (Ort in Form der URL und damit auch Kontext) des 
zitierten Beitrags.

====================================
Ich untersage dir hiermit ausdrücklich, in diesem Forum Beiträge von mir 
oder Teile daraus ohne Quellenangabe im Sinne des Forums (Nickname mit 
Link zum Originalbeitrag) in deine Beiträge zu übernehmen.
====================================

ES REICHT