Kennt jemand von euch ein Open-Source Programm, das Daten von der seriellen Schnittstelle aufnimmt und über UDP versendet? Es sollte Platform unabhängig sein, so dass man es unter Linux, Windows und Mac benutzen kann. Als Beispiel könnte ein kommerzielles Programm für TCP dienen: http://www.serial-server.net/serial-over-ip/ Hier habe ich einen UDP-Serial-Server gefunden, aber das scheint mir nur für den RPi zu sein: https://github.com/AL333Z/arduino-udp-msgservice/blob/master/src/msglib/BroadcastSerialCommChannel.java
:
Verschoben durch User
ch schrieb: > Es sollte Platform unabhängig sein, so dass man es unter Linux, Windows > und Mac benutzen kann. Das ist gerade bei der Ansteuerung serieller Schnittstellen gar nicht so einfach, da haben die drei nämlich sehr weit auseinanderliegende Vorstellungen davon, wie das geht. Wenn Du Eigenentwicklungen nicht abhold bist, könntest Du dem hier die plattformübergreifende Ansteuerung der seriellen Schnittstelle entnehmen: https://iftools.com/opensource/wxterm.de.php Möglicherweise findet sich auch hier was: https://iftools.com/opensource/ctb.de.php
Muss es ein Open source Programm sein ? ich mache das mit billigen Wandlern Ebay 271890553929 Sind echt gut die dinger.
Evtl. mit: http://www.hw-group.com/products/hw_vsp/hw_vsp2_de.html für Windows. Damit und mit "Herkules" vom gleichen Hersteller mache ich alles. Aber für so eine Einfache Sache tut's auch ein kleiner Mikrocontroller (auch Arduino), dann bist Du ch schrieb: > Platform unabhängig Willst Du einen ganzen Rechner nur dafür nutzen, oder laufen da noch andere Sachen drauf, und die Serielle ist virtual, oder die Datenpakete werden local weiterverwendet (127.0.0.1)? Sehr seltsam... Gruss Chregu
Oder D. schrieb: > Ein Vorteil von UDP ist, dass man mit einem Browser interfacen > kann... Verstehe ich nicht.
Naja. Wenn man auf einem PC einen Serial-zu-UDP Konverter hat, kann man auf dem seriellen Device einen Webserver laufen lassen, der sich vom Browser des PCs bedienen laesst. Das Device muss sein Protokoll nur in eine Webseite einpacken, was etwas Text Overhead ist. Und ueber die serielle Schnittstelle damit. Geht gut. Sehr praktisch, sehr Platformunabhaengig.
>Geht gut. Sehr praktisch, sehr Platformunabhaengig.
und hat nichts mit UDP zu tun..
Bei UDP hat man einfach das Problem, das die Serielle Schnittstelle nicht Paketorientiert ist. Also musst du entweder mit Timouts oder mit einem Protokoll arbeiten, weswegen es wohl sehr wenige Lösungen dafür geben wird wo man nicht wenigstens einen Teil selbst betragen muss.
Läubi .. schrieb: > Bei UDP hat man einfach das Problem, das die Serielle Schnittstelle > nicht Paketorientiert ist. Also musst du entweder mit Timouts oder mit > einem Protokoll arbeiten, weswegen es wohl sehr wenige Lösungen dafür > geben wird wo man nicht wenigstens einen Teil selbst betragen muss. naja, wenn man sich auf zeilen mit \n oder \r als trennzeichen einigt, passt das doch ganz gut in ein paket. Ein solches Programm so zu schreiben, dass es parameterisierbar ist, ob es Blockweise oder Zeilenweise (mit frei konfigurierbaren Trennzeichen/Trennsequenz) arbeitet, sollte ein leichtes sein und halte ich für nicht so abwegig/speziell, dass es nicht für viele brauchbar wäre.
Ich halte UDP auch für weniger geeignet. Nicht nur aufgrund der Problematik bezüglich der Datagrammeigenschaft, sondern auch wegen den fehlenden Mechanismen zur Einhaltung der Reihenfolge. Klar kann man diese Problematik auf der Anwendungsebene bearbeiten, aber dann würde ich schon fast zu TCP tendieren...
Vlad T. schrieb: > sollte ein leichtes sein Mit diesen Worten fangen die Probleme an ;-) Der Teufel steckt halt doch im Detail. Dann geht ein Paket verloren und nu? Reihenfolge wurde ja schon angesprochen. Die Umsetzung auf TCP ist da sehr viel natürlicher da beides Streams von Bytes sind, mit Hardware-Handshake hat man sogar ein recht zuverlässiges Flow-Control.
Warum macht ihr es so kompliziert? Ein Datagramm pro Zeichen und gut ist. Was die Nichteinhaltung der Reihenfolge angeht ist es immer wieder erstaunlich mit wie wenig Erfahrung Leute die tollsten Sachen behaupten. Ich habe für ein Projekt die Datenverteilung von mehreren hundert GB über UDP Broadcasts im LAN getestet, Fazit aus diesen Tests war das es in keinem (!) Fall zu einer Nichteinhaltung der Paketreihenfolge kam. Auch die generelle Paketfehlerrate (Nicht übermitteltes Paket/fehlerhaftes Paket) lag deutlich unter einem ppm. Danach wurde Testweise mal eine Unicast UDP-Übertragung mit gleicher Datenmenge übers Internet getestet (knapp 20 HOPs), ebenfalls mit sehr geringer Paketfehlerrate (gegenüber dem LAN allerdings doch deutlich erhöht) und wieder ohne einem einzigen Fehler in der Reihenfolge...
>Autor: Frank Esselbach (Firma: Q3) (qualidat) >Mit ein par Zeilen Java sollte das zu machen sein ... Jetzt sollte es eigentlich funktionieren sagte der Entwickler .... danach dauerte es noch 2 Wochen ... So ist das mit der Entwicklung: eigentlich sollte es gehen, tut es aber nicht. Hier ein schönes Beispiel für ein einfaches, kleines Java-Programm, welches die Zeichen auf ein Textfenster ausgibt. Beitrag "Re: Java serielle Schnittstelle mit JSSC" Eigentlich sollte es funktionieren. Tut es auch, wenn da nicht die Hälfte der Zeichen fehlen würde ...
Tim Taylor schrieb: > Ich habe für ein Projekt die Datenverteilung von mehreren hundert GB > über UDP Broadcasts im LAN getestet, Fazit aus diesen Tests war das es > in keinem (!) Fall zu einer Nichteinhaltung der Paketreihenfolge kam. > Auch die generelle Paketfehlerrate (Nicht übermitteltes > Paket/fehlerhaftes Paket) lag deutlich unter einem ppm. > Danach wurde Testweise mal eine Unicast UDP-Übertragung mit gleicher > Datenmenge übers Internet getestet (knapp 20 HOPs), ebenfalls mit sehr > geringer Paketfehlerrate (gegenüber dem LAN allerdings doch deutlich > erhöht) und wieder ohne einem einzigen Fehler in der Reihenfolge... du kannst dich aber nunmal nicht drauf verlassen.... ich hoffe nur das du keine wichtigen anwendungen baust.
pp schrieb: > Tim Taylor schrieb: >> Ich habe für ein Projekt die Datenverteilung von mehreren hundert GB >> über UDP Broadcasts im LAN getestet, Fazit aus diesen Tests war das es >> in keinem (!) Fall zu einer Nichteinhaltung der Paketreihenfolge kam. >> Auch die generelle Paketfehlerrate (Nicht übermitteltes >> Paket/fehlerhaftes Paket) lag deutlich unter einem ppm. >> Danach wurde Testweise mal eine Unicast UDP-Übertragung mit gleicher >> Datenmenge übers Internet getestet (knapp 20 HOPs), ebenfalls mit sehr >> geringer Paketfehlerrate (gegenüber dem LAN allerdings doch deutlich >> erhöht) und wieder ohne einem einzigen Fehler in der Reihenfolge... > > du kannst dich aber nunmal nicht drauf verlassen.... ich hoffe nur das > du keine wichtigen anwendungen baust. P.S.: Warum macht man dann keinen Multicast?
chris_ schrieb: > Eigentlich sollte es funktionieren. Hat aber nix mit der Seriellen Schnittstelle zu tun sondern das da "mal eben" was zusammengestoppelt wird. Außerdem wird da auch wieder versucht irgendwie Eventbasiert die Serielle Schnitstelle auszulesen was eigentlich nur unnötig kompliziert ist.
>Außerdem wird da auch wieder versucht >irgendwie Eventbasiert die Serielle Schnitstelle auszulesen Vielleicht weißt Du es ja: Wie kann man das Programm so umschreiben, dass das Textfenster ohne Events ohne Zeichenverlust aktualisiert wird?
Für diesen Anwendungsfall würde man wohl Swingworker und das publish Verfahren nutzen. Für eine konkrete Umsetzung müsste man aber erst mal ein paar Randbedingungen festlegen, z.B. ob wirklich byteweise irgendwo was hingeschrieben werden soll, oder ob ein bestimmter Zeichensatz genutzt werden soll und was dann z.B. bei Steuerzeichen passieren soll. Das geht dann aber etwas am Thema dieses Threads vorbei, wenn es dich interessiert solltest du dafür einen eigene Thread eröffnen mit einem konkretem Problem und kompilierbarem Beispielcode.
nicht“Gast„ schrieb: > Nimm socat. Da kann alles, was du willst Ist zwar nicht Plattformunabhängig. Ist aber kein Problem, es muss ja nicht auf jeder Plattform das gleiche Programm sein, solange sie das gleiche tun. Hier ist eins für Windows: http://com0com.cvs.sourceforge.net/viewvc/com0com/com2tcp/ReadMe.txt?revision=RELEASED
Tim Taylor schrieb: > ch habe für ein Projekt die Datenverteilung von mehreren hundert GB > über UDP Broadcasts im LAN getestet, Fazit aus diesen Tests war das es > in keinem (!) Fall zu einer Nichteinhaltung der Paketreihenfolge kam. Dann mach das Ganze mal über WLAN. Da hast Du doppelte Pakete und falsche Reihenfolge ohne Ende. BTDT.
Jim M. schrieb: > Dann mach das Ganze mal über WLAN. Da hast Du doppelte Pakete und > falsche Reihenfolge ohne Ende. BTDT. Nur aus Interesse: d.h. bei UDP wär es dann Sache der Applikation, das zu handlen?
pp schrieb: > du kannst dich aber nunmal nicht drauf verlassen.... ich hoffe nur das > du keine wichtigen anwendungen baust. Eine entsprechende Sicherung wurde im späteren Einsatzzweck noch drüber gelegt, es ging bei den Tests erstmal nur um eine Abschätzungsmöglichkeit ob weiteres Verfolgen der Idee eines Broadcast FTP lohnt. pp schrieb: > P.S.: Warum macht man dann keinen Multicast? Bot für den geplanten Anwendungszweck keine Vorteile und wurde nicht von allen Geräten zufriedenstellend umgesetzt. Jim M. schrieb: > Dann mach das Ganze mal über WLAN. Da hast Du doppelte Pakete und > falsche Reihenfolge ohne Ende. BTDT. Ja, was daran liegt das bei WLAN auch UDP gesichert übertragen wird und bei Verlust eben wiederholt. Natürlich blöd wenn in der Zwischenzeit schon nachfolgende Pakete durchgekommen sind. Le X. schrieb: > Nur aus Interesse: > d.h. bei UDP wär es dann Sache der Applikation, das zu handlen? Ja, hier gibts dann aber immer die Abwägung ob nicht doch TCP die bessere Idee wäre. Meiner Meinung nach lohnt sich der UDP Ansatz nur, wenn man eine Broadcast/Multicast Funktionalität braucht, sehr geringe Ressourcen zur Verfügung stehen oder keinen vollständigen IP-Stack zur Verfügung hat.
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.