while Schleife bei SPI, Dauer

[Eugen T. (der_eugen_thorben)]

Hi, ich hätte eine Frage zu SPI.

Man sendet ein Byte und wartet ja mit

 while(!(SPSR & (1 << SPIF)));

.
Ich würde gern, falls der Master absturzt, nicht, dass es ewig in der 
while Schleife hängen bleibt.

Ich dachte, dass der Master zusätzlich in einer for Schleife hochzählt 
und falls es zu lange dauert, die while Schleife unterbrochen wird.

Jedoch weiß ich nicht so genau, wie hoch ich den Zähler setzen sollte 
oder evtl einen Timer nutzen sollte, obwohl ich lieber die Timer 
freihalte für anderes Zeugs.

Hat da jemand Erfahrung mit?

Hab eine Frequenz von 16 Mhz

[chris (Gast)]

Eugen Thorben schrieb:
> Ich dachte, dass der Master zusätzlich in einer for Schleife hochzählt
> und falls es zu lange dauert, die while Schleife unterbrochen wird.

SPI kann nicht "hängen bleiben", da einfach nur ein Byte rausgetaktet 
wird.
Bei maximaler SPI-Frequenz (0.5*F_CPU) dauert ein Byte per SPI gerade 
mal 16 CPU-Takte.

[Eugen T. (der_eugen_thorben)]

cool, danke.

[Frank (Gast)]

Ich würde so was in der Art machen:

while(!(SPSR & (1 << SPIF)))
{
 cnt++;
 if(cnt>MAXCNT)
 {
  setSpiError();
  break;
 }
}

Oder schöner, wenn du einen ms-Timer hast:

uint16 u16timeBefore = getActms();

while(!(SPSR & (1 << SPIF)))
{
 if( (getActms() - u16timeBefore) > MAXTIME)
 {
  setSpiError();
  break;
 }
}

Oder gleich mit Interrupts arbeiten und garnicht warten.
Ein Timeout sollte man trotzdem implementierten.

[Eugen T. (der_eugen_thorben)]

ja, finde ich auch. ich denke auch, dass es mit einem timer besser ist.

[Thomas E. (thomase)]

Frank schrieb:
> Ein Timeout sollte man trotzdem implementierten.

Welchen Sinn soll das haben? Da kann nichts abstürzen, hängen bleiben 
oder sonstwas. Es sei denn, der Controller geht kaputt. Aber dann ist es 
ohnehin egal.

> if( (getActms() - u16timeBefore) > MAXTIME)

Wenn das SPI mit F_CPU/2 läuft, wartet man nicht aufs SPI, sondern auf 
das Ende dieser Berechnung.

mfg.

[Frank (Gast)]

Wilder Pointer schaltet den Clock der SPI Peripherie ab...oder sonst 
irgendwas wo es der HW nicht möglich ist die Daten auszutakten. Ich hab 
schon Pferde kotzen sehen.
Beim senden gebe ich euch vllt noch Recht.

Beim empfangen gibt es mehr als genügend Fälle wo es ohne Timeout schief 
gehen kann.

[Falk B. (falk)]

@ Eugen Thorben (der_eugen_thorben)

>ja, finde ich auch. ich denke auch, dass es mit einem timer besser ist.

Finden kannst du das, es bleibt aber totaler Unsinn. SPI ist eine 
relativ schnelle, serielle Schnittstelle. Da will man ganz sicher nicht 
viel Zeit verplempern. Im Gegenteil. Also wird man meist versuchen, die 
Daten so schnell wie möglich auszugeben bzw. zu lesen. Und wie schon 
mehrfach gesagt, kann bei SPI niemals was hängen bleiben, weil der Slave 
keinerlei Handshake macht. Einen Interrupt nutzt man bei SPI auch 
selten, weil die Übertragungsrate meist so hoch ist (nahe F_CPU/2), dass 
die Zeit zwischen 2 Bytes eher knapp ist, der Interrupt spart dabei rein 
gar nichts an Rechenzeit, im Gegenteil.

Bei I2C ist das vollkommen anders, dort ist ein Timeout angeraten!

[Falk B. (falk)]

@ Frank (Gast)

>Wilder Pointer schaltet den Clock der SPI Peripherie ab...oder sonst
>irgendwas wo es der HW nicht möglich ist die Daten auszutakten. Ich hab
>schon Pferde kotzen sehen.

Unfug. Und morgen fällt der Mond runter . . .

>Beim empfangen gibt es mehr als genügend Fälle wo es ohne Timeout schief
>gehen kann.

Schon wieder falsch. Auch beim Empfangen, welches parallel zum Senden 
läuft, gibt der Master den Takt vor und ist durch rein GAR NICHTS 
aufzuhalten!

[Thomas E. (thomase)]

Frank schrieb:
> Wilder Pointer schaltet den Clock der SPI Peripherie ab
Ja nee, is klar.

Blödsinn ist das. Dann ist dein Programm Murks. Da nützt dir ein Timeout 
auch nichts.

mfg.

[Wolfgang A. (Gast)]

Eugen Thorben schrieb:
> Ich würde gern, falls der Master absturzt, nicht, dass es ewig in der
> while Schleife hängen bleibt.

Wenn die Hardware von deinem µC ausfällt, laufen noch ganz andere Sachen 
im µC nicht. Hast du schon ein einziges Mal erlebt, dass die SPI 
Hardware die Bits nicht richtig raus tackert? IMHO fehlen da ein paar 
Grundlagen über die SPI Baugruppe.

[Clemens L. (c_l)]

Frank schrieb:
> Wilder Pointer schaltet den Clock der SPI Peripherie ab...oder sonst
> irgendwas wo es der HW nicht möglich ist die Daten auszutakten. Ich hab
> schon Pferde kotzen sehen.

Solche kotzenden Pferde erledigt man mit dem Wachhund, äh, Watch Dog 
Timer.

[S. Landolt (Gast)]

> Unfug. Und morgen fällt der Mond runter . . .

Ihn dünkt', er säh' 'ne SPI,
  die blieb auf einmal stehen.
Er guckt' noch mal und merkt', es war
  die Welt am Untergehen.
"Herrje, Herrjemine," sprach er,
  "ich kann das nicht verstehen."

[Nosnibor (Gast)]

Geht es denn überhaupt um die Master-Seite, oder ist hier jemand in der 
unglücklichen Lage, mit seinem µC die Slave-Rolle übernehmen zu müssen?

Aus Sicht des Slave kann es ja sehr wohl passieren, daß der Master 
mitten in der Übertragung abbricht (z.B. wegen Reset), und damit muß man 
dann irgendwie klarkommen. Das sollte dann aber über die SS-Leitung 
gehen und nicht über irgendwelche willkürlichen Timeouts.

[Thomas E. (thomase)]

Nosnibor schrieb:
> Geht es denn überhaupt um die Master-Seite

Ja.

Eugen Thorben schrieb:
> Ich dachte, dass der Master zusätzlich in einer for Schleife hochzählt
> und falls es zu lange dauert, die while Schleife unterbrochen wird.

mfg.

[Pandur S. (jetztnicht)]

Was bedeutet Empfangen im Master ?

Er clockt soviele 0xFF raus wie er Daten erwartet und liest jeweils das 
SPI Register aus. Da ist nichts mit Warten. Je nach Interrupt 
Implementierung ist eine Soft SPI nicht allzu viel schlechter. Denn wenn 
der compiler fuer einen SPI Interrupt 16 Register push&pop-t...

[Thomas E. (thomase)]

Jetzt Nicht schrieb:
> Denn wenn
> der compiler fuer einen SPI Interrupt 16 Register push&pop-t...

Deswegen ist das Warten auch meist günstiger.

mfg.

[c-hater (Gast)]

Nosnibor schrieb:

> Geht es denn überhaupt um die Master-Seite

Nein, auch wenn einige Leute nicht lesen können. Es geht im OP ganz 
eindeutig um die Implementierung einer Slave-Rolle.

Die Verwirrung im Thread entstand wohl nur dadurch, dass der TO von SPI 
unglaublicherweise so erschreckend wenig Ahnung hat, dass er glaubte, 
als Slave irgendwas aus eigenem Antrieb senden zu können. Das hat wohl 
einige (weniger gründliche) Leser zu der Annahme verleitet, dass es um 
einen Master ginge.

> Aus Sicht des Slave kann es ja sehr wohl passieren, daß der Master
> mitten in der Übertragung abbricht (z.B. wegen Reset)

Genau so ist das auch.

> und damit muß man
> dann irgendwie klarkommen. Das sollte dann aber über die SS-Leitung
> gehen und nicht über irgendwelche willkürlichen Timeouts.

Vollkommene Überwachung geht nicht ohne sinnvolle Timeouts. Es geht aber 
natürlich ohne "willkürliche" Timeouts. Und nein: nicht die SS-Leitung 
wäre dafür zu überwachen, sondern die SCK-Leitung. Am besten aber beide. 
SCK mit Timeout, SS auf Pegel.
Allerdings: man kann es mit Sicherheitsfunktionalität auch so 
übertreiben, dass die Sicherheitsfunktionen (bzw. ihr Verbrauch an 
Rechenzeit) erst die Soll-Funktion so dermaßen stören, daß es zu Fehlern 
kommt...

Das ist eigenartigerweise nichtmal den hochbezahlten Ingenieuren 
diverser Standardisierungsorganisationen klar. Die können wohl alle nur 
C...

[Rudolph R. (rudolph)]

c-hater schrieb:
>> Geht es denn überhaupt um die Master-Seite
>
> Nein, auch wenn einige Leute nicht lesen können. Es geht im OP ganz
> eindeutig um die Implementierung einer Slave-Rolle.

Interessante Theorie, sehe ich jetzt auch nicht so.

Bei einem Slave würde ich jetzt auch nicht per Polling darauf warten, 
dass vielleicht irgendwann mal ein Byte eingetrudelt kommt.