Hallo zusammen Wie auch hier in einem anderen Thread beschrieben hängt sich der W5500 auf und eine neue Kommunikation ist nur nach einem SW-reset möglich. Ich nutze den W5500 für eine binäre Netzwerkkommunikation (TCP), mein System ist dabei der Server. Das funktioniert seit mehreren Monaten problemlos, allerdings bin ich dazu übergegangen, zyklisch den TCP-Socket Status zu überprüfen. Sollte er nicht auf „listen“ stehen, dann wird der W5500 neu initialisiert. Soweit so gut (oder schlecht). Nun soll das System bei Bedarf eine eMail versenden (SMTP unverschlüsselt). Das habe ich nun auch hinbekommen. Nur nach der SMTP Kommunikation, die seitens des Servers mit der Nachricht: „221 2.0.0. Bye“ abgeschlossen wird disconnectiere ich den Socket wieder. Soll dann einen weitere Mail (mit der selben Routine) versendet werden, geht das nicht. Der RX-Speicher gibt nur noch wirre Zeichen aus. Die Überprüfung meiner Routinen (fehlende Inits etc) hat keinen Fehler gezeigt. Nur nach eine Neuinitialisierung des W5500 (SW-reset) kann ich wieder einen Mail versenden. Hat hier jemand eine Lösung dieser W5500 Fehlfunktion gefunden oder leben alle mit dem Workaround? Der funktioniert zwar, aber eventuell gleichzeitig laufende Kommunikationen auf anderen Sockets werden dadurch im Mitleidenschaft gezogen. Auch ja: W5500 Modul aus China, Controller-Modul ist eine Arduino-DUE PCB. Programmiersprache „C“ mit Atmel Studio. Keine Arduino-SW.
Hanns-Jürgen M. schrieb: > Hallo zusammen > > Ich nutze den W5500 für eine binäre Netzwerkkommunikation (TCP), mein > System ist dabei der Server. Das funktioniert seit mehreren Monaten > problemlos, allerdings bin ich dazu übergegangen, zyklisch den > TCP-Socket Status zu überprüfen. Sollte er nicht auf „listen“ stehen, > dann wird der W5500 neu initialisiert. Soweit so gut (oder schlecht). > Warum nicht wieder öffnen und in den Listen Zustand des Socket wechseln, wenn dieser zu ist? Eine z.b. bestehende Verbindung ist ja auch nicht mehr Listen diese würdest damit auch kappen wenn du den Chip reinitialisierst, was ja nicht zielführend wäre. > Nun soll das System bei Bedarf eine eMail versenden (SMTP > unverschlüsselt). Das habe ich nun auch hinbekommen. Nur nach der SMTP > Kommunikation, die seitens des Servers mit der Nachricht: „221 2.0.0. > Bye“ abgeschlossen wird disconnectiere ich den Socket wieder. > > Soll dann einen weitere Mail (mit der selben Routine) versendet werden, > geht das nicht. Der RX-Speicher gibt nur noch wirre Zeichen aus. Die > Überprüfung meiner Routinen (fehlende Inits etc) hat keinen Fehler > gezeigt. > Nach dem Socket Disconnect ist dieser zu, kannst du auch als Status auslesen. Als Client musst du dich wieder connecten oder als Server in den Listen Zustand wechseln, zuvor natürlich noch öffnen, wird das gemacht? Ist dann eine Verbindung aufgebaut geht normal das senden und empfangen wieder vorher natürlich nicht.
FloMann schrieb: > Hanns-Jürgen M. schrieb: >> Hallo zusammen >> >> Ich nutze den W5500 für eine binäre Netzwerkkommunikation (TCP)... >> > Warum nicht wieder öffnen und in den Listen Zustand des Socket wechseln, > wenn dieser zu ist? > Eine z.b. bestehende Verbindung ist ja auch nicht mehr Listen diese > würdest > damit auch kappen wenn du den Chip reinitialisierst, was ja nicht > zielführend wäre. Das erneute Öffnen funktioniert leider nicht. Aus unerfindlichen Gründen kommt es nach einer unbestimmbaren Zeit dazu, daß der Socket vom listen-Status 0x14 in den Staus 0 wechselt. ein erneutes Öfnnen geht dann nicht mehr. Ein anderer Socket, der auf UDP lauscht (Status 0x14) ist seltsamerweise davon nicht betroffen. Dieses Problem ist auch schon von anderen Usern thematisiert worden. Aber keine hat einen Lösung (außer Neuinitialisierung. > >> Nun soll das System bei Bedarf eine eMail versenden ... >> > Nach dem Socket Disconnect ist dieser zu, kannst du auch als Status > auslesen. > Als Client musst du dich wieder connecten oder als Server in den Listen > Zustand > wechseln, zuvor natürlich noch öffnen, wird das gemacht? > Ist dann eine Verbindung aufgebaut geht normal das senden und empfangen > wieder > vorher natürlich nicht. Ist schon klar. Die connect-Phase funktioniert (scheinbar) auch, aber was bei der folgenden SMTP-Kommunikation empfangen wird ist nicht das, was gesendet wird (Wireshark). Mir scheint es, also ob die Buffer im W5500 "verwurschtelt" sind.
Hanns-Jürgen M. schrieb: > Das erneute Öffnen funktioniert leider nicht. Aus unerfindlichen Gründen > kommt es nach einer unbestimmbaren Zeit dazu, daß der Socket vom > listen-Status 0x14 in den Staus 0 wechselt. ein erneutes Öfnnen geht > dann nicht mehr. Nur als Info, ich nutze den Wiznet 5500, nun auch 6100 als ref. eingepflegt in eigenen Designs mit eigener Software. Die von Wiznet bereitgestellten libs kenne ich nur vom überfliegen und erste kurz Tests mit den EvaKits. Status 0x00 ist ja closed, gibt es einen Socket Event? (Socket Interrupt Register) Discon/Timeout Event würde ja dann im Status closed enden. Wie führst du in dem Fall das erneute öffnen durch?, nur über Cmd Reg mit Open? Hast du Mal den Inhalt des Socket Mode Register geprüft das müsste ja noch den ursprünglichen wert für TCP und den weiteren ggf. gesetzten Optionen aufweisen. Sollte dies "unerwartet" z.b. 0x00 haben geht das öffnen nicht. Ist sicher gestellt das der Chip sich nicht vll. resettet hat? Und die Register sich im reset Default befinden? Wie häufig kommt das bei dir vor? Sowas konnte ich bisher "nicht" feststellen über relativ lange Zeit*. Ausnahme z.b. durch Einwirkung von Störungen im Design z.b. starkes ESD, Takt war dann für paar ms. auch nicht mehr vorhanden. Der Chip resettet sich, Register hatten reset Defaults also da kommt man um Register neu setzen nicht herum. Spannungen mal auf Einbrüche überwacht? *z.b. mehrfach 5AT am Stück durchgehend im Labor als Einzelelektronik und als System im Testanlagen Umfeld. > Ein anderer Socket, der auf UDP lauscht (Status 0x14) > ist seltsamerweise davon nicht betroffen. Dieses Problem ist auch schon > von anderen Usern thematisiert worden. Aber keine hat einen Lösung > (außer Neuinitialisierung. ?? Udp auf 0x14 (Listen) ??, Ein mit Udp geöffneter Socket hat doch 0x22 (Sock Udp) Wo thematisiert? Interesse halber, wenn's Schwachpunkte gibt kann es ja mal hilfreich sein diese zu kennen um ggf. Drumrumzuarbeiten.
Zur Vervollständigung, der Wiznet wird primär zur Maschinen Kommunikation per UDP genutzt. Dazu läuft noch eine absolut rudimentäre http Implementierung mit 3 möglichen aktiven Sockets bzw. auch reduziert auf einen und mit jeweils ein Socket auf TCP "Server" und UDP als Daten loopback. Also 4 Sockets wurde aktiv genutzt beim Testen. Letztendlich wird final nur die UDP basierte Kommunikation verwendet beim Testen wurde aber viel auch mit TCP gearbeitet und das nur vereinzelt ein Socket hier unerklärlich* nicht das macht was erwartet bzw sich "abschießt" kam nicht vor. *eigene SW Fehler ausgenommen was dann wiederum erklärlich war. Ein Socket auf Listen konnte ich nach Tagen noch erreichen und lief Einwandfrei. Wobei ich zugeben muss ob er dazwischen reopened wurde, und wenn warum (Timeout/Discon Event?) weiß ich jetzt nicht genau, er war halt erreichbar. Im Datenblatt wird jedenfalls nicht erwähnt (offensichtlich) daß der Listen Status sich selbst beendet. Sicher das bei dir die Software auch immer an den richtigen Socket n Basis Adressen plus Reg Offset arbeitet? Die Socket Konfig zur Fifo Größe passt zu den genutzten Sockets. Der Rx read ptr des sockets wird aktualisiert und der Empfang mit recv Cmd abgeschlossen?
FloMann schrieb: > Zur Vervollständigung, ................ > ................................... Jemand der mit TCP und Sockets umgehen kann sollte auch des Formatierens von Texten mächtig sein. Verwende einen Editor mit dem du den Zeilenumbruch machen kannst und kopier dann den (ausreichend schmal) formatierten Text in das Fenster zum Posten. Zu schwer? Zu kompliziert? ----------------------------------------------------------------- Zur Vervollständigung, der Wiznet wird primär zur Maschinen Kommunikation per UDP genutzt. Dazu läuft noch eine absolut rudimentäre http Implementierung mit 3 möglichen aktiven Sockets bzw. auch reduziert auf einen und mit jeweils ein Socket auf TCP "Server" und UDP als Daten loopback. Also 4 Sockets wurde aktiv genutzt beim Testen. Letztendlich wird final nur die UDP basierte Kommunikation verwendet beim Testen wurde aber viel auch mit TCP gearbeitet und das nur vereinzelt ein Socket hier unerklärlich* nicht das macht was erwartet bzw sich "abschießt" kam nicht vor. *eigene SW Fehler ausgenommen was dann wiederum erklärlich war. Ein Socket auf Listen konnte ich nach Tagen noch erreichen und lief Einwandfrei. Wobei ich zugeben muss ob er dazwischen reopened wurde, und wenn warum (Timeout/Discon Event?) weiß ich jetzt nicht genau, er war halt erreichbar. Im Datenblatt wird jedenfalls nicht erwähnt (offensichtlich) daß der Listen Status sich selbst beendet. Sicher das bei dir die Software auch immer an den richtigen Socket n Basis Adressen plus Reg Offset arbeitet? Die Socket Konfig zur Fifo Größe passt zu den genutzten Sockets. Der Rx read ptr des sockets wird aktualisiert und der Empfang mit recv Cmd abgeschlossen? -----------------------------------------------------------------
Ich weiß jetzt nicht worauf du hinaus möchtest. An meinem Tab mit Chrome sehe ich die selben Absätze wie in deiner Version nur mit etwas längeren Zeilen dafür aber auch mit weniger Zeilen. BTT
Angehängte Dateien:
-
Textumbruch.png
24 KB
FloMann schrieb: > An meinem Tab mit Chrome sehe ich die selben > Absätze wie in deiner Version nur mit etwas > längeren Zeilen dafür aber auch mit weniger Zeilen. Auf meinem Firefox sehe ich da eine etwas chaotischere Darstellung.
Angehängte Dateien:
-
Textumbruch_2.png
23 KB
oweiowei schrieb: > Auf meinem Firefox sehe ich da eine etwas chaotischere Darstellung. Wenn das Firefox Fenster schmäler ist, dann eine noch chaotischere.
Angehängte Dateien:
Um das Format Thema abzuschließen, so sieht es an meinem Tab aus.
FloMann schrieb: > >> Ein anderer Socket, der auf UDP lauscht (Status 0x14) >> ist seltsamerweise davon nicht betroffen. Dieses Problem ist auch schon >> von anderen Usern thematisiert worden. Aber keine hat einen Lösung >> (außer Neuinitialisierung. > ?? Udp auf 0x14 (Listen) ??, Ein mit Udp geöffneter Socket hat doch 0x22 > (Sock Udp) > Wo thematisiert? Interesse halber, wenn's Schwachpunkte gibt kann es > ja mal hilfreich sein diese zu kennen um ggf. Drumrumzuarbeiten. Sry, habe das vertauscht. $14 ist TCP lauschen, §22 ist UDP lauschen. Allen anderen Hinweise, auch die in den übriegen Antworten, werde ich nachgehen und testen. Ich werde dann berichten. Noch einen schönen Sa-abend.
> Sicher das bei dir die Software auch immer an den richtigen Socket n > Basis Adressen > plus Reg Offset arbeitet? Die Socket Konfig zur Fifo Größe passt zu den > genutzten Sockets. > Der Rx read ptr des sockets wird aktualisiert und der Empfang mit recv > Cmd abgeschlossen? Ja, bei mir ist Socket 0 fix UDP Server, Socket 1 fux TCP Server, Socket 2 reserviert als TCP-Client (eMail), gerade neu im Aufbau.
oweiowei schrieb: > FloMann schrieb: >> Zur Vervollständigung, ................ >> ................................... > > Jemand der mit TCP und Sockets umgehen kann sollte auch des > Formatierens von Texten mächtig sein. > > Verwende einen Editor mit dem du den Zeilenumbruch machen kannst > und kopier dann den (ausreichend schmal) formatierten Text in > das Fenster zum Posten. Zu schwer? Zu kompliziert? > > ----------------------------------------------------------------- >er Empfang mit recv Cmd > abgeschlossen? > ----------------------------------------------------------------- Sehr hilfreich, danke ..... Ironie aus.
Marco H. schrieb: > Beitrag "einfache und performante W5500 LIB" > > Immer wieder gut den Thread zu lesen ;) ist nun auf meiner TODO Liste.. Ich verwende übrigens modifizierte Routinen aus div. Libraries und bauer Timeouts ein...
Normalerweise macht man mehrere Sockets mit dem Port xxxx auf, damit man auch mehrere Clients abarbeiten kann. Ist kein offener Socket vorhanden lehnt der W5500 die Verbindung ab. Das passiert dir auch wenn du die Sockets nach erfolgreicher Abhandlung nicht wieder in den richtigen Mode bringst. Dann nimmt der w5500 den nächsten Slot... Bis dann gar nichts mehr geht... Du musst auch alle Sockets abklappern für deinen Service. Wenn du mehre Dienste laufen hast, musst du Aufpassen das du auch die richtigen Register abfragst. Nicht das Dienst A, Dienst B ausließ, der kann dann mit den Daten nix anfangen. Flags mit Timeouts sind wichtig, um die Slots wieder in den richtigen Mode zu bekommen. Sonst bleibt dieser womöglich in einem Status hängen...
:
Bearbeitet durch User
Marco H. schrieb: > Normalerweise macht man mehrere Sockets mit dem Port xxxx auf, damit man > auch mehrere Clients abarbeiten kann. Ist kein offener Socket vorhanden > lehnt der W5500 die Verbindung ab. Das passiert dir auch wenn du die > Sockets nach erfolgreicher Abhandlung nicht wieder in den richtigen Mode > bringst. Dann nimmt der w5500 den nächsten Slot... Bis dann gar nichts > mehr geht... > > Du musst auch alle Sockets abklappern für deinen Service. > > Wenn du mehre Dienste laufen hast, musst du Aufpassen das du auch die > richtigen Register abfragst. Nicht das Dienst A, Dienst B ausließ, der > kann dann mit den Daten nix anfangen. > alles klar. > Flags mit Timeouts sind wichtig, um die Slots wieder in den richtigen > Mode zu bekommen. Sonst bleibt dieser womöglich in einem Status > hängen... ja, das lassen die Originalroutinen der Library zu (Copyright (c) 2013, WIZnet Co., LTD.) So, ich habe ein wenig weiter experimentiert und habe nun die SMTP und POP3 Anwendung laufen. Die Ursache meiner Anfangs beschriebenen SMTP-Sende Probleme habe ich zwar nicht gefunden, ich gehe aber davon aus, dass es sich um einen Fehler in der Beendigung des SMTP-Dialogs gehandelt hat. Das ist behoben. Also wie üblich, mein SW Fehler. Zur anderen Geschichte: Ich hatte hier im Forum vor rund vier Monaten bereits von dem Aufhänge-Problem des W5500 berichtet, das aber gelöst wurde. Es war ein RESET-Pin Problem des Arduino-DUE (Einstreuung). ( Beitrag "Arduino DUE Hardware mit W5500: Seltsame Absturzprobleme" ) Das funktioniert bis jetzt durchgängig. Und ich hatte mich geirrt/ falsch erinnert: Ich brauche keinen SW Reset des W5500 zu machen. Zu "meinen" Sockets: Ich verwende drei fest zugeordnete Sockets. Nr. 0 als UDP Server, Nr. 1 als TCP Server und Nr. 2 bei Bedarf als TCP-Client für SMTP oder POP3. Die Benutzung weiterer TCP-Server Sockets habe ich zwar angedacht, ist aber aktuell bei meiner Anwendung (noch) nicht notwendig. BTW: Es scheint so zu sein, daß die Sockets nur der Reihe nach geöffnet werden können. Die Socket-Installation von Nr. 0,1,3 scheitert. Ich muss das mal genauer analysieren.
Dein Hanns-Jürgen M. schrieb: > BTW: Es scheint so zu sein, daß die Sockets nur der Reihe nach geöffnet > werden können. Die Socket-Installation von Nr. 0,1,3 scheitert. Ich muss > das mal genauer analysieren. Eigentlich nicht, sie unterscheiden sich nur in den Adressen. Dein Server kann nur einen Client abwickeln. Versucht ein weiterer Client sich mit dem Port zu verbinden wird diese abgelehnt. Deine Clients sollten also so konfiguriert sein das sie es zufällig noch mal versuchen. Vorsicht mit ARP der W5500 kann nur eine MAC aufnehmen. Connects zu mehreren Zielen lösen immer wieder ARP Telegramme aus. Das kann womöglich etwas dauern...
:
Bearbeitet durch User
Marco H. schrieb: > Vorsicht mit ARP der W5500 kann nur eine MAC aufnehmen. Connects zu > mehreren Zielen lösen immer wieder ARP Telegramme aus. Das kann > womöglich etwas dauern... Ach du Schande ..... das ist ja mal ein heisser Tip! Danke dafür. Ist sicher beim W5100 nicht anders .... Vielleicht bist du auch beim LWIP mit diesen Gegebenheiten vertraut (und könntest es uns verraten)?
Aber es gibt für jeden der max. 8 möglichen Sockets Register für die Ziel Mac.
Ja fällt dir aber trotzdem auf die Füße, wenn dein UDP Socket Daten an verschiedene Ziele senden muss. Oder man die Verbindung an eine andere IP neu aufbaut, dann dauert es durch ARP länger. Ich hatte damals eine Artnet Node gebaut die in der Lage war zwei Streams zu mischen HTP/LTP, mich dann gewundert warum dann über 2sec alles blockiert ist. Sobald die Ziel IP unterschiedlich ist wird diese aufgelöst, geht ja nicht anders. Abhilfe gab es nur in dem ich mein eignendes Table aufgebaut habe und die MAC vor dem senden in das Register geschrieben wurde. Dadurch das dass Table nur eine MAC aufnehmen kann wird viel Broadcast nebenbei erzeugt wenn man unterschiedlich Ziele bedient.
FloMann schrieb: > Aber es gibt für jeden der max. 8 möglichen > Sockets Register für die Ziel Mac. Eben aber nur eine! Entweder du füllst dieses selbst mit der MAC oder es wird vor dem senden aufgelöst -> ARP Trafic. Man wundert sich dann warum das senden soooo lange dauert. Der Chip ist Käse, das wissen die meisten auch ;)
So, nachdem ich zwei Tage wegen eines idiotischen Fehlers meinerseits sinnlos verplempert habe, werde ich mich wieder dem Thema widmen. Email senden klappt, Pop3 abfragen "manchmal". Ursache dafür liegt wohl nicht bei mir bzw. W5500: Der Versuch, den POP3 Port (110) zu connectieren wird oft mit "Port unreachable" (Wireshark) zurückgewiesen. Daher ist alles etwas zäh.
Marco H. schrieb: > Der Chip ist Käse, das wissen die meisten auch ;) ich bin auch kein Wiznet Freund, aber die ARP Probleme kann ich nicht nachvollziehen. Die ARP Tabelle enthält die Zuordnung MAC <> IP Adresse, und die ist eindeutig. Verschiedene IP, verschiedene MAC, wo ist das Problem? Die Protokolle die darüber liegen unterscheiden noch Ports, aber damit hat die ARP Tabelle ja nichts mehr zu tun.
Das Problem ist das der Chip kein eigenes ARP Table aufbaut. So wie es fast jeder TCP/IP Stack machen würde. Es ist ja ein TCP/IP Stack da interessiert mich die MAC Adresse nicht. So lange du nur TCP/IP benutzt fällt das nicht so wirklich ins Gewicht. Wenn du aber Daten an verschiedene UDP Ziele senden willst, gibt es dann ein Problem... Selbst wenn du die MAC dann selbst in das Register schreibst, ist dies ein schreib zugriff mehr.... Diese dumme Eigenschaft ist nicht transparent genug, wie vieles an dem Ding...
:
Bearbeitet durch User
Angehängte Dateien:
-
W5500-Arp.png
260 KB -
W6100-Arp.png
230 KB
Hallo, es ist jetzt schon etwas her aber nochmal etwas zum ARP. Anbei mal dazu zwei Bilder für W5500 und W6100. Der W5500 (192.168.71.18) hängt an einer EFM8LB12 MCU, der W6100 (192.168.71.02) ist im Bus IO Mode an einem C8051F64. Es wird eine komplett eigene Lib für die Wiznet's verwendet. Es läuft auch noch normales "Programm" nebenher auf der MCU. Dazu kommen zwei Windows PC's (*.100 und *.200) welche mit AX1 Daten senden und im Loopback zurückbekommen(ein UDP Socket). Gestartet wurde mit Client *.200, dann kam *.100 dazu und es wurde innerhalb Wireshark jeweils auf das erste Arp für Client *.100 Frame referenziert. Natürlich kommt es so zu jedermenge ARP "Transfers". Allgemein könnte man auch überlegen ob sowas generell geschickt umgesetzt wäre für seine Applikation, das man ständig mit einem Socket alterniert und es sehr fix/zeitnah raus gehen muss. Und ja, wenn es das muss um sein Ziel zu erreichen, kann man sich dann auch eine ARP Tabelle anlegen um sich die Zeit für den automatischen ARP zu Sparen. Man sieht aber auch das in einem Lokalen Netz der ARP Transfer nicht pauschal zu einem Problem führen muss da es jetzt auch keine Ewigkeiten länger dauert. Ich finde es etwas aufgebauscht und kann auch nicht beurteilen woher deine, "mich dann gewundert warum dann über 2sec alles blockiert ist", kommen. Im Zweifel von deiner Gegenstelle bei der Beantwortung des ARP, oder generell dein Lib und Nutz Code? Zuvor (und immer noch) setzen wir auch einen reinen MAC mit Phy ein und haben einen Stack in Software. Auch dieser legt perse keine ARP Tabelle an und die MAC Adresse muss aufgelöst werden. Wäre hier nicht anders und im allgemeinen mit vergleichbar eingesetzten MCU's im vgl. langsamer und Speicher hungriger. Ich persönlich finde die Wiznet Chips (W5500/6100) schon im Rahmen ihrer Möglichkeiten empfehlenswert. Es ist ein möglicher Weg der Ethernet Kommunikation im Embedded bereich von vielen. Aber die "Kenner" mögen das besser einschätzen können. Grüße FloMann
Hallo zusammen, mein ursprüngliches, im Eingangsthread beschriebes Problem ist gelöst bzw. hat sich in Luft aufgelöst. Ich kann nun beliebig Mails verschicken, abfragen und das alles auch noch unter DNS-Einsatz. Alles nun mit beliebiger Socket-Nr und ohnen Neuinit des W5500 Wie immer lag das Problem in meiner SW bzw. in der Verwendung der besagten Libraries. Die Library habe ich begonnen, komplett umzuschreiben, bzw. nur die Teile, die ich auch benötige. Und das alles mit Timeouts versehen, so daß sich nichts mehr aufhängen kann. Überhaupt war das "Timing" das eigentliche Problem. Ich hatte keine hinreichend lange Warteschleifen vorgesehen. Nur, diese würden grundsätzlich mein SW-Konzept durcheinanderbringen, da ich alle paar Hundert Millisekunden die Hauptprogrammscheife durchlaufen muß. Also habe ich die SMTP, POP3 und die DNS Routine in "Routinchen" portionsweise zerteilt, die dann einzeln in jedem Schleifenumlauf nacheinander angesprungen werden. Ist das Routinchen noch nicht durchlaufbar, weil z.B. noch keine Daten empfangen wurden, dann versuch es erneut im nächsten Umlauf bis zum Timeout. Sonst bearbeite das nächste "Routinchen". Das eigentliche Thema ist damit "erledigt"
Schön... Zum ARP... diese ganze Broadcast müssen alle Teilnehmer im Netz verarbeiten. Dein PC antwortet darauf relativ schnell. Dein TCP/IP Stack im microcontroller deutlich langsamer und wenn die Netze größer werden ist die Trafic auch höher. Gräte mit Mikrocontroller etc. sind nicht in der lange eine Bandbreite mit z.Bsp 100Mbit/s zu verbreiten. Dessen Ports werden überflutet und es gehen Pakete verloren. Ich kam real beim w5500(Arduino DUE) mit HTTP Server auf 1,5Mbit/s(gut mit lesen von der SD-Karte die auf dem selben SPI Port hängt) , UDP 8-10Mbit/s (Artnet DMX). Dein ganzer SPI Protokoll Overhead lässt nicht viel mehr zu, auch beim SPI Takt von 80MHZ. Schau mal die Trafic von W5500 an und du wirst bemerken das dort auch bei TCP ganz viele Pakete erneut angefordert werden.
:
Bearbeitet durch User
Hanns-Jürgen M. schrieb: > Überhaupt war das "Timing" das eigentliche Problem. Ich hatte keine > hinreichend lange Warteschleifen vorgesehen. Nur, diese würden > grundsätzlich mein SW-Konzept durcheinanderbringen, da ich alle paar > Hundert Millisekunden die Hauptprogrammscheife durchlaufen muß. Also > habe ich die SMTP, POP3 und die DNS Routine in "Routinchen" > portionsweise zerteilt, die dann einzeln in jedem Schleifenumlauf > nacheinander angesprungen werden. Ist das Routinchen noch nicht > durchlaufbar, weil z.B. noch keine Daten empfangen wurden, dann versuch > es erneut im nächsten Umlauf bis zum Timeout. Sonst bearbeite das > nächste "Routinchen". Also eine "Art" des kooperativen Multitasking. Ich hatte mich recht schnell dazu entschieden unter anderem auch aus dem Grund hier etwas eigenes aufzusetzen was auch primär über die Socket Events funktioniert (Socket Interrupt Register). Aber Ende gut alles gut, klasse das du dein Ziel noch funktional sauber erreichen konntest.
Angehängte Dateien:
-
W5500-ArpReply.png
12 KB
Marco H. schrieb: > Schön... > > Zum ARP... diese ganze Broadcast müssen alle Teilnehmer im Netz > verarbeiten. Dein PC antwortet darauf relativ schnell. Da erzählts du mir aber nun was neues, der Wiznet antwortet(autark) auf den ARP zwar nicht ganz so schnell aber es geht immer noch recht fix. Ansonsten schweifst du nun von deiner Wiznet und ARP "problematik" ab. Deine "mich dann gewundert warum dann über 2sec alles blockiert ist", ist mir immer noch unklar und wenn es um die halbe Weltkugel ging okay mag das sein was jetzt nix daran ändert das dies kein Prinzipielles Wiznet problem ist. > Dein TCP/IP Stack im microcontroller deutlich langsamer und wenn > die Netze größer werden ist die Trafic auch höher. Worauf möchtest du hinaus? Gerade weil z.B. unser Software Stack mit ext. MAC/Phy an den älteren eingesetzten MCU's langsamer und anspruchsvoller bei Code und Ram ist bietet der Wiznet für diese Basis und unseren Zweck eine gute Alternative. Auch gerade bei mehr Teilnehmern und Traffic im Netz. Aber ja er hat auch klar seine grenzen (z.b. Socket Anzahl und die RX/TX FIFO Größe). > Gräte mit Mikrocontroller etc. sind nicht in der lange eine Bandbreite > mit z.Bsp 100Mbit/s zu verbreiten. Dessen Ports werden überflutet und es > gehen Pakete verloren. Ich kam real beim w5500(Arduino DUE) mit HTTP > Server auf 1,5Mbit/s(gut mit lesen von der SD-Karte die auf dem selben > SPI Port hängt) , UDP 8-10Mbit/s (Artnet DMX). Da sehe ich jetzt kein prinzipielles Wiznet Problem, der macht das was er soll im Rahmen seiner Möglichkeiten. Ich verstehe dann eher bei den "Anforderungen" nicht warum man bei einen Atmel Sam3 mit MAC nicht diesen nutzt sowie die Schnittstelle für die SD Karte. Weil es kein Arduino Shield dafür gibt? Jetzt nimmt man einmal SPI und quetscht SD Karte und W5500 dran? Schreibt/nutzt dann noch ineffizienten Code dazu. Ja gut dann muss man mit 1,5Mbit/s leben. Wenn es für die Anforderrung reicht dann ist ja auch voll in Ordnung. > Dein ganzer SPI Protokoll Overhead lässt nicht viel mehr zu, auch beim > SPI Takt von 80MHZ. 80Mhz SPI kann man quasi vergessen, wenn man real >> 10Mbit bei ETH benötigt sollte man zuvor auch andere Möglichkeiten in betracht ziehen. Dafür ist der Wiznet mit SPI Schnitstelle sicher nicht gemacht. Mit 32Mhz SPI guten Code sollten 20Mbit one Way auch drin sein. > Schau mal die Trafic von W5500 an und du wirst bemerken das dort auch > bei TCP ganz viele Pakete erneut angefordert werden. Hab ich zahlreich, was genau stört dich hier? Viele TCP Retransmissions? Oder Paket Loss bei UDP? Ist hier bei mir kein wirkliches Problem. Kleinvieh macht auch mist so das man am Tag auch mal x GByte transferiert und das soweit ohne Probleme. PS im Bild die ARP Antwort Zeit des W5500 (und ja da steht/ist auch mal etwas mehr)
Ich habe damals die Treiber weiter entwickelt und der Code war grauenhaft... Daraus ist dann eine Artnet Node entstanden mit vollen RDM Support. Man kann verschiedene Streams von Universen mischen HTP/LTP. Auf dem Socket laufen dann zwei Streams ein von unterschiedlichen Quellen a 4 Universen, die auf einen 4x 512 Channels auf ws2812 + auf DMX mit RDM! und 1x DMX in mit RDM!. Das alles weil es nur um den Software ging auf Basis des DUE mit Shield. Da muss man nehmen was man bekommt. Schon recht schnell war klar das der W5500 keine gute Wahl war... Es fehlte Frames durch das Bufferproblem(ok Software), wegen ARP fehlten Frames da während der Auflösung der Socket blockiert war, UDP Pakete gingen verloren. Ziemlich doof bei 44 Frames/s, merkt man sofort das was fehlte... Durch RDM gibt es auch Trafic zurück zu den Controllern... An sich hat die Leistung vom DUE schon ausgereicht, viel Zeit verging um den Gurkencode des Herstellers zu überarbeiten. Bis heute ist dieser kein Stück besser geworden, einfach nur grauenhaft, wie der w5500 auch. Der ist aus vielen Applikationen mittlerweile auch wieder verschwunden. Zu hoher Strombedarf, 100Mbit PHY, macken im Stack usw...
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.