I2C rätsehaftes Verhalten

[Attila C. (attila)]

Hallo!

Dies hier funktioniert:

while (1)
  {
    upper=I2Creceive(0x04);
    lower=I2Creceive(0x05);
    temp=(float)(upper+(lower/256.0));
    dtostrf(temp, 2, 2, test);
    string(test);
    cursorhome();
  }

Dies hier funktinert nicht:

  while (1) 
  {      
    if (loss==1)
    {
      network();
      httpTerm();
      httpInit();    
    }
    if(loss==0)
    {
      upper=I2Creceive(0x04);
      lower=I2Creceive(0x05);
      temp=(float)(upper+(lower/256.0));
      dtostrf(temp, 2, 2, test);
      string(test);
      cursorhome();      
      httpStream(temp);
    }
  }

Es funtioniert allerdings reibungsfrei wenn ich bei der I2C Routine die 
"repeated start"  Prüfung (Und nur die!) auskommentiere.

Vielleicht sagt dieses merkwürdige Verhalten jemandem von euch was?

[Eric B. (beric)]

Mein Glaskugel fängt bei Zeile 42 in der I2Creceive-Funktion zu weinen 
an.

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

Attila C. schrieb:
> Dies hier funktioniert:
Mit welchem Compiler auf welchem Zielsystem?

> Dies hier funktinert nicht:
Und was "funktioniert" da nicht?
Was erwartest du und was erhältst du stattdessen?

Das hier ist übrigens hübsch gefährlich, wenn sich "loss" zwischendurch 
ändern kann:

    if (loss==1)
    {
      network();
      httpTerm();
      httpInit();    
    }
    if(loss==0)
    {
      :

Ich würde da auf jeden Fall so schreiben:

    if (loss==1)
    {
      network();
      httpTerm();
      httpInit();    
    }
    else if (loss==0)
    {
      :

Und falls "loss" nur 1 oder 0 sein kann, dann so

    if (loss==1)
    {
      network();
      httpTerm();
      httpInit();    
    }
    else
    {
      :

BTW:
Sieh dir mal an, was da ein paar Zeilen über der Eingabebox steht:

Wichtige Regeln - erst lesen, dann posten!
   ...
Formatierung (mehr Informationen...)

    [c]C-Code[/c]

[Attila C. (attila)]

Ok ok! Richtig! Das habe ich vergeigt!
Also: Es  ist ein Atmega 8 und geschrieben in C.

Bei der ersten Version wird eine Temperatur über I2C ausgelesen und auf 
dem Display ausgegeben. Ich prüfe sämtliche Statuscodes so wie es im 
datasheet vom Atmega steht.

Bei der zweiten Version wird die Temperatur zusätzlich über ein GSM 
Modul online gestellt. Ansonsten ist alles gleich. Dennoch bleibt die 
I2C Übertragung beim ersten Aufruf bei der Prüfung des "repeated start" 
hängen. Ich habe versuchsweise auf "Start" geprüft (obwohl das 
eigentlich Unsinn ist da es ja in der kurzen Version funktioniert) Ohne 
Erfolg.

Sobald ich die Prüfung auf "repeated start" auskommentiere läuft die 
Übertragung reibungslos.

In meinen "naiven" Augen hat sich, was die I2C Abläufe betrifft 
überhaupt nichts geändert. Daher verstehe ich den Fehler nicht.

Bei meiner I2C Routine wird bei nicht erfolgreicher Prüfung "Stop" 
gesendet.

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

Attila C. schrieb:
> Sobald ich die Prüfung auf "repeated start" auskommentiere
Die aber nicht im gezeigten Code zu finden ist, oder?

> Bei meiner I2C Routine
Häng die doch einfach mal als *.c Datei hier an...

[Attila C. (attila)]

Sorry ich bin heute neben der Spur. Ich hatte vergessen noch folgendes 
zu erwähnen:

Das Modul für die Temperatur ist ein MPL3115A2. Ich hatte mal eins von 
Pololu und das lief mit dem beigefügten Auszug und noch zusätzlichen 
Routinen.

Das mir jetzt vorliegende Modul ist von Adafruit. Wesentlich Unterschied 
scheint mir zu sein das es auch 5 Volt verarbeiten kann also 
Levelshifter und Spannungsregelung mit an Bord hat.

Ich musste die I2C Gescchwindigkeit von 400 auf unter 100kHz reduzieren 
und (und da könnte der Hase im Pfeffer sein!) die "Stop" Anweisung am 
Ende auskommentieren damit es mit dem Modul von Adafruit lief.

[Rene K. (xdraconix)]

Meine Glaskugel sagt mir bei Zeile 42:

Vielleicht wird "loss" aber auch nie 0 und er geht deshalb erst garnicht 
in die Prüfung?!

[Attila C. (attila)]

Naja: Wenn loss nie 0 würde würde die auskommentierte Version nicht 
funktionieren.

Der Fehler ist, vermute ich, irgendwo im I2C zu suchen. Und dort 
vermutlich bedingt durch die geänderte Geschwindigkeit. Es sieht auch 
nicht wirklich schön aus auf dem Oszi. Mir erschliesst sich nur nicht 
warum der Fehler auftritt indem zusätzliche Programmteile angefügt 
werden die nichts mehr mit dem I2C Teil zu tun haben.

[Rene K. (xdraconix)]

Du sagtest, das funktioniert:

 while (1)
   {
     upper=I2Creceive(0x04);
     lower=I2Creceive(0x05);
     temp=(float)(upper+(lower/256.0));
     dtostrf(temp, 2, 2, test);
     string(test);
     cursorhome();
   }

... und das funktioniert nicht:

 while (1)
   {
     if (loss==1)
     {
       network();
       httpTerm();
       httpInit();
     }
     if(loss==0)
     {
       upper=I2Creceive(0x04);
       lower=I2Creceive(0x05);
       temp=(float)(upper+(lower/256.0));
       dtostrf(temp, 2, 2, test);
       string(test);
       cursorhome();
       httpStream(temp);
     }
   }

Da wäre mein allererster Ansatzpunkt: Bekommt loss überhaupt 0 damit es 
in die Abfrage geht!

Wenn doch alles, ohne if Abfrage läuft, wieso sollte es denn dann nicht 
mit Abfrage laufen?! Da erschließt sich mir nur eine einzigste 
Fehlerquelle: loss wird nicht 0!

[Attila C. (attila)]

Also, wie ich bereits sagte: Das Ding sendet bereits den ganzen Tag die 
aktuelle Raumtemperatur and meine Website weil ich, wei man am 
beigefügten Code sehen kann, die Prüfung des "repeated start" 
auskommentiert habe:

  //if ((TWSR & 0xF8) != 0x10)              // 0x10= repeated START
  //TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);        //

Es wird also nicht geprüft ob das TWI syatem 0x10 zurückgibt. Wenn ich 
es nicht auskommentiere bleibt das I2C an der Stelle stehen.

Es sei denn ich beschränke mich darauf die Temperatur nur hier auf dem 
Breadboard über das LCD auszugeben , also die Version die funktioniert. 
DANN kann und wird die "repeated start" Rückgabe geprüft.

[Attila C. (attila)]

Der vollständigkeit halber: Mich stört auch ungemein dass ich bei beiden 
Versionen die "Stop" condition auskommentieren musste. Das kann nicht 
korrekt sein! Ich habe mit verschiedenen TWI Geschwindigkeiten und 
verschiedenen Delays zwischen den Abfragen rumprobiert aber nichts hat 
bislang geholfen.

[Attila C. (attila)]

Das STOP Problem ist jetzt gelöst. Der Sensor mochte das ACK nach dem 
Auslesen der Daten nicht.

Es bleibt bei der auskomentierten Prüfung der START condition. 
Allerdings jetzt bei beiden Versionen. Ich vermute da die Ausgabe auf 
das LCD wesentlich schneller geht als der "upload" ins Netz hat er die 
"repeated start" condition anerkannt.

Anbei der aktuelle Code.

[spess53 (Gast)]

Hi

>Das STOP Problem ist jetzt gelöst. Der Sensor mochte das ACK nach dem
>Auslesen der Daten nicht.

Dann führe dir mal die

http://www.nxp.com/documents/user_manual/UM10204.pdf

Da steht so etwas drin.

MfG Spess

[Attila C. (attila)]

Ja, vielen Dank! Sehr interessante Lektüre. Allerdings hilft es leider 
für das andere Problem nicht weiter. Die TWI Status Codes scheinen ja 
eher eine Atmel Sache zu sein.

[Joachim B. (jar)]

Attila C. schrieb:
> Das STOP Problem ist jetzt gelöst. Der Sensor mochte das ACK nach dem
> Auslesen der Daten nicht.

für das letzte Byte muss ja auch NACK gemacht werden!

ACK nur wenn noch Bytes erwartet werden!

Dann gibt es noch i2c stretching, man muss nur warten bis beide SDA und 
SCL wieder auf high gehen, oder bei I2C EEProms prüfen bis sie wieder 
Antworten.

Für ACK und NACK schau dir mal den Fleury Code an!

http://homepage.hispeed.ch/peterfleury/avr-software.html

[Attila C. (attila)]

So! Das Rätsel scheint gelöst. Meine Routinen warteten nicht darauf das 
die Stop condition ausgeführt wird und rannten sofort weiter zum Start. 
Ging manchmal gut und manchnmal nicht.

Ein:

while(TWCR & (1<<TWSTO));

hinter dem Senden des Stop Befehls schaffte Abhilfe.

Der Blick in den Fleury Code war sehr aufschlussreich.

Vielen Dank an all die mir hier geholfen haben, ich hoffe der Beitrag 
kann auch anderen helfen.