In LabView UDP Pakete vom FPGA auslesen

[Waldemar M. (waldi3141)]

Hi Zusammen,

Das ARTY FPGA dev Board habe ich mit dem Ethernet Code von Hamsterworks 
'programmiert' : 
http://hamsterworks.co.nz/mediawiki/index.php/ArtyEthernet

Den Code habe ich soweit angepasst, dass Daten von einem Sensor über 
Ethernet an den PC gesendet werden.
Über Wireshark habe ich auch keine Probleme die UDP Pakete mit den 
Sensordaten zu empfangen, jedoch über LabView bekomme ich keine Daten.

Zu UDP LabView gibt es ja viele Beispiel VIs, habe einige getestet und 
auch mein eigenes aufgebaut, aber es kommt nichts an.

Es hat wohl irgendetwas mit DHCP? zu tun, davon verstehe  ich aber recht 
wenig. Habe sämtliche Foren zu diesem Problem durchsucht und auch viele 
Problem"lösungen" angewandt, aber half alles nichts.

Im VHDL-Code des Arty kann ich zB. den Port, die MAC und IP für source 
und destination einstellen. Kann diese dann auch in Wireshark sehen. Den 
Port habe ich natürlich angepasst, wird auf 8012 geschickt.

Hier ist der Code zum ArtyEthernet: 
https://github.com/hamsternz/ArtyEtherentTX

Vielleicht hilft das: Ich konnte das Board auch nicht anpingen über cmd. 
Es ist mit einem LAN kabel am PC angeschlossen.

[Duke Scarring (Gast)]

Kannst Du einen Screenshot vom Wireshark zeigen?

[Waldemar M. (waldi3141)]

klar, hier bitte

[Strubi (Gast)]

Moin,

wenn der Ping nicht ankommt: vielleicht kann dein Stack kein ICMP?
An DHCP sollte es nicht liegen (du hast ja offenbar ne statische IP 
vorgesehen), aber ARP sollte dein Stack schon unterstützen. Gibt hier 
einige Threads zu.
Wichtig ist auch, dass die Pakete regelmässig "reinknattern", sonst 
schmeisst der hostseitige Stack einiges weg, dabei sollte aber 
wenigstens ab und an eins ankommen, das wird's also kaum sein.
Jetz ist mir aber grade aufgefallen: Deine deadbeef-MAC ist eine 
Ethernet-Gruppenadresse! Nimm mal eine andere (erstes Byte mal auf 0x00 
setzen).

[Waldemar M. (waldi3141)]

Danke für die Antwort :)

Habe jetzt mal die MAC vom Board geändert, aber LV sagt nein ^^

[Markus F. (mfro)]

Hat dein PC noch ein zweites Bein ins Netz oder wie ist das Ding 
angeschlossen? Zweite Ethernet-Karte?

[Waldemar M. (waldi3141)]

Ne, ich muss immer umstöpseln wenn ich Daten vom Board haben will
WLAN ist deaktiviert.

[Daniel B. (dbuergin)]

Irgendwie erschliesst sich mir Dein Setup nicht ganz. Du hast dieses
"Arty FPGA" Board mit einem Ethernet Kabel in Deinem Netzwerk ?
Das Board hat eine fixe IP-Adresse, die in Dein Netzwerk passt ?
Das Board sendet auf welchem UDP Port ? 8011 und 8012 sehe ich im Dump.

Wenn Du die Daten auf dem PC im Whireshark siehst, ist das schon mal 
gut.
Was Du jetzt brauchst ist ein UDP Receiverscript/Programm, welches auf 
dem
entsprechenden UDP-Port lauscht. Ob Labview das kann weiss ich nicht.

Ich sende so meine Wetterdaten von den Sensoren über mein Heimnetzwerk
an ein Display und an zwei PC's.

G D

[Waldemar M. (waldi3141)]

Der Aufbau ist ganz einfach , Artyboard---Ethernet Kabel---PC , mehr 
nicht.
Die fixe IP-Adresse habe ich ganz einfach im Code des FPGAs frei 
eingetragen, kann aber geändert werden. Das Board sendet auf Port 8012.

Ja ... LabView , wenn man da iwie lauschen könnte .. ;( . Irgendwas 
passt dem Nicht ... ich habe auch das "UDP Send and Receive" in LabView 
getestet(unabhängig vom Board),das läuft.

Hatte den Port auch schon mal geändert, falls der eine besetzt sein 
sollte .. aber nix.

[Mimin I. (kahlenberg)]

Waldemar M. schrieb:
> klar, hier bitte

Im Wireshark-Bild steht de:ad:be:ef:01:23 (DEAD BEEF) als Soruce MAC 
Adresse. Das ist nicht gut. Wahrscheinlich wurde die MAC Addrese im FPGA 
flasch eingestellt?

[Markus F. (mfro)]

Versuch' mal (in einem cmd-Fenster):

arp -s 192.168.100.83 00-ad-be-ef-01-00

und dann noch mal probieren. Vielleicht vorher ein

arp -a

und gucken, ob die MAC-Adresse vielleicht schon im ARP-Stack angekommen 
ist.

[Waldemar M. (waldi3141)]

Board per Ethernet angeschlossen -> leider nicht im ARP angekommen,

danke für die Antworten :) bringt mich auf neue Ideen ~

@mimin icer, danke bereits geändert

[Weltbester FPGA-Pongo (Gast)]

Waldemar M. schrieb:
> jedoch über LabView bekomme ich keine Daten.

Könnte Labview gfs einfach zu langsam sein, es anzunehmen?

[Markus F. (mfro)]

Waldemar M. schrieb:
> danke für die Antworten :) bringt mich auf neue Ideen ~

keine Ahnung, was Windows macht, wenn sein Gateway plötzlich nicht mehr 
da ist. Wenn Du irgendwas anderes per Crosskabel ansteckst - geht das?

[Waldemar M. (waldi3141)]

ja das geht,

Ich glaube meine Ethernet Implementierung von Hamsterworks unterstützt 
Protokolle wie ARP, IP, ICMP,  DHCP gar nicht... schickt nur stumpf UDP

Muss wohl nach einem besseren IP core suchen :S

[Strubi (Gast)]

Waldemar M. schrieb:
> ja das geht,
>
> Ich glaube meine Ethernet Implementierung von Hamsterworks unterstützt
> Protokolle wie ARP, IP, ICMP,  DHCP gar nicht... schickt nur stumpf UDP
>
> Muss wohl nach einem besseren IP core suchen :S

Hab mal kurz in den Link geschaut, in der Tat ist das eine "nackte" 
UDP-Engine. Für ARP/ICMP würde ich zu einer SW-Implementation raten, 
aber damit machst du natürlich das Soft-CPU-Fass auf und verlierst je 
nach Architektur Performance (vllt weniger relevant bei deiner 
Anwendung).
Du könntest aber auch ARP als simple state machine dazustricken. Musst 
nur ein paar Stolperfallen beachten und bösartige ARP-Requests 
maskieren.
Mit den ARP-Manipulationstricks von mfro oben sollten deine Pakete aber 
ansich auch so in deinem Labview-UDP-Server ankommen. Merkwürdig...

[Duke Scarring (Gast)]

Strubi schrieb:
> Für ARP/ICMP würde ich zu einer SW-Implementation raten
Ich prinzipiell auch.
Möglicherweise lässt sich das hamster-Ding aber auch einfach in Hardware 
um ARP-reply und Ping(ICMP)-reply erweitern.
WIMRE schickt man da die empfangenen Pakte leicht modifiziert zurück.

Duke

[Waldemar M. (waldi3141)]

Ja bin jetzt dabei den Microblaze Soft-processor zu verwenden ~

Ja.. dazustricken haha... ich habe vor 2 Wochen mit VHDL angefangen ^^
Aber so ein LAN Interface ohne Soft-processor wäre schon ne feine 
Sache...

[Waldemar M. (waldi3141)]

Nach langem hin und her Hab ichs doch hinbekommen, In LabView Daten zu 
empfangen.
Habe den gleichen Code ARYT EthernetTX von Hamsterworks genommen und den 
Ethernet-Frame nicht gekürtzt, darin lag mein Fehler, dass ich den zu 
klein gemacht habe und dann der Trailer/FCS abgeschnitten wurde??

[Duke Scarring (Gast)]

Vielleicht bist Du auch unter die minimale Ethernetframegröße von 64 
Bytes gerutscht. Dann wirft der Netzwerkstack das Paket auch weg.

Duke