Forum: Mikrocontroller und Digitale Elektronik Regeln für SYNC-Bytes (UART)?


von Detlev T. (detlevt)


Lesenswert?

Hallo Leute,

wenn man mehrere Bytes als Frame über eine serielle Schnittstelle (UART) 
schickt, muss man ja irgendwann einmal wissen, dass ein Byte das erste 
eines Frames ist. Dazu sendet man ein SYNC-Byte.

Von Vorteil wäre es natürlich, wenn dieser Wert sonst nie vorkommen 
kann, ist aber meistens nicht der Fall. Also testet man nach dem Empfang 
eines (möglichen) SYNC-Bytes, ob der Rest plausibel dazu passt, z.B. die 
Prüfsumme stimmt. Soweit alles klar.

Meine Frage: Gibt es aus mathematischen Theorien oder Erfahrung 
besonders günstige Werte? Oder ist der Wert hier weitgehend egal, von 
pathologischen Werten wie 0x00 und 0xff einmal abgesehen. (Bitte 
beachten: Es handelt sich um einen Byte- und nicht einen Bitstrom!) Wie 
wäre es z.B. mit 0xA7 (binär 10100111)?

Vielen Dank für eure Hinweise.

Gruß, Detlev Tietjen

von Falk B. (falk)


Lesenswert?

@  Detlev T. (detlevt)

>Meine Frage: Gibt es aus mathematischen Theorien oder Erfahrung
>besonders günstige Werte?

Schau dir die gängigen Päambeln von Ethernet und anderen Sachen an.

>Oder ist der Wert hier weitgehend egal, von
>pathologischen Werten wie 0x00 und 0xff einmal abgesehen.

Kommt auf das Medium an. Bei RS232 ist es egal, bei Ethernet schon 
weniger.

>beachten: Es handelt sich um einen Byte- und nicht einen Bitstrom!) Wie
>wäre es z.B. mit 0xA7 (binär 10100111)?

Kann man machen.

MFG
Falk

von hdd (Gast)


Lesenswert?

Ohne zu Wissen, was du an Daten schickst kann man da gar keine Aussage 
drüber machen welche Bytes am wenigsten oft vorkommen.

Was spricht für dich gegen 0x00 oder 0xFF, sind Bytes wie jedes andere?
Falls du z.B. reines ASCII verschickst, könntest du auch 0xFF nehmen.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Neben der byteweisen Synchronisation sollte man auch unbedingt die 
bitweise im Auge behalten, d.h. wenn ein dicht gepackter Zeichenstrom 
auftritt und der Empfänger aus dem Tritt gerät, muss er nicht nur die 
Zeichen voneinander unterscheiden können, sondern auch Stop-/Startbit 
von Datenbits.

Aus diesem Grunde bieten sich bei 8N1 als Trennzeichen wirklich 0x00 
oder 0xff an, da sie eine Folge von mindestens neun gleichen Bits 
bewirken und somit auch der Zeichenanfang eindeutig erkennbar wird.

Es gibt einige Protokolle, insbesondere auf RS-485-Basis, die die 
Blocktrennung durch Pausen bewerkstelligen. Dies ist jedoch sehr 
fehlerträchtig, insbesondere wenn das zeitliche Verhalten der 
Kommunikationsteilnehmer nicht exakt definiert ist, z.B. bei PCs.

Man sollte vermeiden, dass das Trennzeichen auch noch an anderer Stelle 
im Datenstrom auftreten kann, um Mehrdeutigkeiten wirksam zu verhindern. 
Entweder verzichtet man in seinem Alphabet auf das Zeichen oder führt 
eine Art Escape-Mechanismus durch. Man sollte aber tunlichst vermeiden, 
z.B. das Zeichen 0x00 durch <escapezeichen> 0x00 darzustellen, sondern 
lieber ein Bit invertieren. Ich empfehle dringend einen Blick auf 
Protokolle wie z.B. (byteweises) HDLC oder PPP (Point to point 
protocol).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.