W5500 flush UDP Buffer

Heiko schrieb:

> Es geht nie ein Paket verloren, nur eben kommt es manchmal verzögert aus
> dem W5500 heraus. Meine Frage:
[falsche Frage]

Die richtige Frage dürfte sein: Was macht der W5500 STATT DESSEN?

Und vermutlich lautet die richtige Antwort darauf: Einen ARP-Lookup. Der 
sollte in Wireshark hervorragend zu sehen sein. Wenn man sinnvoll 
filtert...

Und was lernst du daraus? Hoffentlich: IP ist nicht sonderlich für 
Echtzeitanwendungen geeignet und NICs, die nur auf IP-Level arbeiten 
können demzufolge ebenfalls nicht...

Also hau wech den W5500-Scheiß und nimm statt dessen einen ENC28J60. Da 
kannst du auf Layer2 hantieren. Schon deutlich besser für Echtzeit...

c-hater schrieb:
> Und vermutlich lautet die richtige Antwort darauf: Einen ARP-Lookup.

Sehe ich nicht ein. Warum sollte er das? Er hat doch die Adresse
schon aufgelöst da er schon vorher jede Menge Pakete übertragen
hat. Warum sollte er so aus freien Stücken "zwischendrin" die
Adresse erneut auflösen? Insbesondere da er per UDP sowieso kein
Feedback bekommt ob sein Paket angekommen ist oder nicht.

Warum nimmst du keinen stm32f767zi o. Ä. Der schon einen ETH phy hat 
statt den w5500?

Andi L. schrieb:
> ich denke ehr Windows stellt immer wieder ARP Requests

Nö, muss jeder Client machen sonst weiss er nicht wohin.

Andi L. schrieb:
> Windows füllt den ARP Table ständig neu
> (aktualisiert), wenn ich das richtig in Erinnerung habe

Und was hat das dann mit der Funktion des W5500 zu tun wenn
der dauernd nur UDP Frames sendet?

Ja ok, Windows oder ein anderer Client könnte dazwischen-
funken, dann muss UDP vom W5500 kurz aussetzen und warten.

Richtige Antwort Bezweifler schrieb:

> Sehe ich nicht ein. Warum sollte er das?

Weil der Eintrag für den Peer in seinem ARP-Cache abgelaufen ist.

c-hater schrieb:
> Weil der Eintrag für den Peer in seinem ARP-Cache abgelaufen ist.

So ein Eintrag läuft nicht alle paar Sekunden ab. Da hätte
das Protokoll viel zu tun dauernd die ganze Tabelle abzuscannen,
zu prüfen und Einträge upzudaten. Das dürfte schwierig werden so
einen Ablauf überhaupt mitzukriegen.

Richtige Antwort Bezweifler schrieb:

> So ein Eintrag läuft nicht alle paar Sekunden ab.

Keine Ahnung, was der W5500 hier als Timeout hat. Der ist durch den 
Anwender konfigurierbar (siehe Seite 38 Datenblatt).

Außerdem: der TO schrieb rein garnix darüber, in welchem Abstand der 
Effekt auftritt, sondern konnte sich nur auf so nichtssagendes Gesülze 
wie

Heiko schrieb:

> dass immer wieder ein (manchmal auch mehrere Pakete)
> erst verzögert gesendet werden

festlegen.

Keine Ahnung, wo du hier die Angabe entnommen hast, dass es alle paar 
Sekunden passieren würde. Glaskugel der Extraklasse?

Was der TO allerdings konkretisiert hatte, was der auftretende Delay. 
Und der scheint mir doch recht gut für die Roundtriptime einer 
ARP-Anfrage in einem LAN zu passen.

> Da hätte
> das Protokoll viel zu tun dauernd die ganze Tabelle abzuscannen,
> zu prüfen und Einträge upzudaten.

Nur ein völlig bescheuerter Programmierer würde das auf diese Art 
implementieren. Sprich: du hast ganz offensichtlich keine Ahnung, wovon 
du redest...

Frage: Sendest du mit dem

0x20 SEND Command

oder dem

0x21 SEND_MAC  Command



denn ...
Valid only in UDP mode.The basic operation is same as SEND. Normally 
SEND transmits data after destination hardwareaddress is acquired by the 
automatic ARP-process(Address Resolution Protocol). But SEND_MAC 
transmits data without  the  automatic  ARP-process.  In  this  case, 
the  destination hardware  address  is  acquired  from  Sn_DHAR 
configured  by  host, instead of APR-process

Gruß Thomas