Stabilität von Lwip und stm32

LWIP läuft auf dem ESP8266 mit dem SDK 1.5.4 absolut stabil.

Wenn es bei Dir nicht läuft, wird es wohl eher daran liegen, wie es 
konkret eingebaut wurde oder was drumhum noch läuft.

Stefan U. schrieb:
> wird es wohl eher daran liegen, wie es
> konkret eingebaut wurde

Nein. Es wird wohl dann an der Entwicklung selbst liegen,
nicht daran wie es eingebaut wird.

Bu B. schrieb:
> auf ein selbstgebautes STM32F4 board.

Der Rest bleibt Rätselraten.

An der eigenen Kreation kann es ja nie liegen.
Nur immer an den anderen ....

Ich merke gerade, daß ich ein lustiges neues Wort erfunden habe: drumhum

Stefan U. schrieb:
> LWIP läuft auf dem ESP8266 mit dem SDK 1.5.4 absolut stabil.

Welche Version? Es kursiert ja eine 1.4x und eine 2.0x ....

Dieselbe Frage an den TO.

>> LWIP läuft auf dem ESP8266 mit dem SDK 1.5.4 absolut stabil.
> Welche Version? Es kursiert ja eine 1.4x und eine 2.0x ....

Das weiß ich nicht. Wenn es Dich interessiert, dann lade Dir das SDK 
runter und schau selber nach. Ab behalte im Kopf, daß dieses SDK nicht 
für STM32 geeignet ist.

ich lwip v20

Bu B. schrieb:
> ich lwip v20

... und an deiner Schaltung kann's ja nicht gelegen haben.

Gell?

Nur mal so zum Eingewöhnen:

Beitrag ""Kettenreaktion" von Relais zu Atmega644 löst Reset aus"

Stefan U. schrieb:
> Wenn es Dich interessiert, dann lade Dir das SDK
> runter und schau selber nach.

Nö. Ich brauch kein SDK. Und will auch gar nicht drin
herumwühlen.

Wenn man solche Infos in den Raum stellt sollte man doch
wissen wovon man redet ....

Bei mbed gibt es einen Fix für den STM32 emac Treiber für den Fehler:
STM32 - fix bug were sockets stop receiving data

https://github.com/ARMmbed/mbed-os/commit/9620b0fc7fcb63d792e5b68e8c55e3c31b273811

m.f.G.
Dieter Gräf

http://mikrocontroller.bplaced.net/wordpress/?page_id=1756

Läuft bei mir seit 2 Jahren mit dem STM32F4 Discovery und dem DP83848 
von waveshare durch. Noch hat der Ping-Monitor kein einziges mal 
gemeckert, dass er nicht im 1 Sekundentakt eine Antwort bekommen hätte.

Michi schrieb:
> und dem DP83848 von waveshare

Nein. Der DP83848 ist von National Semiconductor.
Soviel Wahrheit muss sein.

Michi schrieb:
> Läuft bei mir seit 2 Jahren

Um eine Bestätigung der "Fehlerfreiheit" zu bringen müsstest
du zumindest in die Nähe dieser Performance gelangen:

Bu B. schrieb:
> UDP packet länge ist 512 byte. und davon 40 mal die Sekunde.

Gilt auch für

Stefan U. schrieb:
> LWIP läuft auf dem ESP8266 mit dem SDK 1.5.4 absolut stabil.

Ich bezweifle mal dass Stefan 40 mal in der Sekunde 512 Bytes
USP Pakete über den ESP8266 jagt.

> Ich bezweifle mal dass Stefan 40 mal in der Sekunde 512 Bytes
> USP Pakete über den ESP8266 jagt.

Habe ich auch nicht. Der Datendurchsatz sollte keine Rolle spielen. Wenn 
doch (und das will ich hier nicht abstreiten) dann ist die Software oder 
Hardware antürlich fehlerhaft.

> Wenn man solche Infos in den Raum stellt sollte man doch
> wissen wovon man redet ....

Für den STM32 und konkret diese Anwendung kann ich keine direkte Hilfe 
bieten. Allgmein traue ich dem LWIP aufgrund positiver Erfahrung jedoch 
sehr gute Stabilität zu, was mich zu dem Rat bringt, den Fehler erstmal 
woanders zu suchen.

dazu wäre die konfig der lwipopts.h nötig
ebenso wichtig wäre die frage RTOS? oder polling ?

wichtig sind anzahl der buffer ...
gerade ei 40x pro sek kommen da einige daten zusammen



Ich betreie den STM mit RTOS und lwip
alles parallel :
RTP stream in/out  Audio stream
RTP stream in  Video stream MJPEG
Websocket Secure verindung mit max 8kb Block
HTTP server
usw ...

es geht ..
muss nur konfiguriert werden

lwIP ist auch in vielen kommerziellen Produkten drin. Z.B. in GigE 
Kameras von Basler und da läuft das sauber im 24*7 Betrieb.
Kritischer ist der Teil wie das Senden/Empfangen der Pakete an die 
Hardware angebunden ist, da unterscheiden sich die Implementierungen ja.
Und ich kenne eine Bude die fast Jahr nach einem Fehler in UDP 
Datenverkehr mit STM32F4 gesucht hat. Das Senden hörte zuverlässig nach 
einigen Wochen oder Monaten auf. Ursache waren Zähler im STM die bei 
Überlauf einen Interrupt generieren. Nach 2^31 gesendeten Paketen wollte 
die HW nix mehr senden.

Ich würde, wenn es um so kleine HW-Stückzahlen geht, immer dazu 
tendieren etwas fertiges für den Netzwerk-Verkehr zu nehmen. Das läuft 
einfach im Regelfall stabiler.

z.B. gibt es inzwischen viele kleine Linux-Boards mit OpenWRT drauf. Da 
läuft Netzwerk dann out-of-the box und kann seine Applikation im 
Linux-UserSpace laufen lassen. Kommunikation nach außen dann z.B. über 
USB oder so