atmega32p verbinden mit attiny85 über SPI - Richtige SCK Frequenz

[derjaeger (Gast)]

Hallo,

ich möchte einen atmega328p (Master) über hardware-spi mit einem 
attiny85 (Slave) verbinden zum Datenaustausch (Slave=>Master). In wie 
weit ist das ein Problem bei der Übertragung und beim Slave Select, dass 
der Master mit 16 MHz angetrieben (Quarz) und der attiny mit 8 MHz 
internen Oszillator?

Ich hab beim Master die einen Prescaler die Möglichkeit eine 
CLK-Frequenz einstellen von 2 ... 128. Was ist der Mindestprescaler, 
damit der Slave nicht überfordert wird? Bei 2 würde ja die Frequenz am 
CLK Eingang des Slaves der Prozessorfrequenz entsprechen, ist das schon 
zuviel für die Auswertung?

Angehängt ist ein Ausschnitt aus dem Attiny85 Datenblatt (Serial 
Programming Characteristics).

Im Gegensatz zu I2C muss ich zwischen den beiden Mikrocontrollern keine 
Widerstände anbringen oder? Das der CS-Pin/SS-Pin softwareseitig vom 
Master selbst gesteuert werden muss ist mir bewusst und das er als 
Ausgang gesetzt werden muss.

Die ganze Aufgabe hat für mich einen Lerncharakter, um SPI etwas näher 
zu kommen.

[Wolfgang (Gast)]

derjaeger schrieb:
> Die ganze Aufgabe hat für mich einen Lerncharakter, um SPI etwas näher
> zu kommen.

Dann probiere es aus. Fange mit langsamem Takt an und dann steigere 
dich. Du merkst, wenn der Slave mit dem Takt nicht mehr mit kommt. Und 
vergiss nicht, dem Slave genügend Zeit zum Verarbeiten zuzugestehen.

[spess53 (Gast)]

Hi

>Ich hab beim Master die einen Prescaler die Möglichkeit eine
>CLK-Frequenz einstellen von 2 ... 128. Was ist der Mindestprescaler,
>damit der Slave nicht überfordert wird?

Der SPI-Takt des Masters muss kleiner als 1/4 des Taktes des Slaves 
sein.

MfG Spess

[Arno (Gast)]

derjaeger schrieb:
> ich möchte einen atmega328p (Master) über hardware-spi mit einem
> attiny85 (Slave) verbinden zum Datenaustausch (Slave=>Master). In wie
> weit ist das ein Problem bei der Übertragung und beim Slave Select, dass
> der Master mit 16 MHz angetrieben (Quarz) und der attiny mit 8 MHz
> internen Oszillator?

Das ist kein besonderes Problem, denn der ATMega328 kann den SPI-Takt ja 
entsprechend niedrig einstellen. Wie niedrig, das steht im Datenblatt 
des ATTiny85 unter

[quote 
http://www.atmel.com/images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf]
15.3.6 Clock speed considerations
Maximum frequency for SCL and SCK is f_CK / 2
[/quote]

> Ich hab beim Master die einen Prescaler die Möglichkeit eine
> CLK-Frequenz einstellen von 2 ... 128. Was ist der Mindestprescaler,
> damit der Slave nicht überfordert wird? Bei 2 würde ja die Frequenz am
> CLK Eingang des Slaves der Prozessorfrequenz entsprechen, ist das schon
> zuviel für die Auswertung?

...also ist f_CLK = f_CK zu viel. Und auf 4MHz würde ich mich auch nicht 
verlassen, denn so präzise ist der interne RC-Oszillator nicht.

> Angehängt ist ein Ausschnitt aus dem Attiny85 Datenblatt (Serial
> Programming Characteristics).

...was allerdings nicht die "normale" SPI-Schnittstelle beschreibt, 
sondern die Programmierschnittstelle. Die "normale" SPI-Schnittstelle 
ist beim ATTiny85 nicht vorhanden und muss vom USI im Three-Wire-Mode 
nachgebildet werden.

Zum Lernen sicherlich nicht ganz ideal, einfacher wären zwei ATMega328 
zu verbinden. Andererseits kannst du damit gleich ausprobieren, wie man 
eine SPI-Schnittstelle noch so bauen kann, wenn man keine vollständige 
Hardware dafür hat.

MfG, Arno

[derjaeger (Gast)]

>Zum Lernen sicherlich nicht ganz ideal, einfacher wären zwei ATMega328
>zu verbinden.

Ich gebe zu, ich habe eigentlich erwartet das beide Controller 
Hardware-SPI hätten (war so angegeben - Marketing halt), aber beim 
attiny ist aus berechtigten Gründen nur eine abgespeckte Version zu 
finden, ist aber nicht schlimm. Die Ansteuerung find ich halb so wild, 
der tiny soll ja nur Slave sein. Ein zweiten atmega328 hab ich aber auch 
rumliegen, ich finds aber zwischen zwei Serien interessanter.


Nach meinem Verständnis über SPI passiert beim Slave gar nichts, solang 
kein Takt ankommt. D.h. selbst wenn ich etwas ins 
Slave-SPI-Datenregister lege, "verrottet" es im Register solange bis der 
Master sich per Takt meldet, richtig?

Dann würd ich direkt beim Initialisieren schon was in den Sendepuffer 
reinlegen und nur noch daraufwarten (sleep) bis der Master mit dem Takt 
kommt.

Sowie ich es verstanden habe wird der Interrupt "USI Overflow" 
ausgelöst, wenn das Byte vom Master komplett abgeholt wurde.

Könnte ich fürs erste auf eine SS-Ansteuerung bei einem Slave verzichten 
und immer nur auf den "USI Overflow" Interrupt warten, um ständig den 
Sendepuffer nachzufüllen? Erscheint mir am einfachsten zu realisieren 
beim Tiny.

[derjaeger (Gast)]

Ist eine Implementierung denkbar für den SS-Pin beim Slave, dass bei 
einem HIGH auf dem SS-Pin der SCK-Pin des Slaves als AUSGANG geschaltet 
ist (damit nicht das falsche Senderegister ausgelesen wird) und erst 
wenn der jeweilige SS-Pin auf LOW ist, wird zügig der Slave-SCK-Pin als 
Eingang geschaltet.

Oder aktiviert/deaktiviert man einfach immer zwischen den SS-Flanken das 
gesamte SPI-Modul?

[Peter D. (peda)]

derjaeger schrieb:
> Könnte ich fürs erste auf eine SS-Ansteuerung bei einem Slave verzichten

Das machen auch einige und wundern sich dann, wenn die Übertragung 
unzuverlässig ist und aus dem Ruder läuft.
Es reicht dazu der kleinste Störimpuls. Oder der Master beginnt früher, 
als der Slave bereit ist. Oder der Slave ist früher bereit und nimmt 
einfach nen Puls auf dem noch floatenden SCK-Pin als Takt.

Das Slave-SPI ist auf den AVRs eh kritisch (Timing), da muß man nicht 
noch weitere Probleme hinzufügen.

Für MC-MC Kommunikation ist das I2C erheblich besser geeignet, da der 
Slave mit Clock-Stretching dem Master Bescheid gibt, wann er das nächste 
Byte senden darf. Es gibt also keine Timingprobleme oder verlorene 
Daten.

[derjaeger (Gast)]

Hallo,

ich hab ein merkwüdiges Verhalten bei meinem tiny85-Slave.

Ich will das der tiny an den Master senden soll erst NACH dem 
erfolgreichen SS-Pin (=LOW). Damit meine ich das Beschreiben des 
Sendepuffers mit dem Byte. Das Erkennen des Slave-Selects erfolgt per 
PCINT.


Master-Seite:

spi_init(); //enable, clock
while(TASTER nicht gedrueckt);
slave_select();
delay(1s);

//...dummybyte senden...
[code]

Slave-Seite:

[code]
spi_init();
(1) sendepuffer=Daten (<== klappt)
while(slaveflag = high);
(2) sendepuffer=Daten (1<== klappt nicht)

Problem:
(1) wird ausgefuehrt, (2) wird immer "ignoriert". Wenn ich (2) direkt in 
die PCINT Interruptroutine packe, wird es auch ausgeführt:

if(POSITIVE FLANKE)
{
//nichts machen
}
else
{
 sendepuffer=Daten
 slaveflag=low
}

Wo könnte der Unterschied zwischen (2) und der Interruptroutine liegen?

[S. Landolt (Gast)]

slaveflag ohne volatile?

[derjaeger (Gast)]

>slaveflag ohne volatile?

Das wars. Danke.

Jetzt funktioniert das Senden von einem Byte vom attiny85 zum 
attiny328p. Das Senden eines Puffers hat noch Synchronisationprobleme 
zwischen beiden Seiten, sodass die Daten nicht in der richtigen 
Reihenfolge ankommen.

Das Senden eines Bytes hat funktioniert mit folgenden SCK Werten:

Prescaler 8  (SCK=2 MHz)  (auch mit mehreren Bytes hintereinander)
Prescaler 16 (SCK=1 MHz)
Prescaler 64 (250 kHz)
Prescaler 128 (125 kHz)

[neuer PIC Freund (Gast)]

while(slaveflag == high);

Hat da der compiler nicht gemeckert?

[derjaeger (Gast)]

>Hat da der compiler nicht gemeckert?

Leider nicht. Nichtmal eine Warnung. Ich benutze avr-gcc und laut 
Eclipse ist 'W-all' eingeschaltet.

[derjaeger (Gast)]

Der Optimierungslevel steht auf "Size optimized (-Os)"

[Wolfgang (Gast)]

derjaeger schrieb:
> Jetzt funktioniert das Senden von einem Byte vom attiny85 zum
> attiny328p.

SPI tauscht immer Bytes zwischen Master und Slave aus und der Master 
gibt den Takt für den Austausch an. Der Slave kann überhaupt nicht 
selbständig über SPI senden. Was machst du da?

[derjaeger (Gast)]

>Der Slave kann überhaupt nicht selbständig über SPI senden. Was machst du da?

Der Slave sendet nicht selbst, sondern wartet das sich der Master sein 
Byte über den Takt abholt. Dazu sendet der Master "dummy"-Bytes, die der 
Slave nicht interpretiert.

Der Satz war technisch nicht richtig und sollte die gewünschte Aufgabe 
beschreiben, das der Master nur Bytes empfangen will.

Noch eine Frage zu SPI: Ist es für die Synchronisation sinnvoll bzw. 
üblich, nach jedem empfangenen/gesendeten Byte das Slave Select für eine 
kurze Zeit wieder auf HIGH zu setzen?

Damit wüsste der Slave immer bei jeder fallenden Flanke, dass z.B. nach 
5 ms in seinem Slave-Sendepuffer etwas drin stehen muss, sonst ist er zu 
spät.

[S. Landolt (Gast)]

Ich würde innerhalb einer Nachricht das Slave-select auf low lassen, die 
einzelnen Bytes der Nachricht im Slave per ISR, zugelassen über 
USICR.USIOIE, bereitstellen; natürlich muss der Master dann die maximale 
Interruptlatenz des Slave berücksichtigen.
  Ausprobiert habe ich das aber nicht, ich greife eher zu einem ATmega, 
bevor ich mit dem USI arbeite.

[derjaeger (Gast)]

>Ich würde innerhalb einer Nachricht das Slave-select auf low lassen, die
>einzelnen Bytes der Nachricht im Slave per ISR

Das habe ich nicht hinbekommen, weil ich das Datenblatt vom attiny nicht 
gründlich gelesen hatte. Denn dieses "Byte gesendet" - Flag setzt sich 
selbst nicht zurück. Man muss es mit einer "1" im Flagregister selbst 
zurücksetzen:

"If USISIE bit in USICR and the Global Interrupt Enable Flag are set, an 
interrupt will be generated when this flag is
set. The flag will only be cleared by writing a logical one to the 
USISIF bit."

Schon tückisch sowas. Ich war naiv zuglauben, dass es ausreicht in der 
jeweiligen ISR den Code einfach auszuführen. Klappt aber jetzt!


Na wie dem auch sei, ich poste einfach mal meinen Code für die Nachwelt. 
Soooo schwer ist das USI auch nicht als SPI-Slave-Interface :-)

Master atmega:

void spi_master_init(void)
{
  DDRB |= (1<<PB2);//output
  PORTB |= (1<<PB2);//ss:high
  DDRB |= (1<<PB5);  //SCK: output
  DDRB |= (1<<PB3);   //MOSI:out
  DDRB &= ~(1<<PB4);   //MISO:in
  SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0);
}

uint8_t spi_master_receive(void)
{
  uint8_t dummybyte = 0x77;
  uint8_t recvdbyte = 0x00;

  SPDR = dummybyte;
  while (!(SPSR & (1<<SPIF)));

  recvdbyte = SPDR;
  return recvdbyte;
}

int main(void)
{
  char buffer[100]={0};
  uint8_t i = 0;
////////////////
  spi_master_init();
  //===================================
  spi_start_spi();//select slave: SS low
  for(i=0;i<masterdata_cnt;i++)
  {
      _delay_ms(10);//give slave time to prepare
      buffer[i]=(char)spi_master_receive();
            //sends dummy bytes to generate CLK for slave
  }
  //===================================
  spi_stop_spi();//do not select slave: SS high

Slave tiny

void spi_slave_init_usi(void)
{
  DDRB &= ~(1<<PB0); //MOSI:input
  DDRB |= (1<<PB1); //MISO:output
  DDRB &= ~(1<<PB2); //SCK:input
  DDRB &= ~(1<<PB3); //SS:input

  // enable PCINT3
  PCMSK = (1<<PCINT3);
  GIFR = 0; //clear interrupt flag
  GIMSK = (1<<PCIE);
  sei();

  //enable SPI interface (three wiremode)
  USICR = (1<<USIWM0) | (1<<USICS1) | (1<<USIOIE);
}

ISR(PCINT0_vect)//Slave Select
{
  if( !((PINB) & (1<<PB3)) )
  {  // SLAVE SELECT: LOW
          if(count >= masterdata_cnt)
    {
      count = 0;
    }
    USIDR = masterdata[count];//first byte
    count++;
  }
}

ISR(USI_OVF_vect)//Synchronization
{
  USISR |= (1<<USIOIF); // DO NOT FORGET TO CLEAR IFG

  if(count >= masterdata_cnt)
  {
    count = 0;
  }
  USIDR = masterdata[count];
  count++;
}

int
main(void)
{
  _delay_ms(1000); // wait for SS pin of master is high 
  spi_slave_init_usi();
        while(1);
}

[derjaeger (Gast)]

Nachtrag:
Hab den falschen Text aus dem Datenblatt kopiert (falsches Flag). Hier 
der richtige: "This flag is set (one) when the 4-bit counter overflows 
(i.e., at the transition from 15 to 0). If the USIOIE bit in
USICR and the Global Interrupt Enable Flag are set an interrupt will 
also be generated when the flag is set. The
flag will only be cleared if a one is written to the USIOIF bit."