AVR TMP122 per SPI auslesen Problem bei mehrfachem Abruf

[Stefan (Gast)]

Hi und hallo zusammen,

Ich bastle gerade mit einem AVR 644P rum. Ich lese per SPI einen 
einfachen Temperatursensor TMP122 aus.

Datenblatt : http://www.ti.com/lit/ds/symlink/tmp122.pdf

Das funktioniert auch prima. Das Ding liefert mir laufend Daten.

Jetzt das Problem. Ich resete den µC, die Daten werden per SPI 
ausgelesen. WEnn ich mir dann den Inhalt der Variablen ansehe, stimmt 
auch alles. Das ist der einmalige Datenabruf.

Wenn ich das Ganze in eine Schleife packe wie:

while(1)
{
    _delay_ms(2000);
    PORTD &= ~(1<<PD7);
    _delay_us(10);
    while(!(UCSR1A & (1<<UDRE1)));
    UDR1= 0x00;
    while(!(UCSR1A & (1<<RXC1)));
    daten= (UDR1<<8);
    while(!(UCSR1A & (1<<UDRE1)));
    UDR1= 0x00;
    while(!(UCSR1A & (1<<RXC1)));
    daten+= UDR1;
    PORTD |= (1<<PD7);
}

...stimmt dann der erste Wert und alle weiteren stimmen nicht mehr. Der 
erste ist z.B. 19 Grad. Alle weitern Werte sind dann 9, die Daten Vom 
Sensor entsprechend umgerechnet.

Nach einem Reset des Controllers, wird als erster Wert wieder 19 
ausgelesen und alle weiteren Werte sind dann wieder 9.
Als Beispiel:

ALs erstes wird 0x09DF ausgelesen, dezimal sind das 2527.
Die nächsten Werte, die ausgelesen werden sind:
                0x04F7             dezimal sind das 1271.

Die 19 stimmen. Also es sind ca. 19 Grad, somit ist der Wert mal 
richtig. Nur warum liefert er beim zweiten Lesen, bzw. Ab dem zweiten 
Lesen falsche Werte?

Ich habe auch schon SPI vor jedem Abruf neu initialisieren lassen, aber 
das brachte auch keine Änderung.

Hat jemand eine Idee, wo da der Wurm drin sein könnte?

Stefan

[Sascha W. (sascha-w)]

Hallo,

wenn ich dein Program sehe sieht das erst mal nach UART und nicht nach 
SPI aus! Aber das ist ja alles eine Sache der Konfig.

Je nach Taktfrequenz deines AVR glaube ich kaum das du damit
_delay_ms(2000)
eine Pause von 2s erreichst! Warscheinlich ist die Pause so kurz, das du 
während der Wandlung schon wieder Daten ausliest.

Sascha

[Stefan (Gast)]

Hi und hallo zusammen,


das mit UART stimmt SPI-Modus eben.

Ich habe nun mal das delay deutlich vergrößert. Es liegen wirklich 
einige Sekunden zwischen den einzelen Datenabrufen. Es ist aber wie 
gehabt. Beim ersten Aufruf wird die richtige Temperatur ausgegeben z.B. 
20Grad und ab dem zweiten Abruf der Daten gibt der Sensor falsche Daten 
aus wie es scheint.

Komisches Phänomen. BEi 19 Grad beim ersten Abruf, kommen danach immer 
nur 9 an. Bei 20 Grad beim ersten Abruf kommen danach immer 10 raus. 
Wenn ich dann mal ne Lampe drauf halte und die Temperatur erhöhe, steigt 
der Wert...11,12,13 usw. Nur irgendie 10 Grad zu wenig...

Der Sensor wandelt auch kontinuierlich die Daten. Wenn dann ein CS 
während einer Wandlung kommt, wird weiter gewandelt und man erhält in 
dem Moment die letzten Daten. Von daher dürfte das mit dem Delay 
eigentlich eh egal sein.


Stefan

[Stefan (Gast)]

Hi und hallo zusammen,

neue Erkenntnisse.

Die Daten werden richti rausgesendet, kontrolliert mein einem feinen 
Oszi. Mal fix ausgeliehen :) Leider reicht meine Kasse nicht dafür :(

Das Problem muss irgendwie an der Speicerhung der Daten in den Variablen 
liegen, denn es wird immer die hälte dessen empfangen, was gesendet 
wird. Das meine ich im BEzug auf Umrechnung der Hex in Dez.

Z.B. sendet der SEnsor eine 0x0A 0x47 (Dez: 2631) steht in der Variable 
daten eine 1315, also die Hälfte.

Ich habe keinen Schimmer woher das kommen könnte. Schon komisch, dass es 
der Faktor 2 ist.

Stefan

[Stefan (Gast)]

Hi und hallo,

ich nochmal.

Dass es die hälfte ist, kommt daher, dass das Soll-Ergebnis eins zu weit 
rechts steht.

Also:

Soll 0x0A47, dez 2631 0000101001000111
Ist  0x0523, dez 1315 0000010100100011

Also funktioniert beim zweiten Durchgang die Bitschieberei anscheinend 
nicht.

Nur warum, das verstehe ich nicht. WEil es beim ersten Auslesen ja 
funktioniert.

Stefan

[Stefan (Gast)]

So, ichhabs. Es lag anden Edge und Phase Einstellungen des SPI.

Schwere Geburt:

UCPH1 und UCPOL1 dürfen beide nicht gesetzt sein. Ich hatte UCPOL1 
gesetzt. Deswegen funktionierte es nicht. Das erklärt glaube ich auch 
diese Bitverschiebung um 1 Bit aus meinem vorherigen Beitrag.

Vielen Dank!

Stefan

[Mirosa (Gast)]

Hast du es schon mal mit Software SPI versucht? Gibt es Unterschiede 
zwichen Mode 0 und 3? Stimmt das Timing der CS Leitung?

[Stefan (Gast)]

Hi und hallo,

Software SPI hatte ich noch nicht versucht. Das Timing der CS-Leitung 
stimmt.

Unterschied Mode 0 und 3 gibt es auf die Schnelle gesehen anscheinend 
nicht. Ich hatte mOde 2 eingestellt. Deshalb funktionierte das wohl 
nicht.

Stefan

[Mirosa (Gast)]

Schön das es jetzt geht. Ich hatte das gar nicht mitbekommen. Der letzte 
Beitrag den ich gesehen bzw. registriert habe war der von 20:36 Uhr. Ist 
mir direkt unheimlich...

[Stefan (Gast)]

Die SPI EInstelungen Mode XYZ können einen fast zur Verzweiflung 
bringen. ;)