Hallo zusammen, ich möchte mir selbst ein kleines Protokoll für die Kommunikation über RS485 schreiben. Nun war mein Aufbau wie folgt geplant: Startzeichen Bsp: 0x40 (@ Zeichen) Adressbyte Bsp: 0x02 Länge der Datenbytes: Bsp: 0x10 Datenbytes und CRC (optional) Jetzt stell ich mir allerdings die Frage, wie ich verhindern kann, dass 0x40 in der Adresse oder den Daten vorkommt. Bei Homematic wird aus 0xFD als Startzeichen 0xFC und 0x7D. Nur, stimmt ja dann der Frame überhaupt nicht mehr. Also bräuchte ich ja für alle Bytes noch ein zweites zum Ausweichen. Wenn 0x40 dann allerdings nicht in den anderen Bytes vorkommt, müsste ich das jeweils 2. Byte zum Ausweichen ja leer senden. Aber auch das geht ja nicht, da 0x00 ja NULL entsprich und damit der Terminierung von Strings oder? Wäre sehr dankbar für ein paar Tipps Gruß Tobias
da brauchst du wohl escape sequenzen oder machst es wie zB bei DMX und sendest einen "frame error" den du als "start of frame" benutzt
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.
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'.
Ich habe bei Protokollen bei denen alle Zeichen im Datenstrom vorkommen können mal so eine Konstuktion gesehen: Aus dem Zeichen 0x40 wird im Datenstrom 0x1B 0x00 Willst du das Zeichen 0x1B im Datenstrom senden wird daraus 0x1B 0x01. Bei der Lösung die ich gesehen hatte wurde die Telegrammlänge nicht verändert. Die Empfangsroutine hat die Umwandlung selber Rückgängig gemacht, 0x40 oder 0x1B in den Empfangsbuffer geschrieben und den Zeichenzähler nur um eins erhöht. Eine andere Lösung hat zwischen Telegrammen eine gewisse Pause erwartet, die es zwischen den Zeichen eines Telegrammes nicht geben durfte. nur ein Zeichen nach einer Pause konnte ein Startzeichen sein.
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?
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 :)
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.