ist alles völlig irrelevant für die ursprüngliche Frage zu Arduino Serial (Sketch / Wiring) und Processing und die gegebenen Lösungsvorschläge.
Druckbare Version
ist alles völlig irrelevant für die ursprüngliche Frage zu Arduino Serial (Sketch / Wiring) und Processing und die gegebenen Lösungsvorschläge.
Also Transmit, Receive und Ground sind bei mir 3 Adern. Was ja die minimalistichste, serielle, bidirektionale, vollduplex Verbindung ist.Zitat:
Zitat von Unregistriert
die Anzahl der Verbindungen haben nichts mit Parity, Start und Stopbits zu tun. nur ob man Hardware- oder Software Handshake zur Verfügung hat.
Bei 3-Draht hat man eh nur Xon-Xoff.
Aber je nach Gegenseite muß man sich über Parity, Sart-, Stopbits und Baudrate doch Gedanken machen.
Na ja,Zitat:
Zitat von Unregistriert
Jemand hat ein Problem mit serieller Kommunikation und weis nichts oder nur sehr wenig darüber.
Entweder man kaut dem jenigen eine fertige Lösung vor, oder man gibt auch ein paar Infos damit derjenige sich Weiterbilden kann. Klar die die es wissen können auch einfach nichts sagen, aber statt kostenfreiem Forum bleibt dann für die unwissenden nur noch ein kostenpflichtiger Support übrig. Oder an Schulungen teilzunehmen.
Einfach mal drüber nachdenken anstelle sich hinter "unregistriert" zu verstecken und Außerungen abzugeben die auch nichts zum Thema beitragen.
Trolle gibts schon genug.
jein, 2 Datenleitungen und 1 GND - gut, ich schrieb ja 2 (TX+RX) plus GND für die gemeinsame Potentialbasis, also zähl GND meinetwegen mit.
Jedenfalls hat das nichts mit den 9 oder 25 pins bei seriellen Verbindungen zu tun und auch nichts mit den blinkenden LEDs und Breakout Box zu tun.
Das Problem vom Fragesteller ging auch nicht um start stop und paritiy bits, sondern um ein Programm zwischen Arduino Serial und Processing auf dem Computer.
Auch das hat nichts mit der seriellen Schnittstelle zu tun, denn die läuft bei Arduino über ein USB-Kabel (!) zum PC und seinem virtuellen COM-Port und auch hier brauchen wir uns über start, stop und parity keine Gedanken zu machen.
Natürlich gibt es so etwas auch hier und es muss auch funktionieren, aber darum muss sich der Benutzer bei Arduino und der USB-Verbindung nicht kümmern und es wäre eher schädlich, wenn er hier als Anfänger an irgend welchen Voreinstellungen herum"spielt", denn es ist ja alles auf einander eingestellt (auch Wiring / Arduino IDE / Sketch basiert ja auf Processing und dessen Standard-Einstellungen).
All das mit den 9 oder 25 Pins und blinkenden LEDs und start und stop und parity ist also absolut nicht zielführend und eher verwirrend!
Zielführend war hingegen mein (!) Vorschlag, die baud-Rate zu ändern - ursprünglich unter der Vorstellung, der Flaschenhals wäre Arduino-seitig, tatsächlich war er aber ja wohl eher Processing-, also PC-seitig, und lag/liegt wahrscheinlich an der hier darunter bzw. dazwischen liegenden relativ langsamen Java-VM.
Bei der Verdrahtung gibt es keine meintewegend GND mal mitzählen oder auch nicht.
Trenn mal GND auf und dann kommt eine Station an ein Netzteil mit Erdung und eins befindet sich in Schwebe ohne GND ist es da eher Zufall wenn was richtiges ankommt.
Dann müsste man mit diferentiellen Signalen ohne Bezugspotential arbeiten. Da hätte man dann für TX und RX aber 4 Leitungen.
Hat aber auch nichts mit dem Protokoll zu tun.
Hilft aber es zu wissen, bei bestimmten Problemen.
Die Indikator LEDs sind hilfreich wenn man keinen Logikanalyzer oder zweikanalosziloskop zur Verfügung hat.
Das Problem das hier vorliegt, ist genau das man sich um nichts kümmern muß und damit auch aufhört sich darüber Gedanken zu machen.
Es gibt einen Prozess der Daten leifert, einen Prozess der Daten sendet, einen Prozess der Daten empfängt und einen der Sie verarbeitet.
Nimmt man einfach mal im Gedankenmodell vier durchsichtige Schlauchstücke mit verschiedenen Durchmessern die man mit Adaptern untereinender hängt und gießt oben Wasser ein, merkt man sofort das man oberhalb eines Engpasses einen Überlauf bekommt.
Nimmt man jetzt anstelle von Wasser farbigen Sand, und jede Farbe stellt ein Byte dar, dann stellt man noch fest das einzelne Bytes beim Überlauf verloren gehen.
Man also nicht weis ob der Sendepuffer überhaupt eine Bytefolge enthält die ein zusammengehöriges Datagramm bilden oder nur Datenmüll aus zwei, drei oder mehr Datagrammen des liefernden Prozesses.
Oder halt der Empfangspuffer wenn man Leitngsstörungen hat und sich nicht um Kontrollmechnismen gekümmert hat (Parity auf Bitebene, Modulo 11 auf Byteebene etc.)
Einfach nur sagen dreh die Baudrate runter, ist ein erster Ansatz der eine direkten erfolg bringen kann, aber ohne das grundlegende Verständniss beim TE wie die Zusammenhänge sind und wie das ganze funktioniert, wird der TE immer nur murks zusammenbasteln der scheinbar oder temporär, zufällig funktioniert in Wahrheit aber ein unendlicher Quell für Fehler sein wird.
Und eine Möglichkeit ist zum beispiel nicht nur TX und RX zu nutzen sondern das ein langsamer Zielprozess ein TRS oder CTS signalisiert. Damit werdne dann Überläufe beim Sendepuffer vermieden und man braucht kein NOP (delay) das bei veränderungen am Programmablauf plötzlich nicht mehr passt, weil es ja nichts prüft.
Ich habe hier grade erst ein Projekt für einen Energieversorger abgeschlossen wo es um nichts anders ging als zu prüfen ob unter allen Bedingunen, von Schutzgeräten wirklich die korrekten Daten in der Leitwarte ankommen.
Da waren auch jungdynamische Softwareentwickler am werke, die so Basics mal schnell im Grundstudium durchgewunken haben.
Nur bei einer Kaskadenabschaltung quer durch Europa sind die Folgen halt etwas anders wie bei unseren Hobbyprojekten.
Schlimm wird es nur wenn da dann Leute dabei sind die, genau weil bei ihnen privat so zusammenklick und fertig Projekte bisher noch keine größeren Auswirkungen hatten, denken so kann man auch bei einer kritischen Infrastruktur arbeiten.
Schlimm ist hier gewesen, das ich mit Realschulabschluß aber halt vor der Klickmich Ära gelernt, einem Doktor der Informatik so was erklären muß.
Hier wäre es jetzt vermutlich egal, aber wen nder TE für sich was lernen will und sich verbessern will, gereicht es Ihm nicht zum Nachteil wenn er ein mehr an Informationen erhällt.
Auch wenn es einige KISS verfechter gibt, zeigt mir mein Berufsaltag, daß das mit deutlicher Mehrheit schief geht.
Bei der Implementierung sollte am ende natürlich KISS unter dem Gesichtspunkt der Performance und der Wartbarkeit rauskommen. Aber halt nicht beim Gedanken darüber machen ob man alle Eventualitäten abdeckt die das gewünschte Ergebniss verhindern können.
(Meteoreinschläge oder andere eher unwarscheinlichen Worst Case Szenarien mal außen vor gelassen, da ich nicht denke das hier im Forum jemand eine HA Umgebung auf höchstem Niveau fürs Hobby entwickelt)
ich bezweifle ernsthaft, dass dem Fragesteller hier bei seinem Problem mit Logic Analysern, 25 blinkenden LEDs, Breakoutboards, Oszis, start, stop und parity bits oder farbigem Sand geholfen worden ist oder wäre. Zum Verständnis allerdings ist es schon wichtig zu verstehen, wo es mit der seriellen Arduino-USB-PC-Processing- Kette zu Problemen kommen kann, und da war der erste Test(mehr war es ja nicht) der zielführende Hinweis, und wo der Flaschenhals jetzt zu suchen ist, ist ja inzwischen auch klar, inkl. Abhilfevorschlägen wie baud-rate runterregeln und Datenrate Arduino-seitig runterzufahren. Aber ok, wer es jetzt mit Logic Analysern, 25 blinkenden LEDs, Breakoutboards, Oszis, start, stop und parity bits oder farbigem Sand probieren will, gern, bleibt natürlich dem original-Fragesteller überlassen ;)
Mitte der 80er Jahre benutzte ich X.25 (Datex-P). Manchmal konnte man Wochenlang keine binären QNX-Updates aus Kanada, die Server standen damals in Ontario, herunterladen, weil irgend ein AMI-System nur auf 7-Bit Übertragung eingestellt war. Mit der damaligen PTT konnten wir genau herausfinden, welcher Server dies war. Allerdings gab es damals noch keine direkte internationale Zusammenarbeit zwischen den nationalen Betreibern und die Techniker hatten auch keine direkte Telefonnummer oder Adressen. Das musste also über den offiziellen Dienstweg, von Basel zur Direktion in Bern, dann zur Direktion in den USA und dort dann zur zuständige Zentrale mit dem falsch konfigurierten Server :-( Entsprechend wurden natürlich auch Texte mit Umlauten verstümmelt, aber Umlaute kennen die Amis nicht, die kommen mit 7-Bit ASCII aus.Zitat:
Zitat von i_make_it
Sowas war auch die Ursache für SASSER. Da wurde einfach nicht geprüft ob die MSG auch in den Puffer passt! Ethernet kann Datenblöcke bis 64KB versenden, bei dem MS-Protokoll waren maximal 4KB vorgesehen.
Manche haben auch einfach ein Brett vor dem Kopf! Ich hatte mal einen riesen Streit, der Typ konnte keinen Unterschied zwischen folgendem Code erkennen
Code:10 INPUT "Alles Löschen?", A$
20 IF A$="N" THEN GOTO 40
30 REM Code für Löschen
40 REM Weiter im Programm
MfG Peter(TOO)Code:10 INPUT "Alles Löschen?", A$
20 IF A$="J" THEN GOTO 40
30 GOTO 50
40 REM Code für Löschen
50 REM Weiter im Programm
peter-too:Zitat:
Zitat Zitat von i_make_it Beitrag anzeigen
Ich habe hier grade erst ein Projekt für einen Energieversorger abgeschlossen wo es um nichts anders ging als zu prüfen ob unter allen Bedingunen, von Schutzgeräten wirklich die korrekten Daten in der Leitwarte ankommen.
Da waren auch jungdynamische Softwareentwickler am werke, die so Basics mal schnell im Grundstudium durchgewunken haben.
Nur bei einer Kaskadenabschaltung quer durch Europa sind die Folgen halt etwas anders wie bei unseren Hobbyprojekten.
Schlimm wird es nur wenn da dann Leute dabei sind die, genau weil bei ihnen privat so zusammenklick und fertig Projekte bisher noch keine größeren Auswirkungen hatten, denken so kann man auch bei einer kritischen Infrastruktur arbeiten.
Schlimm ist hier gewesen, das ich mit Realschulabschluß aber halt vor der Klickmich Ära gelernt, einem Doktor der Informatik so was erklären muß.
Mitte der 80er Jahre benutzte ich X.25 (Datex-P). Manchmal konnte man Wochenlang keine binären QNX-Updates aus Kanada, die Server standen damals in Ontario, herunterladen, weil irgend ein AMI-System nur auf 7-Bit Übertragung eingestellt war. Mit der damaligen PTT konnten wir genau herausfinden, welcher Server dies war. Allerdings gab es damals noch keine direkte internationale Zusammenarbeit zwischen den nationalen Betreibern und die Techniker hatten auch keine direkte Telefonnummer oder Adressen. Das musste also über den offiziellen Dienstweg, von Basel zur Direktion in Bern, dann zur Direktion in den USA und dort dann zur zuständige Zentrale mit dem falsch konfigurierten Server Entsprechend wurden natürlich auch Texte mit Umlauten verstümmelt, aber Umlaute kennen die Amis nicht, die kommen mit 7-Bit ASCII aus.
Sowas war auch die Ursache für SASSER. Da wurde einfach nicht geprüft ob die MSG auch in den Puffer passt! Ethernet kann Datenblöcke bis 64KB versenden, bei dem MS-Protokoll waren maximal 4KB vorgesehen.
Manche haben auch einfach ein Brett vor dem Kopf! Ich hatte mal einen riesen Streit, der Typ konnte keinen Unterschied zwischen folgendem Code erkennen
Code:
10 INPUT "Alles Löschen?", A$
20 IF A$="N" THEN GOTO 40
30 REM Code für Löschen
40 REM Weiter im Programm
Code:
10 INPUT "Alles Löschen?", A$
20 IF A$="J" THEN GOTO 40
30 GOTO 50
40 REM Code für Löschen
50 REM Weiter im Programm
MfG Peter(TOO)
falscher Post zum falschen Thema im falschen Unterforum im falschen Jahr?
Wir befinden uns hier beim Thema "Arduino Serielle Schnittstelle mit Processing verzögert" im Arduino-Unterforum vom Roboternetz-Forum im Jahr 2017.
Bitte check doch mal deine Raum-Zeit-Maschine und stell sie notfalls um. :D
eine bitte an den threadstarter:
bitte schiessen / beenden!
Viel mehr sollte man Unregistered Accounts verbieten in solchen Bereichen schreiben zu dürfen, man merkt einfach das sich manche auf andere eingeschossen haben und nur stänkern wollen......
cYa
Hallo Leute
es hat mittlerweile funktioniert, einfach eine kleinere Geschwindigkeit gewählt (2400 Baud)
vielen Dank an alle Helfenden
RoboterSindCool