Hallo Ralf,
Zitat Zitat von Feuerring Beitrag anzeigen
hatte ich auch schon drüber nachgedacht, der Datensatz hat ein definierten Anfang (#) und ein definiertes Ende chr(13),
also benötige ich keine Längen Angabe ... Länge ich auf 100 Zeichen begrenzt ...
Nunja, was ist mit den Antworten mit Text?
Das Start- und Ende-Zeichen kann auch gestört sein.
Eine logische Erweiterung für die Zukunft ist sicher die Möglichkeit die Firmware upzudaten.
Dann könnte es auch Module mit einem LCD geben. Ist immer praktisch wenn man da auch einen Text direkt rein schreiben kann.

Die Länge, möglichst als erstes Byte erspart dir eine Menge Ärger und Aufwand.
- Jetzt weisst du die Länge erst wenn du das Kommando dekodiert hast. Hast du ein älteres Modul, welches ein neues Kommando nicht kennt, hat es keine Ahnung wie lange die Meldung ist.
- Mit einer Länge darf ein "#" in einem Text enthalten sein.
- Mit der Länge am Anfang kann man eine Schlaufenzähler setzen und entsprechend viele Zeichen einlesen. Ist die Länge grösser als der Puffer, ignoriert man einfach alles bis zum nächsten chr(13)
- Ist der Zähler durch, MUSS das nächste Zeichen ein chr(13) sein, andernfalls ist die Meldung fehlerhaft.

Zitat Zitat von Feuerring Beitrag anzeigen
Als Prüfsumme alle Byte bis % aufaddieren und bei 255 Überlauf ... so habe ich immer als PS ein Byte ... sollte doch reichen ?!
Man sollte (Prüfsumme-1) übertragen. Falls eine Meldung mit lauter 0 übertragen wird, ist sonst die Prüfsumme auch 0. Bei einem Programmfehler (Absturz) kann das Restprogramm dauernd ein konstantes Byte senden. Ist dies 0 wertet die Prüfsummen-Prüfung dies als gültige Meldung. Hier hilft auch die Länge im Protokoll


Ich habe in meinem Leben eine Menge proprietäre Protokolle im Industriebereich entwickelt und eine Menge Treiber für bestehende Protokolle implementiert. Eine Prüfsumme ist unverzichtbar.
Eine Längenangabe hilft ungemein, wenn es um spätere Erweiterungen geht

Bei meinem Protokollen gab es, dank der Länge, immer auch Mechanismen um Daten direkt durch ein Gerät hindurch zu einem anderen Endpunkt zu schleifen. Damit konnte ich auf Geräten Interpreter für den Abgleich oder Service direkt ansprechen ohne an den dazwischen liegenden Geräten die Software anpassen zu müssen. Es gab einzig den Befehl "Daten weiterreichen" in allen Geräten.

Mit Start-Zeichen, Länge, Prüfsumme und End-Zeichen kann man einen sehr robusten Header bauen, welcher auch bei Störungen immer wieder auf die Füsse fällt ohne kompliziert zu werden. Zumindest die Header-Auswertung habe ich fast immer direkt im Empfänger-Interrupt gemacht. Meistens mit einer Statemachine. Mit dem letzten empfangenen Zeichen ist der eigentliche Inhalt schon dekodiert und geprüft. Fehlerhafte Meldungen werden einfach weggeworfen.


MfG Peter(TOO)