UART Kommunikation zwischen Raspi und Arduino hängt sich ständig auf

[HaWe]

Hat zwar jetzt nicht direkt was mit dem Thema zu tun, aber wenn Du dich ernsthaft mit Elektronik beschäftigen willst wäre ein kleines Oszi schon nicht schlecht.
Eventuell passt ja so ein JYE Tech Oszi in dein Budget ?
https://www.elektor.de/jye-tech-dso0...oscope-diy-kit
Ist jetzt zwar nichts besonderes, aber für einfache Messungen sollte es reichen.
Der Hersteller hat auch noch andere Modelle auf Lager.

ja, stimmt schon, hatte ich auch schon mal überlegt, aber ich programmiere lieber als dass ich elektronische Schaltungen entwickle und analysiere.

[Thomas$]

seh ich das richtig:
du Prüfst ob Daten Im Eingangspuffer sind und liest diese aber nur unter bestimmten Umständen ein?
Wenn jetzt irgendwas in den Eintreffenden Daten kaputt ist scheitert das Programm auf der Empfängerseite

Allgemein ist Polling für soetwas wie UART einlesen nicht sonderlich geeignet, geht auch Eventgesteuert, siehe UART RX Complete Interrupt

ob die software überhaupt etwas tut, lässt sich auch mit blinkender led visuell überprüfen

[HaWe]

seh ich das richtig:
du Prüfst ob Daten Im Eingangspuffer sind und liest diese aber nur unter bestimmten Umständen ein?
Wenn jetzt irgendwas in den Eintreffenden Daten kaputt ist scheitert das Programm auf der Empfängerseite

Allgemein ist Polling für soetwas wie UART einlesen nicht sonderlich geeignet, geht auch Eventgesteuert, siehe UART RX Complete Interrupt

ob die software überhaupt etwas tut, lässt sich auch mit blinkender led visuell überprüfen

die Arduino-Libs funktionieren mit ihrer internen Puffer- und Timeout-Verwaltung an sich sehr stabil, der von mir verwendete Code funktioniert sowohl für Arduino<->Arduino als auch für Arduino<->PC (Borland C++ Builder Anwendung): nur nicht mit dem Raspi und wiringPi Libs.
Irgendetwas tun tut sie auch momentan, es hängt nur irgendwann irgendwo, nur weiß keiner, wo genau: https://www.raspberrypi.org/forums/p...f=33&p=1475408
alles trouble-shooting hat noch keinen eindeutig Schuldigen ermittelt.

Wenn ich feste Arrays von max. 64byte Größe (= UART-buffer-Größe auf Arduino oder Raspi) übergeben, funktioniert es ebenfalls sehr stabil.

Nur mit den sehr langen Message-Strings von variabler Länge klappt es nicht, dabei mit dem schnelleren Due allerdings noch besser als mit dem AVR.

Allerdings ist genau das das Ziel:
UART-Kommunikation zwischen AVR Mega2560 per Arduino-Serial über verschieden lange messages, denen nur gemeinsam ist: dass sie mit "§" beginnen und mit "\n" enden.
Dazu werden jetzt Fachleute gesucht, die den Code selber verfeinern und testen können, per Arduino Sketch und Raspi gcc.

[Ceos]

Dazu werden jetzt Fachleute gesucht

Dann musst du aber auch ein Fachgerechtes Gehalt zahlen :P

Scherz beiseite! Hast du schonmal darüber nachgedacht eine CRC Prüfung einzubauen? https://github.com/dwblair/arduino_c...s/crc8test.ino

So könntest du bei einem timeout während dem Empfang einer unvollständigen Nachricht einafch den Puffer löschen und auf die nächste Eingabe warten und ggf. Fehlerhafte Pakete zum Beispiel byteweise ausgeben um herauszufinden an welcher Stelle die Kommunikation unterbrochen wird (in meinem Fall mit einem STM32NUCLEO Board war es der STLink Chip der als Programmer zwischen dem eigentlichen Controller und dem USB steckt der ab dem 212ten Byte angefangen hat einzelne Bytes zu dropppen)

[Holomino]

Wie ist denn das mit folgender Zeile?
inputString += inChar;

Wird da nicht jedes mal neuer Speicher auf'm heap alloziiert und der ganze Summs dahin kopiert?
(zumindest deutet der Complexity-Absatz unter http://www.cplusplus.com/reference/s...string/append/ darauf hin, dass ein string keine verkettete Liste ist).

[Ceos]

Jein @Holomino

der "+"-Operator für Strings ist überschrieben mit der concat() Funktion

man bräuchte mehr Details/Code um die Auswirkung bestimmen zu können. Wenn die Variable außerhalb der Methode deklariert ist sollte es kein Problem damit geben.

Aber du hast recht was das Design angeht ... wenn ich nur eine maximale definierte Zahl an Bytes empfange, sollte man IMMER einen statischen Speicher verwenden um solch "volatilen" Daten zu verarbeiten, das ist nicht nur performanter, sondern vermeidet auch Nebeneffekte wie du sie beschreibst

[Thomas$]

das Design kann man allgemein verbessern
Elementweiser zugriff auf statisches array z.b.

#DEFINE MAXLEN = 1024
...
char inputString[MAXLEN];
...
inputString[n] = serialGetchar(Serial);
if (inputString[n]=="\n")
{
    stringComplete = true; 
    ...
}
...
n++;

Interrup vs. Polling
"If abfragen" mit Klammern machen es übersichtlicher und vermeidet Fehler

if(foo == 42)   // Leerzeichen zwischen == und dem Rest
{
    doBar;
}
else
{
    doFoo
}

zum überprüfen ob der Buffer evtl. überläuft kann man das Resultat von serialDataAvail(Serial) ausgeben
Auf dem Raspi kann man sich auch mal dmesg "sudo dmesg" ausgeben lassen, damit sollte man Fehler von USB-Serial adapter+treiber finden können. bzw auch Speicherzugriffsfehler von deinem Programm

[HaWe]

Jein @Holomino

der "+"-Operator für Strings ist überschrieben mit der concat() Funktion

man bräuchte mehr Details/Code um die Auswirkung bestimmen zu können. Wenn die Variable außerhalb der Methode deklariert ist sollte es kein Problem damit geben.

Aber du hast recht was das Design angeht ... wenn ich nur eine maximale definierte Zahl an Bytes empfange, sollte man IMMER einen statischen Speicher verwenden um solch "volatilen" Daten zu verarbeiten, das ist nicht nur performanter, sondern vermeidet auch Nebeneffekte wie du sie beschreibst

wenn du dir meinen Code genau ansiehst, mache ich das ja schon genau so.
Wirklich weiterhelfen täte aber jetzt nur ein verbesserter, vollständiger, kompilierbarer Code sowohl für Raspi als auch (falls unbedingt nötig) für den Arduino, womit ich die neue Variante dann auch sofort testen könnte.