Hallo zusammen, für ein aktuelles Projekt frage ich mich, wie man von einem PC aus am Besten mit dem Ethernet Shield eines Ardunios kommuniziert. Zur einfachen Implementiertbarkeit habe ich bereits ein Testprojekt geschrieben, bei dem der Arduino in der Lage dazu ist, auf eine fest definierte WCF-Anfrage zu antworten. Allerdings kann er derzeit die Dienstinformationen nicht bereitstellen, da hier drei oder vier Dateien zum Download bereitgestellt werden müssten. Außerdem ist das Reverse-Engineering mit Wireshark nicht ganz einfach. Theoretisch wäre es kein Problem, das Ganze zu komplettieren. Allerdings frage ich mich, ob das wirklich der „Way to go“ ist. Die WCF-Kommunikation hat einen relativ großen Overhead und man muss die ankommenden Kommunikation auf XML-Basis auf dem Ardunio parsen, den Antwort in eine Vorlage einbauen und dann zurücksenden. Das sind sehr viele Stringoperationen und man braucht viel RAM. Nun ist die Frage, ob es auch effizientere Wege gäbe die Daten zu übermitteln. Beispielsweise, indem man HTML als Protokoll komplett ausnockt und direkt TCP-Pakete mit den relevanten Daten versendet. Was meint ihr? Habt ihr Tips?
André R. schrieb: > Beispielsweise, indem man HTML als Protokoll komplett > ausnockt und direkt TCP-Pakete mit den relevanten Daten versendet. Ja! z.B. UDP, wenns schnell und einfach gehen soll Oder TCP, wenns zuverlässig werden soll
Arduinoquäler schrieb: > Ich verstehe es auch nicht. Typ schrieb: > Was willst du machen? Was er/sie/es auf jeden Fall nicht will, ist einen XML Parser auf dem Arduino laufen lassen. Und das kann ich gut verstehen!
Ein einfaches Format zu Austausch von tabellarischen Daten wäre CSV. Das kannst du mit HTTP Protokoll übertragen oder mit einem selbst ausgedachten protokoll. Im einfachsten Fall könnte eine Leerzeile dazu dienen, das Ende der Daten zu kennzeichnen. Wenn es keine tabellarischen Daten sind, dann gefällt Dir vielleicht das JSON Format. Das nutzen auch viele große Web Anwendungen.
Es ist die Gegenstelle für dieses Projekt hier: Beitrag "Geeigneter Matrix-Decoder für Pick-by-Light-System" Ein Server soll mit der Anlage kommunizieren und gleichbleibende Kommandos senden, mit der LEDs ein- und ausgeschaltet werden können. Womöglich soll noch Text für ein Display übertragen werden. Auf der Serverseite ist die Sprache vb.net Vorgabe. Damit TCP-Pakete zu versenden ist keine große Kunst. WCF hätte den Charme, dass man die Anlage per Knopfdruck in sein Programm einbinden könnte und der Server-Entwickler sich um den Low-Level der Kommunikation nicht scheren müsste. Nachteil ist wie gesagt der hohe Parsingaufwand auf dem Arduino. Deshalb war das hier als Aufruf gedacht, weitere Ideen zu äußern, falls die jemand hat.
Für so einfache Kommandos genügt doch etwas wie: LICHT1=AN LICHT2=AUS oder nicht? Dafür eignet sich das UDP Protokoll ideal. Ich würde aber zusätzlich auch IP Sockets unterstützen, damit du aus Javascripten heraus Kommandos senden kannst.
Danke für die Idee, aber das ist gar kein Anwendungsfall bei meinem Projekt. Die Ansteuerung erfolgt ausschließlich durch einen WCF-Dienst, der wiederum von einem Funkscanner angesteuert wird. Ein Zugriff über Fremdsysteme mittels Javascript o.Ä. ist bei diesem Projekt nicht erwünscht, da es im industriellen Umfeld laufen wird. Ich habe mir ein Format überlegt, bei dem binär Codiert nacheinander übertragen werden: 8 Bit Zeile 8 Bit Spalte 24 Bit Farbe (RGB) 8 Bit Textlänge 0..255 Byte Text Womöglich könnte man noch ein zusätzliches Byte voranstellen, um die Befehlsnummer anzugeben. So könnte man auch beispielsweise einen Befehl zum Ausschalten einer LED sehr einfach implementieren. Alternativ könnte man auch obigen Befehl einfach mit RGB #000 und einem leeren Text versenden.
Binär codierte Übertragungen sind schwierig mitzulesen, was du aber im Fehlerfall tun willst. Mach lieber etwas text basiertes. Hexadezimal-Zahlen lassen sich effizient durch µC parsen. > 8 Bit Textlänge > 0..255 Byte Text Da fehlt eine Möglichkeit der Neusynchronisierung nach einem Übertragungsfehler. Stelle Dir mal vor, das Byte mit der Textlänge fehlt oder kommt beim Empfänger verfälscht an. Dann musst du den Sender und alle Empfänger resetten. Wenn dein Datenpaket hingegen eine eindeutige Start- oder Ende-Markierung hat, lösen sich solche Übertragungsstörungen von selbst.
Stefan U. schrieb: > Binär codierte Übertragungen sind schwierig mitzulesen, was du > aber im Fehlerfall tun willst. Mach lieber etwas text basiertes. Kannst Du mir bitte erklären, warum das der Fall ist? > Da fehlt eine Möglichkeit der Neusynchronisierung nach einem > Übertragungsfehler. Stellt nicht TCP sicher, dass dies nicht passiert? Oder habe ich das Protokoll da falsch/unzureichend verstanden? Falls das nicht klar wurde: Das Protokoll wäre selbstveständlich auf Basis von TCP/IP und meine Ethernet-Peripherie implementiert den entsprechenden Stack bereits auf Hardwareebene, sodass ich mich um die Korrektheit der TCP/IP-Übertragung nicht kümmern muss. > Stelle Dir mal vor, das Byte mit der Textlänge fehlt > oder kommt beim Empfänger verfälscht an. Dann musst du den Sender und > alle Empfänger resetten. Ich würde ohnehin eine DLL bereitstellen, sodass die Korrektheit des Aufrufs stets sichergestellt ist. Es gibt auch nur einen Server und einen Client.
Programmiere eine Zwischenschicht, eine Art Proxy. WCF rein -> simples Protokoll zum Arduino raus und umgekehrt. Die App läuft auf irgend einem Rechner als Hintergrund-Dienst.
>> Binär codierte Übertragungen sind schwierig mitzulesen > Kannst Du mir bitte erklären, warum das der Fall ist? Weil der Mensch sich damit scher tut, Bits oder Bytes zu lesen. So etwas wie: Lample,1,On Ist für den Menschen leichter zu lesen, als eine Kette von Zahlen. Deswegen sind Textbasierte Protokolle wie HTML und SOAP so beliebt geworden. >> Da fehlt eine Möglichkeit der Neusynchronisierung nach einem >> Übertragungsfehler. > Stellt nicht TCP sicher, dass dies nicht passiert? Nicht zuverlässig. TCP stellt nur sicher, dass die Daten in der richtigen Reihenfolge ankommen, wenn sie ankommen. Bei Übertragungsstörungen wiederholt TCP einige male, aber nicht unendlich oft. Deswegen sollten empfangende Programme immer damit rechnen, dass der Empfang Lückenhaft sein könnte. Das kommt zwar nur selten vor, aber es kommt vor. Vor allem bei WLAN. Kennst du das nicht, das du auf einer Webseite irgendwas anklickst und es kommt keine Antwort zurück? Dann klickst du nochmal, und es klappt.
Gut, das ist natürlich ein Argument. Aber in diesem Falle kein technisches Problem sondern eher eine Methode, die Fehlerdomäne zu verkleinern. Es scheint aber keine technisch begründeten Argumente zu geben, oder? Das Andere werde ich berücksichtigen. Danke für den Hinweis!
> Es scheint aber keine technisch begründeten Argumente zu geben, oder?
Wenn du damit die Text-basierten Protokolle meinst: Nein, die macht man
für Menschen.
Erfahrene Programmierer wissen allerdings, dass es in 99% der Fälle
wichtiger ist, Programme gut wartbar und nachvollziehbar zu machen, als
beste Performance anzustreben.
Die Hardware wird von alleine immer Leistungsfähiger, die Menschen, die
damit arbeiten müssen aber nicht!
Ein raspberry pi mit win10 kann wcf out of the box... Vergiss den arduino!
Stefan U. schrieb: > Nicht zuverlässig. TCP stellt nur sicher, dass die Daten in der > richtigen Reihenfolge ankommen, wenn sie ankommen. Bei > Übertragungsstörungen wiederholt TCP einige male, aber nicht unendlich > oft. Deswegen sollten empfangende Programme immer damit rechnen, dass > der Empfang Lückenhaft sein könnte. Das kommt zwar nur selten vor, aber > es kommt vor. Vor allem bei WLAN. Sorry wenn ich hier einhake, das was du schreibst stimmt nicht. Bei TCP kann ich mich darauf verlassen dass alle Bytes in der richtigen Reihenfolge kommen. Sollten z.B. bei WLAN oder so doch Pakete verloren gehen, ist an dieser Stelle Schluss mit der gesamten Verbindung. Wenn das nicht so wäre könnte man auch gleich UDP nehmen.
dunno.. schrieb: > Ein raspberry pi mit win10 kann wcf out of the box... > > Vergiss den arduino! Der braucht aber auch bis zu 30s zum Booten und wehe, auf der SD-Card komm mal etwas durcheinander (z.B. Swap-Speicher). Ein Arduino ist (EEP)-ROM basiert, nach 1s betriebsbereit und völlig unbeeindruckt von beliebig oft ein und ausschalten ...
temp schrieb: > Stefan U. schrieb: >> Nicht zuverlässig. TCP stellt nur sicher, dass die Daten in der >> richtigen Reihenfolge ankommen, wenn sie ankommen. Bei >> Übertragungsstörungen wiederholt TCP einige male, aber nicht unendlich >> oft. Deswegen sollten empfangende Programme immer damit rechnen, dass >> der Empfang Lückenhaft sein könnte. Das kommt zwar nur selten vor, aber >> es kommt vor. Vor allem bei WLAN. > > Sorry wenn ich hier einhake, das was du schreibst stimmt nicht. Bei TCP > kann ich mich darauf verlassen dass alle Bytes in der richtigen > Reihenfolge kommen. Sollten z.B. bei WLAN oder so doch Pakete verloren > gehen, ist an dieser Stelle Schluss mit der gesamten Verbindung. Wenn > das nicht so wäre könnte man auch gleich UDP nehmen. WLAN ist erstmal nur der physikalische Transport und da werden Frames nicht quittiert. Das passiert erst auf Layer 4, falls TCP verwendet wird. Richtig ist, dass bei TCP jedes Paket vom Empfänger quittiert werden muss - aber nicht beliebig oft. Wird ein Schwellwert überschritten, wird die Verbindugn abgebrochen und ein Fehler an den darüber liegenden Layer (App) gegeben. Der kann dann einen erneuten Verbindungsaufbau initiieren ... Wenn es wichtig ist, dass jedes Byte ankommt, sollte man oberhalb von TCP oder UDP hoch ein eigenes Handshaking programmieren und die Nachrichten mit einer Prüfsumme oder wenigstens Start- und Ende-Zeichen versehen.
:
Bearbeitet durch User
Beitrag #5188040 wurde von einem Moderator gelöscht.
Frank E. schrieb: > dunno.. schrieb: > Ein raspberry pi mit win10 kann wcf out of the box... > Vergiss den arduino! > > Der braucht aber auch bis zu 30s zum Booten und wehe, auf der SD-Card > komm mal etwas durcheinander (z.B. Swap-Speicher). > Ein Arduino ist (EEP)-ROM basiert, nach 1s betriebsbereit und völlig > unbeeindruckt von beliebig oft ein und ausschalten ... Wenn das booten ein problem ist, dann aber lieber mqtt statt wcf auf dem arduino.. Wieso hat das eigentlich noch niemand in den raum geworfen?
dunno.. schrieb: > Ein raspberry pi mit win10 kann wcf out of the box... Und kostet im betrieblichen Umfeld monatliche Lizenzgebühren und muss ggf. noch mit Virenscanner usw. bestückt werden (wäre bei uns Vorschrift). temp schrieb: > Sorry wenn ich hier einhake, das was du schreibst stimmt nicht. Bei TCP > kann ich mich darauf verlassen dass alle Bytes in der richtigen > Reihenfolge kommen. Sollten z.B. bei WLAN oder so doch Pakete verloren > gehen, ist an dieser Stelle Schluss mit der gesamten Verbindung. Wenn > das nicht so wäre könnte man auch gleich UDP nehmen. Warum brauche ich dann dennoch, wie von Deinem Nachredner angesprochen, ein eigenes Handshaking und Prüfsummen? Was ist denn nun korrekt? dunno.. schrieb: > Wenn das booten ein problem ist, dann aber lieber mqtt statt wcf auf dem > arduino.. > > Wieso hat das eigentlich noch niemand in den raum geworfen? Wahrscheinlich, weil es kaum einer kennt. Ich jedenfalls höre zum ersten Mal davon. Was kann das denn und wo ist jetzt der Vorteil zu meinem selbstgestrickten Protokoll? Gibt es da schon was Fertiges für .net?
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.