ATMega328P - Hardware SPI - SCK hoert nach ein paar Durchlaeufen auf zu wackeln

[Avr N. (balze)]

Hallo zusammen,

ich wollte mir "nur mal eben schnell" mit einem µC eine Moeglichkeit 
aufbauen, um die Kennlinie eines NTCs zu ermitteln.

Dazu habe ich den NTC in der wie von mir gewuenschten Weise an einen 
Analogeingang des ATMega328P angeschlossen und mir einen digitalen 
Temperatursensor besorgt (TI LM95071).
Beide Messwerte werden dann per serieller Kommunikation an ein FTDI 
Modul uebergeben, das die Daten am USB Port eines PCs zur Verfuegung 
stellt.

Alle 10ms wird der Analogwert gelesen und ein Mittelwert ueber 16 
Messungen gebildet. Ich bekomme also alle ~160ms einen Messwert.

Flux das alte Testboard umgebaut und los geht's.

Funktioniert soweit, bis auf das Hardware SPI. :(
(Deaktiviere ich das SPI_MasterReceive() funktioniert es und ich bekomme 
den gemittelten Analogwert alle 160ms.)

Ich habe fuer den TI-Sensor Hardware SPI des 328P verwendet.
Leider klappt das nicht wie erwartet.

Die ersten 10 bis 15 SPI Zyklen (jeweils 2 Byte) klappen problemlos. 
Doch dann geht SCK zwischen zwei Übertragungen auf high und bleibt dort.

Am SCK-Pin (PB5) ist nur der ISP Konnektor angeschlossen. Dieser dient 
entweder zum Anschluss des AVRISP MKII oder des TI Sensors.

Der Effekt tritt allerdings auch auf, wenn nix (also kein Sensor und 
natuerlich kein AVRISP) angeschlossen ist. (Es liegt also nicht (!) am 
TI Sensor.)

Kann mir jemand sagen, was ich uebersehen habe ?!

Ich wuerde mich sehr freuen.

Ich hoffe der Code ist nicht zuuuu lang um ihn im thread anzuzeigen.

Vielen Dank,

Balze aka AVR_Noob

P.S.: Auf den Screenshots ist zu sehen:
1. Zwoelf erfolgreiche UEbertragungen nach Einschalten
2. Fehlverhalten von SCK nach der 12ten UEbertragung
3. Zwoelfte UEbertragung im Detail

main.c:

/* define CPU frequency in Mhz here if not defined in Makefile */
#ifndef F_CPU
#define F_CPU 6000000UL // Externer Takt von dem FTDI FT232R Module (6Mz)
#endif

#include <util/delay.h>
#include <stdlib.h>
#include <string.h>
#include <avr/io.h>
#include <inttypes.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>

#include "peter_fleury_usart\uart.h"
#include "spi.h"
#include "adc.h"

#define UART_BAUD_RATE      125000

#define CS_DDR  DDRC      // Chip Select fuer TI Temp Sensor
#define CS_PORT PORTC
#define P_CS  PORTC4


volatile uint32_t Zehn_Millisekunden = 0;

volatile uint32_t Mittelwert_ADC = 0;

volatile uint8_t Mittelwert_Zaehler = 0;

volatile uint8_t diesen_Mittelwert_ignorieren = 1;

volatile uint16_t Messungs_Zaehler = 0;

volatile uint16_t Messwerte[16]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

volatile char rs232_array[7] = {'_','_','_','_','_','_',0};


ISR(TIMER1_COMPB_vect)
{
  Zehn_Millisekunden ++;
}

ISR(ADC_vect)
{  
  uint16_t alter_Wert = Messwerte[Mittelwert_Zaehler];
  uint16_t neuer_Wert =  ADC;
  Messwerte[Mittelwert_Zaehler] = neuer_Wert;
  Mittelwert_Zaehler++;
  Mittelwert_ADC = Mittelwert_ADC + (uint32_t) neuer_Wert - (uint32_t) alter_Wert;
  if (Mittelwert_Zaehler >= 16)
  {
    Mittelwert_Zaehler = 0;
    if (diesen_Mittelwert_ignorieren)    // Der erste Mittelwert wird entsorgt !
    {
      diesen_Mittelwert_ignorieren = 0;
    }
    else                  // Zweiter und folgender Mittelwert
    {
      rs232_array[0] = (uint8_t) (Mittelwert_ADC>>12);  // >> 12 -> Division durch 16 entspricht schieben um 4
                          // schieben um 8 fuer das hoeherwertige Byte
      rs232_array[1] = (uint8_t) (Mittelwert_ADC>>4);
      CS_PORT &= ~(1<<P_CS);          // Chip Select auf low
      _delay_us(1);
      rs232_array[2] = SPI_MasterReceive();
      _delay_us(1);
      rs232_array[3] = SPI_MasterReceive();
      _delay_us(1);
      CS_PORT |= (1<<P_CS);          // Chip Select auf high
      _delay_ms(1);
      rs232_array[4] = (uint8_t) (Messungs_Zaehler>>8);
      rs232_array[5] = (uint8_t) (Messungs_Zaehler++);
      for (int i=0;i<7;i++)
        uart_putc(rs232_array[i]);
    }
  }
}

int main ()
{
  CS_DDR |=  (1<<P_CS),
  CS_PORT |= (1<<P_CS);

  TCCR1B = (1<<WGM12) | (1<<CS11) | (1<<CS10);
  TIMSK1 = (1<<OCIE1B);//(1<<OCIE1A) | (1<<OCIE1B);
  
  OCR1A = 937; // 937 fuer ~10 ms
  OCR1B = 937; // 937 fuer ~10 ms // OCR1B fuer das Triggern des ADCs
  TCNT1 = 0x00;

  uart_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU));
  init_ADC();
  SPI_MasterInit();

  sei();

  for (;;)
  {
  }
}

SPI.c:

#include <avr/io.h>
#include "spi.h"

#define SPI_DDR  DDRB
#define P_MOSI  PORTB3
#define P_MISO  PORTB4
#define P_SCLK  PORTB5


void SPI_MasterInit(void)
{
  /* Set MOSI and SCK output, all others input */
  SPI_DDR = (1<<P_MOSI ) | (1<<P_SCLK);
  /* Enable SPI, Master, set clock rate fck/16, SPI Mode 1 */
  SPCR = (1<<SPE) | (1<<MSTR) | (1<<CPHA);// | (1<<SPR0) | (1<<SPR1);
}

char SPI_MasterReceive()
{
  uint32_t counter = 0;
  /* Start transmission */
  SPDR = 0x00;
  /* Wait for transmission complete */
  while(!(SPSR & (1<<SPIF)))
  ;
  return SPDR;
}

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

Die Programmstruktur ist Murks.
Man macht sowas nicht im Interrupt:   while(!(SPSR & (1<<SPIF)));

Und überhaupt ist viel zu viel im Interrupt und viel zu wenig in der 
Hautpschleife. Warum heißt die Hauptschleife eigentlich 
Hauptschleife?

[Karlheinz (Gast)]

Hallo,

entrümple deine ISR mal ganz schnell.

ISR sind gedacht um mal schnell auf einen Event zu reagieren.
Du hast daraus das Hauptprogramm gemacht!

[Avr N. (balze)]

Da habt Ihr natuerlich beide Recht.

Aber sollte das Entruempeln wirklich mein komisches Problem loesen.

Zwischen "kein guter Stil" und "geht so nicht" ist ja noch ein 
Unterschied.

Danke erstmal, werde das nachher mal umstricken und ausprobieren ob das 
ursaechlich war.

Danke, mfG

Balze aka AVR-Noob

[Peter D. (peda)]

Avr Noob schrieb:
> Doch dann geht SCK zwischen zwei Übertragungen auf high und bleibt dort.

Vermutlich der SPI-Standardfehler, wie hast Du den /SS Pin beschaltet 
bzw. definiert?


Peter

[Avr N. (balze)]

Aeeeeehhhmm,

gar nicht :(

Ich habe vermutet, dass es egal ist welchen Pin ich fuer Chip(Slave) 
Select nehme.
(Ich sollte aufhoeren bei µCs Vermutungen anzustellen :)

Muss ich !SS behandeln als waere !SS der zustaendige Slave Select?
(als Ausgang definieren; low vor UEbertragung, high nach UEbertragung)

Danke, mfG

Balze aka AVR_Noob

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

Avr Noob schrieb:
> (Ich sollte aufhoeren bei µCs Vermutungen anzustellen :)
Ja, dagegen hilft das Datenblatt...

When the SPI is configured as a Master (MSTR in SPCR is set), the user can
determine the direction of the SS pin.

If SS is configured as an output, the pin is a general output pin which 
does not affect the SPI system. Typically, the pin will be driving the 
SS pin of the SPI Slave.

If SS is configured as an input, it must be held high to ensure Master SPI 
operation. If the SS pin is driven low by peripheral circuitry when the SPI 
is configured as a Master with the SS pin defined as an input ... the SPI 
system takes the following actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave.

[Avr N. (balze)]

Asche auf mein Haupt.

Ich muss gestehen, dass ich den Absatz "/SS Pin Functionality" komplett 
ueberlesen habe.

Sorry, dass ich Euch mit Anfaegnerfehlern dieZeit raube.

Dickes Danke!

Wird gleich ausprobiert (und hoffentlich in meinem nicht fluechtigen 
Speicher zwischen den Ohren abgelegt.)

MfG,

Balze aka AVR_Noob

[Avr N. (balze)]

Kurze Rueckmeldung, damit moeglicherweise jemand anderes mit einem 
aehnlichen Problem nachlesen kann, dass Peter Danneggers Frage und 
Lothar Millers Hinweis auf das Datenblatt die Loesung gebracht haben.

Es funktioniert!

Vielen Dank nochmal!

MfG,

Balze aka AVR_Noob

[Stefan (Gast)]

Den gleichen Fehler hatte ich auch gemacht, schätze darauf fallen viele 
Anfäger rein.

Auch AVR's verhalten sich nicht zu 100% so, wie man es vermutet. Man 
soll sich halt nicht auf Annahmen verlassen.