SPI Winkelsensor Novotechnik RFC4800 will nicht

[Jan (Gast)]

Hallo,

ich will mit einem Olimex AT90CAN128 Board 16-Bit Werte eines 
Winkelsensors RFC 4800 von Novotechnik über CAN-Bus senden. Der Bus 
funktioniert und läuft mit der CAN-Lib von Marco Glietsch 
Beitrag "CAN-Bibliothek für den at90CAN128 und das AVRStudio".
Angeschlossen ist der Sensor wie in der angehängten 
Applikation-Note(Anhang) des Herstellers beschrieben. Als FET habe ich 
den BS170 verwendet(Anhang).
MISO --> Drain
MOSI --> Gate
GNG  --> Source
Die Wiederstände habe ich wie in Zeile 4 (Atmel AVR) der Tabelle 
beschrieben gewählt. Sicherheitshalber hab ich die Schaltung nochmal 
durch gemessen. Soweit ok.

Nun habe ich meine Quellcode auf Basis verschiedener Beispiele u.A. aus 
dem Datenblatt vom Controller und AVR151(Setup And Use of The SPI) 
aufgesetzt. So weit ich es verstanden habe muss der Sensor in SPI Mode 1 
betrieben werden. Also CPHA=1 und CPOL=0. Laut Support des Herstellers 
soll ich die SCK-Frequenz auf 50kHz stellen.
Dazu habe ich einmal den IO-Clock Prescaler (CLKPR) auf 4  und dann noch 
den SPI-Clock Prescaler auf 128 gesetzt um von 16MHz CPU auf 62,5kHz 
SCK-Frequenz zu kommen.

Nach langem rumgefummel habe ich es hin bekommen, dass der Anfrage-Frame 
gesendet wird (0x55, 0x00...[Laut Hersteller soll ich die invertierten 
Signale von dem was in der Appikationnote steht senden]). Dazu ziehe ich 
den SS-Pin erst auf Low und warte 1,5ms damit sich Master und Slave 
synchronsieren. Dann SS-Pin wieder hoch für Mastermode und 
Master-Enable, weil durch SS:low Master disable (MSTR in SPCR). Dann 
senden nach dem in Beispielen üblichen Schema.

Anschließend wechsel ich durch SS-Pin auf Low in den Slavemode um Daten 
zu empfangen. Mit der ebenfalls nach üblichem Schema aufgebauten 
receive-Methode empfange ich dann zwei Bytes, aber beim dritten 
Durchlauf der Methode wird while(!(SPSR & (1<<SPIF))) nicht mehr 
verlassen.

Nun verstehe ich nicht warum das passiert. Darf ich den SS-Pin nicht auf 
Low ziehen? Ist die Frequenz ok? Nächst kleinere wäre 31,25kHz. Was ja 
viel zu kurz wäre. Muss ich das DDR-Register im Slavemode umstellen? 
Also "MISO output, all others input". Z.z sieht es so aus:

SPI_DDR = (1<<SPI_DDR_MOSI)|(1<<SPI_DDR_SCK);

Anbei der SPI-Quellcode, in dem ich zur Kontrolle Ausgaben auf ein LCD 
mache. Anbei auch ein Bild des LCD, damit man sich das besser vorstellen 
kann. Weitere Ausgaben in der Main...

#include "PORT.h"
#include "SPI.h"
#include "LCD.h"

int8_t i=0;

void SPI_init(void)
{
  //Enable SPI
  //Mastermode
  //SPI Mode 1 (CPOL=0 | CPHA=1)
  /*
  SPI2X|SPR1|SPR0|SCK Frequency
  0   |0   |0   |fclkio/4
  0    |0   |1   |fclkio/16
  0    |1   |0   |fclkio/64
  0    |1   |1   |fclkio/128
  1    |0   |0   |fclkio/2
  1    |0   |1   |fclkio/8
  1    |1   |0   |fclkio/32
  1    |1   |1   |fclkio/64  
  F_SCK = F_CLK/PR_SPI = F_CPU/PR_CLK/PR_SPI = 
  16000kHz/4(CLKPR)/128(SPCR) = 62,5kHz*/
  SPCR = (1<<SPE)|(1<<MSTR)|(1<<CPHA)|(1<<SPR1)|(1<<SPR0);
  
  //Wait for RFC 4800 startup
  _delay_ms(16); 
}

void SPI_select_mastermode(void)
{
  /* To synchronize communication, the master deactivates /SS high for at least 
  t5 (1,5ms). In this case, the slave will be ready to receive a new frame.*/
  SPI_PORT &= ~(1<<SPI_PIN_SS);
  _delay_us(1500);
  
  /*In master mode, the SS pin must be held high to ensure master SPI operation*/
  SPI_PORT |= (1<<SPI_PIN_SS);
  
  /*Once the MSTR bit has been cleared by a low level on the SS line, 
  it must beset by the application to re-enable SPI master mode.*/
  SPCR |= (1<<MSTR);
}

void SPI_select_slavemode(void)
{
  //Chipselect Active Low
  SPI_PORT &= ~(1<<SPI_PIN_SS);
  _delay_us(1500);
}

void SPI_master_transmit(char data)
{
  //write param to SPI data register
  SPDR = data;

  //Wait for transmission to complete
  while(!(SPSR & (1<<SPIF)));
}

char SPI_slave_receive(void)
{
  LCD_displayInt8(3,4,i);
  //Wait for transmission to complete
  while(!(SPSR & (1<<SPIF)));
  LCD_displayInt8(3,6,i);
  i++;
  return(SPDR);
}

Und hier die Main. Die Delays nach den LCD-Methoden sind nur wegen 
Timing-Problemen des Displays die ich auch noch fixen muss.

#define F_CPU 16000000

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

#include "PORT.h"
#include "LCD.h"
#include "CAN.h"
#include "ADC.h"
#include "SPI.h"

uint16_t adc_var=0;
uint16_t adc_var_high=0;

uint8_t angle_var_lsb=0;
uint8_t angle_var_msb=0;

int main(void)
{
  PORT_init();
  ADC_init();
  LCD_init();
        LCD_clear();
  SPI_init();
  
  
  /*SET CLOCK PRESCALER
  CLKPS3|CLKPS2|CLKPS1|CLKPS0|Clock Division Factor
  0    |0   |0    |0     |1
  0    |0   |0   |1      |2
  0    |0   |1   |0      |4
  0    |0   |1   |1      |8
  0    |1   |0   |0      |16
  0    |1   |0   |1      |32
  0    |1   |1   |0      |64
  0    |1   |1   |1      |128
  1    |0   |0   |0      |256  
  
  F_CLK = F_CPU/PR_CLK =
  16MHz/2 = 8MHz*/
  CLKPR |= (1<<CLKPCE)|(1<<CLKPS0);
  
  CAN_init(500,RX);//(500kBaud, Interrupt für Empfang)
  
  // Definition von CAN message structs
  CAN_message    msg;
  // ID-Maske festlegen -> alle IDs akzeptiert
  msg.idm = 0x00000000;   
  //CAN MOB aktivieren
  CAN_enableMOB(0,TRANSMIT_DATA,msg);  
  CAN_enableMOB(1,TRANSMIT_DATA,msg);  
  
    while(1)
    {
    //Get ADC Voltage value
    adc_var = ADC_readMeanValueOf(5);
    adc_var_high = (adc_var >> 8);
    
    CAN_senden(0,0x100,8,adc_var_high,adc_var,0x00,0x00,0x00,0x00,0x00,0x00);
    
    //Send SPI data request frame
    SPI_select_mastermode();
    SPI_master_transmit(0x55);
    
    LCD_displayInt8(3,0,1);
    _delay_ms(1);
    
    for(int i=0; i<9;i++)
    {
      SPI_master_transmit(0x00);
      LCD_displayInt8(3,2,i+1);
      _delay_ms(1);
    }
    
    //Read SPI data frame
    SPI_select_slavemode();
    
    LCD_displayInt8(0,0,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(0,2,SPI_slave_receive());
    _delay_ms(1);
    angle_var_msb = SPI_slave_receive();
    LCD_displayInt8(0,4,angle_var_msb);
    _delay_ms(1);
    angle_var_msb = SPI_slave_receive();
    LCD_displayInt8(0,6,angle_var_lsb);
    _delay_ms(1);
    LCD_displayInt8(1,0,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(1,2,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(1,4,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(1,6,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(2,0,SPI_slave_receive());
    _delay_ms(1);
    LCD_displayInt8(2,2,SPI_slave_receive());
    _delay_ms(1);
    
    CAN_senden(0,0x200,8,0xFF,0xFF,angle_var_msb,angle_var_lsb,0x00,0x00,0x00,0x00);
    _delay_ms(1000);
    }
}

Und noch die Mail vom Support:
> sie verwenden sicherlich den im Datenprotokoll angegebenen FET, da
> wir die 3-Leitertechnik verwenden. Der eingesetzte chip ist ein
> Melexis 90316 und bietet dieses 3-Leiter Version an.
> Um den eingesetzten Transistor zu sperren um Daten zu empfangen senden
> Sie  anstatt (AA,FF,FF,..) bitte die invertierten Signale (55, 00,00,..)
> um den Transistor zu sperren.
> Dann müssten Sie die Daten empfangen können. Bitte achten Sie darauf,
> dass die timings eingehalten werden.
> Bei einer clock rate von 50kHz müsste dies automatisch der Fall sein.

So ich hoffe ich habe alles geschrieben was wichtig sein könnte. Danke 
schon mal für die Hilfe und dafür dass du bist ganz unten gelesen hast 
:)

[holger (Gast)]

>Dazu ziehe ich
>den SS-Pin erst auf Low und warte 1,5ms damit sich Master und Slave
>synchronsieren. Dann SS-Pin wieder hoch für Mastermode und
>Master-Enable, weil durch SS:low Master disable (MSTR in SPCR).

So ein Unsinn. SS schaltet den Master nur auf Slave um
wenn es ein EINGANG ist. SS als Ausgang kann man
nutzen um das SlaveSelect des Slaves zu steuern. Dazu legt
man SS auf low wenn man den Slave ansprechen möchte.
Beim lesen UND beim schreiben.

Den Master hier auf Slave umschalten zu wollen macht gar
keinen Sinn. Wer soll denn dann den SPI Takt liefern?
Dein Slave macht das jedenfalls nicht. Der Master empfängt
indem er DummyBytes sendet. Nur so wird der SPI Takt erzeugt.

[Jan (Gast)]

Also bleibt der SS-Pin die ganze Zeit auf Low in meinem Fall, weil nur 
ein Master und ein Slave? So war ich drauf gekommen: 
http://www.atmel.com/images/doc2585.pdf
Seite 3 SS-Pin Funcionality

[holger (Gast)]

>Also bleibt der SS-Pin die ganze Zeit auf Low in meinem Fall,

Nein, SS legt man nur low wenn etwas gelesen, geschrieben
werden soll. Wenn man damit fertig ist zieht man SS auf high.
So bleibt das SPI immer schön synchron.

[Jan (Gast)]

holger schrieb:
> Der Master empfängt
> indem er DummyBytes sendet. Nur so wird der SPI Takt erzeugt.

Also so:

char SPI_receive(void)
{
  LCD_displayInt8(3,4,i);

  SPDR = 0x00;
  
  //Wait for transmission to complete
  while(!(SPSR & (1<<SPIF)));
  LCD_displayInt8(3,6,i);
  i++;
  return(SPDR);
}

holger schrieb:
> Nein, SS legt man nur low wenn etwas gelesen, geschrieben
> werden soll. Wenn man damit fertig ist zieht man SS auf high.
> So bleibt das SPI immer schön synchron.

void SPI_SS_high(void)
{  
  SPI_PORT |= (1<<SPI_PIN_SS);
  
  SPCR |= (1<<MSTR);
}

void SPI_SS_low(void)
{
  SPI_PORT &= ~(1<<SPI_PIN_SS);
  
  _delay_us(1500);
}

Muss MSTR in SPCR nochmal gesetzt werden?

Jan schrieb:
> http://www.atmel.com/images/doc2585.pdf
> Seite 3 SS-Pin Funcionality

Dort steht:
A low level will switch the SPI into slave mode and the hardware of the 
SPI will perform the following actions:
1.    The master bit (MSTR) in the SPI Control Register (SPCR) is 
cleared

In der Main sieht es jetzt so aus:

int main(void)
{
  PORT_init();
  LCD_init();
  SPI_init();
  LCD_clear();

  CLKPR |= (1<<CLKPCE)|(1<<CLKPS0);

  
    while(1)
    {
    SPI_SS_low();
    
    for(int i=0; i<10;i++)
    {
      if(i)
        SPI__transmit(0x00);
      else
        SPI__transmit(0x55);
        
      LCD_displayInt8(3,2,i);
      _delay_ms(1);
    }
    
    for(ini i=0; i<3; i++)
    {
      for(int ii=0; ii<8; ii+=2)
      {
        LCD_displayInt8(i,ii,SPI_receive());
        _delay_ms(1);
      }
    }

    SPI_SS_high();
    
    _delay_ms(100);
    }
}

[Jan (Gast)]

Hmm nach dem ersten Trasmit bleibts wieder hängen. Seltsamerweise blinkt 
auch in der zweiten Zeile, jedesmal wenn ich das Netzteil ein- und 
ausschalte eine 666 auf. Das Anweisung dafür ist längst gelöscht, weil 
ich nur was testen wollte. Oo
Extra in AtmelStudio auch ganz sicher nochmal die Datei vorm flashen 
ausgewählt. Seltsam oder?