[AVR] Serielle Protokolle: STX, ETX usw.

[Florian H. (trapperjohn)]

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

[Ulrich (Gast)]

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

[Christian R. (supachris)]

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

[Florian H. (trapperjohn)]

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.

[Christian R. (supachris)]

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.