STM32 - Ethernet Tx Queue

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Abend!

Ich habe mir eine Ethernet+Stack C++Lib auf dem STM32F4 
zusammengeschustert. Das funktioniert soweit auch alles prima, es gibt 
lediglich ein kleines Problemchen beim Senden von Frames. Im Prinzip 
funktioniert das bei mir so:

Beim Empfangen neuer Frames löst der Rx-Interrupt aus und es geht dann 
direkt in den IP-Stack. Der dekodiert das ganze und bereitet auch die 
Antwortframe vor. Danach wird nach einem freien Tx-Descriptor gesucht, 
dieser wird dann auch eingerichtet und der Übertragungsstart getriggert. 
Das findet alles in der Interruptroutine statt und funktioniert 
wunderbar und zügig.

Nun ist es allerdings so, dass es auch die Möglichkeit gibt ausserhalb 
der Rx-ISR einen Tx-Descriptor zu suchen, zu bearbeiten und die 
Übertragung zu starten. Beispielsweise aus der Mainloop heraus oder auch 
innerhalb anderer ISRs die niedriger oder höher priorisiert (sowohl Sub 
als auch Preempt) sein können. Das bedeutet, der Codeabschnitt zwischen 
Tx-Descriptor suchen und Übertragung starten, muss gelockt werden.


1. Nehmen wir mal an, dass der Controller in einer niedrig priorisierten 
ISR ist, dort in den gelockten Codeabschnitt kommt und dann ein 
Interrupt auslöst der höher priorisiert ist (Preempt) und auch den 
gleichen Code mit dem Lock ausführt. Hier bleibt der ganze Spaß dann ja 
stecken, sehe ich das richtig?

2. Sieht jemand eine Möglichkeit, das ganze mit locks und / oder 
Interrupt-Disablen-Reenablen zu ermöglichen oder ist das so nicht zu 
schaffen? Die Mainloop möchte ich nicht anfassen.

3. Kennt ihr eine gute Seite die mir die Funktionsweise der "__LDREXW"- 
und "__STREXW"-Funktionen bzw. deren Instruktionen an den Cortex 
erklärt? Auf der ARM-Webseite steht da ja nicht sonderlich viel dazu, 
was da genau passiert.


Vielen lieben Dank schonmal!
Grüße
Reggie

[Ruediger A. (Firma: keine) (rac)]

? Die Beschreibung ist etwas konfus. Die ETH DMA Engine entkoppelt Rx 
und Tx total voneinander. Ein Rx Interrupt hat auf die Tx 
Deskriptorenkette keinerlei Auswirkungen. Der Rx Interrupt (in der 
Realität wirklich der low Pri Receiver Prozess) und die DMA 
"konkurrieren" um die Rx Deskriptorketten, und der Tx Interrupt und die 
Tasks, die Transmits ausführen, "konkurrieren" um die Tx 
Deskriptorenkette.

Jeder gut programmierte TCP-IP stack behält diese Trennung bei. WAS 
passieren kann ist daß sowohl ein Applikationstask als auch die TCP/IP 
task nebenläufig versucht, ein Paket in die Tx Deskriptorenkette zu 
legen (several:1 im Gegensatz zum Rx Pfad), aber in der Regel ist das 
durch OS queues voneinander entkoppelt, oder sonst durch 
Mutexabriegelung.

Sieh Dir mal eine Beispielapp mit lwip und FreeRTOS an, dort ist der 
Kontrollfluss recht gut analyiserbar.

Ich beschreibe sowohl diesen Prozess als auch die Operation im Access 
Monitor des Cortex Kerns (ldrexw und strexw, die aber an der Stelle 
nicht relevant sein sollten) recht ausführlich in meinem Buch (Vorsicht 
Eigenwerbung). Bitte schick ein Mail, wenn Du mehr Offline Klärung 
brauchst.

- Rüdiger R. Asche

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Punkt 3 konnte ich mir gerade selber beantworten: Warum ich nicht an das 
Programming-Manual gedacht hatte, weiß ich auch nicht.

Punkt 1 und 2 wären noch offen :)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Ruediger A. schrieb:
> Die Beschreibung ist etwas konfus.
Das tut mir leid. "Etwas komplexere" Vorgänge in einem Forum vorzuführen 
ist nicht immer einfach.

Ruediger A. schrieb:
> Die ETH DMA Engine entkoppelt Rx
> und Tx total voneinander
Das ist mir alles absolut klar. Spiele schon seit knapp einem Jahr mit 
dem STM32 ETH rum.

Ruediger A. schrieb:
> Jeder gut programmierte TCP-IP stack behält diese Trennung bei.
Dafür kopiert meiner keine Buffer unnötig lange hin und her :) Nee, dass 
meiner keine Konkurrenz für alle anderen Stacks ist, ist mir klar. 
Allerdings möchte ich eben möglichst wenig overhead haben. Desweiteren 
möchte ich, wie gesagt, die Mainloop freihalten.

Ruediger A. schrieb:
> WAS
> passieren kann ist daß sowohl ein Applikationstask als auch die TCP/IP
> task nebenläufig versucht, ein Paket in die Tx Deskriptorenkette zu
> legen
Ganz genau, bei mir gibt es Beispielsweise die Möglichkeit, dass eine 
andere Schnittstelle (im konkreten Fall UART-ISR) meinem Stack 
dazwischen kommen könnte.

Ruediger A. schrieb:
> OS queues
Ich hab kein OS :)

Ruediger A. schrieb:
> Sieh Dir mal eine Beispielapp mit lwip und FreeRTOS an, dort ist der
> Kontrollfluss recht gut analyiserbar.
Ah natürlich, danke für den Tipp, weißt du zufällig wie das dort gemacht 
wird, also vor allem bezüglich meines Problems zu Punkt 1? Das ist ja 
schon wieder ein klein wenig spezieller.