'Sichere' Übertragung mit SPI

[A. G. (grtu)]

Hallo zusammen,

ich möchte Daten bidirektional zwischen zwei Mikrocontrollern 
austauschen, und habe dafür momentan SPI implementiert. Das läuft 
soweit, allerdings nur wenn ich ein Delay zwischen den Übertragungen 
einbaue, sonst verschluckt der Slave manchmal die Datenpakete, da er 
eine gewisse aber unbestimmte Zeit braucht um diese zu bearbeiten. Gibt 
es da sinnvolle Möglichkeiten wie man sowas verhindern kann? Ist SPI für 
sowas überhaupt sinnvoll?

[Cyblord -. (cyblord)]

A. G. schrieb:
> Hallo zusammen,
>
> ich möchte Daten bidirektional zwischen zwei Mikrocontrollern
> austauschen, und habe dafür momentan SPI implementiert. Das läuft
> soweit, allerdings nur wenn ich ein Delay zwischen den Übertragungen
> einbaue, sonst verschluckt der Slave manchmal die Datenpakete, da er
> eine gewisse aber unbestimmte Zeit braucht um diese zu bearbeiten. Gibt
> es da sinnvolle Möglichkeiten wie man sowas verhindern kann? Ist SPI für
> sowas überhaupt sinnvoll?

Wenn du beide Controller programmiert hast, solltest du wissen welche 
Zeit wofür verwendet wird und wie lange der Sender ggf. warten muss.

Ansonsten kannst du Checksummen und entsprechende Response vom Slave 
einbauen um in solchen Fällen das Paket wiederholen zu können.

Ein Komm Kanal kann immer mal gestört werden. Das muss ein Protokoll 
halt abfangen wenn jede Übertragung 100% ankommen muss.

[Jörg W. (dl8dtl) (Moderator)]

A. G. schrieb:
> Ist SPI für sowas überhaupt sinnvoll?

Eher nicht.

SPI taugt mehr dafür, wenn du als Slave etwas in Hardware hast, ein 
Schieberegister, ein FPGA. Dort hast du normalerweise mit der nächsten 
Flanke des Hardwaretaktes (der ohnehin immer viel schneller als der 
SPI-Takt sein muss) die Antwort parat.

Für Controller als Slave eignet sich I²C besser, denn da hat der Slave 
die Möglichkeit, dem Master ein "Halt mal kurz!" zuzurufen, bis er die 
Antwort bereit hat.

[A. G. (grtu)]

Jörg W. schrieb:
> SPI taugt mehr dafür, wenn du als Slave etwas in Hardware hast, ein
> Schieberegister, ein FPGA. Dort hast du normalerweise mit der nächsten
> Flanke des Hardwaretaktes (der ohnehin immer viel schneller als der
> SPI-Takt sein muss) die Antwort parat.

Das ist ein guter Hinweis. Der Slave ist tatsächlich ein FPGA, auf dem 
NIOS läuft, und das ist etwas langsam. Ich versuche es mal so 
umzustellen, dass die SPI-Kommunikation direkt in Hardware über einen 
Adressenbereich (wie bei einem EEPROM) gemacht wird.

Cyblord -. schrieb:
> Ansonsten kannst du Checksummen und entsprechende Response vom Slave
> einbauen um in solchen Fällen das Paket wiederholen zu können.
>
> Ein Komm Kanal kann immer mal gestört werden. Das muss ein Protokoll
> halt abfangen wenn jede Übertragung 100% ankommen muss.

Das stimmt, eine Checksumme ist notwendig. Ich wollte nur vermeiden so 
lange zu pollen bis das 'richtige' Ergebnis zurück kommt, was den Master 
dann vollkommen lahmlegen würde.

[Gerd E. (robberknight)]

Jörg W. schrieb:
> Für Controller als Slave eignet sich I²C besser, denn da hat der Slave
> die Möglichkeit, dem Master ein "Halt mal kurz!" zuzurufen, bis er die
> Antwort bereit hat.

Das mag sein. Allerdings ist I2C ziemlich empfindlich gegen 
EM-Störungen. Kommt da eine Störung, die der Slave als Clocksignal 
interpretiert, der Master aber nichts gesendet hat, kommen Master und 
die Slaves durcheinander.

Das muss man dann erkennen und den Bus wieder "freitakten". In den 
meisten Fällen hilft das, ich hab aber auch schon Slaves gehabt die 
manchmal einen Reset brauchten bevor das I2C wieder funktionierte.

Vor allem wenn für die Anwendung garantierte Antwortzeiten benötigt 
werden ist das also gar keine gute Idee. SPI ist da besser, da es über 
das Slaveselect-Signal immer sauber synchronisiert wird.

Für einen FPGA als Slave würde ich SPI nehmen, mit SPI in Hardware. Ist 
auch von der Logik her deutlich einfacher als I2C.

Für einen Mikrocontroller als Slave ist vermutlich etwas UART-basiertes 
das einfachste. Bei mehreren Mikrocontrollern dann als Open Collector 
Bus.