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