Fragen zum Lwip-Stack

[Entwickler (Gast)]

Hallo, ich möchte den Lwip-Stack auf einen Cortex-M3 (Stm32) einsetzen.
Für diesen Stack benötige ich einen eigenen Hardware-Timer-Interrupt 
oder einen eigenen Task. Wie lange braucht eigentlich der Lwip-Stack bei 
der Bearbeitung eines ankommenden Ethernetpacketes ? Liegt die 
Bearbeitung bzw. Verarbeitung bei ca. 1ms ? Gibt es da bereits Messungen 
?

Vielen Dank im Vorfeld!

[Entwickler (Gast)]

Hat hier einer bereits den Lwip-Stack auf einen Mikrocontroller benutzt 
?

[Strubi (Gast)]

Moin,

1ms sollte zu schaffen sein. Hängt aber von deinem OS bzw. deinem 
Scheduler/Handler ab, wie auch der uC-Performance.
Der lwip läuft zwar auf vielen Systemen, ist aber nicht auf Performance 
getrimmt. Für schnelle, garantierte Antwortzeiten ist das Ding IMHO 
relativ unbrauchbar, besser man schreibt sich seinen auf DMA optimierten 
UDP-Stack (TCP ist für Realtime bekannterweise problematisch).

Grüsse,

- Strubi

[Entwickler (Gast)]

Vielen Dank für die Antwort. Gibt es für den STM32 einen DMA optimierten
UDP-Stack ? In der ersten Variante möchte ich einen Hardwaretimer für 
die einkommenden Ethernetpackete spendieren. Die zweite Variante ich 
verwende das FreeRTOS.

[Gebhard R. (Firma: Raich Gerätebau & Entwicklung) (geb)]

Timerinterrupt für sowas? Find ich fragwürdig. Der MAC muss ohnehin die 
Pakete zwischenspeichern ehe du sie durch den Stack prügelst. Wenn das 
geschehen ist,kann man ja ein Flag setzen um zu signalisieren,dass der 
Mac wieder gepollt werden soll. Die meisten Mac's besitzen auch 
Interruptleitungen,die bei Eintreffen eines neuen Paketes gesetzt werden 
=> für hohe Übertragungsraten empfehlenswert.

Grüsse

[Entwickler (Gast)]

Was ist die Verwendung eines Timerinterrupts hiefür fragwürdig ?
Am besten wäre also wenn ich den Empfangsinterrupt für ankommende 
Ethernetpackete nutzen würde ? Ich muss in der STM32 Lib mal 
nachschauen. Aber ich denke der Empfangsinterrupt wird doch schon 
verwendet.

[Entwickler (Gast)]

Ist die Verwendung eines Timerinterrupts hiefür fragwürdig ? Warum ?
Am besten wäre also, wenn ich den Empfangsinterrupt für ankommende
Ethernetpackete nutzen würde ? Ich muss in der STM32 Lib mal
nachschauen. Aber ich denke der Empfangsinterrupt wird doch schon
verwendet.

[Rolf M. (rmagnus)]

Entwickler schrieb:
> Ist die Verwendung eines Timerinterrupts hiefür fragwürdig ? Warum ?

Weil es keinen Grund gibt, einen Timer zu verwenden. Du hast damit dann 
nur den Nachteil, daß du mit der Verabeitung immer bis zum nächsten 
Timer-Interrupt wartest, statt das einfach sofort zu tun. Du schaffst 
dir also eine unnötige zusätzliche Latenz.

> Am besten wäre also, wenn ich den Empfangsinterrupt für ankommende
> Ethernetpackete nutzen würde ?

Ja.

[♪Geist (Gast)]

>1ms sollte zu schaffen sein.
locker. Mein STM32F107 schafft da 60Mbits, kannst gerne ausrechnen. LwIP 
kann ich dir ans Herz legen, toll gemacht, wenn auch anfangs wenig 
unübersichtlich.
Verwende das mit DMA und da reicht auch in deiner Main Loop nach Daten 
zu gucken, hier aus dem Beispiel:

    while (1) {
      if (ETH_GetRxPktSize()!=0) {
        LwIP_Pkt_Handle();
      } 
    }

[geb (Gast)]

>1ms sollte zu schaffen sein.
Als reine Durchlaufzeit durch den Stack sicherlich. Wenn aber noch 10 
Interrupts, die womöglich schlecht programmiert sind, und 2 DMA*s 
laufen, da kann dann viel passieren. Besser sich nicht auf solche 
Spekulationen einlassen, das fällt einem irgendwann auf den Kopf.

Grüsse

[Strubi (Gast)]

geb schrieb:
> Als reine Durchlaufzeit durch den Stack sicherlich. Wenn aber noch 10
> Interrupts, die womöglich schlecht programmiert sind, und 2 DMA*s
> laufen, da kann dann viel passieren. Besser sich nicht auf solche
> Spekulationen einlassen, das fällt einem irgendwann auf den Kopf.

Da haste allerdings recht.
Habe bei einem komplexeren Gesamtsystem deswegen gleich uClinux mit 
einem Echtzeit-Hack verwendet. War bisschen ein riskantes Spiel, aber 
lieber mit Kanonen auf Spatzen schiessen, anstatt sich in der 
Entwicklung verzetteln und wochenlang herumoptimieren...
Solange allerdings kein Netzwerk nötig ist, würde ich nicht mehr uClinux 
verwenden. Zudem gibt es einige Chips die dem "halt es simpel"-Prinzip 
der beliebten FTDI-Käfer folgen und direkt TCP <-> SPI bieten, etc. 
Allerdings müsste man da auch div. Echtzeitgarantiern evaluieren..

Grüsse,

- Strubi