AVR Tempeatursensor auslesen SPI

Mit Hellsehen habens die meisten hier nicht so...
Tönt als würdest du mit der SPI was falsch machen... Hard- oder Soft 
SPI???

poste doch mal Schema + Software sonst wirds schwirig dazu was zu 
sagen...

Uwe schrieb:
> Die Clock läuft Ordnungsgemäß und CS eben auch, sonst würde ja auch gar
> nix ausgelesen.

Das ist kein Argument. Wenn du nicht den richtigen SPI Mode gesetzt 
hast, kann es übles Kuddel Muddel geben.

Wenn du das Programm postest, schreib doch auch bitte gleich, welchen 
Prozessor du verwendest und mit welcher Taktfrequenz du ihn betreibst.

Hallo,

ich verwende einen AT90CAN32; 16MHz

Hardware SPI.

Hier einmal die SPI Init:

1

void init(void)                

2

{

3

    SPI_PORT_DDR &=~(1<<SPI_MISO);           // miso auf input

4

    SPI_PORT_DDR |= (1<<SPI_Clock);          // clock auf output

5

    SPI_PORT_DDR |= (1<<SPI_MOSI);           // mosi auf output

6

    SPI_PORT_DDR |= (1<<SPI_SS);            

7

    DDRA |= (1<<PE2); 

8

    PORTE |= (1<<PE2);      // CS auf High                               

9

10

11

    SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<CPOL)|(1<<CPHA);    

12

              // SPI Enable

13

              // Master Select

14

              // f_clkio/64

15

              // Leading Edge -> Falling

16

              // Trailing Edge -> Rising

Hier folgt das Auslesen:

1

int main(void)

2

{

3

       cli();                       

4

       init();                  

5

sei();                       

6

7

    volatile uint16_t data;

8

9

    PORTE &= ~(1<<PE2);                // CS 

10

    _delay_us(10);                          

11

    SPDR= 0x00; 

12

    while(!(SPSR & (1<<SPIF)));             

13

    data= (SPDR<<8);                                         

14

    SPDR= 0x00;                             

15

    while(!(SPSR & (1<<SPIF)));             

16

    data+= SPDR;                            

17

    _delay_us(10);                           

18

    PORTE |= (1<<PE2);                   

19

20

    while(1)

21

    {

22

        ...

23

    }

24

}

Vielen Dank!
Gruß
Uwe

Hallo,

ich habe mittlerweise vorsichtshalber mal einen anderen Temperatursensor 
genommen, um auszuschließen, dass der eine kaputt ist oder so. Es ergibt 
sich aber das gleiche Bild. Es kommen Daten, aber nix gescheites.

Vielen Dank!
Gruß
Uwe

> data= (SPDR<<8)

Bin kein C-Experte, aber wenn SPDR 8bit sein sollte, ist dann nicht ein 
Cast erforderlich, damit die Bits nicht einfach verschwinden?

data = ((uint16_t)SPDR)<<8 ?

Hallo,

> data= (SPDR<<8)

Das dürfte auch so gehen. Ich konnte mir mittlerweile mal ein gescheites 
Oszi ausleihen. Damit kontrolliere ich die empfangenen Daten. Der Sensor 
spuckt immer 0x02 0x04 raus, egal welche Temperatur das ist. Wenn ich 
das im Code debugge, steht das auch so in den Variablen drin, d.h. dass, 
was vom Sensor gesendet wird, wird auch richtig empfangen. Nur die 
Daten, die der Sensor sendet sind irgendwie Müll, aber ich habe keine 
Ahnung, woran das liegen könnte. Wie oben geschrieben, habe ich den 
Sensor ja schon getauscht.

Vielen Dank!
Gruß
Uwe

Die Timing-Characteristics aus dem Datenblatt richtig umgesetzt
?

Hallo,

ich hoffe ja.

Usprünglich hatte ich mal mit folgendem angefangen

1

2

    SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<CPOL)|(1<<CPHA);    

3

              // SPI Enable

4

              // Master Select

5

              // f_clkio/64

6

              // Leading Edge -> Falling

7

              // Trailing Edge -> Rising

(1<<CPOL) und (1<<CPHA) habe ich jetzt mal weggelassen, aber das 
Ergebnis ist das selbe.
Ich habe verschiede Geschwindigkeiten probiert, aber auch das selbe 
Ergebnis.

Ich sehe es schon kommen, das hängt wieder nur an einer super 
Kleinigkeit.

Vielen Dank!
Gruß
Uwe

Hallo,

ich habe jetzt noch einmal mit den Einstellungen des SPI gespielt.

Ich habe einmal die Edge Einstellung geändert, das ändert aber leider 
nichts an meinem Ergebnis. Ich habe mal einen Screenshot vom SPI Signal 
angehängt.

Das ist mit den folgenden Einsellungen entstanden:

1

SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1); // f_clkio/128 bei 16MHz

Software SPI werde ich dann wohl mal als nächstes probieren. Mal sehen, 
ob es damit geht.

Vielen Dank!
Gruß
Uwe

Hallo,

jetzt weiß ich gar nicht mehr weiter.
 Ich habe jetzt einmal die lock per Software getoggelt und den 
Datenstrom mit einem Analyzer überwacht. Die Clock läuft wunderbar, CS 
ebenfalls, der Sensor spuckt Daten aus, aber wie oben 02h 04h. Das 
einzige, was anders ist, ist, das die Pause zwischen den beiden Byte 
Daten nicht vokommt, wenn ich die Clock per Software toggeln lasse.

In diesem Moment sende ich nix an den Sensor. Das verlangt der ja auch 
nicht.

Das verstehe wer will.

Vielen Dank!
Gruß
Uwe

Zuerst das Datenblatt:
http://www.analog.com/static/imported-files/data_sheets/ADT7301.pdf
Es wäre Deine Aufgabe gewesen, den Link zu posten.

Die Frage ist: wie hast Du Din (Pin 2) angeschlossen?
Wenn der auf H-Pegel liegt, geht das Device in den Stand-By-Mode, was 
eine solche Antwort erklären könnte.

Uwe schrieb:
> Ich habe mal einen Screenshot vom SPI Signal angehängt.

Verglichen mit dem Datenblatt (Figure 14. Serial Interface Timing 
Diagram)
ist dein Clock genau invertiert.
http://www.analog.com/static/imported-files/Data_Sheets/ADT7301.pdf

Bin gard nur mit dem iPad unterwegs aber mir scheint, dass mit dem Clock 
alles ok ist, ne Invertierung seh ich grad nicht, liegt aber vielleicht 
auch am Gerät.
Da aber immer das gleiche Signal kommt könnte ich mir auch eher sowas 
wie Stand By vorstellen.

0x204 sind 16,125°C.

Beim Auslesen der Daten wird immer gleichzeitig ins Config-Register 
geschrieben.

An sich ein schickes Teil (1/32 ° Auflösung), was kosten die und wo gibt 
es die?

Matthias hat Recht, der Ruhepegel von Clk sollte H sein.
Mit den 2 Bits CPOL und CPHA gibt es ja 4 Möglichkeiten (die schon 
manchen Entwickler zum Verzweifeln brachten), aufpassen: manchmal geht 
eine Richtung, aber die andere nicht, oder die Übertragung ist 
unzuverlässig, wenn diese Bits nicht stimmen.


SUPPLY DECOUPLING
The ADT7301 should be decoupled with a 0.1 μF ceramic capacitor between 
VDD and GND. This is particularly important if the ADT7301 mount is 
remote from the power supply.

Michael schrieb:
> Bin gard nur mit dem iPad unterwegs aber mir scheint, dass mit dem Clock
> alles ok ist, ne Invertierung seh ich grad nicht, liegt aber vielleicht
> auch am Gerät.

In dem Datenblatt liegt SCLK im Ruhezustand auf high, dann geht /CS auf 
low, dann folgt die Übertragung, SCLK geht wieder auf high und 
anschließen /CS auf high. Bei dir ist mindestens der Clock im Ruhzustand 
auf low.

Hallo,

eProfi schrieb:
> SUPPLY DECOUPLING
> The ADT7301 should be decoupled with a 0.1 μF ceramic capacitor between
> VDD and GND. This is particularly important if the ADT7301 mount is
> remote from the power supply.

Ist gemacht.

eProfi schrieb:
> An sich ein schickes Teil (1/32 ° Auflösung), was kosten die und wo gibt
> es die?

Die gibt es z.B. bei Schuricht ( www.distrelec.de ). Kosten 2,84 Euro.
Machen +-1Grad.

Matthias schrieb:
> In dem Datenblatt liegt SCLK im Ruhezustand auf high, dann geht /CS auf
> low, dann folgt die Übertragung, SCLK geht wieder auf high und
> anschließen /CS auf high. Bei dir ist mindestens der Clock im Ruhzustand
> auf low.

Das habe ich nun mit

1

SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<SPR0)|(1<<CPOL);

geändert. Die Clock leigt nun im Ruhezustand uaf High. Während dem 
Empfang sende ich zwei mal 0x00. Somit liegt der Pin 2 des Sensors auf 
Low und er dürfte nicht in den Ruhezustand kommen.

eProfi schrieb:
> Mit den 2 Bits CPOL und CPHA gibt es ja 4 Möglichkeiten (die schon
> manchen Entwickler zum Verzweifeln brachten)

Das kenne ich ;)

Im Anhang mal ein neue Screenshot mit den Einsellungen von oben. Signale 
von unten nach oben: MOSI, CS, CLOCK, MISO

Vielen Dank!
Gruß
Uwe

Liegt die Vcc genug lange vor dem Init an?
Mach mal ein Delay von 1,5 - 2 Sekunden vor und nach dem Init rein.
Du fragst ja auch nur einmal ab, versuche das öfters.

Hallo,

ich habe die Abfrage einmal in eine Schleife gepackt, aber es wird immer 
das gleiche vom Sensor gesendet.

Das mit dem Delay vor und nach dem Init habe ich auch versucht, das 
brachte aber leider auch keine Änderung.

Vielen Dank!
Gruß
Uwe

Da bin ich leider genauso ratlos wie Du.
Bitte messe mal direkt am Din-Pin, ob da wirklich L anliegt 
(Leitungsunterbrechung?).
Vielleicht liegt es an einer zu langsam ansteigenden Vcc (kein interner 
Reset)?

Wenn Du mir einen oder zwei schickst, versuche ich es mal.

Oder nimm was anderes. Wenn Du die hohe Auflösung brauchst: die alten 
Dallas mit den zwei Oszillatoren (z.B. DS1820, DS1620) haben eine sehr 
hohe (allerdings temperaturabhängige) Auflösung von < 0,01°C.
Beitrag "Re: DS18S20 hohe Auflösung berechnen"

Falls Du es schaffst: bitte hier posten, es interessiert mich / uns.

Hallo,

ich habe den Din-Pin jetzt einfach mal direkt auf Masse gezogen. Somit 
liegt auf jeden Fall immer Low am Din-Pin an. Daran lag es aber nicht.

Ich habe hier mal meine Kramkisten durchsucht und noch einen 
Temperatursensor von TI gefunden. Hatte ich wohl mal als Sample 
bestellt. Per SPI ausgelesen funktionierte auf anhieb. Komisch , 
komisch.

Ich habe noch zwei weitere von den ADTs hier. Die werde ich mal testen. 
Ich glaube aber eher nicht, dass die alle hin sind. Bis jetzt habe ich 
ja zwei probiert aus der gleichen Bestellung, aber bei beiden genau das 
gleiche Bild, deswegen denke ich, dass es doch an irgendwelchen SPI 
EInstellungen liegt.

Vielen Dank!
Gruß
Uwe

Hallo,

ich habe den Fehler wohl gefunden. Die Sensoren sind in Ordnung. Ich 
habe eine Platine mit dem Controller drauf undeine andere mit dem 
Sensor. Dazwischen ein Kabel. 25-30cm lang. Mit dem langen kabel kommt 
nur Mist raus.. Kürze ich das Kabel auf 5cm funktioniert alles 
wunderbar. Also liegt es wohl an den langen Kabeln. Da muss ich mir nun 
mal etwas einfallen lassen.

Gruß
Uwe

Danke, dass Du Dich nochmal rührst.
Bei langen Leitungen treten Reflexionen auf, wenn sie hart getrieben 
werden. Diese kann man dämpfen, indem man ein- oder beidseitig Rs 
einfügt:

    ------ R ------------------------------------------- R ------

Richtwert: 10 bis 100 Ohm