Frage 1: Framing oder Länge
Soll das Ende der Nachricht durch eine 'End of Frame' Kontrollzeichen
oder nach einer beim Beginn übertragenen Länge erkannt werden ? Meiner
Meinung nach total egal. In beiden Fällen kann die Nachricht dynamisch
und ohne puffern empfangen und gesendet werden (obwohl ich das nicht
empfehlen würde ...).

Mir persönlich gefällt der Framing-Ansatz besser.


Frage 2: Maximale Länge der Nachrichten
In beiden obigen Fällen (und bei uCs mit wenig Speicher sowieso) brauchen
wir eine maximal mögliche Nachrichtenlänge. Ich würde mal 128 Byte vorschlagen.


Frage 3: Codierung von Kontrollzeichen
Welche Möglichkeiten gibt es ?

Ein Kontrollzeichen mit Bytestuffing:
X => Kontrollzeichen, XX => Datenzeichen X
Problem: Nur Startzeichen kann eindeutig erkannt werden,
alle anderen Zeichen könnten mehrdeutig sein.

Escapezeichen für alles:
XY => Escapezeichen mit 'Parameterzeichen'
abhängig von Y ist XY entweder Daten- oder KOntrollzeichen
Immer eindeutig, aber Kontrollzeichen immer 2 Bytes lang.

Mischform:
A, B, C => direkte Kontrollzeichen
XY => Escapesequenz, entweder Daten (A, B, C oder Kontrollzeichen)
Genau ein Kontrollzeichen(Escapezeichen) zur Darstellung der
Datenbytes. Alle anderen Kontrollzeichen 1 Byte. Eindeutig.

Da wir im Vergleich zu den Steuerzeichen wohl eher kurze Nachrichten
haben fallen reine Escapezeichen wohl aus. Ich schlage deshalb die
Mischform vor. Ich glaube jetzt erstmal nicht, daß wir eine ganze
Gruppe an Kontrollzeichen definieren müssen, ist mir aber letztendlich
egal. In der Mischform ganz einfach (3 bit, 7 Kontrollzeichen, 1 Escapezeichen):
0xA0 - 0xA6 sind Kontrollzeichen
0xA7 ist ein Escapezeichen, vom nachfolgenden Datenbyte werden 0x08 abgezogen.
Datenbytes 0xA0 - 0XA7 werden als 0XA8 - 0XAF übertragen.

Am Anfang sollte eigentlich erstmal zwei Escapezeichen reichen:
0xA0=StartFrame und 0XA1=StopFrame.


Frage 4: Protokollinitiierung
Die Idee, das genaue Protokoll in einer Initiierungsphase festzulegen
finde ich eigentlich gut. Das ganze würde ich aber noch etwas schieben
bis wenigstens ein mögliches Protokoll implementiert ist. Dieses erste
Protokoll würde ich auch erstmal ganz einfach gestalten: ohne Handshake,
Acks, CRCs, bidirektional und ohne timeouts. Ausserdem würde ich bei
dem 'Handshake' nicht darauf vertrauen, daß es einen 'Slave' und einen
'Master' gibt, sondern beide können versuchen, die Verbindung aufzubauen.
Eventuell will ich ja auch mal zwei uCs oder zwei Rechner verbinden.


@NumberFive: Click unten auf die Uhr, dann wirst du wieder Benachrichtigt.

@PicNick: Little/Big Endian Probleme würde ich sie erstmal an den
Anwender (Schicht 4) weiterschieben. Dann können wir als Konvention
immer noch network order für große Zahlen verwenden.

ciao,
Ragnar