UART ohne CrLf?

[Che Guevara]

Hi,

ich hab auch vor einiger Zeit mein eigenes Protokoll entwickelt (mittlerweile gibts ein paar Verbesserungen, aber das wäre zuviel).
Es ging damals darum, ein Byte-Array von einem µC auf einen PC und andersrum zu übertragen. Da ich aber nichtmehr soviel Platz auf dem µC hatte, dachte ich mir, jedes einzelne Byte, das gespart werden kann, wird gespart!
Also hab ich mir die Situation rausgesucht, bei der die meisten Byte übertragen werden müssen und diese Byte-Anzahl als Norm-Länge verwendet.
Nun wird einfach immer ein Array dieser Länge (bei mir sind 132 Byte) übertragen, incl. Erkennungsbytes (damit der Empfänger weiß, was er mit den Daten machen soll).
Um niemals die Synchronisation zu verlieren, frage ich regelmäßig die Anzahl der bereits empfangenen Daten ab und kucke mir die Zeit an, seit der sich die Anzahl nicht mehr verändert hat. Wird eine bestimmte Zeit überschritten, gehe ich davon aus, dass Daten verlorengegangen sind und setze die Zähler zurück.
Das ganze läuft bei mir auf dem µC per DMA, so wird sogut wie keine Zeit für das Empfangen verschwendet.
Neuerdings schwirren mir wieder ein paar Verbesserungen im Kopf rum, welche ich demnächst wohl mal einpflegen werde.
Zum Beispiel will ich von der festen Array-Länge weg, da es in manchen Fällen vorkommen kann, dass nur 10% von den 132 Bytes effektiv genutzt werden. Das ist zwar grundsätzlich egal, sieht aber nicht schön aus.
Auch wäre eine Verbindung verschiedener µCs untereinander nicht schlecht, sodass am Anfang eines Arrays zuerst der Empfänger, dann der Sender, dann die Anzahl der folgenden Bytes und anschließend evtl. noch eine Checksumme integriert sind. Außerdem wäre es eine schicke Idee, die Daten sozusagen Seitenweise zu übertragen, heißt:
Eine Seite ist z.b. 10Bytes lang, in ihr befinden sich alle relevanten Informationen für die Übertragung ansich, ebenso wie die zu übertragenden Daten selbst. Unter den für die Übertragung relevanten Daten finden sich noch zwei Werte, die akt. Seitenzahl und die Gesamtseitenzahl. So liesen sich mit nur 10Bytes Speicher große Datenmengen übertragen.
Das Alles noch mit einem ACK abgerundet, fertig ist ein High-Level-Protokoll.

Es kommt aber eben darauf an, WAS du willst. Willst du Daten schnell austauschen, störsicher, große Datenmengen, etc ... ?

Gruß
Chris

[malthy]

Ich denke man braucht dedizierte Steuerzeichen (das heißt Zeichen, die nur Steuerzeichen sind). Ob das nun historische wie LF oder CR sind, ist dabei natürlich erstmal wurscht.

Um jetzt bei einem reinen binären Datenstrom noch zusätzlich Steuerzeichen zu gewinnen, arbeitet man mit einem Escape-Zeichen.
Gerne wird dafür der Wert 0x1B (ESC) verwendet.
Will man ein Steuerzeichen einfügen sendet man zuerst ein ESC und dann das Steuerzeichen.
Da der Wert 0x1B aber auch in den Daten vorkommen kann, sendet man in diesem Falle zwei mal ESC.

Die Logik verstehe ich nicht ganz. Wenn der Wert des Steuerzeichens auch in den Daten vorkommen kann, wie kann man dann ausschließen, dass es sich bei einem "scheinbaren" Steuerbefehl nicht zufällig um zwei Datenwerte handelt, die aussehen wie ein Steuerbefehl. Also konkret: wenn 0x1B einen Befehl markieren würde und ein 0x50 würde zB die Ausgabe von der folgenden drei Bytes (binary) auf einem LCD bedeuten, wie wäre der Fall davon zu unterscheiden, dass einfach zufällig dezimal 27 und 80 in einem anderen Zusammenhang aufgetaucht sind? Sich nämlich darauf zu verlassen, dass man immer sicher im Leseraster ist (was natürlich eine Lösung wäre), finde ich etwas gewagt ... Oder habe ich da irgendwo einen Denkfehler?

Ich hab auch schonmal ein Testprogramm in Bascom geschrieben, das nicht erst auf CrLf warten soll, sondern direkt das jeweils empfangene Byte aufnimmt, allerdings kam so keine Kommunikation zustande.

Hm, verstehe ich nicht ganz ... Ich verwende zwei Varianten. Die eine ist im Hauptloop - also quasi durch permanentes Polling - mit

If Ischarwaiting() = 1

jeweils zu gucken ob was im UART Puffer für mich zum abholen liegt, und falls ja, es mit

Uart_buf(uart_buf_i) = Inkey()

abzuholen. Meist schreibe ich die Zeichen in einen Ringpuffer, den ich dann nach jedem neuen Byte nach der Sequenz absuche, die das Ende der Nachricht signalisiert (bei mir idR CR/LF, das kann definitionsgemäß nicht als Datenwerte vorkommen). Wenn das Ende erreicht ist, wird eine Anzahl Bytes vorher im Ringpuffer, die der Nachrichtenlänge entspricht ausgewertet. Das heißt in meinem Falle von Hex (String) nach Dezimal (oder wie auch immer man die Variable dann interpretiert) umgewandelt. Meist schleppe ich noch einen 8 bit CRC Wert mit, der dann noch ausgewertet wird.

Die andere Varainte geht fast genauso, da verwende ich dann allerdings den urxc Interrupt, dh mit

On Urxc Rxc_isr

wird bei jedem neuen Zeichen die entsprechende ISR angesprungen, die dann die Auswertung wie eben gesagt macht.

Ist methodisch nicht sehr intellektuell und die Codierung ist auch "far from optimal", aber es funktioniert stumpf

Gruß
Malte

[Peter(TOO)]

Hallo,

Die Logik verstehe ich nicht ganz. Wenn der Wert des Steuerzeichens auch in den Daten vorkommen kann, wie kann man dann ausschließen, dass es sich bei einem "scheinbaren" Steuerbefehl nicht zufällig um zwei Datenwerte handelt, die aussehen wie ein Steuerbefehl. Also konkret: wenn 0x1B einen Befehl markieren würde und ein 0x50 würde zB die Ausgabe von der folgenden drei Bytes (binary) auf einem LCD bedeuten, wie wäre der Fall davon zu unterscheiden, dass einfach zufällig dezimal 27 und 80 in einem anderen Zusammenhang aufgetaucht sind? Sich nämlich darauf zu verlassen, dass man immer sicher im Leseraster ist (was natürlich eine Lösung wäre), finde ich etwas gewagt ... Oder habe ich da irgendwo einen Denkfehler?

Also: 27 80 als Daten wird als 27 27 80 gesendet.

Sobald 27 im Datenstrom auftaucht wird dieses beim Empfänger entfernt und das nächste Byte auch, weil dies der Befehl ist. Das folgende 80 ist dann der Befehl fürs LCD ...

Der Befehl 27 bedeutet dann, füge 27 in den Ausgabestrom ein.

In Pseudocode:

z1 = LeseZeichen()
If (z1 = 27) then
  Z2 = Lese Zeichen()
  if (z2 =  0) then .....
  if (z2 =  1) then .....
  if (z2 = ..) then .....
  if (z2 = ..) then .....
  if (z2 = 27) then SchreibeZeichen(27)
  if (z2 = ..) then .....
  if (z2 = 80) then SchreibeLCD()
  if (z2 = ..) then .....
else
  Schreibe Zeichen(z1)
endif

MfG Peter(TOO)

[Mxt]

Die Logik verstehe ich nicht ganz. Wenn der Wert des Steuerzeichens auch in den Daten vorkommen kann, wie kann man dann ausschließen, dass es sich bei einem "scheinbaren" Steuerbefehl nicht zufällig um zwei Datenwerte handelt, die aussehen wie ein Steuerbefehl.

Das ist genauso wie mit den Escape-Sequenzen in C. Man schreibt da ja z.B. "\r\n" für das CR LF. Wenn man einen Backslash schreiben will, schreibt man "Dies ist ein \\". Der Backslash ist hier das Escape Zeichen.

- - - Aktualisiert - - -

Hi,
Zum Beispiel will ich von der festen Array-Länge weg, da es in manchen Fällen vorkommen kann, dass nur 10% von den 132 Bytes effektiv genutzt werden. Das ist zwar grundsätzlich egal, sieht aber nicht schön aus.
Auch wäre eine Verbindung verschiedener µCs untereinander nicht schlecht, sodass am Anfang eines Arrays zuerst der Empfänger, dann der Sender, dann die Anzahl der folgenden Bytes und anschließend evtl. noch eine Checksumme integriert sind. Außerdem wäre es eine schicke Idee, die Daten sozusagen Seitenweise zu übertragen, heißt:
Eine Seite ist z.b. 10Bytes lang,

Was du da beschreibst, machen z.B. Automobil Steuergeräte häufig mit dem oben schon erwähnten abgewandelten ISO-TP.

Beispiel:

Es sollen die Daten 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 übertragen werden. In der Praxis natürlich viel mehr Daten, aber ich will nicht so viel schreiben.

Entweder die beteiligten Geräte wissen, welche maximale Paketgröße die jeweilige Gegenstelle verträgt, oder sie handeln das auch noch mit dem Protokoll aus. Das lasse ich hier aber mal weg.


Fall 1 ein großer Controller akzeptiert alle Daten auf einmal:
Der Sender sendet 0x02 0x01 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 yy. Das sind ein STX, die Framenummer 1, Datenzahl 8, die Daten und irgendeine Prüfsumme yy.
Der Empfänger bestätigt z.B. 0x02 0x01 0x06 yy . Das sind STX, Framenummer, ACK und Prüfsumme.


Fall 2 ein kleine Controller akzeptiert maximal 4 Datenbytes auf einmal:
Der Sender sendet 0x02 0x01 0x04 0x00 0x01 0x02 0x03 yy
Der Empfänger bestätigt mit 0x02 0x01 0x06 yy
Der Sender sendet 0x02 0x02 0x04 0x04 0x05 0x06 0x07 yy ( STX; 2. Frame; 4 Bytes; Daten; Prüfsumme )
Der Empfänger bestätigt mit 0x02 0x02 0x06 yy

Hoffe jetzt wird es etwas klarer.

[malthy]

Das ist genauso wie mit den Escape-Sequenzen in C

Gutes Stichwort Hast natürlich vollkommen Recht, das habe ich übersehen.

[Geistesblitz]

Danke für die guten Tipps, da hilft mir schon einiges von weiter.
Gedacht ist es dafür, wenn ich eine Reihe von (auch selbstgebauten) Servoreglern mit Sollwerten und/oder Parametern füttern will, vor allem die Sollwerte sollten da nicht zu lange zum Übertragen brauchen. Und wenn man sich einen kaskadierten Regelkreis aufbauen will, wo man Sollposition, Sollgeschwindigkeit und Sollstrom beispielsweise innerhalb 1ms oder kürzer übertragen will, muss man sich nunmal was einfallen lassen. Ich würde wohl in dem Fall Position mit 4 Bytes und die anderen beiden mit jeweils 2 Bytes angeben, dann noch bisschen drum herum und man kommt dann sicher auf 10-12 Bytes wenn das richtig knapp gehalten wird. Würde man die reinen Zeichen übertragen, wären da locker 20+ Bytes nötig. Um Übertragungsfehlern vorzubeugen, ist es dann wohl besser, die Baudrate nicht zu hoch zu wählen.

@Mxt: wofür steht eigentlich das STX-Byte? Ist das die Adresse des Zielcontrollers oder wie? Und wofür ist die Frame-Nummer? Würde die nicht irgendwann einfach überlaufen, wenn die immer nur hochzählt? Oder markiert die zusammenhängende Daten?

[schorsch_76]

Danke für die guten Tipps, da hilft mir schon einiges von weiter.
Gedacht ist es dafür, wenn ich eine Reihe von (auch selbstgebauten) Servoreglern mit Sollwerten und/oder Parametern füttern will, vor allem die Sollwerte sollten da nicht zu lange zum Übertragen brauchen. Und wenn man sich einen kaskadierten Regelkreis aufbauen will, wo man Sollposition, Sollgeschwindigkeit und Sollstrom beispielsweise innerhalb 1ms oder kürzer übertragen will, muss man sich nunmal was einfallen lassen. Ich würde wohl in dem Fall Position mit 4 Bytes und die anderen beiden mit jeweils 2 Bytes angeben, dann noch bisschen drum herum und man kommt dann sicher auf 10-12 Bytes wenn das richtig knapp gehalten wird. Würde man die reinen Zeichen übertragen, wären da locker 20+ Bytes nötig. Um Übertragungsfehlern vorzubeugen, ist es dann wohl besser, die Baudrate nicht zu hoch zu wählen.

@Mxt: wofür steht eigentlich das STX-Byte? Ist das die Adresse des Zielcontrollers oder wie? Und wofür ist die Frame-Nummer? Würde die nicht irgendwann einfach überlaufen, wenn die immer nur hochzählt? Oder markiert die zusammenhängende Daten?

Na da würde ich auf ein einfach umzusetzendes, aber standardisiertes Protokoll wie USS setzen.
http://cache.automation.siemens.com/...53_spez_00.pdf

Der Kern ist
STX LGE ADR xx xx xx BCC

1. Einleitung
Das USS

-Protokoll (Universelles-s
erielles-S
chnittstellen-Protokoll) definiert ein Zugriffsverfahren nach dem
Master-Slave-Prinzip für die Kommunikation über einen seriellen Bus. Als Untermenge ist darin auch die Punkt-
zu-Punkt-Verbindung eingeschlossen
Wesentliche Merkmale des USS

-Protokolls sind:
•
Unterstützung einer mehrpunktfähigen Kopplung, z. B. EIA RS 485-Hardware
•
Master-Slave-Zugriffsverfahren
•
Single Master-System
•
Maximal 32 Teilnehmer (max. 31 Slaves)
•
Einfacher, sicherer Telegrammrahmen
•
Einfach implementierbar
•
Wahlweiser Betrieb mit variablen oder festen Telegrammlängen.
Am Bus können ein Master und max. 31 Slaves angeschlossen werden. Die einzelnen Slaves werden vom
Master über ein Adreßzeichen im Telegramm angewählt. Ein Slave kann niemals von sich aus die
Sendeinitiative ergreifen, ein direkter Nachrichtenaustausch zwischen den einzelnen Slaves ist nicht möglich.
Die Kommunikation erfolgt im Halbduplex-Betrieb.
Die Masterfunktion kann nicht weitergegeben werden (Single-Master-System).
....
....
4.1. Datencodierung
Die Informationen sind wie folgt codiert:
•
STX (Start of Text): ASCII-Zeichen: 02 Hex
•
LGE (Telegrammlänge): 1 Byte, enthält die Telegrammlänge als Binärzahl,
siehe Abschnitt 4.2
•
ADR (Adreßbyte): 1 Byte, enthält die Slave-Adresse und den Telegrammtyp.
Binär codiert, siehe Abschnitt 4.3
•
Nutzzeichen: Je ein Byte, Inhalt auftragsabhängig
•
BCC: 1 Byte, Datensicherungszeichen (Block Check Charakter),
Bildungsgesetz, siehe Abschnitt 4.4

Das ganze setzt auf RS232 für PtP auf oder auf RS485 für mehrere Slaves und einen Master.

[Mxt]

@Mxt: wofür steht eigentlich das STX-Byte?

Es zeigt einfach den Beginn einer Übertragung an.

Möglicherweise hat der Empfänger ja den Anfang nicht mitgekriegt, weil er z.B. erst später seine Schnittstelle aufgemacht hat. Er schmeißt also erstmal alle Bytes weg, bis er auf ein STX trifft.

Dann sind wir wieder bei meinem ersten Beispiel aus meiner ersten Antwort. Man schickt einfach

STX ... beliebig viele Datenbytes ... ETX

und wenn in den Datenbytes der Wert von STX, ETX oder ESC auftaucht, dann sendet man zusätzlich noch ein ESC davor. Das ist auch das, was die anderen, wie Peter, meinen.


Die Sache mit den Frames kommt ins Spiel, wenn man große Datenmengen schicken will, aber Sender oder Empfänger nicht genug freien Speicher dafür haben. Dann müssen die Daten in Pakete zerlegt werden. Die Framenummer ist die Paketnummer. Man kann das auch beliebig erweitern, z.B. in eine "Dies ist Paket 1 von 4" Numerierung mit zwei Framenummerbytes.

ISO-TP kommt eigentlich vom CAN Bus. Da hat man das Problem, dass eine Message nur maximal 8 Datenbytes haben kann. Mit Hilfe der Framenummern kann man aber, aufgeteilt auf viele Botschaften, bis zu 4095 Bytes auf definierte Weise übertragen. Die Framenummer darf normalerweise nicht überlaufen, deshalb legt die Anzahl der verfügbaren Nummern die maximale Größe einer Übertragung fest.

Verwendet wird das z.B. bei den Daten auf dem Diagnosestecker des Autos:
http://de.wikipedia.org/wiki/Unified...ostic_Services
http://de.wikipedia.org/wiki/KWP2000

[malthy]

Hallo Peter(TOO),

ja, vielen Dank für die Erläuterung, nach dem Hinweis von Mxt auf die Escape Sequenzen ist mir dann ein Licht aufgegangen. Du hattest es vorher ja im Prinzip auch schon gesagt.

Gruß
Malte

[Peter(TOO)]

Hallo,

Die Sache mit den Frames kommt ins Spiel, wenn man große Datenmengen schicken will, aber Sender oder Empfänger nicht genug freien Speicher dafür haben. Dann müssen die Daten in Pakete zerlegt werden. Die Framenummer ist die Paketnummer. Man kann das auch beliebig erweitern, z.B. in eine "Dies ist Paket 1 von 4" Numerierung mit zwei Framenummerbytes.

Frames braucht man auch, wenn man Störungen hat und Datenblöcke deshalb erneut übertragen muss.

Besonders zu Zeiten der Modem-Übertragung über das Telefon, erzeugten die Gebührenimpulse gerne gestörte Daten

Du willst eine Datei übertragen, welche dafür 60 Sekunden benötigt.
Nun kommt aber alle 30s ein Gebührenimpuls.
Am Stück bekommst du die Datei nie rüber!
Wenn man jetzt die Datei in Blöcke zerlegt, welche z.B. jeweils 10s dauern, musst du 2 Blöcke doppelt übertragen um die Datei fehlerfrei zu übertragen.

MfG Peter(TOO)