mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32: SPI-Transfer laut Datenblatt ohne Interrupts


Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

beim STM32F10x heißt es im Datenblatt zum SPI für Transfers im 
Master-Modus:
> The software has to follow this procedure to transmit and receive data:
> 1. Enable the SPI by setting the SPE bit to 1.
> 2. Write the first data item to be transmitted into the SPI_DR register
>    (this clears the TXE flag).
> 3. Wait until TXE=1 and write the second data item to be transmitted.
>    Then wait until RXNE=1 and read the SPI_DR to get the first received
>    data item (this clears the RXNE bit). Repeat this operation for each
>    data item to be transmitted/received until the n–1 received data.
> 4. Wait until RXNE=1 and read the last received data.
> 5. Wait until TXE=1 and then wait until BSY=0 before disabling the SPI.

(Seite 710)

Das ganze ziehlt wohl auf das doppelte gepufferte Datenregister ab. 
Allerdings frage ich mich, ob die Beschreibung tatsächlich etwas naiv 
ist:

Man schreibt also ein Byte ("first data item") rein und das SPI beginnt 
mit der Übertragung, wodurch das Pufferregister frei wird und man schon 
ein Byte nachladen ("second data item") kann. Dann wartet man implizit 
auf das Ende der Übertragung des ersten Bytes ("RXNE"), durch das ja 
gleichzeitig auch ein Byte empfangen wurde, welches man dann lesen soll 
("first received data item"), um direkt im Anschluss wieder ein Byte zum 
Versand nachzuladen.

Wenn man allerdings nun ein Byte nicht rechtzeitig liest, etwa weil ein 
Interrupt dazwischenkommt, dann geht dieses doch schlimmstenfalls 
verloren, oder? Denn im Puffer befindet sich ja wegen der 
verschachtelten Prozedur laut Datenblatt schon das nächste zu 
versendende Byte. Und wenn das fertig übertragen wurde, würde das 
dadurch gleichzeitig empfangene Byte wieder in den Puffer geschrieben. 
Damit wäre ein Byte überschrieben und verloren.

Übersehe ich da etwas?
Ich meine, es ist ja nicht so, dass diese Problematik nicht leicht 
durchschaubar wäre. Aber ich bin es eigentlich von Datenblättern anderer 
Mikrocontrollerfamilien gewohnt, dass solche Sachen beschrieben werden. 
Und im Datenblatt des STM32 bin ich darum etwas hin- und hergerissen:
(a) Das Datenblatt ist schon richtig so. Das heißt, ich übersehe 
irgendwas.
(b) Das Datenblatt ist naiv und geht aufgrund der Komplexität nicht 
auf jeden "Randfall" extra ein.
(c) Das Datenblatt ist Mist.

Fairerweise würde ich (a) annehmen wollen, aufgrund meiner Erfahrung 
gehe ich aber von (c) aus.


Danke & Grüße,
K

Autor: Doctor Snuggles (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Übersehe ich da etwas?

Ja.
Zum einen gibt es ein Overflow-Flag, was anzeigt, dass Du etwas verpasst 
hast.
Zum anderen lässt sich das Verpassen auf verschiedene Art und Weise 
verhindern.
Zum einen kannst Du einen Interrupt mit ausreichender Priorität 
aktivieren, in dem Du sofort empfangene Daten abholst.
Zum anderen kannst Du DMA nutzen, dann läuft das im Hintergrund ab.

Das steht, wie Du es gewohnt bist, im Reference Manual. Dazu noch in 
thematischen Datenblättern wie z.B. für DMA richtig ausführlich.
Einfach lesen!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doctor Snuggles schrieb:
> Einfach lesen!

Mir sind die 100 anderen Optionen ja durchaus bewusst, mit denen man das 
Problem umschiffen kann. Das ist aber nicht das, was ich hoffe, zu 
übersehen.

Ich hoff(t)e, einen Mechanismus im UART zu übersehen, der bei exakter 
Befolgung der Beschreibung im Datenblatt dafür sorgt, dass kein Byte 
verlorengeht.

Oder anders gesagt, ich kann die Beschreibung im Datenblatt so nicht 
nachvollziehen: Warum wird dort ein "kompliziertes" Verschachteln der 
Sende-/Empfangszyklen beschrieben?
- Es ist, so wie es dort steht, nicht sicher.
- Man könnte es problemlos so umsortieren, dass es sicher ist (d.h. 
nicht verschachteln, sondern immer auf das einlaufende Byte warten, 
bevor nachgeladen wird). Klar, ist dann langsamer.
- Es gibt DMA.
- Es gibt Interrupts mit Prioritäten.

Was also soll diese Vorschrift?

Einen Sinn würde die Vorschrift zum Beispiel ergeben, wenn der UART das 
erste empfangene Byte ins Pufferregister schiebt und das zweite dann im 
SPI-Schieberegister behält. Wenn nun ein drittes Byte reinkommt, ists 
natürlich wieder vorbei. Aber solange man ja nur zwei Bytes gesendet hat 
(das erste plus das nachgeladene), können auch nur zwei Bytes 
reinkommen. Dann könnte man in aller Ruhe das Puferregister lesen, 
wodurch das Byte aus dem Schieberegister ins Pufferregister nachrückt 
und so weiter.

Ich kann aber nirgends ersehen, ob das SPI so gebaut ist. Und ehrlich 
gesagt bezweifle ich es auch.

Die Vorschrift ist also strenggenommen Blödsinn oder wohlwollende 
Statistik a.k.a. schnell genug sein. Hat doch im Datenblatt nix verloren 
sowas.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, auch bei ST finde ich dazu kein verwertbares Feedback.

Irgendwie passt das wieder einmal mehr zum desolaten Zustand des 
ARM-Ökosystems :-(

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Irgendwie passt das wieder einmal mehr zum desolaten Zustand des
> ARM-Ökosystems :-(

Seltsam ... die ganze Welt macht SPI mit ARM-Prozessoren und
jammert nicht rum, und bei dir ist die Kacke am dampfen.

Was will uns das sagen?

Autor: StinkyWinky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Wenn man allerdings nun ein Byte nicht rechtzeitig liest, etwa weil
> ein Interrupt dazwischenkommt, dann geht dieses doch schlimmstenfalls
> verloren, oder?

Nur, wenn du in deinem Interrupt mehr Zeit vertrödelst, als die 
Übertragung eines Bytes benötigt.

Autor: UweBonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum muss es den der STM32F10x sein? Den gibt gibt es schin 10 Jahre, 
und ST hat einiges an der Peripherie verbessert.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das nicht egal bei SPI? Da bestimmt der Master doch auch den Takt. 
Und der kann AFAIK sich während einer Übertragung ändern. Dat hat man 
doch genug Zeit, das Byte abzuholen, weil der Takt erst dann generiert 
wird, wenn man das nächste Zeichen sendet.

Oder sehe ich das falsch?

Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Man schreibt also ein Byte ("first data item") rein und das SPI beginnt
> mit der Übertragung, wodurch das Pufferregister frei wird und man schon
> ein Byte nachladen ("second data item") kann. Dann wartet man implizit
> auf das Ende der Übertragung des ersten Bytes ("RXNE"), durch das ja
> gleichzeitig auch ein Byte empfangen wurde, welches man dann lesen soll
> ("first received data item"), um direkt im Anschluss wieder ein Byte zum
> Versand nachzuladen.

Wenn man sich die Überschrift zu Fig. 241 im RM ansieht, ist klar, warum 
das so gemacht werden soll: continuous

Schreibt man nur jeweils ein Byte ins Sende-Register und wartet auf das 
RXNE, liest das empfangene Byte und scheibt erst danach das nächste Byte 
ins Sende-Register, gibt's zwischen den einzelnen Bytes immer ein Pause, 
aber man verpasst garantiert nichts.

> Wenn man allerdings nun ein Byte nicht rechtzeitig liest, etwa weil ein
> Interrupt dazwischenkommt, dann geht dieses doch schlimmstenfalls
> verloren, oder? Denn im Puffer befindet sich ja wegen der

Klar. Wenn man es so macht wie im RM beschrieben (um eben KEINE Pausen 
zu haben), muss man natürlich immer
(a) rechtzeitig für Nachschub sorgen und
(b) rechtzeitig die empfangenen Daten abholen ...

Ansonsten bleibt ja der einfachere Weg, wo halt kein kontinuierlicher 
Transfer stattfindet.

Die Frage ist letzlich, ob die "Gegenstelle" solche Pausen verdaut oder 
sich daran verschluckt.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UweBonnes schrieb:
> Warum muss es den der STM32F10x sein? Den gibt gibt es schin 10 Jahre,
> und ST hat einiges an der Peripherie verbessert.
Naja, er ist halt gängig. Zumindest hatte ich den Eindruck, als ich mich 
vor ca. 2 Jahren damit erstmalig beschäftigt habe und nach einem 
Einstiegsmodell gesucht habe.

PittyJ schrieb:
> Oder sehe ich das falsch?
Ja, siehst du. In o.g. Beispiel aus dem Reference Manual ist das nächste 
Byte ja schon sendebereit. Das ist ja genau das Problem.

STM Apprentice schrieb:
> Seltsam ... die ganze Welt macht SPI mit ARM-Prozessoren und
> jammert nicht rum, und bei dir ist die Kacke am dampfen.
Und das macht die konkrete Peripherie samt Beschreibung im STM32F103 nun 
irgendwie "gut" oder "besser"?

Das ist ja ein triviales Problem hier. Mir sind, wie ich ja schon 
schrieb, diverse Lösungen dafür bekannt.
Aber es ist m.M.n. ziemlich repräsentativ dafür, wie dünn das RM ist. 
Irgendwie habe ich oft das Gefühl, dass Peripherie nur grob umrissen 
wird und ich vieles wirklich ausprobieren muss, wenn es um Randfälle und 
so geht.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Wenn man allerdings nun ein Byte nicht rechtzeitig liest, etwa weil ein
> Interrupt dazwischenkommt, dann geht dieses doch schlimmstenfalls
> verloren, oder? Denn im Puffer befindet sich ja wegen der
> verschachtelten Prozedur laut Datenblatt schon das nächste zu
> versendende Byte. Und wenn das fertig übertragen wurde, würde das
> dadurch gleichzeitig empfangene Byte wieder in den Puffer geschrieben.
> Damit wäre ein Byte überschrieben und verloren.

Ein Paradebeispiel von "Ich hätte gerne ein Problem".
Wenn man den SPI auf max Takt betreibt und im IRQ Fibonaccis rekursiv 
berechnet dann geht das verloren.

Der SPI im F103 kann maximal 18MBit, der CPU Kern kann bis zu 72MHz.
Also pro SPI CLK verspeist die CPU 4 Befehle.
Nun sind es aber 8Bit pro SPi Übertragung, also 32 Befehle.
Wird knapp wenn da nen IRQ mit Registerstacking reinpfuscht.

Aber Volldampf senden ohne DMA war noch nie eine gute IDee, mit 1-4MHz 
auf dem SPI sollts keine Probleme geben.
Also b)

Und wieso wird auf einmal vom UART gefaselt wenns eigentlich um den SPI 
geht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.