was passiert bei fehlerhafter Adresse im I2C-Bus?

[R. F. (rfr)]

Hallo

wenn man einen slave im Bus hat und diesen adressiert, sendet er ein ACK 
zurück. Wenn er falsch adressiert wirt, was macht er dann? sendet er ein 
NACK oder garnichts zurück?


Gruss

Robert

[testtest (Gast)]

Der I2C ist ein Bus. Stell dir vor, du hast einige Teilnehmer daran 
hängen und jeder quasselt auf ein Kommando das nicht an ihn ging.
Nö, der IC bleibt ruhig.

[Walter Tarpan (Gast)]

R. Freitag schrieb:
> was passiert bei fehlerhafter Adresse im I2C-Bus?

Nichts. Es antwortet niemand.

[Paul B. (paul_baumann)]

Testtest schrub:
>Stell dir vor, du hast einige Teilnehmer daran
>hängen und jeder quasselt auf ein Kommando das nicht an ihn ging.

Das wäre dann praktisch so wie hier....
;-)
MfG Paul

[R. F. (rfr)]

Aha.

Es besteht folgendes Problem: Ein Display mit unbekannter Adresse soll 
angesteuert werden. Es werde eine Startcondition und dann eine Adresse 
gesendet. Ein Nack würde Klarheit schaffen. Wenn nichts gesendet wird, 
kann ich bis zum St.Nimmerleinstag warten. Ich will aber alle max. 128 
Adressen testen. Die erkannte Adresse antwortet also mir ACK. Wie lange 
muss ich denn warten, bis ich den nächsten Adressenwert senden kann und 
der slave diesen auch prüft?

Grüsse

Robert

[Marc V. (Firma: Vescomp) (logarithmus)]

Paul Baumann schrieb:
> Das wäre dann praktisch so wie hier....
> ;-)
> MfG Paul

 LOL

[Karl H. (kbuchegg)]

R. Freitag schrieb:
> Aha.
>
> Es besteht folgendes Problem: Ein Display mit unbekannter Adresse soll
> angesteuert werden. Es werde eine Startcondition und dann eine Adresse
> gesendet. Ein Nack würde Klarheit schaffen.

Dann sieh dir doch einfach mal an, wie die Sache mit NACK bzw. ACK am 
I2C Bus technisch funktioniert. Dann sollte dir die Antwort auf deine 
Frage eigentlich unmittelbar ins Auge springen.

> Wenn nichts gesendet wird,
> kann ich bis zum St.Nimmerleinstag warten. Ich will aber alle max. 128
> Adressen testen. Die erkannte Adresse antwortet also mir ACK. Wie lange
> muss ich denn warten, bis ich den nächsten Adressenwert senden kann und
> der slave diesen auch prüft?

Weniger als eine halbe Stunde :-)

[Marc V. (Firma: Vescomp) (logarithmus)]

R. Freitag schrieb:
> kann ich bis zum St.Nimmerleinstag warten. Ich will aber alle max. 128
> Adressen testen. Die erkannte Adresse antwortet also mir ACK. Wie lange
> muss ich denn warten, bis ich den nächsten Adressenwert senden kann und
> der slave diesen auch prüft?

 Auweia.
 Erst schreiben, dann nachdenken (bezieht sich auf mich und meinen
 geloschten Beitrag).

 Selbst mit Clock stretching muss ACK oder NACK in max. 10 CLK kommen,
 Wenn du mit 100KHz arbeitest ist das genau ?

[Dieter W. (dds5)]

Wenn kein Baustein antwortet entsteht durch den pullup Widerstand an SDA 
automatisch ein NACK.

Versuche mal testweise die Adresse 0, einige Bausteine akzeptieren die 
als general call. Dann kann man zumindest schon mal sehen ob überhaupt 
eine Antwort kommt.

Durchprobieren der Adressen kann man ohne großartige Pausen. Nach einem 
"Stop" mal 5 Takte (50µs) warten und dann wieder "Start"en.

[Sven B. (scummos)]

i2cdetect -y 0 macht an jedem Rechner ziemlich genau das: einfach alle 
Adressen durchprobieren und schauen wo was antwortet:

# time i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- 5c 5d 5e 5f
60: -- 61 -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
0.00user 0.00system 0:00.02elapsed

Besonders lang dauert es auch nicht, du kannst die Adressen direkt 
nacheinander durchprobieren. Ich finde so immer die Adressen von 
i2c-Clients, geht schneller als das Datenblatt lesen ;)

[R. F. (rfr)]

i2cdetect ist wo verfügbar?

[Walter Tarpan (Gast)]

R. Freitag schrieb:
> i2cdetect ist wo verfügbar?

Linux. Wobei das für einen µC auch schnell selbst geschrieben ist. Meins 
sieht so aus:

/* Suchen von I2C-Devices und Darstellen auf LCD */
void i2c_scan(void)
{
  I2C_TypeDef* I2Cx = I2C1;

  uint8_t status;

  status = I2C_init(I2Cx); // initialize I2C peripheral
    if(status) goto error;

  printf_P(PSTR("\fScan I2C adresses\n\a"));

  /* Check for I2C devices */
  printf_P(PSTR("I2C=\a"));
  for(uint8_t i=0x00; i<0x7F; i++) {
    printf_P(PSTR("0x%2x\a"),i<<1);

    status = I2C_ping(I2Cx,i<<1);

    switch (status) {
    case i2c_ok:
      printf_P(PSTR("\nI2C=\a"));
      break;
    case i2c_ackTimeout:   // NACK
    case i2c_noAck:        // auch NACK
      printf_P(PSTR("\b\b\b\b\a"));
      break;
    case i2c_otherTimeout: // Busfehler: Konnte START nicht senden
      // fallthrough
    default:               // Unterwarte Faelle
      I2C_reset(I2Cx);
      printf_P(PSTR("TO=%2x,%2x \a"),i<<1,status);
    }

    delay_us(50000);
  }
  printf_P(PSTR("\b\b\b\bdone.    \a"));

  while(!key_getstroke());
  return;


  error:
  I2C_reset(I2Cx);
  printf_P(PSTR("\nError scanning I2C bus\nerror code 0x%x\npress key to leave\a"),status);
  while(!key_getstroke());
}

und

/* I2C-Adresse kurz anpingen um zu sehen, ob Geraet vorhanden
 *
 * return: i2c_ok          : Device vorhanden und hat mit ACK bestaetigt
 *         i2c_busyTimeout : Bus nicht frei
 *         i2c_otherTimeout: Unerwarteter Fehler
 *         i2c_ackTimeout  : NACK, Device nicht vorhanden */
uint_fast8_t
I2C_ping(I2C_TypeDef *I2Cx, uint8_t slaveaddr)
{
  uint_fast8_t status;

  // i2c_ok oder i2c_busyTimeout
  status = I2C_waitbusy(I2Cx);
  if(status) {
      status |= (2<<4);
      goto error;
  }

  // Startbedingung
  // i2c_ok           : ACK empfangen, Teilnehmer vorhanden
  // i2c_ackTimeout   : kein ACK empfangen, keine Antwort vom Teilnehmer
  // i2c_otherTimeout : Start-Bedingung konnte nicht gesendet werden.
  // Senderfehler.
  status = I2C_start(I2Cx,slaveaddr,I2C_Direction_Transmitter);
  I2C_stop(I2Cx);

  error:
  return status;
}

für einen AVR.