Serial verschluckt Daten ?

[combie]

Haben wir bis jetzt testbaren Code gesehen?
Die Chance, den Fehler zu reproduzieren?

Überhaupt den winzigsten Ansatz, wo es klemmt?
Nein!

Und wir sind jetzt bei 30 Beiträgen.

Entweder setzt jetzt langsam mal eine andere Denkrichtung ein, oder das wird hier gar nichts mehr!



----------------

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?

Es gibt Leute, die verklemmen sich irgendwie mit ihren Gedanken.

Und wenn erst ein Troll kommen muss, um ihnen das zu sagen, ja, dann bin ich wohl ein Troll.
Dann bin ich auch gerne ein Troll.
Und es ist mir gelinge gesagt vollkommen egal, was die Zielperson davon hält.
Die hat sowieso die Kröte zu schlucken, dass Sie auf einem völlig falschen Ast sitzt.
Auf der falschen Baustelle buddelt.

Und dann gibts da noch die Leute, welche lieber sauer, auf andere sind, als die eigene Einstellung zu prüfen.
Die sollen ja schließlich auch ihren Spaß haben!
Matthäus 7

Übrigens:
Sind es nicht meistens eher die Trolle, welche in allem und jedem erst mal einen Troll erkennen?

[dsyleixa]

Code: [Select]

Sind es nicht meistens eher die Trolle, welche in allem und jedem erst mal einen Troll erkennen?
weiß ich nicht, ich zumindest trolle schließlich nicht rum und mache keine Leute und auch nicht ihre Ideen, ihre Fragen oder ihren Kenntnisstand mies.

[combie]

ich zumindest trolle schließlich nicht rum

Darüber kann man durchaus geteilter Meinung sein! 

[TERWI]

@ combie
Wenn du hier nicht (mangels Vorstellungskraft wegen fehlendem Komplett-Code inkl. Sende-Tool) nicht sinvoll beitragen kannst oder möchtest, dann spar dir bitte deine nutzlosen Kommentare. Danke.

@ ElEspanol
Ich habe schon so weit möglich abgespeckt, so dass der Sinn & Funktion erhalten bleibt.
Ich muss mich wiederholen:
Das funktioniert ja so weit 1A, so lange ich ein (paar) Serial.print's als Debug drin lasse oder eben ein delay(x) in die Loop packe, was ja nicht sonderlich sinnig ist...
Kommentiere ich alles Debug-ähnliche raus, verschwinden irgendwie bytes. Mir völlig unerklärlich. Es lässt sich ohne Debug auch nicht wirklich nachvollziehen, wo. (.... und wenn drin, dann geht's ja ...)

@ dsyleixa
Ich schicke das vom PC aus via Borland Delphi. Das Tool/die Routinen darin sind anderweitig getest und laufen sicher.
Auf dem Dino wollte ich keinen großen Empangspuffer bauen, weil ich den kleinen Speicher später noch für andere Programmsachen brauche - also  minimalst dirket lesen und sofort in Aktion umsetzen.

Vielleicht noch mal zum Sinn dieser Aktion:
Ich möchte in einer Routine möglichst verschieden lange Telegramme (der Header) zur allgemeinen Steuerung schicken und dazu dann auch. verschieden lange Datenpakete.
Das ganze sollte möglichst sicher sein, auch wenn die Daten durch Übertragungstörungen (soll auch mal OTA angewendet werden) die Form/Anzahl verlieren/verändern.
Deshalb eben ein MARKER-Start, der den Anfang des Headers definiert. Ein MARKER-Daten, der definiert das Ende des Headers und Begin der Daten anzeigt. Und ein MARKER-End, welcher Das Ende der Übermittlung anzeigt.
Passt alles geht das gleiche Telegramm (nicht immer mit allen/gleichen oder angeforderten Daten) zur Kontrolle zurück.
Passt irgendwie ein Marker nicht an seiner erwarteten Position, ist die ganze Nachricht hinfällig und es findet keine Aktion im DINO statt.
Und/oder wenn der Header ggf. ungültig und kommt kein ECHO, sendet der Master nochmal.

[TERWI]

Mittlerweile habe ich den Code ein wenig umgebaut.
Zunächst hatte ich mich auf Aussagen im Forum verlassen, keine blockenden Serial-Funktionen zu nutzen und mich an Robin2's Beispiel gehalten.
Nun hab ich eben diese "bösen" und vermeintlich nicht so doll funzen Blockierfunktionen genommen - macht den Code etwas schlanker und (was am wichtigsten ist !!!) :
ES FUNKTIONIERT endlich.
Auch ohne irgendwelche Debugs oder delay()'s. und mit weniger Globalen.
Für "wie es geht" hab ich entsprechende Kommentare eingefügt.
Hier mal nur die Lese-routine neu:

Code: [Select]


void CMD_check()
{
  if (Serial.available() < 15) return;    // minimum telegram-size

  int num      = 0;
  int ofs      = 0;
  for (int i = 0; i < HEADERSIZE; i++) header[i] = 0;  // clear header

  if (!Serial.find(MARKERSTART))                            // MARKER found ?
    Serial.println("CMD_CKECK - MARKER-Start NOT found !"); // NO
  else                                                      // YES
  {
    header[IDXHEADLEN] = Serial.read();                    // read real Header-length
    num = Serial.readBytes(header + 1, header[IDXHEADLEN] - 1);  // read rest of Header at header[1] !!!
    if (num != (header[IDXHEADLEN] - 1))                  // did we read the wanted number of bytes ?
      Serial.println("CMD_CKECK - HEADER-Size doesn't match !");   // NO
    else                                                           // YES
    {
      if (!Serial.find(MARKERDATA))                             // MARKER found ?
        Serial.println("CMD_CKECK - MARKER-Data NOT found !");  // NO
      else                                                      // YES
      {
        for (int i = 1; i <= header[IDXDATABLK]; i++)   // read all data-blocks
        {
          num = Serial.readBytes(data + ofs, header[IDXDATALEN]);  // read 1 data-block
          if (num != header[IDXDATALEN])   // did we read the wanted number of bytes ?
          {                                // NO
            header[IDXDATALEN] = 0;        // set val in Header to 0 / no length
            header[IDXDATABLK] = 0;        // set val in Header to 0 / no blocks
            break;                         // stop the loop
          }
          ofs = ofs + header[IDXDATABLK];  // increment adress to write to
        }
        if (!Serial.find(MARKEREND))                             // MARKER found ?
          Serial.println("CMD_CKECK - MARKER-End NOT found !");  // NO
        else                                                     // YES
        {
          CMD_eval();  // evaluate the command and/or data
          CMD_echo();  // send echo to master
        }
      }
    }
  }
  while (Serial.available() > 0) Serial.read();  // clear RX-buffer for safety
}


[dsyleixa]

@ dsyleixa
Ich schicke das vom PC aus via Borland Delphi. Das Tool/die Routinen darin sind anderweitig getest und laufen sicher.
Auf dem Dino wollte ich keinen großen Empangspuffer bauen, weil ich den kleinen Speicher später noch für andere Programmsachen brauche - also  minimalst dirket lesen und sofort in Aktion umsetzen.

Vielleicht noch mal zum Sinn dieser Aktion:
Ich möchte in einer Routine möglichst verschieden lange Telegramme (der Header) zur allgemeinen Steuerung schicken und dazu dann auch. verschieden lange Datenpakete.
Das ganze sollte möglichst sicher sein, auch wenn die Daten durch Übertragungstörungen (soll auch mal OTA angewendet werden) die Form/Anzahl verlieren/verändern.
Deshalb eben ein MARKER-Start, der den Anfang des Headers definiert. Ein MARKER-Daten, der definiert das Ende des Headers und Begin der Daten anzeigt. Und ein MARKER-End, welcher Das Ende der Übermittlung anzeigt.
Passt alles geht das gleiche Telegramm (nicht immer mit allen/gleichen oder angeforderten Daten) zur Kontrolle zurück.
Passt irgendwie ein Marker nicht an seiner erwarteten Position, ist die ganze Nachricht hinfällig und es findet keine Aktion im DINO statt.
Und/oder wenn der Header ggf. ungültig und kommt eine ECHO, sendet der Master nochmal.

Genau aus diesem Grunde mache ich es ja auch, nur offenbar mir einem anderen Puffer, anderen Daten und einem anderen Protokoll und ohne dass Daten verlorengehen.

Aber jetzt gerade las ich ja, dass es endlich funktioniert.
Glückwunsch!