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

Zitat:

---

Zitat von wkrug

Ich hab jetzt den Code nicht zerpflückt und bin auch kein ARDUINO Mann aber,

könnte es sein das der Raspberry einen Softwareloop auf die serielle Schnittstelle macht und somit der Eingangspuffer mit den empfangenen Daten, die der Arduino selbst gesendet hat überläuft?
Das sollte sich testen lassen, wenn man die RxD Leitung des Arduino mal auftrennt und den Sendecode umschreibt.

Ich lös das immer so, das der Datenempfang im Interrupt läuft und einen Ringpuffer befüllt.
Dann gibt's da noch einen Schreib- und einen Lesezeiger auf den Ringbuffer und in der Hauptroutine wird dann, wenn die beiden unterschiedlich sind eine Abfrageroutine ausgeführt und die empfangenen Bytes ausgewertet.

Die Senderoutine läuft dann ganz normal mit Polling auf das USARTx DRE Bit.
Da die Atmegas einen Doppelpuffer haben gehen da am Anfang immer gleich 2 Bytes rein.
Kriegt man die Hauptroutine unter 86µs pro Durchlauf sollten da auch keine Lücken im Sendedatenstrom entstehen.

---

danke, aber ich wüsste jetzt nicht, wie ich das umschreiben soll, und ich kann den Arduino ja nicht per Serial/USB- console auslesen, weil er per USB am Raspi hängt - auf einen genauen (Arduino- oder Raspi C) Code wäre ich da jetzt schon angewiesen.
Kann aber auch sein, dass der Fehler Raspi-seitig ist, nicht Arduino-seitig, s. hier: https://www.raspberrypi.org/forums/v...9e491#p1475408

In jedem Falle wäre es aber am besten, einen Code zu benutzen, den schon jemand erfolgreich verwendet, und nach so vielen Jahren Raspi und Arduino müsste es das doch geben - ich bin doch da wschl nicht wirklich der allererste, der sich daran versucht?

(Später will ich einen sehr langen String mit an die 50 tokens+args übergeben, mit denen ich schnell Variablen (int, double)- und pin-r/w-Werte (digital, ADC) hin und her übertragen will. Auch serielle Eingaben über die Konsole, abgeschlossen per Enter, sollen später grundsätzlich möglich sein, daher soll der lange String mit '\n' enden.)

- - - Aktualisiert - - -

PS,
auf einen Tipp hin habe ich die Leseroutine beim Pi jetzt abgeändert (versuchsweise optional auch am Arduino entsprechend)

Code:

---

if (serialDataAvail(Serial)) {
        while(!stringComplete && n<MSGLEN-1) {   
          if(n==MSGLEN-2) inChar='\n'; // emergency brake
          else 
            inChar = serialGetchar(Serial);
     
          if(inChar=='\n' || inChar>=' ') inputString += inChar;     
          if (inChar == '\n')  {
            stringComplete = true;
          }
          n++;
        }
    }

---

läuft jetzt am Mega mit 2000-3000 loops, aber dann hängt er wieder - am Due läufts ohne Probleme bislang weiter....
Künftig sollen beide Codes aber auch unabhängig vom Arduino-Board laufen, egal ob AVR oder ARM oder ESP.



Update: nach ca. 30min hat es sich dann auch beim Due aufgehängt...

Häng doch mal ein OSZI an den TxD Pin des des Prozessors am ARDUINO.
Der müsste dann weiter senden.
Soweit Ich weiss ist auf em ARDUINO nur eine Serial nach USB Bridge.
Dieser Chip muss dann auch vom RASPI aus konfiguriert werden. Eventuell liegt ja da der Hund begraben?

sowas wie ein Oszi besitze ich doch gar nicht... ;)
aus irgendeinem Grund hängt sich die Verbindung auf, und vermutlich liegt es am Raspi, denke ich inzwischen (UART-timing, Puffer, USB, Linux kernel, wiringPi-/wiringSerial libs....).
Hilfreich wären wahrscheinlich wirklich nur Codes für beide Boards (Arduino Sketch C++11 und Raspi gcc/gpp), die jemand auch bei sich selber testen kann.
Am besten ntl, wenn jemand eine funktionierende Lösung bereits irgendwo (github?) gefunden haben sollte...

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.

Zitat:

---

Zitat von wkrug

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.

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

Zitat:

---

Zitat von 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

---

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.

Zitat:

---

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)

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

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