Forum: PC-Programmierung Messwerte per UDP vom µc => PC


von Sunday (Gast)


Angehängte Dateien:

Lesenswert?

Hallo

im Rahmen eines studentischen Projekts wollen wir Messwerte von einem 
Mikrocontroller an einen PC schicken. Die Anbindung erfolgt über 
entsprechende Netzwerkcontroller und ein örtliches Netzwerk, aktuell 
aber aus Entwicklungsgründen mit Crosslinkkabel direkt am Laptop.

Wir haben uns für einen Versand über UDP entschieden, da weder wichtige, 
noch viele Daten verschickt werden (pro Gerät ca 200Bytes alle 3s), 
später aber von vielen Teilnehmern.

Um die Kommunikation zu überwachen setzen wir Wireshark ein.

Die Programmierung von der PC Software die später die Auswertung 
übernehmen soll erfolgt in C++.

Wir sind in der Lage, UDP Frames vom µC im Netzwerk zu verschicken, 
diese können wir wunderbar in Wireshark betrachten. Die Frames entstehen 
nicht automatisch sondern sind im Moment noch von Hand eingegeben, 
Byteweise. Das gibt uns den besten Zugriff auf den Frame.

Nun haben wir ein Programm am PC laufen, welches alle 500ms zufällige 
Datenpakete via UDP übers Netzwerk schickt. Verbinden wir zwei PCs 
miteinander, so funktioniert diese Kommunikation einwandfrei.

Tauschen wir nun einen der PCs (den Sender) mit unserem µC, kopieren den 
UDP Frame 1 zu 1 in den µC und lassen diesen Senden, sehen wir zwar in 
Wireshark den Frame, 100% identisch zu dem vom PC geschickten, aber die 
Software registriert diesen nicht mehr.

Wir haben bereits mehrere Varianten ausprobiert: C++(VS2010), 
C++(QT4.7), C#, VB2010, Java(Processing) jeweils bezogen auf die PC 
Software die bisher ganz einfach nur emfpangene Pakete in einer Textbox 
ausgibt.

Kommunikation von PC zu PC geht immer, aber von µC zu PC nicht.

Da wir nun ratlos sind, hier die Frage ob sich eventuell jemand mit 
dieser Thematik auskennt und ebenfalls vor einem solchen Problem stand. 
Wir verstehen nicht so ganz, weshalb 2 identische Pakete einmal 
verarbeitet werden, und einmal nicht.

Im Bild sichtbar der Frameaufbau. In diesem Falle als Broadcast, ein 
Beispiel von QT arbeitete mit Broadcasts.

Gruß

von willibald (Gast)


Lesenswert?

Zeig doch mal den Sourcecode der empfangenden PC-Software. Alle Stellen, 
die irgendwas mit UDP machen.

von Udp (Gast)


Lesenswert?

Setzt mal die UDP Checksum auf 0.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Der o.a. Ethernet-Frame beinhaltet eine MAC-Adresse von MSI. Ich nehme 
an, dass diese (ursprünglich) von dem betreffenden PC stammt.

Wurde die MAC-Adresse nicht verändert, sondern 1:1 übernommen, kann der 
PC entsprechende Ethernet-Pakete verwerfen, da er annehmen muss, dass er 
seine eigenen Pakete auf Grund irgendwelcher Netzwerkschleifen empfangen 
hätte.

Es spricht in der Tat wenig dagegen, sich für einen eigenen Testaufbau 
MAC-Adressen auszudenken statt gleich einen Block zu kaufen. Notfalls 
kann man ja auch die Adresse einer alten, nicht mehr verwendeten 
Ethernetkarte wiederverwenden.

Man sollte bei frei definierten Adresse jedoch unbedingt darauf achten, 
dass einige Bits im höchsten Oktett korrekt gesetzt sind, um nicht 
irgendwelche Sonderadressen zu verwenden, z.B. dedizierte 
Multicast-Adressen.

von Sunday (Gast)


Lesenswert?

Hallo,

Was den Quellcode angeht, dieser ist aktuell ein Beispiel von QT4.7 in 
C++, verwendet QT eigene Bibliotheken etc (Broadcast Receiver 
http://doc.qt.nokia.com/latest/network-broadcastreceiver.html).

Die MAC Adresse ist von MSI, von dem Laptop der vorher der Sender war. 
Um den Frame 1 zu 1 zu kopieren haben wir diese einfach übernommen. 
Natürlich befindet sich der Laptop mit dieser Adresse nicht mehr im 
Netz, wir tauschen ihn gegen den µC aus. Darum sollte das kein Problem 
darstellen.

IP und MAC stimmen also bei beiden Geräten überein, und da UDP 
verbindungslos arbeitet sehen die Pakete für den empfangenden PC 
identisch aus.

Die Checksumme ist vom Originalframe übernommen, wie auch der ganze Rest 
dieses Frames. Es geht ja darum, den 100% selben Frame von zwei Quellen 
zu senden. Von einer wird er erkannt, von der anderen nicht, was auch 
unser Problem darstellt. In Wireshark sind beide ohne Unterschied 
erkennbar.

von Frank K. (fchk)


Lesenswert?

Denkt daran, dass Ethernet-Pakete eine Mindestlänge von 64 Bytes haben 
müssen. Das wird im Wireshark eventuell nicht so angezeigt. Sind die 
Pakete kürzer, müsst entweder Ihr oder der Ethernet-MAC die auffüllen.

Außerdem hat jedes Ethernet-Paket zusätzlich noch eine FCS (Frame 
Checksum), die der Wireshark auch nicht anzeigt. Der Ethernet-Controller 
muss die jedoch erzeugen und senden.

fchk

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Stimmt, es sind laut Wireshark nur "61 Bytes on wire"! Neben der 
minimalen Länge von 64 Byte sollte man auch darauf achten, dass die 
Pakete eine gerade Anzahl von Bytes haben, da manche Netzwerkkomponenten 
Prüfsummen bei ungeraden Paketlängen falsch berechnen.

von Sunday (Gast)


Lesenswert?

Hallo,

die Mindestlänge ist durchaus bekannt, wenn allerdings Wireshark die FCS 
nicht anzeigt, sind es 65 Bytes (jedenfalls bei dem PC generierten 
Paket).

Wie schon gesagt, das Paket ist 1 zu 1 aus einer funktionierenden 
Kommunikation kopiert jedoch ohne die FCS da sie nicht angezeigt wird. 
Gemeine Falle :(

Der Hinweis auf die fehlende FCS ist super, die senden wir nämlich nicht 
mit. Mal sehen ob es mit klappt.

Vielen Dank erstmal.

von Sunday (Gast)


Lesenswert?

Guten Morgen,

wir sind der Sache mit der FCS heute früh mal auf den Grund gegangen. 
Wir haben über die Ferien hinweg eine längere Pause im Projekt 
eingelegt, daher war mir entfallen, dass unser Controller (ENC28J60) die 
CRC bereits berechnet.

Insofern entsprechen wir mit dem 61Byte Paket den Anforderungen an die 
Mindestlänge da hier die FCS einberechnet wird.

Da diese Möglichkeit nun ausgeschlossen scheint, stehen wir wieder auf 
dem Schlauch, sprich wir sind für weitere Vorschläge offen.

von Frank K. (fchk)


Lesenswert?

Sunday schrieb:

> wir sind der Sache mit der FCS heute früh mal auf den Grund gegangen.
> Wir haben über die Ferien hinweg eine längere Pause im Projekt
> eingelegt, daher war mir entfallen, dass unser Controller (ENC28J60) die
> CRC bereits berechnet.

Sicher?

Schaut Euch mal MACON3.TXCRCEN und MACON3.PADCFG an, nachdem Ihr ein 
Paket gesendet habt.

fchk

von Sunday (Gast)


Lesenswert?

Hallo Frank,

Diese werden bei uns in der Initialisierung gesetzt. Wir werden dennoch 
morgen mal einen Blick darauf werfen.

von Sebastian (Gast)


Lesenswert?

Hallo Frank,

ich bin zusammen mit Sunday an dem Projekt beschäftigt.
Ich habe gerade das MACON3-Register ausgelesen. Nachdem Powerup ist das
Register leer, so wie es sein soll.

Nach der Initialisierung ist der Hex-Wert 32, was heißt, dass die beiden
Bits TXCRCEN und PADCFG0 gesetzt sind.
Dieser Wert wird auch nach mehreren Paketen beibehalten.

Sebastian

von Frank K. (fchk)


Lesenswert?

Sebastian schrieb:
> Hallo Frank,
>
> ich bin zusammen mit Sunday an dem Projekt beschäftigt.
> Ich habe gerade das MACON3-Register ausgelesen. Nachdem Powerup ist das
> Register leer, so wie es sein soll.
>
> Nach der Initialisierung ist der Hex-Wert 32, was heißt, dass die beiden
> Bits TXCRCEN und PADCFG0 gesetzt sind.
> Dieser Wert wird auch nach mehreren Paketen beibehalten.

OK, dann kann es daran auch nicht liegen.

Jetzt mal ein anderer Test: Besorgt Euch einen 10 MBit Hub (es ist 
wichtig, dass es ein Hub und kein Switch ist), hängt Sender und 
Empfänger da dran, und probiert noch einmal.

Dieser Test soll verhindern, dass irgendwer sonst das gesendete Paket 
anfasst. Ein Hub ist nur ein Koppelverstärker, der das an einem Port 
ankommende Signal an alle Ports durchreicht. Switches hingegen haben 
Intelligenz und Speicher eingebaut, und das wollen wir jetzt nicht. 100 
MBit Hubs waren extrem selten (und die konnten dann auch wirklich nur 
100 MBit) Wenn die Kiste noch einen BNC- und/oder einen 15-poligen 
SUB-D-Anschluss hat, umso besser - dann ist es mit ziemlicher Sicherheit 
ein Hub.

Habt Ihr keinen, dann sollte es auf ébay sowas für 1€ geben.

Ich hatte schon einige Male das Problem, dass mein HP Switch zu viel 
Intelligenz hatte und Pakete gefiltert hat (zu Recht, wie ich später 
immer wieder herausgefunden hatte, aber erst einmal war es verwirrend).

Notfalls nehmt Ihr ein gekreuztes Ethernet-Kabel. Ggf. müsst Ihr dann 
auf beiden Enden 10BaseT full-duplex fest einstellen (anschließend 
wieder auf auto stellen nicht vergessen)

Ansonsten fällt mir auch nichts mehr ein.

fchk

von Sunday (Gast)


Lesenswert?

Hallo Frank,

vielen Dank für deinen ausführlichen Hinweis.

Unser "Netzwerk" bestand bisher zu Testzwecken nur aus einem 
Crosslinkkabel, daher ist auch diese Möglichkeit ausgeschlossen.

Gestern Abend allerdings ist es uns gelungen ein Paket (und weitere 
tausende) zu empfangen.

Im Grunde war alles gleich aufgebaut, wir haben nur mal ein Paket eines 
ganz einfachen UDP Chat in C# ausprobiert.

Heute werden wir anfangen dies auszubauen und (hoffentlich) auf C++ 
umsteigen können.

Gruß

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
Noch kein Account? Hier anmelden.