Serial verschluckt Daten ?

[TERWI]

Warum so garstig ?
Diese Zeile steht am Ende der Leseroutine.
Und sie ist optional und nur zur Sicherheit, wie ich schrieb.
Sei sicher: Ich habe diese Zeile auch schon auskommentiert und das Verhalten ist das gleiche.
Daran liegt es offensichtlich nicht.

[dsyleixa]

hallo,
so einen riesigen langen Code wird kaum jemand debuggen können/wollen.

Kürze doch bitte schrittweise alles zurück bis auf die minimalste kompilier- und lauffähige Version, wo nur die fragliche Serial-Ausgabe drin ist und alles andere rausgeschmissen wurde (Variablen, Hilfsroutinen, if-Blöcke, switch/breaks, auskommentierte Programmzeilen), was nicht unbedingt relevant ist, aber dann immer noch den Fehler reproduziert (sog. MCVE Code Version).
50-80 Programmzeilen müssten dafür ausreichen.

[TERWI]

@ dsyleixa
Na ... sooo lang ist der Code ja nun auch nicht. Sind ja letztendlich nur 2 Funktionen.
Sei versichert, das habe ich schon mehr als 2x gemacht - auch die ganze Struktur (wieder) umgestellt wie im zuvor beschriebenen "Basisbeispiel".
Es bleibt bei diesem Problem...

Und: Eben grade beim ausdünnen (Raus mit den Debug-Prints u.a.) ist mir das erst aufgefallen, dass da irgendwie bytes verschwinden !
Mit (oder eben mit delay in der Loop) läuft das tadellos.

[uwefed]

Mit (oder eben mit delay in der Loop) läuft das tadellos.

Genau das ist der Gedankenfehler.

Die Bits trudeln so langsam ein und Du erwartest sie alle sofort vollzählig im Eingangsbuffer der Schnittstelle.
Mit einem langsamen Programm (durch die delays) funktioniert das dann schon.

Der Sketch muß die Bytes holen wenn sie ankommen und sofort analysieren. Wenn keine ankommen dann kontrolliert er halt solange bis wieder was da ist.

Grüße Uwe 

[Serenifly]

Ein Byte braucht 1 / Baudrate * 10 Sekunden (1 Startbit, 8 Datenbits, 1 Stopbit). Das sind bei 9600 Baud ca. 1ms. Selbst bei sehr hohen Baudraten ist die serielle Schnittstelle noch deutlich langsamer als der Prozessor

[dsyleixa]

@ dsyleixa
Na ... sooo lang ist der Code ja nun auch nicht. Sind ja letztendlich nur 2 Funktionen.
Sei versichert, das habe ich schon mehr als 2x gemacht - auch die ganze Struktur (wieder) umgestellt wie im zuvor beschriebenen "Basisbeispiel".
Es bleibt bei diesem Problem...
Und: Eben grade beim ausdünnen (Raus mit den Debug-Prints u.a.) ist mir das erst aufgefallen, dass da irgendwie bytes verschwinden !
Mit (oder eben mit delay in der Loop) läuft das tadellos.

es geht nicht um das, was du selber alles ausprobiert hast, sondern um einen nachvollziehbaren, minimalen, aber kompletten und sofort kompilierbaren Code, der den Fehler sofort reproduziert, und  den wir uns hier ansehen und ggf. auch downloaden und selber austesten können. Ohne alles dafür nicht unbedingt notwendige Zeugs. Höchstens (!) minimal (!) länger als 50 Zeilen.
Also poste bitte mal diese MCVE Code Version.

[TERWI]

@ Serenifly
Ich nutze i.d.R. 57600 - nur Testweise hatte ich mal auf 9600 gestellt. Gleiches Prob.
Als "delay" sind zwar die Serial.pint's in der Leseroutine, aber das delay() selbst steht in der Loop.
Anmerkung dazu siehe unten.

@ Uwe
Ich warte ja schon auf z.Zt. min. 14 Zeichen im Puffer (11x Header, 3x Marker).
Das liest die Routine ja auch anständig aus - ggf auch mit angehängten Daten-bytes.

@ dsyleixa
Hier ist eben das Prob, dass das nicht ein 0815-Ding ist, sondern eben etwas komplexer und eigentlich auch nur mit einem "Master" arbeitet, welcher eine Telegramm (Header mit Markern) sendet, diese wieder empfängt und auch wieder prüft.
Wer das richtig testen will, braucht schon meine kleines "DINO-CCOM-Tool" für den PC.
Wenn das anwenderfreundlicher geworden ist, poste ich das hier auch noch.
Hier ist etwas mehr Vorstellungskraft nötig ...

Zum möglichen Gedankenfehler:
Mich beschleicht eher mehr das Gefühl, das CMD_Check ( & CMD_Echo) in der Loop viel zu schnell wieder aufgerufen wird.
D.h., Serial macht alles asynchron und blockt nichts (?!), Routine ist fertig und der nächste Aufruf kommt, bevor der Puffer richtig leer ist
Mit delay(20) klappt das gut - mit weniger (<= 10) verhaspelt sich das wieder.

[Serenifly]

Ich nutze i.d.R. 57600 - nur Testweise hatte ich mal auf 9600 gestellt. Gleiches Prob.

Dann dauert ein Byte immer noch ca. 170µs!

[combie]

und blockt nichts (?!)

Die FiFos der Seriellen, eines UNO, sind 64 Byte groß.
Danach blockiert das senden.
Das lesen verliert dann Bytes

Aber das kannst du auch alles selber herausfinden.
Denn schließlich liegt der Quellcode auf deinem PC.

[TERWI]

Das mit den Puffer-Limits ist mir bekannt.
Aktuell sendet der PC jedoch nur 11 Header-, 3 Daten- und 3 Marker-bytes. Also ges. 17. Da läuft nix über.
Z. Zt. werden zurück gesendet 11 Header- und 6 Marker-bytes zzgl bei
- bei IDXREPLY=1: 12 bytes (2 Werte, DINO_ID_STRING) als Kennung bei SetUp/Reset
- bei IDXREPLY=3: 3 bytes wie empfangen zur Kontrolle
Ges. 17 bzw 29 bytes. Auch da läuft nix über.

Da PC-Proggie wartet nach jeder Übertragung auf Antwort und verifiziert diese.
Erneutes senden wird mit einem Timeout von 3 Sek. geblockt, so das der Dino nicht gestresst wird.
An zu viel Daten und/oder zeitkritischen Aufrufen sollte es also nicht liegen.

CMD_Echo scheint einwandfrei zu sein.
Nur CMD_Check hat nach wie vor offensichtlich ein Problem, Daten richtig zu lesen.
Bisher keine Anhung warum. Immer wenn ich das mit Serial.print irgendwie/-wo debugge, ist alles OK - wie eben mit dem zusätzlichen delay.

Zugegebener Weise ässt sich das in dieser Form schlecht test ....
... aber hat denn niemand in ähnlicher Form schon mal so einen Effekt gehabt ?

[uwefed]

... aber hat denn niemand in ähnlicher Form schon mal so einen Effekt gehabt ?

Ja, hatte ich, bei einem Indexüberlauf eine Arrays.
Grüße Uwe

[ElEspanol]

Die Bytefolge ließe sich aus jedem Terminalprogramm heraus senden und empfangen.
Wenn du deinen Sketch auf das Minimum schrumpfst, was das Verhalten noch produziert, springt einen (vielleicht nicht dich) der Fehler oft förmlich an.
Wenn du weiter eindampfst, das der Fehler nicht mehr auftritt, hast du einen Ansatz zum suchen.

[dsyleixa]

... aber hat denn niemand in ähnlicher Form schon mal so einen Effekt gehabt ?

ich verschicke bis zu 1024 Bytes lange messages zwischen Arduino und PC (Borland C++ Builder) über Serial und das Borland-COMM-Widget hin und her und habe nie Probleme mit verschluckten Daten.
UART-clock: Serial.begin(115200).
Ich schreibe (sende) am Arduino verschieden lange cstring-Arrays ( char cbuf[1024], wird aber nicht immer maximal gefüllt ) per Serial.println (Abschluss erfolgt dadurch immer per  Message-Ende-Marker  '\n'  );
lesen  (empfangen) von unterschiedlich langen Messages (<1024 bytes) immer byte-weise  (vor Weiterverarbeiting am Arduino zunächst per String = String class, am PC als C++ AnsiString) bis  Message-Ende-Marker '\n' erreicht ist (Messages werden auch vom PC-Programm damit abgeschlossen).
Weiterverarbeitung der empfangenen (Roh-) strings dann nach Umwandlung in cstrings (ebenfalls char cbuf[1024]).
Lesen/schreiben ist hier auch nicht durch Serial()-Puffer-Limits eingeschränkt.

[combie]

Ach Leute...
Jetzt lasst unseren TERWI doch noch ein bisschen gären....

Im Moment ist er (scheinbar?) noch nicht bereit das Problem ernsthaft anzugehen.
Er möchte lieber noch etwas jammern.
Bisher agiert er eher Problem orientiert, als Lösungsorientiert.

Als wenn versucht wird ein technisches Problem mit sozialen Lösungsstrategien anzugehen.
Und das wird bekanntlich nichts.
Denn die Technik kann ihre Einstellung nicht ändern.
Und es macht auch wenig Sinn sie zu besprechen.

ich verschicke ..
Ich schreibe ...

Ja, du bist schon ein toller Hecht!
Ohne jeden Zweifel....

Ich möchte dein Glück/Erfolg nicht schmälern, aber wie soll dein Sieg hier helfen?

[dsyleixa]

Jetzt lasst unseren TERWI doch noch ein bisschen gären....
Er möchte lieber noch etwas jammern.
...
Ja, du bist schon ein toller Hecht!
Ohne jeden Zweifel....

und du bist schon ein toller Troll (aber das kenne ich ja schon von früheren posts von dir, z.B. im Topic C++ für Anfänger und dem zum Wii Nunchuk)!
Hauptsache, die Leute runtermachen, gell?

edit,
ok, jetzt hast du nacheditiert...
es geht auch nicht um einen von dir  ironisch-hochnäsig titulierten "Sieg", sondern um die Frage des TO, ob noch jemand sonst derartige Probleme beobachtet hat, und mein Rezept, wie ich sogar deutlich längere Messages zwischen PC und Arduino hin- und herschicken konnte, ohne dass Daten "verschluckt" werden oder wurden, entgegen dem Statement

Die FiFos der Seriellen, eines UNO, sind 64 Byte groß. Danach blockiert das senden. Das lesen verliert dann Bytes.