MAX31855 antwortet nicht

Gast #3095926
Lesenswert?

Hallo Leute,

ich möchte einen MAX31855 über SPI mit einem Atmega8 auslesen. Der 
Atmega sowie der MAX laufen auf 3,3V. Angeschlossen ist der MAX mit

CS an PB2(SS)
SO an PB4(MISO) über einen 1,2k Widerstand
SCK an PB5(SCK)  über einen 1,2k Widerstand

Der SPI wird auch zur Programmierung (ISP) genutzt, deswegen die 
Widerstände in der MISO und SCK Leitung. Der ISP Programmer (STK500) ist 
direkt verbunden.

Wenn ich CS auf LOW ziehe und der Atmega einen Takt an SCK erzeugt 
sollte der MAX ja eigentlich anworten, wozu er sich allerdings nicht 
überreden lässt. Mit dem DSO lässt sich auch keine Reaktion erkennen. 
Ist der MAX vllt. kaputt, wie lässt sich das testen?

Mein SPI Routinen:
1
void SPI_init(void)
2
{
3
  SPI_DDR |= (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS); // MOSI, SCK an SS as output
4
  SPI_DDR &= ~(1 << SPI_MISO); // MISO as input
5

6
  SPI_PORT |= (1 << SPI_SS); // deselect slave
7
  _delay_ms(220);
8

9
  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1) | (1 << CPHA); // enable SPI, master, set clock rate fck/128  = 31,25kHz, clock phase
10
}
11

12
uint8_t SPI_recvByte(void)
13
{
14
  SPDR = 0;
15
  while(!(SPSR & (1 << SPIF))); // wait for reception complete 
16

17
  return(SPDR); // return data register
18
}
19

20
uint8_t SPI_getTemp(void)
21
{
22
  unsigned long value = 0;
23
  uint8_t temp = 0;
24
  uint8_t index = 0;
25
  uint8_t byte = 0;
26
  uint32_t buffer = 0;
27

28
  SPI_PORT &= ~(1 << SPI_SS); // select slave  
29
  _delay_ms(1);
30

31
  for(index = 3; index >= 0; index--)
32
  {
33
     byte = SPI_recvByte();  
34
     buffer |= (uint32_t)(byte << (8 * index));
35
  }
36

37
  SPI_PORT |= (1 << SPI_SS); // deselect slave
38

39
  value = (buffer >> 18);
40
  temp = (((value * 0.25) * 9) / 5) + 32;
41

42
  return(temp);
43
}

Wenn ich das Programm auf den µC schreibe führt er dieses vermutlich nur 
bis
1
while(!(SPSR & (1 << SPIF))); // wait for reception complete

aus, dann hängt er sich auf.
Gast #3096106
Lesenswert?

Hmm, also könnte man davon ausgehen das der MAX defekt ist. Ich habe 
beim verbinden des STK500 mit dem Breadboard (auf dem ich die Schaltung 
aufgebaut habe) für kurze Zeit den VTARGET Jumper des STK500 gesteckt 
gehabt. Warscheinlich hat dann das STK500 (5V) die Schaltung (3,3V) 
kurzzeitig hochgezogen.  Was meinst du mit Bit-Banging?
Gast #3096733
Lesenswert?

Tatsächlich, wenn ich den MAX wie folgt ansteuere:
1
_delay_ms(220);
2
SPI_PORT |= (1 << SPI_SS);
3
_delay_ms(1);
4
SPI_PORT &= ~(1 << SPI_SS);
5

6
for(uint8_t index = 0; index < 32; index++)
7
{
8
  _delay_us(100);
9
  SPI_PORT |= (1 << SPI_SCK);
10
  _delay_us(100);
11
  SPI_PORT &= ~(1 << SPI_SCK);
12
}
13

14
SPI_PORT |= (1 << SPI_SS);

Bekomme ich von ihm eine Antwort, erkennbar auf dem Oszi.

Warum geht das nicht mit dem Hardware SPI des Atmegas?
Ist die Taktrate zu hoch? Eig. nicht grenze liegt bei 5MHz.

Wann wird den SPIF gesetzt, im Datenblatt steht immer nur wenn die 
Übertragung beendet ist. Was heißt das explizit?
Gast #3097994
Lesenswert?

Am besten mal die CS/Clock Leitung am Oszi während des Bit-Bangings 
aufnehmen und dann mit dem HW-SPI output vergleichen. Evtl auch komplett 
ohne Slave... Die HW SPI vom Atmega ist zeitweise etwas zickig, da man 
durchaus z.B. bei der "Flanken-Triggerung" usw gern mal wo nen Config 
Bit falsch setzt.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren