RS485 Protokoll im Eigenbau

ist eigentlich egal wenn das Startzeichen in den Daten vorkommt. Du 
musst ja nicht auf jedes Startzeichen neu synchronisieren.

Wenn die Übertragung anfängt, wartest du auf der 1. Startzeichen. Dann 
liest du das packet ein ohne weiter Startzeichen zu beachten. Wenn die 
CRC nicht stimmt, dann ist das packet ungültig.

Das nächste Packet beginnt wieder mit einen Startzeichen, spätestens 
nach ein paar packet ist wieder alles ok.

Hallo,

nimm für Steuerfunktionen die im ASCII-Code dafür vorgesehenen Zeichen 
im Bereich 00h - 1Fh. Da gibt es schon vordefiniert z.B: STX - Start of 
Text, ETX - End of Text usw. Für die Daten verwende die Buchstaben- und 
Ziffern-Codes, so gibt es keine Doppeldeutigkeiten.

Gruß. Tom

TomA. schrieb:
> Für die Daten verwende die Buchstaben- und
> Ziffern-Codes, so gibt es keine Doppeldeutigkeiten.

dafür ist es aber eine recht dumme Verschwendung von Bandbreite.

Ich versteh kein Wort. Was macht dieser Frame-Error?

Peter II schrieb:
> TomA. schrieb:
>> Für die Daten verwende die Buchstaben- und
>> Ziffern-Codes, so gibt es keine Doppeldeutigkeiten.
>
> dafür ist es aber eine recht dumme Verschwendung von Bandbreite.

Ja das denke ich auch.
Ich möchte die Datenbytes halt recht klein halten

Peter II schrieb:
> ist eigentlich egal wenn das Startzeichen in den Daten vorkommt.
> Du
> musst ja nicht auf jedes Startzeichen neu synchronisieren.
>
> Wenn die Übertragung anfängt, wartest du auf der 1. Startzeichen. Dann
> liest du das packet ein ohne weiter Startzeichen zu beachten. Wenn die
> CRC nicht stimmt, dann ist das packet ungültig.
>
> Das nächste Packet beginnt wieder mit einen Startzeichen, spätestens
> nach ein paar packet ist wieder alles ok.

Dann muss ich aber an allen Slaves jedes Paket komplett auslesen oder?
Egal ob der µC damit im Nachhinein was macht oder nicht.

Tobias S. schrieb:
> Dann muss ich aber an allen Slaves jedes Paket komplett auslesen oder?
> Egal ob der µC damit im Nachhinein was macht oder nicht.

ja, aber das ist doch meist eh der fall.

Tobias S. schrieb:
>> dafür ist es aber eine recht dumme Verschwendung von Bandbreite.
>
> Ja das denke ich auch.
> Ich möchte die Datenbytes halt recht klein halten

Welche Baudrate soll es denn werden?
Erst dann kann man sehen, ob es eine Verschwendung von Bandbreite gibt 
und ob das unbedingt dumm ist.

Sieh Dir mal den Inhalt einer Intel .hex-Datei an. Da wird auch viel 
Speicherplatz 'verschwendet'. Keiner wird das als dumm bezeichnen.

Tobias S. schrieb:
> Dann muss ich aber an allen Slaves jedes Paket komplett auslesen oder?
> Egal ob der µC damit im Nachhinein was macht oder nicht.

Stichwort: Multiprozessor-Modus, dummerweise wird dabei allerdings 
Bandbreite durch ein 9. Bit 'verschwendet'.

Jürgen D. schrieb:
> Aus dem Zeichen 0x40 wird im Datenstrom 0x1B 0x00
> Willst du das Zeichen 0x1B im Datenstrom senden wird daraus 0x1B 0x01.

Und mal den Gedanken weiter gedacht: was passiert, wenn im Datenstrom 
wirklich 0x1B 0x00 vorkommt? Dann macht dein Empfänger ein 0x40 draus. 
Und bei 0x1B 0x01 macht er 0x1B draus. Und beides wäre beim Vorkommen im 
Datenstrom eine falsche Interpretation. Oder wird das dann auch 
irgendwie abgefangen?

Jürgen D. schrieb:
> Im Datenstrom kann keine 0x1B 0x00 vorkommen, das wird als 0x1B
> 0x01
> 0x00 gesendet.
> Daher ja auch das Ersetzen einen normalen 0x1B in 0x1B 0x01 :)

Ah, jetzt ist der Groschen gefallen, alles klar :-))
Danke!

http://de.wikipedia.org/wiki/High-Level_Data_Link_Control#Blocktypen

Geht aber leider nicht sinnvoll bei UART.