Hallo zusammen, ich möchte mit einem MSP430 Mikrocontroller (G2553) Daten über Ethernet versenden. Als Ethernet-Controller kommt der W5500 von Wiznet zum Einsatz. Geplant ist die Kommunikation per UDP. Die SPI-Kommunikation zwischen dem MSP430 und dem W5500 habe ich bereits eingerichtet und erfolgreich getestet. Ich habe mir auch die offizielle ioLibrary_Driver von Wiznet auf GitHub angeschaut – allerdings fällt mir der Einstieg etwas schwer. Besonders die Struktur der Bibliothek und die initiale Einbindung wirken auf den ersten Blick etwas unübersichtlich. Hat jemand hier im Forum bereits erfolgreich die ioLibrary mit dem W5500 in Verbindung mit einem MSP430 verwendet? Ich würde mich sehr über Beispiele, Tipps oder Hinweise zur Implementierung freuen. Danke
Na dann.... Hast du deine SPI Funktionen schon in der Lib registriert, bzw. eigene gebaut? Nein? Machen!
Man kann den W5500 auch ohne lib nutzen. Einfach nach Datenblatt programmieren. So habe ich damit auch ein paar einfache Ethernet Anwendungen gemacht. Wenn du allerdings ein echtes Socket Interface brauchst, würde ich das Rad nicht neu erfinden und versuchen die bereitgestellte library nehmen.
Hi, leider bin ich nicht wirklich weiter gekommen. Finde die wiznet Lib ziemlich verwirrend. (Was wird für UDP bzw TCP benötigt, kann da leider nicht wirklich eine Beschreibung finden. Habe testweise mal die w5500.h, socket.h und wizchip_conf.h mit #include geladen. Doch leider bekomme ich da mit Socket schon gleich Probleme (shift count to large). Im Anhang habe ich meinen Anfang angehängt, @arduinof ist das was du gemeint hast? Danke
Danke, Cyblord – ich bin mir noch nicht sicher, was die bessere Lösung ist. Das generelle Ziel ist es, Sensordaten per LAN an einen Empfänger (Computer oder vielleicht ein WLAN-Modul) zu übertragen. In Zukunft könnte das Projekt (relativ) komplexer werden, z. B. durch den Einsatz von Motoren, um den Sensor in X- und Y-Richtung zu verfahren, oder durch die Ansteuerung zusätzlicher Module. Daher bin ich unsicher, ob es sinnvoll ist, die offizielle Library zu verwenden oder ob es besser wäre, alles selbst zu programmieren – ich habe wenig Ahnung von Ethernet, und die Datenübertragung ist nicht das eigentliche Problem. Deshalb wollte ich es so einfach wie möglich halten. Würdest du UDP für meine Anwendung empfehlen? Hast du vielleicht Beispielcode, an dem ich mich orientieren könnte (Hauptsache der Code ist in C)? Danke!
Uli D. schrieb: > Das generelle Ziel ist es, Sensordaten per LAN an einen Empfänger > (Computer oder vielleicht ein WLAN-Modul) zu übertragen. Das hätte jetzt nicht allgemeiner sein können. Aber wie? Welche Stacks oder Protokolle willst du nutzen? Nur UDP oder läuft da was drauf? > Hast du vielleicht > Beispielcode, an dem ich mich orientieren könnte (Hauptsache der Code > ist in C)? Dein Problem ist schlicht dass beide Ansätze einen gewissen Skillevel erfordern, den du nicht hast. Es erfordert grundlegendes Wissen um Controller, SPI, Ethernet und den W5500 um ihn direkt anzusteuern. Es erfordert Wissen um SPI und allgemein C um fertige Libs einzubinden und zu nutzen. Du kannst aktuell beides nicht. Fang kleiner an.
:
Bearbeitet durch User
Da in den G2553 jetzt nicht ewig viel reinpasst und Code-Banking nicht drinliegt, wuerde ich jetzt eher den Wiz bare metal programmieren. Das ist nicht allzu aufwendig. Dazu kommt, dass in der Wiz-library auch mal "verbotene" potentielle Endlosschleifen drin stecken, heisst, Watchdog-Szenarien, die zuschlagen koennen. Also, als Beispielcode zu sehen. Im Hinblick auf weitere Komplexitaet ist vielleicht der msp430 etwas eng bemessen. Ich mache es hier andersrum, der MSP430 ist der intelligente ADC-Slave und den ganzen Rest macht ein FPGA-SoC (da spare ich mir den Wiznet). Daten streamen macht per UDP schon Sinn, wenn es um Echtzeit-Messdaten gehen, und ab und an mal ein Paket fehlen darf. Bei TCP kann es Haenger geben, Queues volllaufen, Watchdog zuschlagen, usw.
Ansonsten, WENN du doch bereits die SPI Kommunikation hast, dann schau ins Datenblatt und fang an, ein Socket zu erstellen, zu öffnen und was zu schicken. Ich empfehle die Programme Wireshark und PacketSender um den Erfolg zu kontrollieren. Ob MAC und Source IP Adresse korrekt konfiguriert sind, kann man sogar schon mit einem PING vom PC aus testen. Also da kann man schön Step by Step vorgehen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Ansonsten, WENN du doch bereits die SPI Kommunikation hast Hat er nicht. Ich hab mal die grundlegenden Routinen für SPI als Source angehängt. Ist zwar für einen STM32F4, aber man kann erkennen was unbedingt erforderlich ist um mit dem Chip zu sprechen. Ja, die vier Funktionen braucht man unbedingt. Das alles kann man aber auch aus dem Datenblatt entnehmen. Das ist der "Urschleim", wenn man das kann, kann man mit dem Aufbau der höheren Level beginnen.
Hier noch die unbedingt erforderlichen Sourcen für den W5500 die direkt oberhalb des SPI Levels angesiedelt sind. In W5500.h sind jede Menge Makros und Adressen abgelegt. Leicht umgeschrieben und beautyfied aus den Sourcen von Wiznet. Allerdings nicht unbedingt sofort passend für den MSP430. Wenn man das fehlerfrei compilieren kann ist man schon recht weit.
Ich habe jetzt erstmal versucht Daten mit UDP zu senden - ohne Lib mit Register. Leider keine Daten am anderen Ende. Der PC am anderen Ende schein wohl daten zu senden... SPI schein mir soweit die richtigen daten zu senden. Unten habe ich den Ablauf meines Programmes aufgelistet - ist der Ablauf richtig? Habe ich was vergessen? (Im Anhang auch mein aktuelle Code) 1. Software Reset: (0x0000, 0x04, 0x80) 2. Wait 3. Set MAC(00:08:DC:AB:CD:EF): (0x0009, 0x04, 0x00);(0x000A, 0x04, 0x08);(0x000B, 0x04, 0xDC);(0x000C, 0x04, 0xAB);(0x000D, 0x04, 0xCD);(0x000E, 0x04, 0xEF); 4. Set IP(192.168.0.10): (0x000F, 0x04, 192);(0x0010, 0x04, 168);(0x0011, 0x04, 0);(0x0012, 0x04, 10); 5. Set Subnet(255.255.255.0): (0x0005, 0x04, 255);(0x0006, 0x04, 255);(0x0007, 0x04, 255);(0x0008, 0x04, 0); 6. Set Gateway(192.168.0.1): (0x0001, 0x04, 192);(0x0002, 0x04, 168);(0x0003, 0x04, 0);(0x0004, 0x04, 1); 7. Set Socket UDP: (0x4000, 0x0C, 0x02); 8. Set Port 5000: (0x4004, 0x0C, 0x13);(0x4005, 0x0C, 0x88); 9. Open Socket: (0x4001, 0x0C, 0x01); 10. TX Write Pointer: (0x0024, 0x0C);(0x0025, 0x0C); 11. Transfer Data: (0x8000 + i, 0x14, data[i]) 12. Read Socket 0 TX Write Pointer: (0x4000 + 0x20, 0x0C, (len >> 8) & 0xFF); (0x4000 + 0x21, 0x0C, len & 0xFF); 13. Send Command: (W5500_SOCKET0_BASE + 0x01, 0x0C, 0x20); 14. Wait: while (!(w5500_read(0x4000 + 0x02, 0x0C) & 0x10)); 15. Clear: (0x4000 + 0x02, 0x0C, 0x10);
Deine magischen Zahlen zu übersetzen und zu prüfen ist mir zu mühselig. Du solltest schon die von Wiznet gelieferten Defines benutzen (kostet ja nix) damit man eine einigermassen vernünftige Basis für einen Meinungsaustausch hat. Insbesondere deine Prosa-Source ist da nicht weiter hilfreich. Nur soviel: Wenn mal alles aufgesetzt (initialisiert, gestartet) ist sollte man das Statusregister des W5500 dauernd lesen und daraus seine Schlüsse ziehen. Einfach blind Daten senden und auf Reaktion/Empfang warten lässt einen hilflos im Wald stehen. Auf die Schnelle sehe ich dass deine Reset Steuerung wohl so nicht ausreicht. Im Datenblatt wird von 500usec gesprochen. Deine Soft-Delay-Loop ist dafür ungeeignet (ist zu kurz und könnte zudem vom Compiler weg-optimiert werden), da sollte es im Framework des Controllers zumindest etwas Besseres geben. Dass es durchaus hilfreich ist in verschiedenen Leveln zu programmieren scheint dir noch nicht geläufig zu sein. Zumindest in diesem Fall sollte man sich darauf "einigen", SPI, W5500-HAL (Register-Operationen) und Applikation in getrennten Levels zu behandeln. Eigentlich sind die Socket-Operationen nochmal ein eigener Level unterhalb der Applikation. Übrigens: Quelltext wir hier im Forum als *.c Datei gepostet, nicht als *.txt. Deine SPI Read- und Write-Funktionen sind doppelt gemoppelt, es genügt eine Funktion (SPI Transfer) die sowohl ein Byte schreibt und bei der Rückkehr ein gelesenes Byte liefert.
Ja, da hast du definitiv recht... Wobei das Datenblatt und die w5500.h nicht gerade zur Verständlichkeit beitragen – die Registerbezeichnungen wirken nicht durchgängig konsistent. Aber gut, das ist im Moment eher zweitrangig. Ich arbeite aktuell (wieder) an meiner SPI-Kommunikation und bin mir noch nicht sicher, ob das Empfangen von Daten wirklich funktioniert. Gibt es ein Register, das man abfragen kann und das immer einen konstanten Wert zurückliefert (zur Überprüfung der SPI-Kommunikation)? Ich habe versucht, die Versionsnummer (VERSIONR) auszulesen – mit folgender Byte-Sequenz: 0x00, 0x39, 0x01, 0x00, 0x00 (also Adresse 0x0039, Read-Befehl, 1 Byte Daten; die letzten beiden Bytes sind Platzhalter für die Antwort des W5500) Auf dem Bus sehe ich mit dem Logikanalysator folgendes: MOSI: 0x00 | 0x39 | 0x01 | 0x00 | 0x00 MISO: 0x01 | 0x02 | 0x03 | 0x04 | 0x01 Bei anderen Registern, die ich adressiere, bekomme ich ähnliche Rückmeldungen, als würde intern irgendwie hochgezählt werden – die Rückgabewerte 0x01, 0x02, 0x03 usw. wiederholen sich. Hat jemand Erfahrung damit oder einen Tipp für ein Register, das zuverlässig einen festen Wert zurückliefert?
Uli D. schrieb: > Auf dem Bus sehe ich mit dem Logikanalysator folgendes: > MOSI: 0x00 | 0x39 | 0x01 | 0x00 | 0x00 > MISO: 0x01 | 0x02 | 0x03 | 0x04 | 0x01 Da ist ein Byte zuviel. Wie das Datenblatt angibt sind 4 Bytes zu schreiben (Fixed Data Length Mode 01), im letzten Transfer kommt ein zu lesendes Byte daher. Chip Select rahmt die vier Transfers ein. Uli D. schrieb: > die letzten beiden > Bytes sind Platzhalter für die Antwort des W5500) Du kommandierst "1 Byte lesen", redest aber dann von zweien? Bist du sicher dass du weisst was du tust? Im Anhang meine (hoffentlich selbsterklärende) Startup- Testroutine ob der W5500 ansprechbar ist.
Angehängte Dateien:
-
W5500_Read_Byte.png
82 KB
Wastl schrieb: > im letzten Transfer > kommt ein zu lesendes Byte daher. Chip Select rahmt die vier > Transfers ein. Ist alles glasklar im Datenblatt beschrieben. Was ist daran nicht zu verstehen? Ist dir der Mechanismus des SPI Transfers noch nicht klar?
Hi, mein zusätzliches Byte war nur das "hochzählen" darzustellen. Naklar ist das ein Byte zu viel. Dein LoopBack Test habe ich auch und scheint zu funktionieren. Um mit UDP Daten zu senden, was wird benötigt? Ich habe bis jetzt: 1) Reset (mit Wait 1ms) 2) Read Version Nr (sollte 0x04 sein) 3) Gateway: mit 192.168.0.1 (wird gespeichert=> zurücklesen gut) 4) Subnet Mask: 255.255.255.0 (wird gespeichert=> zurücklesen SPI gut) 5) MAC Address: 0x00, 0x08, 0xDC, 0x01, 0x02, 0x03 (wird gespeichert=> zurücklesen SPI gut) 6) IP Address: 192.168.0.2 (wird gespeichert=> zurücklesen SPI gut) 7) UDP Mode (wird gespeichert=> zurücklesen SPI gut) 8) Port 80 (wird gespeichert=> zurücklesen SPI gut) 9) Open Socket (wird gespeichert=> zurücklesen SPI gut) Kann ich diese ganzen Parameter irgendwie mit einem Computer überprüfen? Leider kann ich keine Daten mit einem PC empfangen... Habe ich ein Fortschritt gemacht, wenn ich mit TeraTerm mich verbinden will und eine Meldung Connection refused bekomme?
:
Bearbeitet durch User
Gibt es eine Möglichkeit zu Testen ob ein Socket geöffnet wird? Register Status von Sn_SR schein wohl 0x00 zu sein...
Uli D. schrieb: > Habe ich ein Fortschritt gemacht, wenn ich mit TeraTerm mich verbinden > will und eine Meldung Connection refused bekomme? Dann hast Du immerhin schonmal die IP-Adresse erfolgreich konfiguriert, und der W5500 schickt ein RST, weil auf dem Port nichts lauscht. Ob die MAC-Adresse die richtige ist, kannst Du danach mit arp -a überprüfen. Aber Du solltest nicht einfach irgendeine nehmen, sondern entweder eine, die Dir zugeteilt wurde, oder eine Locally Administered Address. Für letzteres kannst Du z.B. 6 zufällig erzeugte Bytes nehmen, vom ersten muss dann Bit 1 gesetzt und Bit 0 gelöscht werden.
Uli D. schrieb: > Habe ich ein Fortschritt gemacht, wenn ich mit TeraTerm mich verbinden > will und eine Meldung Connection refused bekomme? Mit einem Terminal-Programm wirst du kein UDP-Protokoll erzeugen können. UDP ist nicht Connection-basierend. Datenpakete werden rausgeschrieben ohne gemeldet zu bekommen ob das irgendwo empfangen wurde. Uli D. schrieb: > Gibt es eine Möglichkeit zu Testen ob ein Socket geöffnet wird? > Register Status von Sn_SR schein wohl 0x00 zu sein... Das ist der aussagekräftige Status deines W5500 (siehe Datenblatt). Nochmal: es gibt bei UDP keine Connection wie bei TCP. Wenn der Status ungleich Null ist dann ist der W5500 im Falle von UDP bereit. Dann sollte ein erfolgreicher Ping am den W5500 möglich sein. Dagegen muss seine IP Adresse bzw. MAC- Adresse (noch) nicht in der ARP Liste deines Rechners erscheinen. Wenn du einen Socket öffnest kontrolliere den Fehlerzustand wie es in den Wiznet Sourcen zu sehen ist. Wenn dort ein Fehler gemeldet wird hast du irgendetwas nicht oder fehlerhaft initialisiert. Sind die Read und Write Buffer korrekt gesetzt? Vielleicht musst du doch mal ein paar Zeilen (echten) Sourceode zeigen?
Uli D. schrieb: > Kann ich diese ganzen Parameter irgendwie mit einem Computer überprüfen? Cyblord -. schrieb: > Ich empfehle die Programme Wireshark und PacketSender um den Erfolg zu > kontrollieren.
Hmmm schrieb: > oder eine Locally Administered > Address. Für letzteres kannst Du z.B. 6 zufällig erzeugte Bytes nehmen, > vom ersten muss dann Bit 1 gesetzt und Bit 0 gelöscht werden. Hallo, ich lese aktiv diesen Thread, weil ich demnächst auch mit dem W5500 arbeiten will. Heißt es aus dem zitierten Text, dass der SHAR0 Register (Offset 0009) im Common Register Block ein Format von xxxxxx10 haben muss? Ist das korrekt? Danke!
:
Bearbeitet durch User
Ozvald K. schrieb: > dass der SHAR0 > Register (Offset 0009) im Common Register Block ein Format von xxxxxx10 > haben muss? > Ist das korrekt? Nö, dem W5500 ist es völlig egal welche MAC Adresse du konfigurierst. Zumindest mal abgesehen von der Broadcast Adresse wobei auch das wahrscheinlich nicht geprüft wird.
:
Bearbeitet durch User
Ozvald K. schrieb: > Heißt es aus dem zitierten Text, dass der SHAR0 Register (Offset 0009) > im Common Register Block ein Format von xxxxxx10 haben muss? Wenn Du eine saubere Locally Administered Address verwenden willst, ja.
Bekomme aktuell weder Ping zum W5500 hin, noch funktioniert die UDP-Kommunikation... Ich teste auf dem PC mit Hercules, sehe dort aber keinerlei eingehende Daten. Was bisher auffällt: - Wenn ich testweise 0x1F in das Register Sn_IR schreibe, bleibt dieser Wert auch nach dem Öffnen des Sockets erhalten. - Ohne vorherigen Reset steht Sn_IR zu Beginn auf 0xA8, auch dieser Wert ändert sich nicht, wenn ich versuche, den Socket zu öffnen (via Sn_CR = OPEN). - RX- und TX-Buffer-Größe sind aktuell beide auf 1 Byte (0x01) gesetzt. Auch das bleibt so, wenn ich nach einem Reset keine neuen Werte schreibe. Ich konnte den Fehler bisher leider nicht finden.
Ich habe mir gerade Wireshark angeschaut, auch wenn ich aktuell noch keinen Socket öffnen kann. In Wireshark sehe ich LCFECHO-Requests, die an eine MAC-Adresse gesendet werden. Nachdem ich testweise die MAC-Adresse des W5500 auf FF:FF:FF:FF:FF:FF geändert habe, sehe ich nun in den LCFECHO-Requests die MAC-Adresse FF:FF:FF:C0:A8:00. Ich vermute, dass die geänderten ersten drei Bytes (FF:FF:FF) ein Hinweis darauf sind, dass der W5500 tatsächlich aktiv ist – aber warum wird nur der erste Teil der MAC-Adresse verändert? Ich habe das Schreiben der MAC-Adresse mehrfach überprüft und konnte bisher keinen Fehler finden. Ein Fehler in Wireshark?
Uli D. schrieb: > Ein Fehler in Wireshark? Das ist überaus unwahrscheinlich. Was MAC-Adressen betrifft: Du kannst Du problemlos irgendeine ausdenken, auch wenn Dir keine offizielle zugewiesen wurde. MAC-Adressen müssen nur innerhalb Deines lokalen Netzwerks eineindeutig sein -- wenn Du versehentlich eine erwischt, die ein Computer auf der anderen Straßenseite hat, wirst Du das nie herausfinden. Die sehen sich nicht. Also kannst Du auch einfach de-ad-be-ef-12-34 verwenden. Oder irgendwas. Die Chance, zufälligerweise eine Adresse zu erwischen, die eines Deiner Netzwerkgeräte hat, ist gering; und Du kannst auf Deinem Computer auch mit arp -a nachsehen, was so vorbeigeschneit ist.
Die letzten drei Bytes der MAC-Adresse lassen sich nicht ändern, obwohl ich – wie oben beschrieben – versuche, sie korrekt in das entsprechende Register zu schreiben. Komisch, die letzen Teile der MAC ähneln sehr meiner Gateway Adresse...
:
Bearbeitet durch User
Uli D. schrieb: > Ich konnte den Fehler bisher leider nicht finden. Ich stelle fest: 1) Du bist nicht bereit Dein Programm an den entscheidenden Stellen (Socket öffnen und aktivieren) zu zeigen (Source). 2) du benutzt wohl nach wie vor Magic Numbers anstatt dich auf die Defines von Wiznet zu stützen. 3) du machst deinen eigenen Stiefel anstatt dich an die von Wiznet vorgefertigten Funktionen zum Anlegen und Betreiben eines Sockets zu halten. Dort wird nämlich nicht nur einfach "ein Register beschreiben und gut is". Dieses Verhalten nennt man Beratungsresistenz. Ich bin hier nicht weiter bereit Fehler zu finden und beratschlagend Kommentare abzugeben. Ich habe mein Möglichstes getan um dich auf die richtige Spur zu bringen.
Wastl schrieb: > Uli D. schrieb: >> Ich konnte den Fehler bisher leider nicht finden. > > Ich stelle fest: > > 1) Du bist nicht bereit Dein Programm an den entscheidenden > Stellen (Socket öffnen und aktivieren) zu zeigen (Source). > > 2) du benutzt wohl nach wie vor Magic Numbers anstatt dich > auf die Defines von Wiznet zu stützen. > > 3) du machst deinen eigenen Stiefel anstatt dich an die > von Wiznet vorgefertigten Funktionen zum Anlegen und Betreiben > eines Sockets zu halten. Dort wird nämlich nicht nur einfach > "ein Register beschreiben und gut is". > > Dieses Verhalten nennt man Beratungsresistenz. Ich bin > hier nicht weiter bereit Fehler zu finden und beratschlagend > Kommentare abzugeben. Ich habe mein Möglichstes getan um dich > auf die richtige Spur zu bringen. Ganz herzlichen Dank nochmals für deine bisherige Hilfe. Wie du bereits richtig erkannt hast, fehlt mir leider das nötige Verständnis, um die w5500.h und w5500.c vollständig zu durchdringen. Deshalb ist für mich das Datenblatt die primäre Referenz – einfach weil ich mich daran besser und direkter orientieren kann. Es mag sein, dass mir momentan das Wissen fehlt, um den offiziellen Code wirklich zu verstehen. Aber was soll ich tun? Selbst nach stundenlangem Durchsehen der Dateien blicke ich nicht durch – ich weiß schlicht nicht, wo ich anfangen soll. Im Gegensatz dazu finde ich im Datenblatt zumindest einen groben Einstieg. Wenn ich versuche, die offiziellen w5500.h- und .c-Dateien zu verwenden, stoße ich bereits beim Kompilieren auf Fehler. Meinen eigenen Code habe ich bisher nicht gepostet, weil ich mir eine eigene w5500.h geschrieben habe, in der ich die Registerwerte direkt gemäß dem Datenblatt definiert habe. Grundsätzlich hätte ich kein Problem damit, meinen Code zu zeigen – aber du hattest ja erwähnt, dass du dir eigenen Code lieber nicht anschauen möchtest, was ich natürlich respektiere. Nochmals vielen Dank für deine Unterstützung! Leider fehlt mir im Moment wirklich der Ansatz, wie ich sinnvoll mit den .h- und .c-Dateien umgehen soll, um sie effektiv zu nutzen. Ich habe das Gefühl, den Wald vor lauter Bäumen nicht zu sehen. Falls du mir doch noch einen Hinweis geben könntest, wie ich da besser einsteigen oder weiterkommen kann, wäre ich dir sehr dankbar. Wenn nicht, verstehe ich das natürlich auch.
:
Bearbeitet durch User
Hallo ihr beiden, ich verfolge das hier mit großem Interesse, obwohl ich mich nicht aktiv beteiligen kann, weil ich meine Energie gerade leider in einen Umzug investieren muss. Die Fragen könnten von mir stammen und ich warte schon immer gespannt auf den nächsten Ratschlag. @Wastl: Ich würde mich freuen, wenn du noch weiter Geduld haben und helfen würdest, da deine Hilfe auch mir zugute kommt - und ich glaube, ich bin nicht der einzige, dem es so geht @beide: Es wäre super, wenn ihr auch Code veröffentlichen könntet!
Uli D. schrieb: > Wenn ich versuche, die offiziellen w5500.h- und .c-Dateien zu verwenden, > stoße ich bereits beim Kompilieren auf Fehler. Man könnte ja versuchen, diesen Fehlern auf die Spur zu kommen. Zeig doch mal (in Textform, bitte keine Screenshots) die ersten paar Fehlermeldungen. (mehr als die ersten paar sind in der Regel nicht nötig, die weiteren sind oft nur Folgefehler)
Bin mir nicht sicher, ich habe beim ersten mal die Fehlermeldung shift count to large bekommen. Die bekomme ich jetzt nicht mehr, vielleicht habe ich aber die Sektion wo der Chip Kommentiert wird falsch interpretiert. Jetzt bekomme ich den Fehler, kann "W5500/w5500.h" nicht finden. Bin mir nicht sicher warum aus w5500.h "W5500/w5500.h" wurde. => zu finden in der wizchip_conf.h, Line (Link: https://github.com/Wiznet/ioLibrary_Driver/blob/6a78918eaa24bb502e7149fa2da37890a2ba77af/Ethernet/wizchip_conf.h#L203C4-L203C28)
Uli D. schrieb: > Gibt es eine Möglichkeit zu Testen ob ein Socket geöffnet wird? > Register Status von Sn_SR schein wohl 0x00 zu sein... hier gefunden: https://docs.wiznet.io/Product/iEthernet/W5500/Application/udp "After W5500 accepts the command, the Sn_CR register is automatically cleared to 0x00. Even though Sn_CR is cleared to 0x00, the command is still being processed. To check whether the command is completed or not, please check the Sn_IR or Sn_SR."
Ozvald K. schrieb: > Uli D. schrieb: >> Gibt es eine Möglichkeit zu Testen ob ein Socket geöffnet wird? >> Register Status von Sn_SR schein wohl 0x00 zu sein... > > hier gefunden: > > https://docs.wiznet.io/Product/iEthernet/W5500/Application/udp > > "After W5500 accepts the command, the Sn_CR register is automatically > cleared to 0x00. Even though Sn_CR is cleared to 0x00, the command is > still being processed. To check whether the command is completed or not, > please check the Sn_IR or Sn_SR." Ja, das hab ich auch gelesen. Nur bekomme ich im Sn_SR keine Rückmeldung, auch nach langem Warten >10Min.
Ich kann wärmstens empfehlen, mit irgendeinem LLM als Peer zu programmieren. Nimm zum Beispiel ChatGPT. Auch wenn es nicht unbedingt ein komplett lauffähiges Programm ausspuckt, so bringt es dich Schritt für Schritt weiter und hilft dir aus der ein oder anderen Sackgasse. Außerdem kannst du das Teil sicherlich zum Datenblatt des Wiznet Chips befragen und die Lib kennt es wahrscheinlich auch noch.
H >Ich kann wärmstens empfehlen, mit irgendeinem LLM als Peer zu >programmieren. Nimm zum Beispiel ChatGPT Zu blöd Wiznet zu Programmieren (Chatcpt)? Den WS5200 habe ich schon vor Jahren erfolgreich unter Assembler zur Komm- unikation eingesetz. Wer das unter C/C++ hinbekommt soll sich sein Lehrgeld zurück geben lassen.
Uli D. schrieb: > Bin mir nicht sicher, ich habe beim ersten mal die Fehlermeldung shift > count to large bekommen. Bitte, nicht "stille Post" spielen, sondern die vollständige Fehlermeldung des Compilers (als Text! Kein Screenshot!) posten. Da steht die Zeilennummer drin, in der der Compiler den Fehler ankreidet. Uli D. schrieb: > Jetzt bekomme ich den Fehler, kann "W5500/w5500.h" nicht finden. Bin mir > nicht sicher warum aus w5500.h "W5500/w5500.h" wurde. Weil das die vorgegebene Verzeichnisstruktur ist. Sieh Dir doch einfach mal den Verzeichnisbaum auf der github-Seite an: Das Verzeichnis W5500 ist eine Verzeichnisebene unterhalb des Ortes, an dem wizchip_conf.h zu finden ist. Es ist ratsam, den kompletten Sourcebaum herunterzuladen und so zu lassen, wie er ist (also keine Dateien umsortieren, Verzeichnisse umbenennen etc.).
Hallo Uli D., ich habe den W5100S am Raspi Pico Pi mit den WIZNET-Bibliotheken ohne Probleme zu Laufen bekommen. Im SW-Paket gibt es VZ "examples". Dort sollte man starten. MQTT lief auf Anhieb. (publish) Wenn du alles per Registerzugriff zum Laufen bekommen willst, wirds schwierig. Im örtlichen SM-Club wärst du da besser aufgehoben. :-) Runout
Thomas T. schrieb: > Im örtlichen SM-Club wärst du da besser aufgehoben. Erschwerend kommt hinzu dass "das Projekt" extrem geheim ist, weder Entwicklungsumgebung noch (auch nur eine Zeile) relevanter Sourcecode darf veröffentlicht werden. Allgemeiner Sourcecode wird zur Tarnung auch nicht als *.c Datei veröffentlicht sondern als *.txt. Damit hat es die Spionage extrem schwer etwas Sinnvolles anzufangen. Gefährlich (besser gesagt verboten) für "das geheime Projekt" ist es auch, die von mir zurechtgeschneiderten Sources zu verwenden. Es könnte dadurch ja ein Virus eingeschleust werden der nicht nur das Projekt scheitern lässt sondern auch den Entwicklungsrechner weitergehend infiziert und lahmlegt.
Erstmal ganz herzlichen Dank für die rege Beteiligung, mir bei meinem Problem zu helfen, auch durch meine eigene Unfähigkeit. >>Uli D. schrieb: >> Bin mir nicht sicher, ich habe beim ersten Mal die Fehlermeldung shift >> count too large bekommen. >Bitte, nicht "stille Post" spielen, sondern die vollständige >Fehlermeldung des Compilers (als Text! Kein Screenshot!) posten. >Da steht die Zeilennummer drin, in der der Compiler den Fehler >ankreidet. Danke, ich habe diese Fehlermeldung vor ein paar Tagen bekommen, mich damit nicht mehr weiter beschäftigt. Gestern habe ich nochmal ein neues Projekt erstellt und da habe ich diesen Fehler nicht bekommen. Denke, der Grund war, weil ich die Zeile für das Spezifizieren der w5500.h nicht richtig gemacht habe. Jetzt bekomme ich mit der Wiznet Library diesen Fehler nicht mehr. Wastl schrieb: >Erschwerend kommt hinzu, dass "das Projekt" extrem geheim ist, >weder Entwicklungsumgebung noch (auch nur eine Zeile) relevanter >Sourcecode darf veröffentlicht werden. Allgemeiner Sourcecode >wird zur Tarnung auch nicht als *.c-Datei veröffentlicht, >sondern als *.txt. Damit hat es die Spionage extrem schwer, >etwas Sinnvolles anzufangen. >Gefährlich (besser gesagt verboten) für "das geheime Projekt" >ist es auch, die von mir zurechtgeschneiderten Sources zu >verwenden. Es könnte dadurch ja ein Virus eingeschleust werden, >der nicht nur das Projekt scheitern lässt, sondern auch den >Entwicklungsrechner weitergehend infiziert und lahmlegt. Anbei habe ich meinen Versuch, die Register zu beschreiben, angehängt. Bitte entschuldige, wenn ich wichtige Details zu meinem Versuch, den W5500 in UDP zum Laufen zu bekommen, ausgelassen habe. Als Mikrocontroller benutze ich einen MSP430(G2553) und als Entwicklungsumgebung IAR Embedded Workbench (Version 6.40.1). Der Grund, meinen Probecode als Txt anzuhängen, war, dass dies einfach zu lesen ist. Ich dachte, eine Umbenennung ist nicht schwierig, sorry für die Umstände. Bezüglich deiner Anmerkung, die von dir bereitgestellten Sources zu verwenden (danke nochmals dafür) – hier habe ich wirklich Probleme, den Wald vor lauter Bäumen nicht zu sehen. Thomas T. schrieb: > Im örtlichen SM-Club wärst du da besser aufgehoben. Dies würde ich gerne vermeiden, nur kann ich nur schwerlich den Code der Sources verstehen... ich denke es ist wichtig: 1) Wie kann ich eine richtige SPI-Funktion schreiben für die Libs? Wo fange ich an? Wie erkenne ich die benötigten Funktionen? 2) Wie kann ich die bereitgestellten Funktionen benutzen, um eine "richtige" Verbindung/Socket/Konfiguration zu erstellen? Ich habe deine w5500.h und w5500.c eingebunden, das ist aber auch schon alles. Deine w5500.h wird mit Warning[Pa050] non-native end of line detected (this diagnostic is only issued once) angemerkt – in der ersten Zeile mit: //W5500.h. Ansonsten scheint kein Error zu kommen und das Linking funktioniert... Ich bin mir unsicher, wie ich hier dann eine richtige Funktion für das Lesen und Schreiben bereitstelle. Weiter ergibt sich mir daraus nicht, wie ich dann die Kommunikation via UDP zum Laufen bekomme... Sorry für die Umstände, für Hilfe die offiziellen Sources zu verstehen bin ich wirklich dankbar!
Uli D. schrieb: > Anbei habe ich meinen Versuch, die Register zu beschreiben, angehängt. Jetzt wo ich weiss mit welcher IDE du arbeitest hätte ich ja noch Lust und Laue verspürt den grundelegenden Ansatz zu deinem Programm zu legen. Aber diese IAR-Kack-Umgebung verlangt auch noch eine kommerzielle e-mail-Adresse zur Registrierung (Download). Daher ist dieser Weg auch versperrt, Kopfstände zum Aufbau einer funktionierenden IDE werde ich nicht machen.
Wastl schrieb: > Uli D. schrieb: >> Anbei habe ich meinen Versuch, die Register zu beschreiben, angehängt. > > Jetzt wo ich weiss mit welcher IDE du arbeitest hätte ich ja > noch Lust und Laue verspürt den grundelegenden Ansatz zu deinem > Programm zu legen. > > Aber diese IAR-Kack-Umgebung verlangt auch noch eine kommerzielle > e-mail-Adresse zur Registrierung (Download). Daher ist dieser > Weg auch versperrt, Kopfstände zum Aufbau einer funktionierenden > IDE werde ich nicht machen. Hallo Wastl, ich bin dir wirklich dankbar für deine Unterstützung! Ich nutze keine aktuelle Version der IAR-IDE – die wurde damals (vor langer Zeit) von TI für den MSP430 bereitgestellt. Der aktuelle Download ist auch ohne kommerzielle E-Mail-Adresse möglich, zumindest bei mir gerade eben. Ich bin mir ehrlich gesagt nicht sicher, wie entscheidend die IDE überhaupt ist – solange ich den Umgang mit der w5500.h/.c verstehe, sollte ich damit auch weiterkommen. Aber ganz ehrlich: Würdest du dir das wirklich antun, diese IAR-Umgebung herunterzuladen und zu installieren?
Uli D. schrieb: > Würdest du dir das wirklich antun, diese IAR-Umgebung > herunterzuladen und zu installieren? Ja wenn du mir zeigst wie - ohne kommerzielle e-mail Adresse.
Uli D. schrieb: > Ich bin mir ehrlich gesagt nicht sicher, wie entscheidend die IDE > überhaupt ist – solange ich den Umgang mit der w5500.h/.c verstehe, > sollte ich damit auch weiterkommen. Wie wär's denn mit einem weiter verbreiteten Controller, einem STM32 zum Beispiel? Da kommt man durch Hilfe von Anderen sofort auf einen grünen Zweig. Eval Boards gibt es für 25 Euro, und der Debugger ist auch schon dabei. Alles andere ist kostenlos von STM herunterladbar. Die Performance und Speichergrösse sind dem MSP430 weit überlegen.
Wastl schrieb: > Uli D. schrieb: >> Würdest du dir das wirklich antun, diese IAR-Umgebung >> herunterzuladen und zu installieren? > > Ja wenn du mir zeigst wie - ohne kommerzielle e-mail Adresse. Interessant, ich hab es gerade mit vier EMails probiert. Die letzte ist rausgefolgen. Die Emails mit tuta.io als auch proton.me scheinen zu funktionieren. Habe dir eine PM geschickt.
:
Bearbeitet durch User
OK, es tut sich was ..... Nicht sehr motivierend, so eine temporäre IAR Lizenz .... Im Anhang - damit man sieht dass sich etwas tut - die solide Grundlage zum Arbeiten mit dem W5500. Prüfe ob du damit arbeiten kannst, ich habe keine Hardware um das auszutesten.
Hier mal "schnell was aus dem Boden gestampft". Du wirst noch einige Kleinigkeiten an Initialisierung hinzufügen müssen. Schaue es dir gut an und verstehe was da gemacht wird. Das Projekt lässt sich fehlerfrei compilieren, Ergänzungen sind erforderlich! Insbesondere deine Funktion für die Testausgabe (UART_Putstring) und eine vernünftige delay_ms() Funktion. Habe das auf die Schnelle nicht gefunden. Zumindest müsstest du in der Hauptschleife in main.c jetzt bald einen W5500 mit seiner IP-Adresse anpingen können.
Wastl, ganz herzlichen Dank. Leider hatte ich noch keine Zeit, mir das Projekt im Detail anzuschauen – trotzdem bin ich wirklich beeindruckt, was du in so kurzer Zeit geschafft hast. Auch der Aufbau des Codes ist wirklich super – hab noch einiges zu lernen... Danke!!!
Wenn man sich noch etwas länger mit den Controller beschäftigt fällt auf dass der verfügbare Speicher mickrig klein ist. Du wirst also mit dem von mir spendierten Code keinen Lauf auf dem MSP430G2553 zustande bringen, es seit denn du speckst an irgendwelchen Stellen noch ab damit genug nutzbares RAM zur Verfügung steht. Dürfte schwierig werden. Die IDE jedenfalls compiliert alles und der Linker gibt gar keine Fehlermeldung aus dass ein Speicher überläuft. Erst die Project Map gibt darüber Auskunft dass die 512 Bytes an RAM mehr als aufgebraucht sind.
Die Erkenntnisse lassen für mich nur zwei Schlussfolgerungen zu. Entweder "Projekt" Aufgeben, oder mit einem anderen, fähigen Controller weitermachen. Bei dieser Gelegenheit zitiere ich mich mal wieder selbst: Wastl schrieb: > Wie wär's denn mit einem weiter verbreiteten Controller, einem > STM32 zum Beispiel? Da kommt man durch Hilfe von Anderen sofort > auf einen grünen Zweig. Eval Boards gibt es für 25 Euro, und der > Debugger ist auch schon dabei. Alles andere ist kostenlos von > STM herunterladbar. Die Performance und Speichergrösse sind dem > MSP430 weit überlegen. Selbst mit einem Arduino (Uno, Mega2560, ....) kommt man wesentlich weiter als mit der MSP430-Krücke (sorry) von 512 Bytes an RAM. Fast alle Arduinos kann man auch ohne Arduino-IDE programmieren (das ist dann AVR Studio v4.18 oder Atmel Studio 7.x). Nachdem der Preisvorteil extrem gering ist nimmt "man" heutzutage einen STM32 Controller, vorzugsweise einen Nucleo mit F4 Chip bei dem man sich bei Flash- und RAM-Grösse keine Sorgen mehr machen braucht. Auch der Debugger ist gleich mitgeliefert, alles ohne Sorgen.
Uli D. schrieb: > ich bin dir wirklich dankbar für deine Unterstützung! Ich nutze keine > aktuelle Version der IAR-IDE – die wurde damals (vor langer Zeit) von TI > für den MSP430 bereitgestellt. Der aktuelle Download ist auch ohne > kommerzielle E-Mail-Adresse möglich, zumindest bei mir gerade eben. Zur Info: Das TI Code Composer Studio ist seit mindestens Version 5 kostenlos downloadbar und enthält sowohl den TI Compiler als auch den MSPgcc, und läuft unter Windows, Linux und MacOS. https://www.ti.com/tool/CCSTUDIO fchk
Frank K. schrieb: > Zur Info: Das TI Code Composer Studio ist seit mindestens Version 5 > kostenlos downloadbar und enthält sowohl den TI Compiler als auch den > MSPgcc, und läuft unter Windows, Linux und MacOS. Danke, aber das macht den verfügbaren Speicher des MSP430G2553 auch nicht grösser .... ;-)
Wastl schrieb: > Frank K. schrieb: >> Zur Info: Das TI Code Composer Studio ist seit mindestens Version 5 >> kostenlos downloadbar und enthält sowohl den TI Compiler als auch den >> MSPgcc, und läuft unter Windows, Linux und MacOS. > > Danke, aber das macht den verfügbaren Speicher des MSP430G2553 > auch nicht grösser .... ;-) Natürlich. Und damit ungeeignet für die Aufgabe. fchk
Wastl schrieb: > Hier mal "schnell was aus dem Boden gestampft". Ich sehe schon, nachdem die Begeisterung des TO, hier Beiträge zu verfassen, doch deutlich nachgelassen hat .... scheint die Freude am Programmieren gar nicht mehr so gross wie am Anfang. Suggeriert doch das Datenblatt dass man mit einem "Dreizeiler" (paar Register schreiben) schnell zu einem tollen Netzwerk- Erlebnis kommen kann. Jetzt, angesichts des Projektes das ich gepostet habe, sind wir auf dem Boden der Tatsachen angelangt. Die Luft ist raus.
Danke dir für das Projekt! Ich hatte noch nicht viel Zeit, mir den Code nochmal anzuschauen. Die fehlenden Funktionen wurden ergänzt (z. B. delay_ms()). Trotzdem bekomme ich genau das gleiche Problem wie mit meinem eigenen Code – das Socket wird nicht geöffnet… Ich muss mir das in den nächsten Tagen nochmal genauer ansehen.
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.