Forum: Mikrocontroller und Digitale Elektronik W5500 flush UDP Buffer


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Heiko (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hallo zusammen,

ich nutze einen Wiznet W5500 Ethernet Adapter an einem STM32. Ich 
kommuniziere mit meinem PC per UDP im 1ms Takt um kleine Datenpakete 
auszutauschen. Wenn ich mir die Kommunikation im Wireshark anschaue, 
dann sieht man, dass immer wieder ein (manchmal auch mehrere Pakete) 
erst verzögert gesendet werden (ca. 2ms verzögert). Da ich im STM32 
einen Timestamp (Ticks) mitsende, sieht man, dass die Daten rechtzeitig 
in den Buffer des W5500 geschoben worden sind (SEND im SN_CR Register 
führe ich dazu aus).

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

Gibt es noch irgendeine Möglichkeit den Buffer zwangsweise sofort 
raussenden zu lassen (flush)? (Es befinen sich keine weiteren 
Netzwerkgeräte mit in dem Aufbau, die dazwischen funken könnten).

Danke und viele Grüße
Heiko

von Andi L. (andili)


Bewertung
0 lesenswert
nicht lesenswert
Ich verwende das Teil gerne mit Arduino und mich interessiert dabei 
nicht, ob Pakete taktgenau versendet werden.

Aber das Netz sagt das: 
https://github.com/Wiznet/ioLibrary_Driver/issues/31

War das hilfreich?

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Richtige Antwort Bezweifler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andi L. (andili)


Bewertung
0 lesenswert
nicht lesenswert
Richtige Antwort Bezweifler schrieb:
> Warum sollte er das?

Gute Frage, ich denke ehr Windows stellt immer wieder ARP Requests, die 
der W5500 dann beantwortet. Was sagt Wireshark dazu?

von Jitterer (Gast)


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

von Richtige Antwort Bezweifler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andi L. schrieb:
> ich denke ehr Windows stellt immer wieder ARP Requests

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

von Andi L. (andili)


Bewertung
0 lesenswert
nicht lesenswert
Richtige Antwort Bezweifler schrieb:
> Andi L. schrieb:
>> ich denke ehr Windows stellt immer wieder ARP Requests
>
> Nö, muss jeder Client machen sonst weiss er nicht wohin.


Klar, aber nur initial einmal. Windows füllt den ARP Table ständig neu 
(aktualisiert), wenn ich das richtig in Erinnerung habe

von Richtige Antwort Bezweifler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andi L. (andili)


Bewertung
0 lesenswert
nicht lesenswert
Richtige Antwort Bezweifler schrieb:
> Ja ok, Windows oder ein anderer Client könnte dazwischen-
> funken, dann muss UDP vom W5500 kurz aussetzen und warten.

Ja, das denke ich. Und da im W5500 ein Hardware UDP/IP Stack ist, kann 
man da wohl nichts dran ändern. Das weiß ich aber nicht sicher.

Wireshark wird das ganze aber einfach aufklären, ich bin gespannt.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Richtige Antwort Bezweifler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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...

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

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.