i2C bleibt hängen

Robert schrieb:
> Hat jemand bitte einen Tip ?

Ja!

Robert schrieb:
> Muss mir noch das i2C Signal genauer ansehen. Eventuell pull up R
> anpassen,

Mache da Fakten draus!
Das wäre ein wichtiger Schritt.

mmh.. derzeit 10k pull up, eventuel auf 5k runter gehen..
Aber bei 50kHz i2C, sollte das auch kein Problem sein..

Aber das Programm dürfte nicht hängenbleiben, egal ob Signal schlecht 
oder gut...

Welche Fakten brauchst du noch ?

Robert schrieb:
> Welche Fakten brauchst du noch ?

Ich brauche keine Fakten....
Du brauchst welche.
Denn so kommst du zu machtvollen Urteilen.

Vermutungen und "was wäre wenn", helfen da nicht.

Mein Vorgehen, bei I2C Problemen:
1. Signalform ok? (oszi)
2. Signalanalyse (LA)

Dann weiß man ob einer der Partner den Bus niederhält.
Mit einem Serienwiderstand, kann man auch raus finden, welcher der 
beiden das ist.


Robert schrieb:
> Verwende die Lib von Peter Fleury
Die kenne ich nicht (nur aus der Ferne)

Ausschließen, dass das ein Software Fehler ist, kann ich nicht. Aber das 
sieht man bei der Analyse des Busses.

@Arduino Fanboy
Ja, mit Osci muss ich noch schauen.. (Flanken)
Mit dem LA habe ich die Woche lang, Messungen gemacht..
Leider tritt der Fehler nur selten auf.. :-(
Braucht oft Stunden...
Habe mit dem LA nur gemerkt, dass nach dem Aufhängen des Busses die 
Pegel verschieden sind... Manchmal beide auf High, manchmal 
unterschiedlich...
(hoffte auf einen Fehler in der Clock-Leitung)

--
Danke für die anderen Kommentare   Peter, usw...

Scheint also doch nicht so selten zu sein, dass der Bus hängen bleiben 
kann..

Wenn ich einen Timeout in der Lib einbauen würde, muss ich da etwas 
beachten ?!
Bestimmte Register zurücksetzen? oder nur  normal mit Return (Break) 
aufsteigen ?!

Robert schrieb:
> Hat jemand schon mal so ein Problem gehabt?

Massig. i2c-Probleme gibt es hier im Forum relativ oft.

Wie ober bereits vorgeschlagen, stell auf sw-i2c um. Wenn es dir um das 
Verständnis von i2c geht, klappt das mit sebst erstellter i2c software 
am besten.

Ich wundere mich etwas über die SoftI2C Predigten....

OK, ich kenne nur meine kleine Arduino AVR I2C Welt.
Da funktioniert das allerdings prächtig.

Nix Ausfälle alle Stunde, oder so.

Und das ist nicht SoftI2C, sondern nutzt die TWI Hardware.
Solange nicht mehr, als 2 AVR Master, sich die Spielwiese teilen müssen, 
tuts das.

Hi

>> Hat jemand schon mal so ein Problem gehabt?

>Massig. i2c-Probleme gibt es hier im Forum relativ oft.

Hä? Wir setzen schon seit fast 20 Jahren HW- bzw. SW-I2C ein. Das läuft 
beides sehr zuverlässig. Allerdings beides mit eigenen Routinen.

MfG spess

Gu. F. schrieb:
> Typischerweise sollten da eher 1k5 drin sitzen.

?

Peter Fleury empfiehlt 4k7
Ich halte das bei Vcc=5V schon für einen guten Ausgangspunkt.

Aber vielleicht haben wir es ja hier mit 2m Kabel (und dann auch noch im 
Auto) zu tun.

... und keiner spricht hier wieder vom Aufbau der ja
immer soooooo gut ist dass darüber auf keinen Fall
gesprochen werden muss und darf.

Ja, der Aufbau ist mehr als nur zwei Pullup-Widerstände.

Hi

>Peter Fleury empfiehlt 4k7

Interessiert eigentlich den Gasmann. Dafür gibt es offizielle Dokumente:

UM10204: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

MfG Spess

Um den Fehler öfters zu provozieren kannst du auch öfters lesen.
Vorschlag: 1000 mal lesen/schreiben, 500ms Pause und wieder von vorn.

Also wenn Lego 82k Ohm Pull-Ups verwendet (was ich nicht tun würde), 
dann können 10k nicht völlig falsch sein, oder?

Hi

Scheinbar liegt es an der lese Routine der Lib

/*********************************************************************** 
**
 Read one byte from the I2C device, request more data from device

 Return:  byte read from I2C device
************************************************************************ 
*/
unsigned char i2c_readAck(void)
{
  TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA);
  while(!(TWCR & (1<<TWINT)));

    return TWDR;

}/* i2c_readAck */


/*********************************************************************** 
**
 Read one byte from the I2C device, read is followed by a stop condition

 Return:  byte read from I2C device
************************************************************************ 
*/
unsigned char i2c_readNak(void)
{
  TWCR = (1<<TWINT) | (1<<TWEN);
  while(!(TWCR & (1<<TWINT)));

    return TWDR;

}/* i2c_readNak */

------------------------

Wenn hier kein Slave dran ist, oder es Störungen gibt, hängt er sich 
wohl in dieser Routine auf bzw. wartet endlos :-(

Schreiben geht immer...

(Ist nur Master und 1 (2) Slave)

Mit SW-i2c ging das immer.

Könnte jetzt immer Abfragen, ob ein Slave da ist, aber bei einer Störung 
oder wenn der Slave spinnt, ist dann wieder das gleiche...

Gu. F. schrieb:
> Spess hat doch schon auf die Spec verlinkt.

Bei LEDs wird hier im Forum scheinbar immer der Maximalstrom angesetzt, 
bei den I2C Pullups immer der Minimalwiderstand. An der Achse steht 
Rp(min), kleiner ist zwar nicht unbedingt kaputt aber außerhalb der 
Spec.

> Warum also nicht gleich richtig machen?

Richtig heißt also immer größer als in diesem Bild gezeigt, ein Wert 
für den Maximalwert ist da nicht gezeigt.

MfG Klaus

PS. Die typische Antwort hier im Forum auf den Ratschlag: "mach die 
Pullups kleiner" ist "hat nichts gebracht"

Robert schrieb:
> Scheinbar liegt es an der lese Routine der Lib

  while(!(TWCR & (1<<TWINT)));


setz halt einen Timeout ein. Hatten wir die Tage schon mal.

1

u32 downtimer=200000;

2

    while((TWCR & (1<<TWINT)) && downtimer)downtimer--;

3

if (!downtimer)return;

Hi

>Dann bleib doch dabei. Die gezeigte Hardware-Lösung pollt ja auch nur
>stumpf das Statusbit, und bringt damit keinerlei Vorteile.

Wenn man sich das Beispiel aus dem Datenblatt ansieht, dann fehlt bei 
den hier

Beitrag "Re: i2C bleibt hängen"

die Behandlung der Fehler.

MfG Spess

Robert schrieb:
> enn hier kein Slave dran ist, oder es Störungen gibt, hängt er sich
> wohl in dieser Routine auf

Nachtrag: Was soll er bei dieser Routine denn sonst machen als sich 
aufhängen wenn kein slave dran ist???

Hallo

@grundschüler    danke für den Tip :-)

gibt den Beitrag hier:
Beitrag "Timeout bei serieller abfrage"


Habe das aber ein bisschen anders gelöst:

---------
*/
unsigned char i2c_readNak(void)
{

uint32_t downtimer = 25000;

  TWCR = (1<<TWINT) | (1<<TWEN);
  while(!(TWCR & (1<<TWINT)))
        {
        if downtimer <1) return 0;
        downtimer--;
        }

    return TWDR;

}/* i2c_readNak */

-----------

Wie das Beispiel in dem Link funktionieren soll, ist mir zwar nicht ganz 
klar, aber damit habe ich dann meine Lösung gebastelt..

Mit dem 8MHz Takt und mit einem downtimer Wert von 25000, bekomme ich 
eine Timeout von ca. 0,1 Sekunden.

Robert schrieb:
> while(!(TWCR & (1<<TWINT)))
>         {
>         if downtimer <1) return 0;
>         downtimer--;
>         }

das ist im Prinzip identisch mit
while(!(TWCR & (1<<TWINT)) && !downtimer )
         {
         downtimer--;
         }


Die Bedingung "downtimer ergibt 0" wird nur in der while-Bedingung statt 
bei dir als separate Bedingung abgearbeitet.

        if downtimer <1) return 0;
=> hier sollte nicht 0 sondern ein Fehlerwert zurückgegeben werden.

Hallo

Ich versuche gerade das Nack vorher abzufangen, befor es überhaupt zum 
i2c_read.. kommt.


Habe mir dazu folgendes gebastelt
(für die Lib von Peter Fleury)

---------------------------------------------------
unsigned char test[1];
uint8_t  Daten1, daten2;
-------------

i2c_Start (0x50);
test[1] = i2c_write (0x10);

if (test[1] ==1)
    {
    i2c_stop();
    springe raus-->
    }

i2c_rep_start (0x51);
Daten1 = i2c_readAck();
Daten2 = i2c_readNak();
i2c_stop();
------------------------------------------------------


Link zur Lib ist hier:
http://homepage.hispeed.ch/peterfleury/i2cmaster.zip


Mein Code funktioniert ganz gut, schaut aber ein bisschen aufwendig aus.
Kann man das irgendwie  besser(einfacher) machen ?

Danke für Tips :-)

l.G. Robert

> Kann man das irgendwie  besser(einfacher) machen ?

Nicht wirklich.

> Mein Code funktioniert ganz gut...

Solange, bis an test[1] eine andere Variable liegt.