SPI übertragungsablauf

[Kimmy (Gast)]

Tag,
eine Frage zum ablauf einer Übertragung von Nachrichten über SPI.

Controller A sendet Daten nach Controller B.
Controller setzt einen Pin auf high und startet direkt danach die 
ÜBertragung. Nach der Übertragung wird der Pin wieder auf Low gesetzt.
Im Controller B wird durch dem von Controller A auf high gesetztem Pin 
ein Interrupt ausgelöst. In der ausgelösten ISR werden die Daten, 
herausgeholt.

Wie schnell sind die Daten vom Controller A da? Kann es vorkommen, dass 
Controller B die Daten abfragt obwohl die Übertragung noch gar nicht 
abgeschlossen ist? Also Controller A sendet noch und Controller B fragt 
schon ab.

Eigentlich werden die Daten doch alle zunächst automatisch in einem 
Register gespeichert, wo ich mir die nur rausziehe oder?

Aber wie kann ich sicher sein, dass die Übertragung zu ende ist?
Oder wie frage ich am besten nach den Daten ab?

Kimmy

[Falk B. (falk)]

@ Kimmy (Gast)

>Controller A sendet Daten nach Controller B.
>Controller setzt einen Pin auf high und startet direkt danach die
>ÜBertragung.

Jain. Meistens sind die Chip Select Signale Low aktiv, d.h. für die 
Auswahl des SPI-Slave wuird das SIgnal auf LOW gesetzt und am Ende 
wieder auf High.

>Nach der Übertragung wird der Pin wieder auf Low gesetzt.
>Im Controller B wird durch dem von Controller A auf high gesetztem Pin
>ein Interrupt ausgelöst. In der ausgelösten ISR werden die Daten,
>herausgeholt.

Jain. Der Empfänger kann auch mehrere Bytes empfangen und dann muss er 
schon, sobal das CS-Signal aktive (=low) wird in die passende ISR 
springen.

>Wie schnell sind die Daten vom Controller A da?

So schnell, wie er sie sendet.

> Kann es vorkommen, dass
>Controller B die Daten abfragt obwohl die Übertragung noch gar nicht
>abgeschlossen ist?

Nein, denn Controller A gibt den Takt vor.

>Also Controller A sendet noch und Controller B fragt
>schon ab.

Geht nicht.

>Eigentlich werden die Daten doch alle zunächst automatisch in einem
>Register gespeichert, wo ich mir die nur rausziehe oder?

Ja. Und wenn die Übertragung von einem Byte abgeschlossen ist, wird ein 
passendes Flag in einem IO-Register gesetzt. Das muss der Empfänger 
abfragen und dann die Daten auslesen.

[Kimmy (Gast)]

Ja, das mit dem Aktive Low für den SlaveSelect war mir bekannt, hatte 
ich jetzt aber vergessen. Werde ich aber so umsetzen.


Falk B. schrieb:
> Ja. Und wenn die Übertragung von einem Byte abgeschlossen ist, wird ein
> passendes Flag in einem IO-Register gesetzt. Das muss der Empfänger
> abfragen und dann die Daten auslesen.


Also Controller A setzt den Pin auf Low und fängt an zu übertragen.
Controller B springt in die ISR und wartet, bis die Übertragung beendet 
ist.

richtig?

[Sto (Gast)]

Kimmy schrieb:
> Controller A sendet Daten nach Controller B.
...
> Wie schnell sind die Daten vom Controller A da? Kann es vorkommen, dass
> Controller B die Daten abfragt obwohl die Übertragung noch gar nicht
> abgeschlossen ist? Also Controller A sendet noch und Controller B fragt
> schon ab.

Am besten dürfte es sein, dass wir nicht von Controller A und B sondern 
von Master und Slave sprechen. Der Master bestimmt die Geschwindigkeit 
(er gibt die Clock vor) und dementsprechend auch wann was passiert. Nur 
der Master kann Übertragungen beginnen. Das muss man als Programmierer 
natürlich im Master richtig handeln, dass sich da nichts überschneidet. 
Der Slave muss natürlich entsprechend reagieren können, wenn der Master 
seine Anfragen sendet - das muss bei der Programmierung des Masters 
beachtet werden.

Kimmy schrieb:
> Controller B springt in die ISR und wartet, bis die Übertragung beendet
> ist.
>
> richtig?

Das kann man so pauschal nicht sagen. Meistens wird der Interrupt erst 
ausgelöst, wenn die Übertragung (für gewöhnlich 8 bit) beendet ist. Dann 
steht das Ergebnis in einem Register und kann verarbeitet werden. 
Größere Controller haben einen Puffer oder DMA, damit man nicht ständig 
mit Interrupt Requests zugeballert wird. Das wäre z.B. bei einem 30 MHz 
SPI ziemlich nervig, wenn mit ca. 3,75MHz Interrupt Requests (IRQs) 
kommen.

[Kimmy (Gast)]

Sto schrieb:
> Meistens wird der Interrupt erst
> ausgelöst, wenn die Übertragung (für gewöhnlich 8 bit) beendet ist.

Dazu habe ich noch einmal eine Frage
Das Auslösen des Interrupts mache ich ja mit einem extra pin. Ich muss 
bei der Programmierung selber den Pin auf Low und dann wieder auf High 
setzen, wodurch beim Slave der Interrupt ausgelöst wird.
Soll ich diesesn wechsel dann erst nach dem senden machen?

Die Sende-Funktion sieht ja wie folgt aus

void spi_transmit (uint8_t data)
{
  SPDR = data;
  while((SPSR & (1<<SPIF))==0);
}

angenommen, der SlaveSelect Pin ist auf PB0

soll ich dann nach der while-schleife PB0 auf low setzen und sofort 
wieder auf high?

ich hätte jetzt vor der while schleife PB0 auf low gesetzt und danach 
wieder auf high.
Dann wäre es aber wie ich denke, dass der Slave empfängt, während der 
Master noch sendet

ISR vom Slave:

ISR(INT0_vect){
while(!(SPSR & (1<<SPIF)))
received_data = SPDR;
}

[Falk B. (falk)]

@ Kimmy (Gast)

>> Meistens wird der Interrupt erst
>> ausgelöst, wenn die Übertragung (für gewöhnlich 8 bit) beendet ist.

Das kann man machen, das macht den Slave aber nochmal langsamer.

>Das Auslösen des Interrupts mache ich ja mit einem extra pin. Ich muss
>bei der Programmierung selber den Pin auf Low und dann wieder auf High
>setzen, wodurch beim Slave der Interrupt ausgelöst wird.

Ja.

>Soll ich diesesn wechsel dann erst nach dem senden machen?

Nein.

>void spi_transmit (uint8_t data)
>{
>  SPDR = data;
>  while((SPSR & (1<<SPIF))==0);
>}

Soweit OK.

>angenommen, der SlaveSelect Pin ist auf PB0

Also sind deine Controller AVRs.

>soll ich dann nach der while-schleife PB0 auf low setzen und sofort
>wieder auf high?

Nein! VOR der Übertragung setzt man CS auf LOW, DANACH wieder auf High!

>ich hätte jetzt vor der while schleife PB0 auf low gesetzt und danach
>wieder auf high.

Genau so!

>Dann wäre es aber wie ich denke, dass der Slave empfängt, während der
>Master noch sendet

Muss er doch!


>ISR vom Slave:

>ISR(INT0_vect){
>while(!(SPSR & (1<<SPIF)))
>received_data = SPDR;
>}

Genau so.

[Kimmy (Gast)]

Der Slave sollte ein Attiny2313 sein. Ist es mit diesem überhaupt 
möglich Daten zu empfangen? Wenn ja, wie? Im Datenblatt stehen leider 
nur Beispiele wie man Daten Sendet.

[holger (Gast)]

>Im Datenblatt stehen leider
>nur Beispiele wie man Daten Sendet.

Ach was? Ich sehe ein Kapitel

SPI Slave Operation Example

[Kimmy (Gast)]

Ja, das habe ich auch, aber da ist nur die Initalisierung und das Senden

The following code demonstrates how to use the USI module as a SPI 
Slave:

init:
ldi r16,(1<<USIWM0)|(1<<USICS1)
out USICR,r16
...
SlaveSPITransfer:
out USIDR,r16
ldi r16,(1<<USIOIF)
out USISR,r16
SlaveSPITransfer_loop:
sbis USISR,USIOIF
rjmp SlaveSPITransfer_loop
in r16,USIDR
ret

[S. Landolt (Gast)]

I'll be darned, lad' ich mir aus diesem Anlass extra das aktuelle 
Datenblatt herunter, steht noch immer "Preliminary" auf der ersten 
Seite.

[holger (Gast)]

>Ja, das habe ich auch, aber da ist nur die Initalisierung und das Senden

Nein, dort steht nicht senden sondern Transfer.
Und diese Zeile

in r16,USIDR

holt die empfangenen Daten ab.

Ansonsten ist dieses USI Geraffel eher sowas wie ein
ständiges jucken im Arsch.

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

Kimmy schrieb:
> Frage zum ablauf einer Übertragung von Nachrichten über SPI.
Da sollte man sich vielleicht vorher mal im Klaren sein, was "SPI" 
überhaupt ist. Das sind letztlich nur 2 gekoppelte Schieberegister mit 
nachgeschalteten Latches: 
http://www.lothar-miller.de/s9y/archives/15-SPI.html

Und wenn man sich diese Ablauf bewusst gemacht hat, kann man die 
Zeitpunkte, wo diese Register am besten beschrieben werden sollten, viel 
besser vorstellen. Dann ist auch klar, dass ein Slave eigentlich immer 
"alte" Daten sendet. Und dass ein Slave nichts senden kann, wenn der 
Master nich4s sendet...

[jkidghwd (Gast)]

>Das Auslösen des Interrupts mache ich ja mit einem extra pin.

Das ist falsch.
Der Slave Select löst i.A keinen Interrupt aus, sondern steuert
nur die SPI HW.

Interrupt hat ja nur einen Sinn, wenn ein Datum zum Slave übertragen 
wurde und von der SW abgeholt werden kann.

>Controller B springt in die ISR und wartet, bis die Übertragung beendet
>ist.
>
>richtig?

Nein. Da ist nix mit Warten. Slave Interrupt wenn Übertragung fertig.

[Falk B. (falk)]

@ jkidghwd (Gast)

>>Das Auslösen des Interrupts mache ich ja mit einem extra pin.

>Das ist falsch.
>Der Slave Select löst i.A keinen Interrupt aus, sondern steuert
>nur die SPI HW.

Nicht zwangsläufig. Ein AVR als Slave ist eher langsam, der braucht ein 
paar Dutzend Takte, eher er im Interrupt ist (in C).

>>Controller B springt in die ISR und wartet, bis die Übertragung beendet
>>ist.
>
>>richtig?

>Nein. Da ist nix mit Warten. Slave Interrupt wenn Übertragung fertig.

Wenn er erst in die SPI-ISR springt, wenn die Übertragung beendet ist, 
dauert das relativ lange, das kann bei hohen SPI-Taktraten zu langsam 
sein.

[Frank (Gast)]

Jetzt verstehe ich immer weniger.
Der Master Sendet wie folgt Daten zum Slave

void spi_transmit (uint8_t data)
{
  PORTB &= ~(1<<PB2);
  SPDR = data;
  while((SPSR & (1<<SPIF))==0);
  PORTB |= (1<<PB2);
}

PORTB &= ~(1<<PB2); SlaveSelect wird auf low geschaltet
  -> Slave sprint in ISR (Leitung ist mit INT0 vom Slave verbunden)

SPDR = data; Schreibe Daten ins Register und Sende diese Raus

while((SPSR & (1<<SPIF))==0); Warte bis fertig gesendet worden ist

Also bevor die Daten ins Register geschrieben worden sind und er Master 
noch nicht fertig gesendet hat, springt der Slave in die ISR und wartet, 
dass der Master fertig ist.

[S. Landolt (Gast)]

> Jetzt verstehe ich immer weniger.
Ich auch - wo kommt jetzt plötzlich der Frank her?

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

S. Landolt schrieb:
> wo kommt jetzt plötzlich der Frank her?
Frank und Kimmy: nur 1 Name pro Thread!
Siehe Nutzungsbedingungen
Aber da kann man schon mal durcheinanderkommen, nicht wahr?

[S. Landolt (Gast)]

an Kimmy/Frank:

In der INT0-ISR wird USI zurückgesetzt, um eine definierte 
Anfangsbedingung zu schaffen. Gewartet wird anschließend nicht, der 
Slave kann irgendetwas anderes machen. Wenn der Master fertig gesendet 
hat, springt der Slave in die USI_OVF-ISR und holt das eben empfangene 
Byte ab.

(Ich bin kein Spezialist in Sachen USI)

[Kimmy (Gast)]

Hallo, leider funktioniert das alles noch nicht so wie gewünscht. Daher 
bitte ich noch einmal um eure Hilfe

Atmega SPI:

#define PORT_SPI    PORTB
#define DDR_SPI     DDRB
#define DD_MISO     DDB4
#define DD_MOSI     DDB3
#define DD_SS       DDB2
#define DD_SCK      DDB5

volatile unsigned char spi_data;
volatile unsigned char new_spi_data;

void spi_init()
// Initialize pins for spi communication
{
  /* Set MOSI SCK and SS output, all others input */
  DDR_SPI = ((1 << DD_MOSI) | (1 << DD_SCK) | (1 << DD_SS));
  PORT_SPI |= (1 << DD_SS);
  DDR_SPI &= ~(1 << DD_MISO);

  /* Enable SP */
  SPCR = ((1<<SPE)|               // SPI Enable
      (1<<SPIE)|              // SPI Interupt Enable
      (0<<DORD)|              // Data Order (0:MSB first / 1:LSB first)
      (1<<MSTR)|              // Master/Slave select
      (0<<SPR1)|(1<<SPR0)|    // SPI Clock Rate
      (0<<CPOL)|              // Clock Polarity (0:SCK low / 1:SCK hi when idle)
      (0<<CPHA));             // Clock Phase (0:leading / 1:trailing edge sampling)  
}

uint8_t spi_fast_shift (uint8_t data)
// Clocks only one byte to target device and returns the received one
{
  usart_transmit_string("\r\nsend data: ");
  PORT_SPI &= ~(1 << DD_SS);
  SPDR = data;
  while((SPSR & (1<<SPIF))==0);
  return SPDR;
  PORT_SPI |= (1 << DD_SS);
}

main Atmega:

int main(void){
  spi_data = 0;
  usart_data = 0;
  new_usart_data = 0;
  usart_init(USART_MYUBRR);
  usart_transmit_string("RX devices ready"); 
  spi_init();
  usart_transmit_string("\r\nSPI device ready");

  sei(); // Global Interrupts activate
  while (1){
    if(new_usart_data == 1){
      usart_transmit_string("\r\nnew data: ");
      spi_data = spi_fast_shif(0x02);
      usart_transmit_char(spi_data);
      new_usart_data = 0;

    }

  }
}

Wie in der Funktion spi_fast_shift zu sehen ist, setze ich vor dem 
Senden den Pin PB2 auf low, wodurch der ATtiny in die ISR springt. 
Zunächst soll dieser nur eine LED Toggeln, damit ich sehe, der Attiny in 
die ISR gesprungen ist.



Attiny SPI

#define PORT_SPI    PORTB
#define DDR_SPI     DDRB
#define DD_MISO     DDB4
#define DD_MOSI     DDB3
#define DD_SS       DDB2
#define DD_SCK      DDB5

volatile unsigned char spi_data;
volatile unsigned char new_spi_data;

void spi_init()
// Initialize pins for spi communication
{
  /* --- SLAVE --- */
  /* Set MISO as output, all others input */ 
  DDR_SPI = (1 << DD_MISO);
  DDR_SPI &= ~((1 << DD_MOSI) | (1 << DD_SCK) | (1 << DD_SS));

  /* Enable SP */
  USICR = ((0<<USISIE)|            // Start Condition Interrupt Enable
       (0<<USIOIE)|            // Counter Overflow Interrupt Enable
       (0<<USIWM1)|(1<<USIWM0)|      // Three-wire mode
       (1<<USICS1)|(0<<USICS0)|(0<<USICLK)|
       (0<<USITC));            // Toggle Clock Port Pin

  extern_interrupt_init();

}

void extern_interrupt_init(void){
  DDRB &= ~(1 << DDD2); // External Interrupt on INT0

  MCUCR |= (1 << ISC01); // INT0 falling edge
  MCUCR &= ~(1 << ISC00); // INT0 falling edge

  GIMSK |= (1 << INT0);  // enable INT0 interrupt
}

ISR(INT0_vect){
  PORTB ^= (1<<PORTB5); // Toggle PD5
  while(!(USIDR& (1<<USIOIF)))
  spi_data = USIDR;
  new_spi_data = 1;
}

Attiny main

int main(void){
  _delay_ms(200);
  spi_data = 0;
  usart_data = 0;
  new_usart_data = 0;
  usart_init(USART_MYUBRR);
  usart_transmit_string("USART devices ready \r\n"); 
  spi_init();
  usart_transmit_string("SPI devices ready \r\n"); 
  sei(); // Global Interrupts activate
  DDRB |= (1<<PORTD5); // PD5 -> Output
  PORTD &= ~(1>>PORTD5); // PD5 -> Low
  while (1){
    if(new_spi_data==1){
      new_spi_data = 0;
    }

  }
}

Was passiert?
der Atmega resettet sich bei der funktion spi_fast_shift. Der Attiny 
toggelt auch nicht die LED. Verbunden habe ich es wie folgt:
Atmega -> ATtiny
MISO -> MISO
MOSI -> MOSI
SCK -> SCK
PB2 -> INT0

[holger (Gast)]

>der Atmega resettet sich bei der funktion spi_fast_shift.

Natürlich tut er das. Du gibst den SPI Interrupt frei, hast
aber keine Interruptroutine dafür. Bumm.

Ausserdem wird der Slave Select nie wieder high:

  return SPDR;
  PORT_SPI |= (1 << DD_SS);

Da sollte der Compiler doch wenigstens ein "unreachable code"
als Warnung ausspucken.

[S. Landolt (Gast)]

>       (1<<SPIE)|              // SPI Interupt Enable
? Passt nicht zum Polling
>   while((SPSR & (1<<SPIF))==0);

[S. Landolt (Gast)]

Diese Definitionen unter 'Attiny SPI' - reden wir überhaupt noch vom 
ATtiny2313?

[Bastian W. (jackfrost)]

Dein

If(new_usart_data ==1)

wird nicht ausgeführt da du die Variable mit 0 initialisierst.

Gruß JackFrost

[S. Landolt (Gast)]

>   PORTD &= ~(1>>PORTD5); // PD5 -> Low
Nanu?

[Kimmy (Gast)]

holger schrieb:
> return SPDR;
>   PORT_SPI |= (1 << DD_SS);

Ja, dass war ein Denkfehler. Ich wollte erst am Ende der Funktion die 
Leitung wieder auf High setzen, habe aber nicht berücksichtigt, dass die 
Funktion beim return beendet wird.

Das mit dem Interrupt hatte ich auch falsch gedacht. Habe beides 
geändert. Jetzt stürzt der Atmega wenigstens schon einmal nicht ab.
Der Attiny scheint aber nicht in die ISR zu springen, da die LED aus 
bleibt.

[holger (Gast)]

Und dann das hier:

uint8_t spi_fast_shift (uint8_t data)

      spi_data = spi_fast_shif(0x02);

Das oben gezeigte Programm ist doch nie und nimmer durch den Compiler
und Linker gekommen.

[Kimmy (Gast)]

S. Landolt schrieb:
> Diese Definitionen unter 'Attiny SPI' - reden wir überhaupt noch vom
> ATtiny2313?

Ja. Der Attiny hat ja kein richtiges SPI, sondern über USI.

Bastian W. schrieb:
> If(new_usart_data ==1)
>
> wird nicht ausgeführt da du die Variable mit 0 initialisierst.

Sollte aber in der ISR auf 1 gesetzt werden, wenn eine neue Nachricht 
eintrifft

S. Landolt schrieb:
>>   PORTD &= ~(1>>PORTD5); // PD5 -> Low
> Nanu?

Da ist die LED angeschlossen.

[S. Landolt (Gast)]

>   while(!(USIDR& (1<<USIOIF)))
USIOIF steht in USISR.

>Ja. Der Attiny hat ja kein richtiges SPI, sondern über USI.
Schon, aber ich lese in meinem Datenblatt eine andere Pin-Belegung.

> Da ist die LED angeschlossen.
Schon, aber Sie schieben nach rechts.


Am besten nochmal, in aller Ruhe, gründlich über die Bücher.

[Kimmy (Gast)]

holger schrieb:
> Das oben gezeigte Programm ist doch nie und nimmer durch den Compiler
> und Linker gekommen.

doch

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped 
==========

[holger (Gast)]

>> Das oben gezeigte Programm ist doch nie und nimmer durch den Compiler
>> und Linker gekommen.

>doch

>Build succeeded.

Merkwürdig.

      spi_data = spi_fast_shif(0x02);

Hinter dem _shif fehlt das 't'.

[Kimmy (Gast)]

S. Landolt schrieb:
> Schon, aber Sie schieben nach rechts.

tatsache, ist mir gar nicht aufgefallen

S. Landolt schrieb:
> Schon, aber ich lese in meinem Datenblatt eine andere Pin-Belegung.

Wie meinst du das?

[Bastian W. (jackfrost)]

Kimmy schrieb:
>
> Bastian W. schrieb:
>> If(new_usart_data ==1)
>>
>> wird nicht ausgeführt da du die Variable mit 0 initialisierst.
>
> Sollte aber in der ISR auf 1 gesetzt werden, wenn eine neue Nachricht
> eintrifft
>
>

Dann müsste die Variable global und volatil sein.

Poste bitte den ganzen Code mit allen ISR die du schon hast.

Gruß JackFrost

[Kimmy (Gast)]

spi.c

#include "spi.h"

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

void extern_interrupt_init(void);

#define PORT_SPI    PORTB
#define DDR_SPI     DDRB
#define DD_MISO     DDB4
#define DD_MOSI     DDB3
#define DD_SS       DDB2
#define DD_SCK      DDB5

volatile unsigned char spi_data;
volatile unsigned char new_spi_data;

void spi_init()
// Initialize pins for spi communication
{
  /* --- SLAVE --- */
  /* Set MISO as output, all others input */ 
  DDR_SPI = (1 << DD_MISO);
  DDR_SPI &= ~((1 << DD_MOSI) | (1 << DD_SCK) | (1 << DD_SS));

  /* Enable SP */
  USICR = ((0<<USISIE)|            // Start Condition Interrupt Enable
       (0<<USIOIE)|            // Counter Overflow Interrupt Enable
       (0<<USIWM1)|(1<<USIWM0)|      // Three-wire mode
       (1<<USICS1)|(0<<USICS0)|(0<<USICLK)|
       (0<<USITC));            // Toggle Clock Port Pin

  extern_interrupt_init();

}

void extern_interrupt_init(void){
  DDRB &= ~(1 << DDD2); // External Interrupt on INT0

  MCUCR |= (1 << ISC01); // INT0 falling edge
  MCUCR &= ~(1 << ISC00); // INT0 falling edge

  GIMSK |= (1 << INT0);  // enable INT0 interrupt
}

ISR(INT0_vect){
  PORTB ^= (1<<PORTB5); // Toggle PD5
  while(!(USIDR& (1<<USIOIF)))
  spi_data = USIDR;
  new_spi_data = 1;
}

in spi.h
extern volatile unsigned char spi_data;
extern volatile unsigned char new_spi_data;

[S. Landolt (Gast)]

> Wie meinst du das?

> #define DD_MISO     DDB4
> #define DD_MOSI     DDB3
> #define DD_SCK      DDB5

Bei mir steht es anders.

[Kimmy (Gast)]

Habe den Fehler gefunden.
Wen die LED an PD5 angeschlossen ist, sollte man auch diesen Pin 
Toggeln.

Kimmy schrieb:
> PORTB ^= (1<<PORTB5); // Toggle PD5

[Kimmy (Gast)]

Ich habe noch einmal eine etwas andere Frage.
Und zwar flashe ich den ATtiny mit dem Diamex Prog S Programmer. Da 
dieser allerdings ebenfalls an der SPI schnittstelle verbunden ist, gibt 
es Probleme, wenn der ATmega gleichzeitig dran hängt. Bisher habe ich 
immer die Kabel zwischen ATtiny und Atmega entfernt, geflasht und neu 
verbunden. Gibt es da irgendwie eine Alternative?