2Byte Wert "aufteilen" und auslesen

(19.11.2013 17:26 )jg schrieb:  Prinzipiell musst du die Schnittstelle öffnen, in einer Schleife andauernd die anliegenden Bytes auslesen und solange zu einem String zusammensetzen und analysieren (Stichwort Schieberegister), bis du auf das Synchronisationsmuster "3x 0x0" triffst. Jetzt muss das nächste Byte im Stream untersucht werden. Ist es ungleich 0x0, dann ist es das erste Byte einer Kanal-Info, falls es dagegen 0x0 lautet, dann war es das letzte Byte eines Trennblocks und das darauffolgende Byte muss das erste Byte einer Kanal-Info sein.

Das ist aber noch nicht alles. Wenn man mitten in einen laufenden Datenstrom hineinhört, dann beginnt das Lesen nicht nur mit dem womöglich falschem Byte. Das Lesen kann sogar mitten ein einem der seriell übertragenen Bytes beginnen. Man muß also zu allererst so lange 1-Byte-weise Lesen, bis kein "Rahmenfehler" mehr auftritt.
Man sollte auch mal darauf hinweisen, dass Daten über die seriellen Schnitstelle normalerweise im ASCII-Format übertragen werden. Man braucht dann allerdings für jedes Datenbyte einen String von 2 Byte Länge, also z.B. für den Wert "255" den zweistelligen Srring "FF". Dafür fällt aber der ganze Shit mit Synchronisation-Bytes und Parsen weg. Ein Datensatz wird dann einfach mit dem Zeilenendezeichen abgeschlossen, das genügt zur Synchronisation.
In hier in diesem Fall bringt die direkte Übertragung von Datenbytes sogar überhaupt nichts: Es werden jetzt pro Datensatz 5 Bytes übertragen (3 Synchronisationsbytes und 2 Datenbytes). Eine ASCII-Übertragung würde auch nur 5 Bytes brauchen (1 Byte Kanal-Nr, 3 Bytes Daten, 1 Bytes Zeilenende)
Bei der Direkt-Byte-Übertragung gibt es immer das Problem, dass das Synchronisationsmuster nicht in den Daten vorkommen darf. Das könnte man hier dadurch erreichen, dass man die KanalNr. "0" nicht verwendet. Ansonsten könnte es passieren, dass bei gleichzeitigem Dateninhalt = 0 mehr als 3 Byte den Wert 0 haben und die Start-Markierung nicht eindeutig ist.
Das "Experimental-Board" hast Du doch selbst programmiert, nehme ich an. Was hindert Dich daran, auf ASCII-Format umzusteigen?

Edit: Irrtum von mir. Auch wenn die KanalNr. 0 vermieden wird, sind Mehrdeutigkeiten bei der Startsynchronisation nicht ausgeschlossen. Wenn die letzten 16bits eines Datensatzes null sind, hat man mit dem nachfolgenden Datensatz 4 hintereinanderliegende Null-Bytes. (Und das erste Parkinsonsche Gesetz lautet ja: "Alles, was schief gehen kann, geht schief.")
Unter diesen Umständen kann man nur hoffen, dass die Übertragung der Datensätze nicht unmittelbar hintereinander erfolgt, sondern immer mit Pausen zwischendrin. Die Erkennung einer Pause wäre dann gewissemassen das Synchronisationszeichen für einen neuen Datensatz, und die Synchronisationsbytes brauchte man eigentlich überhaupt nicht mehr.