Für die serielle Kommunikation zwischen einem ATMega8 und der Software
auf einem Mobiltelefon erstelle ich gerade eine Reihe von (kurzen)
Telegrammen, die hin- und hergeschickt werden sollen. Da ich nicht weiß,
wie fehleranfällig diese Kommunikation werden kann (mir fehlt da die
praktische Erfahrung), habe ich überlegt, die Telegramme in Frames zu
packen, evtl. mit zusätzlicher Prüfsumme.

Recht verbreitet scheint ja folgendes Protokoll zu sein:

DLE STX Daten DLE ETX

wobei DLEs innerhalb der Daten ein weiteres DLE vorangestellt wird.

Folgendes Beispiel lässt mich jetzt seit einer halben Stunde grübeln:
In den Daten ist ein "DLE STX". Vor dem Senden wird es ergänzt zu "DLE
DLE STX" und dann abgeschickt. Wenn jetzt der Empfänger durch einen
blöden Zufall exakt im Moment nach dem ersten DLE "hinhört", sieht es
für ihn ja exakt aus wie eine Startkennung und das erste Paket ist
"Murks"? Oder?

Wie wird dieses Problem umgangen?

Abgesehen davon - ist ein Verpacken in Frames wirklich notwendig, wenn
die Telegramme feste Längen haben, recht kurz sind und der Datenverkehr
nur langsam und sporadisch stattfindet?

Danke für Tipps,
Florian

also ich habe schon viele verschiedene Dinge ausprobiert.
Bei meinem letzten "Projekt" war die kommunikation in einer Art Base64.
Das hieß 3Zeichen(24Bit) wurden auf 4Zeichen(32Bit) verteilt. Also pro
Byte(auf der seriellen Schnittstelle) nur 6Bit Nutzdaten. Diese 6Bit
haben einen Wertraum von 0-63 und wurden in der ASCII-Tabelle in den
hinteren Bereich gemappt. Ich habe als obset immer '0' genommen.
Der Vorteil ist jetzt das man 256-64=>192Steuerbytes hat die im
datenstrom niemals vorkommen. Dann kan man start,ende usw machen. Und
wenn man noch einen 2Datenstrom übertragen will dann mappt man den in
einen anderen Bereich. Und der Empfänger kann dann jedes Byte dem
richtigen Datenstrom wieder zuordnen da er weiß welcher Datenstrom wo in
der "ASCII-Tabelle" ist

Schau dir einfach mal das Protokoll vom LMX8920 Bluetooth-Chip an, das
nehmen wir immer.

Christian R. wrote:
> Schau dir einfach mal das Protokoll vom LMX8920 Bluetooth-Chip an, das
> nehmen wir immer.

Ich habe nur LMX9820 gefunden - Schreibfehler? Dessen Protokoll ist ja
ähnlich (STX Daten ETX), nur dass nicht erwähnt wird, was passiert, wenn
in den Nutzdaten auch ein STX oder ETX vorkommt?

@Ulrich: Klingt interessant und funktioniert sicher auch, ist mir aber
eigentlich zu viel Rechenaufwand für "das bisschen" Kommunikation, das
geplant ist.

Ja, 9820 natürlich. Sorry. Naja, du hast ja immer noch die Länge und die
Checksumme, muss dann natürlich alles zusammen passen. Erst dann ist der
Frame gültig. STX am Anfang, passende Länge, passende Checksumme und ETX
am Ende. Da müssten schon sehr sehr viele Zufälle passieren, dass da was
falsch wird. Man kann statt der einfachen Checksumme vielleicht besser
CRC16 über den ganzen Frame verwenden.