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
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?
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.
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?
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.
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
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: > 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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.