Arduino Serielle Schnittstelle mit Processing verzögert

**i_make_it** · 23.01.2017, 11:13

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 · 23.01.2017, 12:08

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)** · 23.01.2017, 16:32

Zitat von i_make_it

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)

Unregistriert · 23.01.2017, 17:39

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.

**inka** · 23.01.2017, 18:10

eine bitte an den threadstarter:

bitte schiessen / beenden!

**piggituX** · 27.01.2017, 09:58

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