Arduino Serielle Schnittstelle mit Processing verzögert

[i_make_it]

Oh, serielle Schnittstelle kann so schön einfach sein.
Wenn mann nicht durchsteigt, geht man erst mal hin und nimmt den vollen 25 Pin Stecker und holt sich ein paar LEDs und Widerstände.
Dann beide Seiten auf 900 Baud und man kann jede Signaländerung an den LEDs sehen.
Wenn mann dann eine bidirketionale Kommunikation hat dreht man den Speed hoch.
bei 9600 kann man aber nur noch an der Helligkeit der LEDs erkennen ob das passt. Da das eher einer 1kHz PWM Ansteuerung der LEDs entspricht.
Soche "Serial Port Monitor" Stecker gabs auch zu kaufen.
Da heute "fast" alle Computer nur noch USB haben, aber jeder Netzwerkswitch und größerer Router immer noch einen 9 oder 25 Pol Console Anschluß hat.
Ist das bei mir aber auch noch Tagesgeschäft, wenn einer der Spezialisten, Remote mal wieder was totkonfiguriert hat und der Kollege vor Ort auch über fordert ist.
Ist halt kein Plug an Pray, sondern man kann alles noch selbst einstellen.

Hier in dem Fall sollte man aber neben der Baud Einstellung tatsächlich auch das Volumen der erzeugten Daten reduzierten. Zum einen wurde mit den 2400 Baud ja bereits festgestellt, das man die Menge an Daten gar nicht beim Empfänger verarbeiten kann und deshalb die Übertragung drosseln musste. Zum anderen kann in der Zeit ggf. der µC auch was sinnvolleres machen als Daten für Dev0 zu produzieren.

[Unregistriert]

Ich weiss auch nicht wieso die meisten Leute mit Daten-, Parity- und Stop-Bits und der Baudrate überfordert sind?
Ich bin jetzt seit 1976 beruflich mit der Entwicklung beschäftigt und die serielle Schnittstelle war immer für die meisten ein Horror, auch für Techniker und Ings.
Vermutlich weil man auf beiden Seiten 4 Parameter gleich einstellen muss, damit die Verbindung funktioniert. Nur mit kindlichem Rumspielen bekommt man es eben meist nicht hin.
Hinzu kommt noch, dass es oft mehr als nur 3 Drähte benötigt, da sind noch ein paar Statusleitungen, welche man im einfachsten Fall brücken muss, damit der Sender überhaupt etwas sendet.

tatsächlich reden wir hier über die Arduino Serial Class und den Arduino UART pins mit nur 2 Kabeln, nämlich TX und RX (und GND), und da brauchen wir uns ja gottseidank um start, stop und parity keine Gedanken zu machen und ich sehe da auch keine Verbindung zu "kindlichem Rumspielen", dafür wurde das Arduino-Serial ( per "Wiring") ja schließlich genau so konzipiert.

[quote] Ob Default-Werte sinnvoll sind, wurde nicht gefragt, [!quote]
Doch, eigentlich war genau das gemeint mit "keine Ahnung, warum auch immer von allen Leuten 9600 benutzt wird....", das bezog sich aufs default 9600 wie Arduino es eingestellt hat und auch auf die sehr häufig unveränderte Übernahme ins eigene Programm

wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingeht

Und wo liegt der Unterschied?
Mit beiden varianten wird die nutzbare Bandbreite begrenzt. Nur kommt die Herabsetzung der Baudrate ohne zusätzlichen Code aus und lässt sich auch einfach wieder aufheben. Bei Geräten, bei welchen man keinen Einfluss auf den Code hat, ist das Herabsetzen der Baudrate die einzige Möglichkeit, wenn ein Empfänger "überfahren" wird. Wobei es eigentlich noch die genormten Handshakes gäbe!

Der Unterschied ist, dass das Arduino Programm jede Mengen Daten versucht in den Serial Buffer reinzuschaufeln, der aber die ganze Ladung nicht durchschaufeln kann bei 2400 baud, sodass der Serial Buffer ständig überläuft. Es werden also unnütz viele Daten produziert, die sich vor dem Serial Buffer stauen, überlaufen und verloren gehen (für dev0, wie i_make_it richtig schrieb). Also war der Vorschlag, die Daten-Masse durch delays etc. zu begrenzen, wenn eh auf der anderen Seite nur ein Bruchteil verarbeitet werden kann - dann kann man ja immer noch mit 2400 baud übertragen aber hat vor den Serial- und Processing-Engpässen nicht ganz so viel Müll produziert.

[Peter(TOO)]

tatsächlich reden wir hier über die Arduino Serial Class und den Arduino UART pins mit nur 2 Kabeln, nämlich TX und RX (und GND), und da brauchen wir uns ja gottseidank um start, stop und parity keine Gedanken zu machen und ich sehe da auch keine Verbindung zu "kindlichem Rumspielen", dafür wurde das Arduino-Serial ( per "Wiring") ja schließlich genau so konzipiert.

Das ist eben nur die halbe Wahrheit!
Da ist immer auch noch auf der Gegenseite noch was.
Und die Beiden müssen zusammenpassen, damit es funktioniert.

- - - Aktualisiert - - -

bei 9600 kann man aber nur noch an der Helligkeit der LEDs erkennen ob das passt. Da das eher einer 1kHz PWM Ansteuerung der LEDs entspricht.
Soche "Serial Port Monitor" Stecker gabs auch zu kaufen.

Gab es auch noch als Breakout Box zu kaufen.
Mit Drähten konnte man die Verbindungen zwischen den Steckern stöpseln, wie bei einem Steckbrett.
Gab es auch mit Schaltern für die gebräuchlichen Verbindungen (gerade/gekreuzt, Handshake/Nullmodem).

MfG Peter(TOO)

[Unregistriert]

ist alles völlig irrelevant für die ursprüngliche Frage zu Arduino Serial (Sketch / Wiring) und Processing und die gegebenen Lösungsvorschläge.

[i_make_it]

tatsächlich reden wir hier über die Arduino Serial Class und den Arduino UART pins mit nur 2 Kabeln, nämlich TX und RX (und GND), und da brauchen wir uns ja gottseidank um start, stop und parity keine Gedanken zu machen

Also Transmit, Receive und Ground sind bei mir 3 Adern. Was ja die minimalistichste, serielle, bidirektionale, vollduplex Verbindung ist.
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.

ist alles völlig irrelevant für die ursprüngliche Frage zu Arduino Serial (Sketch / Wiring) und Processing und die gegebenen Lösungsvorschläge.

Na ja,
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.

[Unregistriert]

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.

[i_make_it]

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)

[Unregistriert]

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

[Peter(TOO)]

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

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

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)

[Unregistriert]

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)

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.