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?
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.