SPI-Kommunikation - was wenn hängen bleibt?

[har (Gast)]

Liebes Forum,

ich programmiere den STM32F303 und verwende die Stadard Peripheral 
Library von STMicroelectronics.
Momentan arbeite ich an der SPI-Kommunikation.
Es funktioniert soweit alles.
Unter anderem habe ich folgende Programm-Zeilen:

SPI_SendData8(SPI1,0xff);
    while (SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == 1);

Wie aus den Zeilen erkennbar, wird nachdem 0xFF gesendet wird, gewartet, 
bis die nächsten Schritte ausgeführt werden sollen.

Jetzt stelle ich mir vor, was passiert, wenn mit der SPI-Schnittstelle 
etwas nicht funktioniert und zum Beispiel das SPI_I2S_FLAG_BSY nie Null 
wird. Der Mikrocontroller würde in der while-Schleife hängen bleiben.

In einem solchen Fall möchte ich, dass die SPI Kommunikation abgebrochen 
wird und ein Fehlercode in der Funktion zurück gegeben wird.

Wie löst ihr diesen Fall? Bzw. wie kann ich überprüfen, ob der uC in der 
while-Schleife schon "längere Zeit" hängt?

Danke für eure Tipps und Hinweise!

[jo mei (Gast)]

har schrieb:
> wie kann ich überprüfen, ob der uC in der
> while-Schleife schon "längere Zeit" hängt?

Indem du eine Zeitmessung in der Schleife einbaust und durch
Abprüfen entscheidest ob es jetzt aus ist oder nicht.

[Peter D. (peda)]

Der Sender erzeugt den Takt und ist nach der festgelegten Anzahl Bits 
fertig. Die einzige Möglichkeit, daß er nicht fertig wird, ist, ihm den 
Takt abzuschalten.
Nur als Slave muß man warten, bis der Master einen taktet.

[PittyJ (Gast)]

Bei was baue ich immer noch eine zweite Komponente ein:
Zähler mit maximaler Anzahl der Durchläufe.
Oder Timer mit maximaler Testzeit.

Bei Fehler dann Meldungen, Abbruch, Fehlerflags etc.

[Olaf (Gast)]

> Wie löst ihr diesen Fall? Bzw. wie kann ich überprüfen, ob der uC in der
> while-Schleife schon "längere Zeit" hängt?

In dem du da einen Zaehler einbaust. Das ist z.B bei I2C extrem wichtig. 
Aber in deinem speziellen Fall vermutlich nicht so wichtig weil deine 
SPI-Schnittstelle eine Staetemachine/Bitzaehler in Hardware ist. Wenn du 
da Master bist dann sollte das nicht stehenbleiben koennen. Ist 
natuerlich anders wenn du slave bist.

Olaf

[W.S. (Gast)]

har schrieb:
> SPI_SendData8(SPI1,0xff);
>     while ...;
>     while ...;

Tja, wenn man immer nur wie ein Schönwetter-Programmierer von eitel 
Sonnenschein ausgeht, dann kann man da eben stecken bleiben.

Also: Wenn man irgend eine Kommunikation mit einem anderen Gerät 
programmieren will und dabei eben nicht stecken bleiben will, dann muß 
man sich Gedanken über eine sinnvolle Überwachung der Kommunikation 
machen. Zumeist ist es das Einfachste, sich sinnvolle Wartezeiten 
auszudenken, die so groß sind, daß die normale Kommunikation ohne 
Probleme stattfinden kann, die aber auch so klein sind, daß man die 
eigenen Vorgänge nicht gar zu sehr behindert. Und wenn irgend ein 
erwartetes Signal von der Gegenstelle zu lange auf sich warten läßt und 
also die zugehörige Wartezeit um ist, dann muß der Vorgang eben 
abgebrochen werden und eine sinnvolle Fehlerbehandlung folgen.

So geht das Leben. Auch bei einem µC.

W.S.

[Patrick C. (pcrom)]

Aufgepasst :
"@note Do not use the BSY flag to handle each data transmission or 
reception.  It is better to use the TXE and RXNE flags instead."
(ursprung : 
http://www.disca.upv.es/aperles/arm_cortex_m3/curset/STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/html/group___s_p_i___group5.html)


Dabei kann timeout in diesen fall NUR kommen durch falsch initialisieren 
im Software. Fuer diesen fall koennte man einen Watchdog benutzen

[c-hater (Gast)]

W.S. schrieb:

> Also: Wenn man irgend eine Kommunikation mit einem anderen Gerät
> programmieren will und dabei eben nicht stecken bleiben will, dann muß
> man sich Gedanken über eine sinnvolle Überwachung der Kommunikation
> machen.

Nicht bei SPI! Das ist eine völlig dumme Schnittstelle. Der Master hat 
alle Macht. Dementsprechend braucht (und kann) man auf Master-Seite auch 
nix "überwachen", jedenfalls nicht auf dem Transport-Layer. Irgendwelche 
Bits werden immer eingehen, geht garnicht anders.

Wenn also eine Überwachung irgendeinen Sinn ergeben soll, muss sie auf 
Protokoll- oder gar Anwendungsebene arbeiten.