Hallo, wal meider ein neues Problemchen. Ich "spiele" gerade mit einem W5500 Modul an meiner Arduino DUE Plative. (Standard C) Die Ansteuerung des W5500 funktioniert, ich kann auch als Webserver "laucschen" und die Anfrage des Browsers "sehen". Ich antworte auch richtig, bzw,. will richtig antworten. Aber das kommt offensichtlich nicht an. Der W5500 scheint den Sendebefehl bzw. das Einschreiben der Strings zu ignorieren. Stutzig macht mich, daß der bei der Anfrage vom Browser geöffnete Socket sofort (oder einige ms) nach der Anfrage geschlossen wird. Ist das korrekt? Meines Wissens doch eher nicht, aber ich finde keine Möglichkeit, einen Time-Out zu programmieren. Weiterhin "dubios" finde ich die RD und WR Pointer des TX-Buffers. Diese liegen bei jeder Browseranfrsge höchst unterschiedlich verteilt in einem 64k Adressraum. Das ist mehr als verwunderlich, da doch nur 16kbyte für alle TX-Sockets in suma verfügbar sind. Trotz Sendebefehl (0x20) wird (logischerweise??) der Sendebuffer NICHT gesendet... Falls keine triviale Lösungsantwort möglich ist, poste ich gerne den Sourcecode (aus main.c) und die betreffende Senderoutine, die bei Github gefunden und dann entsprechend modifiziert habe. Aber das würde viel Platz in Anspruch nehmen. Vielleicht ist es auch nur eine "Kleinigkeit", die ich übersehen habe. Allerdings hatte ich vor einigen Jahren einen AVR ARduino mit einem W5100 mit den gleichen Hauptprogrammroutinen laufen. So, jetzt mache ich "Schluß" und bin erst morgen wieder am PC.
Hallo zusammen, leider hat keiner auf meine Anfarge von gestern geantwortet. Heute habe ich viele (!) Stunden damit verbracht, mit Hilfe des Internets und durch Tests dem Problem auf die Spur zu kommen. Auch ein Wechsel der HW (Ich habe drei W5500 PCBs) hat nichts gebracht. Schlußendlich habe ich meine SW radikal gechopped. Problem scheint eine eher zufällige Falschinitalisierung des TX_Wr und und des TX_RD Pointers des jeweiligen Sockets zu sein. Nach Programmstart initialisiere ich den W5500 als TCP-Server und schalte ihn auf "Listen" Zudem setze ich die TX Pointer auf 0. Das funktioniert auch, ich lese sie nach der Initialisierung zyklich aus. Eine Auswertugn der evnetuellen Browserabfragen findet nicht statt, in keinster Weise. Aber sobald der Browser seinen Anfragestring sendet, wird zwar der RX-Pointer richtig gesetzt, aber der TX-Pointer wird mit einen eher zufälligen Wert überschrieben. Das ist absolut reproduzierbar, allerding ist der jeweilige TX-Pointerwert (Der WR-Pointer) zufällig. Die Main-Schleife sieht wie folgt aus...
1 | while (1) { |
2 | WDT->WDT_CR = 0xA5000001; //REset Watchdog |
3 | TFT_csabs(7,1); |
4 | printf("%02X SR %02X SN %02X", server_client_available(), client_status(),client_get_sock()); |
Der IRQ des W5500 ist nicht aktiv. Socket "0" ist in dfer Auswerteroutine estgelegt, da dieser nach einem RESET auch automatisch gewählt wird. Ich stehe völlig auf dem Schlauch. Sicherlich liegt der Fehler bei meiner SW, aber wo könnte ich noch suchen? Pls help.
Prinzipiell zum W5500 da mir die Arduino Implementierung auch nicht bekannt ist. Erstmal ist es nicht schlecht dessen Dateblatt zu bemühen da ist das mapping der Rx/Tx Fifos als auch das handling mit dessen zeigern erläutert. Die Fifo Zeiger initialisiert der W5500 selber, je nach Protokoll, beim Öffnen oder dann beim connect Event des Socket dir kann es dabei egal sein wo diese im 64k Adressraum liegen. Zum Senden als Beispiel. 1. Prüfe auf freien Platz im Tx Fifo gibt entsprechendes register dazu und beachte das ein nur einmaliges lesen zu Fehler führen kann da nicht atomar. also z.b doppelt lesen so lange beide gelesenen werte gleich sind. Dies beim Rx Register für Anzahl Bytes im Fifo genau so. Wenn nun platz zum Senden von Daten ist, dann: 2. Tx Write Zeiger aus w5500 lesen. 3. Daten in den Tx Fifo schreiben. 4. Die Anzahl Bytes der in den Fifo geschriebenen Daten auf den Tx write Zeiger aufaddieren und diesen wert an den w5500 zurückschreiben. 5. Send cmd absetzen. Fertig, um mehr muss man sich mit den Fifo zeigern nicht kümmern. Gruß Florian
Hallo Florian, danke für Deine Antwort. Das Datenblatt habe ich (natürlich) intensiv studiert, nur es bringt nicht wirklich die Erleuchtung bezüglich des Fifo Mappings. Ich habe es, wie auch einige andere Postings im I-Net ergeben haben, so verstanden, daß der jeweilige Pointer (TX-WR, TX-RD, RX-WR, RX-Rd) bei 0 anfängt und dann beim Überschreiten der Maximalgrneze wieder bei = beginnt. Das tatsächliche Mäpping also für den user verborgen bleibt ( Beim W5100 ist es, so glaube ich mich zu erinnern, etas anders). Ich bin mir da aber nicht sicher. Beim RX-WR-Fifo Pointer zumindest ist es so. Ich beschreibe das TX-Fifo genau so wie Du es erwähnt hast, auch mit der Überprüfung beim Lesen der 16-bit Register. Ich werde das aber nochmals genau untersuchen, vielleicht liegt da ein Fehler im Detail. Ich melde mich dann.
So, ein kleines Update: Offenbar ist ist Wert der TX-Fifo Pointer tatsächlich "irgendwo" im 64k Adressraum Ich habe ein paar Vereinfachungen in meiner SW vorgenommen und nun scheint tatsächlich etwas ausgesendet zu werden. Das das der Browser nicht als Antwort akzeptiert dürfte wohl nicht am W5500 liegen. Ich will mal versuchen, mir den Datenstrom anzusehen. Ich melde mich wieder...
Hanns-Jürgen M. schrieb: > So, ein kleines Update: > > Offenbar ist ist Wert der TX-Fifo Pointer tatsächlich "irgendwo" im 64k > Adressraum Wie beim mapping im DB ersichtlich werden die Fifos jeweils über den gesamten 16Bit adressraum mehrfach gemappt. Der W5500 kümmert sich dabei um wraparround und das es physikalisch da landet wo es hin soll. > > Ich habe ein paar Vereinfachungen in meiner SW vorgenommen und nun > scheint tatsächlich etwas ausgesendet zu werden. Das das der Browser > nicht als Antwort akzeptiert dürfte wohl nicht am W5500 liegen. Ich will > mal versuchen, mir den Datenstrom anzusehen. > > Ich melde mich wieder... Nutze Wireshark und schaue dir an was auf die Leitung geht/ging Ps w5100 und w5500 sind schon signifikant unterschiedlich also sicherstellen das die richtigen libs überall genutzt werden. Und nein am w5500 als chip liegt es sicher nicht das ist ein sw ding. (defekte, suboptimal ausgeführter Aufbau in HW ausgenommen)
:
Bearbeitet durch User
Ich befürchte, ich bin einem Phantom hinterher gelaufen... Wireshark habe ich mir installiert, aber ich komme auf die Schnelle nicht damit klar, scheint mir aber ein tolles Tooll zu sein, mit dem ich mich nähere auseineder setzenm werden. Ich habe "HyperTerminal" auf TCP Winsock und Port 80 eingestellt, meine SW so geändert, daß sie schon nach einem empfangenen Zeichen den String zurücksendet, und siehe da, es wird korrekt gesendet. Die "Website" wird vom HyperTerminal korrekt empfangen (bzw. deren Sourcecode). Ich denke, das Problem "W5500" ist gelöst (oder hat nie bestanden...). Das Problem liegt offenbar in der gesendeten Antwort zum Browser.. Aber das bekomme ich in den Griff BTW, der Antwortstring: HTTP/1.1 200 OK <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> <HTML><HEAD></HEAD><BODY><br><br><br><br><br> <center> <H3>NUR EIN HELLO WORLD</h3></center></body></html>
Also die Zeiger setzt der W5500 selbst. Um zu wissen ob etwas empfangen wurde müssen die Statusregister ausgelesen werden. Sobald die Buffer gelesen oder geschrieben werden setzt der w5500 diese neu. Ist der Buffer voll wird im TCP/IP Mode kein ACK gesendet. Bis zum Timeout dann wird der Socket geschlossen. Holst du die Daten nicht aus dem Buffer wird der Socket geschlossen. Steht alles im Datenblatt...
Ja, danke, schon klar. Wie erwähnt basiert meine SW auf den "alten" AVR-Routinen für den W5100. Die HW-nahen Routinen natürlich angepasst. Sobald eine Verbidnung "etablished" ist (SnSR == 0x17), wird der Buffer ausgelesen und (zunächst nur) rudimentär ausgewertet. Dann wird der Sendestring rausgeschickt. Das klappt ja auch (laut Hyperterminal). Nur, der Browser akzeptiert es WTF nicht. (Egal, ob FF oder IE). Ich denke doch, ein Empfang der OK-Strings " HTTP/1.0 200 OK\n\r " der Browser doch eigentlich zufrieden sein sollte? Meine Idee war zunächst, daß die DIPR falsch ist.. Ich habe vor dem Sende-CMD die DIPR ausgelesen, sie ist richtig (IP des Client). Die DPORT Nummer ist "exotisch", ich vermute, die wird beim Verbindungsaufbau Browser <-> W5500 "vereinbart" Nun habe ich im I-Net herumsucht und einen simple-Webserver gefunden: https://olduino.wordpress.com/2014/12/11/minimal-http-server-with-w5500/ aber die dortigen Befehle entsprechen schlußendlich meinen... Ich denke, ich bin wieder einmal betriebsblind und habe etwas übersehen.
...Ergänzung: Beim W5100 habe ich die Zeichen einzeln ausgelesen und das beim W5500 auch so übernommen. Dies kostet Zeit..
So, meine Versuche heute waren alle für den Besagten. Ich werde, spbald ich Zeit finde, meine SW 1:1 durch diese https://olduino.wordpress.com/2014/12/11/minimal-http-server-with-w5500/ ersetzen. Angeblich soll diese ja funktionieren.
Hanns-Jürgen M. schrieb: > BTW, der Antwortstring: > HTTP/1.1 200 OK > <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> > <HTML><HEAD></HEAD><BODY><br><br><br><br><br> <center> > <H3>NUR EIN HELLO WORLD</h3></center></body></html> Füge mal nach der ersten Zeile eine Leerzeile ein (Falls die nicht schon da ist und durch die Foren-Formatierung verlorengegangen ist). HTTP erwartet nach der Statusantwort eine (eventuell leere) Liste von Headern, dann ein einzelnes CRLF, und dann erst die Nutzdaten.
Marco H. schrieb: > Beitrag "einfache und performante W5500 LIB" > > Ich kann ja nochmal in den Code schauen... Hi Marco, ich habe Deinen Post erst nach dem Versenden meiones vorigen gelesen. Danke für Dein Angebot, aber vlt. sollte ich erst einmal das erwähnte Beispiel aus dem link nehmen. Denn ich glaube eher nicht, daß es an der W5500 Programmierung liegt, da der Antwortstring ja ausgesendet wird. Wenn es mit dem Beispiel auch nicht funktioniert, dann liegt das Problem wohl ganz woanders. Vor weit über 15 Jahren hatte ich einmal einen Linux-Server zwischen meinem LAN und dem I-Net hängen, der den Datenverkehr aufzeichnete. Leider habe ich den Rechner und insbesondere seine SW nicht mehr...
Heiko G. schrieb: > Hanns-Jürgen M. schrieb: >> BTW, der Antwortstring: >> HTTP/1.1 200 OK >> <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> >> <HTML><HEAD></HEAD><BODY><br><br><br><br><br> <center> >> <H3>NUR EIN HELLO WORLD</h3></center></body></html> > > Füge mal nach der ersten Zeile eine Leerzeile ein (Falls die nicht schon > da ist und durch die Foren-Formatierung verlorengegangen ist). HTTP > erwartet nach der Statusantwort eine (eventuell leere) Liste von > Headern, dann ein einzelnes CRLF, und dann erst die Nutzdaten. Wieder war ich zu langsam... ich checke das jetzt gleich
So, Versuch verlief leider negativ. Morgen baue ich das mal alles um... Im Bild (Screenshot vom Hypetrterminal) siehst Du die resetmeldung des Dues, dann die Anfrage des Servers (ausgelesen aus dem W5500) und dann die Antwort, mit eingefügten Leerzeilen, si im W5500 abgeklegt und gesendet wird. Die TX-RD und WR Pointer zeigen dies. Viele Grüße und vielen Dank für Deine beständige Hilfe! Yogy
So, das "Simple Server" Beispiel hat auch ein paas Fehler, aber, nachdem ich diese beseitigt habe, gibt der Browser das aus, was er soll. Jetzt suche ich mal konkret die Unterschiede..
Hanns-Jürgen M. schrieb: > So, meine Versuche heute waren alle für den Besagten. Überlege mal: Wie sollen wir den Fehler in deinem Quelltext zeigen, ohne ihn sehen zu können? Der Größte Fehler in der Softwareentwicklung ist, davon auszugehen, dass der Fehler nicht im eigenen Code ist.
Stefanus F. schrieb: > Hanns-Jürgen M. schrieb: >> So, meine Versuche heute waren alle für den Besagten. > > Überlege mal: Wie sollen wir den Fehler in deinem Quelltext zeigen, ohne > ihn sehen zu können? > > Der Größte Fehler in der Softwareentwicklung ist, davon auszugehen, dass > der Fehler nicht im eigenen Code ist. Ich hatte schon erwähnt, daß der Fehler in meinem Code liegt. Und so langsam nähere ich mich auch der Ursache an... (siehe mein heutiges Porting von 16h06. Sobald ich das Problem gefunden und gelöst habe, werde ich das hier "melden".
Auf jeden Fall finde ich deinen Versuch gut, das Programm auf möglichst wenig zu reduzieren. Wenn du dann noch Hilfe brauchst, solltest du es uns aber mal zeigen.
Nabend zusammen der W5500 wird von Arduino nativ unterstützt. Man includiert statt ethernet.h ethernet2.h dann geht der w5500 und das ohne Probleme bei mir dann noch zu den Pointer und Buffer beim W5500. 1. müssen die für alle benutzten sockets angelegt werden. Es ist getrennt RX und TX buffer 2. wenn ein socket kein speicher bekommt kann man ihn auch nicht nutzen. 3. TX Buffer uuf Null stellen ... warum ??? Denn das sind Ringbuffer... den Anfang vom Buffer schreibt immer der W5500 um !!! Ich würde die Finger davon lassen. Der Sendevorgang geht so. Den W5500 fragen wieviel im Sendebuffer frei ist. Dann ab dem Start Zeiger mit der freien Länge (oder was man davon braucht) reinschreiben was gesendet werden soll. Das eben mit Umbruch am Ende Ringbuffers. Pointer nachziehen bis wo man reingeschrieben hat. Dann Warten bis der W5500 sendet, oder das Senden antriggern wenns pressiert. Wenn noch was zu senden ist, immer nachfragen was im Buffer frei ist. So habs ich ohne Arduino gemacht .... und es geht Gruß Thomas
Wie gesagt haben alle AVR viel zu wenig Buffer für die Daten. Da braucht man über den zusätzlichen Speicherbedarf für Ethernet gar nicht weiter nachzudenken.
Stefanus F. schrieb: > Auf jeden Fall finde ich deinen Versuch gut, das Programm auf möglichst > wenig zu reduzieren. Wenn du dann noch Hilfe brauchst, solltest du es > uns aber mal zeigen. Mache ich sicher, danke
Thomas K. schrieb: > Nabend zusammen > > der W5500 wird von Arduino nativ unterstützt. > Man includiert statt ethernet.h ethernet2.h > dann geht der w5500 und das ohne Probleme bei mir > > > Gruß Thomas Da liegt wohl ein Mißverständis vor. Ich nutze keine Arduino-SW-Platform, sondern Standard C mit Atmel Studio. Mit Buffern, Pointern etc habe ich auch keine Probleme. Die ursache des Problems liegt irgendwo im Verborgenen, ich bin ihr aber auf der Spur...
Stefanus F. schrieb: > Wie gesagt haben alle AVR viel zu wenig Buffer für die Daten. Da braucht > man über den zusätzlichen Speicherbedarf für Ethernet gar nicht weiter > nachzudenken. Ja, schon klar. Aktuell ist meine Hardware ein SAM3X8e auf einer Arduino-DUE PCB Meine spätere Anwendung wird kein Webserver o.ä. sein, sondern ein proprietäres Binär-Protoll, inkl. Overhead maximal 180 Bytes lang.
Hanns-Jürgen M. schrieb: > Meine spätere Anwendung wird kein Webserver o.ä. sein, sondern ein > proprietäres Binär-Protoll, inkl. Overhead maximal 180 Bytes lang. Ach so. Dann ist Ok.
HEUREKA, Problem gelöst, Fehler gefunden. Nach der Übetragung der Antwort zum Browser (Client) muß offenbar der Socket disconnectiert werden. Der "Simple Server" aus dem Internetlink (s.o.) macht das so, und das habe ich dann übernommen. Soweit ist das aber verstanden habe, wird ein Socket erst nach Ende der Kommunikation, und das ja mehrfaches Hinundher bedeuten, geschlossen. (Bei einer Browseranfrage gibt es halt nur ein Hin und ein Her (Vom Handshaking mal abgesehen) Korrekt? Danke für Eure Hilfe und Eure Geduld...
Nabend... ok reines C Besser so, ich hab es genau so. Ist viel schneller als Arduino ..... Also solange das Webseiten sind, die nur was ausgeben, macht man die immer zu. Damit kann dann der nächste auch schon kommen. Immer das </html> ausgeben. Dann noch kurz warten damit es gesendet ist. Oder den W5500 abfragen wieviel speicher zum Senden zur Verfügung steht, wenn wieder alles frei ist, ist alles gesendet. Dann den Socket zumachen. Bei Binär würde ich es offen lassen. Ist schneller... Wenn es aber rein Binär ist, wie du es sagst, würde ich eine Simples Protokoll drüber hängen, damit ein Sync funktioniert. Dann rennen lassen. Was ich immer benutze (egal USB oder Netzwerk) ist folgendes. Ich Sende immer ein 0xAA als Frame Erkennung. Dann als nächtes Byte die Länge (Wenn es nur die 180 Byte bleiben passt das) als letzten noch eine pseudo CRC sprich ich addiere incl Länge alle Bytes als char (sprich mit überlauf) das sind 3 Byte gesamt mehr. Wenn das mal nicht passt und ich keine Antwort bekomme sende ich als erstes 255 Byte nullen. Damit ist das Flag wieder weg..... Das Flag setze ich beim Sync 0xAA, dass eben erst zurückgesetzt wird wenn alles durch ist. Damit kann 0xAA auch als Data vorkommen. Damit kann man im laufenden Betrieb ein und ausstecken und fällt immer wieder auf die Füsse. Gruß Thomas
Nö das macht der Client... Du musst bloß den Status auslesen und den Socket wieder im richtigen Mode bringen.. Wenn der Socket verbunden ist steht dieser nur dem einem Client zur Verfügung andere Anfragen werden nicht bearbeitet. Es sei denn du machst weitere Sockets auf dem Port auf. Deswegen muss der Code mit N Sockets umgehen können... Bei maximal 8 Clients gleichzeitig ist Schluss...
:
Bearbeitet durch User
Hanns-Jürgen M. schrieb: > HEUREKA...hin und her...Korrekt? It depends. Zunächst mal muss geklärt werden, ob der Browser weiß, wie viele Bytes er zu erwarten hat. Bei HTTP 1.0 teilt der Server dies dem Browser mit dem optionalen Content-Length Header mit. Sobald der Browser alle Bytes empfangen hat, muss er die Verbindung schließen. Ohne diesen Header muss der Server die Verbindung am Ende schließen, damit signalisiert er das Ende der Übertragung. Probleme bekommst du, wenn beim Browser noch nicht alles angekommen ist. Nach dem Schließen der Verbindung kann er keine Empfangsstörung mehr signalisieren, dann bleibt es halt bei einer unvollständigen Datei. Bei HTTP 1.1 gibt es eine weitere Methode, die für Datenmengen unbekannter Größe vorgesehen ist. Nennt sich Chunked-Transfer. Dabei werden die Daten in Blöcken mit bekannter Größe übertragen. Zum Schluss sendet der Server einen Block mit der Größe 0, um das Ende zu kennzeichnen. Bei HTTP 1.1 soll die Verbindung normalerweise offen gehalten werden. Der Client kann über diese eine Verbindung mehrere Anforderungen senden und der Server hat sie in der gleichen Reihenfolge zu beantworten. Der Client entscheidet normalerweise, wann er die Verbindung schließen möchte. Der Server darf sie allerdings auch schließen, wenn er es für notwendig hält (z.B. nach einer Minute Inaktivität). HTTP 1.1 ermöglicht auf Strecken mit hohen Laufzeiten erheblich bessere Performance. Für Mikrocontroller ist das eher uninteressant, aber dieser Chunked Transfer ist eine nette Sache denn er reduziert das Risiko erheblich, den letzten Block der Datei zu verlieren.
Danke für Eure Antworten und Kommentare. @Thomas: Das von mir verwendete Protokoll basiert auf einer (von mir maßgeblich mit entworfenem) industriellen Kommunikationsstruktur (BiCat, 1993). Ich verwende es seit etwa 1995 und läuft ursprünglich über UART Systeme. (z.B. RS 485) Es ist stabil und robust. Es ist eine Single-Master System. Ich habe allerdings aktuelleeinen Fortentwicklung im Test, das mit "echter" CRC arbeitet und weiteren Kontrollmechanismen ausgestattet ist. @Marco, @Stefanus. Wertvolle Hinweise, die mir bislang unbekannt waren, insb. bezüglich HHTP 1.0 und 1.1, Ich werde also noch ein paar Experiemnte machen. Wie erwähnt soll der W5500 (wie auch der W5100 und andere) bei mir mit einem reinen Binaerprotokoll arbeiten. Bislang ist das Netzwerk ein Single-Master System, das mit einem Socket auskommt. Das künftige Protokoll wird aber multimasterfähig sein, so daß ggf. mehrere Sockets bearbeitet werden müssen. ich denke, daß auch "gleichzeitig" Client- und Server Sockets implemenieren werde (zumindest will ich das versuchen), aber das liegt noch in fernerer Zukunft. Auch bislang kann ich auf dem Controller mehrfere Kommunikationswege gleichzeitig und unabhängigvoneinander betreiben (UARTs, USB, LAN, Funk RFM12), solange der Controller das alles, insb. speichermäßig, schafft. @Stefanus Frage, wie sende ich einen Block der Größe "0"? Einfach ein Sendecommand ohne den TX-Buffer mit irgendetwas geladen zu haben?
Hanns-Jürgen M. schrieb: > Wie erwähnt soll der W5500 (wie auch der W5100 und > andere) bei mir mit einem reinen Binaerprotokoll arbeiten. > @Stefanus Frage, wie sende ich einen Block der Größe "0"? Einfach ein > Sendecommand ohne den TX-Buffer mit irgendetwas geladen zu haben? bezieht sich deine Frage auf HTTP oder auf dein selbst erfundene Protokoll? Ich kann Dir dein eigenes Protokoll nicht erklären. Dass Ethernet Pakete (also UDP) mit 0 Bytes Daten beim Empfänger ankommen, darauf würde ich mich nicht verlassen. Das TCP Protokoll ist hingegen Stream-orientiert. Dabei kannst du dich nicht darauf verlassen, dass die Daten in der selben Stückelung beim Empfänger ankommen, wie sie gesendet wurden. TCP stellt aber im Gegensatz zu UDP die richtige Reihenfolge sicher und dass verlorene Pakete automatisch wiederholt werden.
Stefanus F. schrieb: > Hanns-Jürgen M. schrieb: >> Wie erwähnt soll der W5500 (wie auch der W5100 und >> andere) bei mir mit einem reinen Binaerprotokoll arbeiten. > >> @Stefanus Frage, wie sende ich einen Block der Größe "0"? Einfach ein >> Sendecommand ohne den TX-Buffer mit irgendetwas geladen zu haben? > > bezieht sich deine Frage auf HTTP oder auf dein selbst erfundene > Protokoll? Ich kann Dir dein eigenes Protokoll nicht erklären. > > Dass Ethernet Pakete (also UDP) mit 0 Bytes Daten beim Empfänger > ankommen, darauf würde ich mich nicht verlassen. Das TCP Protokoll ist > hingegen Stream-orientiert. Dabei kannst du dich nicht darauf verlassen, > dass die Daten in der selben Stückelung beim Empfänger ankommen, wie sie > gesendet wurden. TCP stellt aber im Gegensatz zu UDP die richtige > Reihenfolge sicher und dass verlorene Pakete automatisch wiederholt > werden. Meine Frage bezieht sich auf das Thema HTTP 1.1, das hattest Du doch erwähnt? Ich habe gerade mal nach HTTP gegooschelt, und habe da in der Wikipedia etwas gefunden, ich werde das jetzt testen.... Solong Yogy
HTTP ist zum Übertragen von Text gedacht. Dein eigenes binäres Protokoll in HTTP zu tunneln erscheint mir nicht sinnvoll. Ich hatte HTTP nur zur Sprache gebracht, weil du es "Webserver" genannt hast und Teile von HTML Dokumenten zitiert hast.
Stefanus F. schrieb: > HTTP ist zum Übertragen von Text gedacht. Echt? Und wie denkst du werden z.B. PNGs übertragen? Cheers, Roger
Stefanus F. schrieb: > HTTP ist zum Übertragen von Text gedacht. Dein eigenes binäres Protokoll > in HTTP zu tunneln erscheint mir nicht sinnvoll. Ich hatte HTTP nur zur > Sprache gebracht, weil du es "Webserver" genannt hast und Teile von HTML > Dokumenten zitiert hast. Das eigene Protokoll wird natürlich NICHT in HTTP verpackt. Ich habe mich da wohl mißverständlich ausgedrückt. Die Spielerei mit HTTP dient mir alleine dazu, Fehler nur auf der Serverseite suchen zu müssen und nicht bei einem Client. Aif jeden Fall danke für die offenbar dringend notwendige HTTP Nachhilfe. Ich habe mich daraufhin auch etwas schlauer gemacht, und meine Antwort aus die Anfrage des Clients ist nun: HTTP/1.1 200 OK Content-Length: 120 Content-Language: de Connection: close Content-Type: text/html <HTML><HEAD></HEAD><BODY><br> <br><br><br><br><center><H1> NUR EIN SCHNELLES HELLO WORLD </h1></center></body></html> Die Länge der Nichtheaders ist 120 byte <HTML>...</HTML> Damit funzt es, in dem ich den Socket Status nach der Übertragung intensiver auswerte (hatte ich aus Unkentnis nicht gemcht). Da schließt nun der Client den Socket oder der Client meldet "CLOSE WAIT". In den beiden Fällen trenne ich den Socket und starte den Server erneut auf "listening" So scheint es zu funzen...
eben das ist was ich meinte. Man muss den Status des w5500 immer wieder abfragen oder man bemüht die ISR.. Anhand des Status muss dann das Event ausgelöst werden. Die Schleife muss alle verwendeten sockets abarbeiten. Auch der Webserver muss Status basiert arbeiten damit er mehre Clients auf verschieden Sockets abarbeiten kann. Genau das wirst du Festellen wenn die Datei größer ist als der buffer. Die Verbindung offen zu lassen ist beim w5500 etwas kontraproduktiv, damit lassen sich genau 8 Clients bedienen, beim 9 Client der connect abgewiesen. Noch ein Problem gibt es mit dem ARP Table das kann nur eine Adresse speichern. Jedes mal wenn ein anderer Client bedient wird löst der W5500 diese per ARP auf.. Abhilfe schafft nur ein eignendes Table und das setzen vor dem senden.
:
Bearbeitet durch User
Angehängte Dateien:
-
webserver.jpg
250 KB
Das sieht dann so aus ... Was ich gerade festgestellt habe das das Project auf einen China Clone läuft und im Code steht das es mit dem orginalen und dem ASP probleme mit dem CD gab, das dort gefixt wurde. Auf einen orginalen initalsiert die SD Karte nun nicht mehr...
Nachdem nun das ursprüngliche Problem gelöst ist, ich etwas über HTTP geöernt habe und auch mein Binärptotokoll nach unwerwarteten Problemchen mit dem Visual-Basic Client (ist eigentlich nicht mein Beritt) will ich etwas weiter "herumspielen" und optimieren bzw. den Code "choppen". Interessant finde ich die Möglichkeit, das "Pingen" bzw. die Pingantwort zu verbieten. Darauzs ergäbe sich doch die Möglichkeit, auf der einen IP-Adresse mherere Server anzuschließen, die sich nur in der Portnummer unterscheiden? Ist das (technuch) möglich und praktikabel? (ich weiß, daß das "unsauber" ist...)
Hanns-Jürgen M. schrieb: > Interessant finde ich die Möglichkeit, das "Pingen" bzw. die > Pingantwort zu verbieten. > Daraus ergäbe sich doch die Möglichkeit, auf der einen > IP-Adresse mherere Server anzuschließen, die sich nur in der Portnummer > unterscheiden? Ja sicher geht das, und es hat mit Ping überhaupt nichts zu tun. Ping benutzt das ICMP Protokoll. Wenn du Port Nummern verwendest, dann bist du beim TCP oder UDP Protokoll. Alle drei Protokolle kannst du voneinander unabhängig nutzen. Du könntest sogar auf TCP Port 80 einen anderen Service betreiben, als gleichzeitig auf UDP Port 80.
Danke für die Antwort. Mein Verzicht auf die Pingantwort hat nichts mit den Ports zu tun, sondern soll ggf. der "Verschleierung" der Anwesenheit dienen. Allerdngs: Fall mehrere Netzteilnehmer mit identischer IP vorhanden sind, würden doch alle auf eine Ping-Afrage hin antworten (wollen), oder?
Jeder Rechner hat innerhalb eines lokalen Netzes eine eindeutige IP Adresse. Auf einem Rechner können aber mehrere Server-Dienste laufen.
Was hat das mit dem Ping zu tun ? Ping ist ein eignender Dienst der von W5500 abgewickelt wird, genau so wie ARP. Ich habe es doch oben erklärt ! Du kannst immer nur einen Client pro Socket abwickelten. Du kannst beim W5500 genau 8 Clients bzw. 8 offenen TCP/IP Verbindungen abwickeln. Als Server machst du eben 1-8 Sockets auf die auf dem Port z.Bsp 80 hören. Ist einer belegt nutzt der W5500 den nächsten, sind alle belegt wird der Connect abgewiesen.
:
Bearbeitet durch User
Ich glaube, mein Ansinnen ist völlig falsch verstanden worden. 1. Die Ping-Funktionalität möchte ich abschalten, um dadurch das "Entdecken" von Nodes zu erschweren. 2. Wenn die Pingfunktionalität abgeschaltet ist, so kam mir die Idee, könnte ich doch mehrere Nodes im Netz mit einer identischen IP-laufen lassen, die aber zur Unterscheidung unterschieldiche Ports benutzen. ANderes gesagt: Kaffeemaschine, Waschmaschine, Kühlschrank haben alle die selbe, identische IP, sie unterscheiden sich nur in der Portnummer..
Ach ja, natürlich wäre das nicht im Sinne des Erfinders, es geht mir auch nur um die Möglichekit.
Hanns-Jürgen M. schrieb: > 2. Wenn die Pingfunktionalität abgeschaltet ist, so kam mir die Idee, > könnte ich doch mehrere Nodes im Netz mit einer identischen IP-laufen > lassen, die aber zur Unterscheidung unterschieldiche Ports benutzen. Wie gesagt, die IP Adresse ist im lokalen Netz eindeutig. Anders funktioniert es nicht. Lies mal wie ARP funktioniert, dann wird Dir das auch klar.
Stefanus F. schrieb: > Hanns-Jürgen M. schrieb: >> 2. Wenn die Pingfunktionalität abgeschaltet ist, so kam mir die Idee, >> könnte ich doch mehrere Nodes im Netz mit einer identischen IP-laufen >> lassen, die aber zur Unterscheidung unterschieldiche Ports benutzen. > > Wie gesagt, die IP Adresse ist im lokalen Netz eindeutig. Anders > funktioniert es nicht. Lies mal wie ARP funktioniert, dann wird Dir das > auch klar. Danke, habe ich gemacht und verstanden.
Na hoffentlich, so wird auch klar das die wirkliche Kommunikation im Layer 2 stattfindet. Punkt zu Punkt per MAC.. Das ARP Table kann nur eine Adresse speichern. Sobald du eine andere IP was versendet muss der W5500 die MAC per ARP auflösen. Das verzögert bei UDP Verbindungen die response stark und deshalb habe ich damals mein eignendes Table aufgebaut und vor dem senden die Register des W5500 gesetzt.
Hallo zusammen, ich wollte keine neuen Thread aufmachen, falls notwendig, bitte Bescheid geben. Nachdem die Kommunikation zwischen Client (PC mit kleiner VB.net Routine) und dem W5500 am Arduino DUE funktioniert, und ich das auch mit einem Arduino MEGA geschaffgt habe, will ich das nun per UDP machen. Bitte keine Diskussion über UDP vs TCP, ich brauche Broadcast. Der Server (W5500 mit Arduino) lauscht nun auf Broadcasts an einen festgekegten Port. Auf dem PC werkelt wieder ein VB.net Progrämmchen... Ich selber habe von VB.net mehr oder weniger keine Ahnung... Das VBnet-Progrämmchen schickt nach Tastendruck eine UDP-Broadcast Nachricht an die Teilnehmer im Subnet. Diese Nachricht wird auch vom Arduino richtig empfangen und decodiert und mit einer UDP Nachricht an den Client (Antwort also kein broadcast) benatwortet. Nur der laufende UDP Receiver im VB-Net empfängt nur die eigene Broadcast-Nachricht, aber nicht die des Servers. Ich habe nun den Server so programmiert, daß er sekündlich einen Nachricht aussendet (An den Client, kein Bradcast). Nur der Client (VBnet empfängt "nichts" Das VB.net UDP-Epnfangsprogamm: (verkürzt)
1 | Dim UdpReceivingClient = New UdpClient(8820) |
2 | UdpReceivingClient.EnableBroadcast = True |
3 | |
4 | '''' hier waere die Senderoutine |
5 | |
6 | Label1.Text = "RECEIVING" |
7 | |
8 | endTime = Now.AddMilliseconds(5000) 'WARTEZEIT AUF ANTWORT MAX |
9 | |
10 | Dim RemoteIpEndPoint As IPEndPoint = New IPEndPoint(IPAddress.Any, 8820) |
11 | 'ALTERNATIV, geht aber auch nicht: Dim RemoteIpEndPoint As IPEndPoint = New IPEndPoint("192.168.1.113", 8820)
|
12 | |
13 | 'Das ist ein Beispiel für die IP-Adresse des Servers und die Portnummer |
14 | |
15 | While Now < endTime |
16 | Application.DoEvents() |
17 | If UdpReceivingClient.Available Then |
18 | endTime = Now |
19 | End If |
20 | End While |
21 | If UdpReceivingClient.Available Then |
22 | |
23 | Dim Anz As Integer |
24 | Anz = CInt(UdpReceivingClient.Available) 'Gibt Anzahl der Bytes zurueck |
25 | |
26 | idata = (UdpReceivingClient.Receive(RemoteIpEndPoint)) |
27 | |
28 | Me.Refresh() |
29 | |
30 | For i = 0 To Anz - 1 |
31 | If idata(i) < 16 Then |
32 | Label1.Text = Label1.Text + " $0" + Hex(idata(i)) |
33 | Else |
34 | Label1.Text = Label1.Text + " $" + Hex(idata(i)) |
35 | End If |
36 | Me.Refresh() |
37 | Next |
38 | |
39 | |
40 | End If |
41 | ..... |
42 | |
43 | UdpReceivingClient.Close() |
Auf der W5500 Seite ist UDP eingestellt, sonst koennte ich ja nicht empfangen. Das Starten des Sendes wird mit der gleichen Routine wie für TCP vorgenommen, das protokoll wird nicht verändert. DIPR wird mit der Server-IP beschrieben. Dort dürfte das proebleme eher nicht liegen, oder? Sehe ich vor lauter Bäumen den Waöd nicht mehr? Danke und viele Grüße Yogy PS: Wie bekomme ich hier die rechtschreibprüfung aktiviert? Anleitung von Mozilla (rechte Maustaste) hilft nicht.. und meine Brille ist noch nicht fertig
Hanns-Jürgen M. schrieb: > PS: Wie bekomme ich hier die rechtschreibprüfung aktiviert? Anleitung > von Mozilla (rechte Maustaste) hilft nicht.. und meine Brille ist noch > nicht fertig Du musst ein Wörterbuch als Firefox Extension installieren. https://support.mozilla.org/de/kb/Rechtschreibpruefung-nutzen
Stefanus F. schrieb: > Hanns-Jürgen M. schrieb: >> PS: Wie bekomme ich hier die rechtschreibprüfung aktiviert? Anleitung >> von Mozilla (rechte Maustaste) hilft nicht.. und meine Brille ist noch >> nicht fertig > > Du musst ein Wörterbuch als Firefox Extension installieren. > https://support.mozilla.org/de/kb/Rechtschreibpruefung-nutzen Ich habe ein Wörterbuch installiert, und diese Supportseite kenne ich, bringt aber nichts, da ich beim Clicken mit der re maustaste in einen mehrzeiligem Eingabefeld im Kontextmenue bei mir nichts bezüglich Rechtschreibung erscheint.
:
Bearbeitet durch User
Ich hab's gerade mit einem frisch installierten Firefox ausprobiert. Die Rechtschreibkontrolle hat direkt nach der Installation des Wörterbuches funktioniert, ohne weitere Einstellungen.
Mag sein, denkbar wäre bei mir z.B. eine "Beeinflussung" durch andere AddOns: NoScript PrintFriendly AdblockPlus Video Downloadhelper Tails Verification Toggle Referrer uMatrix (deaktiviert) Ach ja, Wörterbuch: Deutsch (DE) Language Pack, letzte Aktualisierung 26. Okt 2018, ist auch vorhanden. Aber gut, daß mit der RS-Kontrolle ist nicht wirklich vordringlich.
kurz zur UDP Geschichte: VB ist nicht das Probelem. Zwei VB.net PCs können miteinander über UDP Daten austauschen. Der Gehler liegt im W5500 bzw. in der Ansteuerung, die offenbar falsch ist. Aber ich bin guter Hoffnung...
ich er weniger.. Du musst den W5500 Socket in den UDP Mode bringen... Was man bei UDP noch beachten sollte ist das es keine Flusskontrolle gibt. Abhängig vom SPI Takt und Code schafft er nicht 100Mbit/s Trafic zu verarbeiten. Trotz Buffers, in dem die Pakete landen und du zusehen musst diesen schnell genug auszulesen. Sonst sind die Pakete weg...
Ja, danke, alles soweit klar. Der W5500 kann die UDP-Nachrichten (Broadcast) von VBnet empfangen, offenbar funktioniert das Rücksenden nicht richtig. Ich kann aktuell nach dem Beschreiben nicht die DIPR für den zug. Socket auslesen, bzw. nicht beschreiben. Das ist wohl ein Fehler meinerseits. Aber zum Verständis mal folgende Frage (Die Applikation von WizNet ist da für mich unverständlich) (https://wizwiki.net/wiki/doku.php?id=products:w5500:application:udp_function) Zunächst beschreibe ich zum zugehörigen Sockel die DIPR Adresse, z.B. 192.168.178.255 (255 als Broadcast) und die DPORT Nummer (funzt bei mir auch nicht, what the hell...) Dann baue ich den Nachrichtenbuffer zusammen, bestehend aus Source-IP,Source Port und Anzahl der nachfolgenden folgenden Nachrichtenbytes (insg. also 8 bytes) und dann die Nachricht (bei mir maximal 160 bytes). Diese kopiere ich in den TX-Buffger des Sockets und gebe den Sendebefehl. Es wird auch etwas ausgesendet (LEDs des Hubs blinken), aber es wird nicht empfangen (VB.net). Ich dene, es liegt an der (scheinbar) fehlenden DIPE, aber ich bin auf der Suche,m wo ich da meinen Bug verbaut habe. (Die Selektion und das handshaking wird durch meine Nachrichtenstruktur bearbeitet)
...DIPR/DPORT Problem gelöst, mit einigen weiteren Modifikationen klappt es nun "grob" mit dem erfolgreichen Aussenden der Broadcast-Nachrichten...
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.