UART Übertragung Ende feststellen

Indem du 1 Zeichen definierst, welches in den Daten nicht vorkommen 
darf. Sollte dieses Byte tatsächlich in den Daten vorkommen, musst du es 
soweit verändern, dass
* der Empfänger feststellen kann, dass es entsprechend modifiziert wurde
* die Veränderung rückgängig machen kann.

Du könntest zb folgendes vereinbaren.

In den Daten selber darf ein 0x04 nicht vorkommen. Sollte es doch 
vorkommen, dann schickst du statt dessen ein 0x05. Um jetzt die 0x04 von 
0x05 unterscheiden zu können, schickst du nach einem 0x05 noch ein 
zusätzliches Byte, welches beim Empfänger klarstellt ob das empfangene 
0x05 tatsächlich ein 0x05 war oder ob es sich um ein 0x04 gehandelt hat.

zb
du willst übertragn

  0x34 0x56 0x45 0x34

da kein 0x04 da drinnen vorkommt, überträgst du

  0x34 0x56 0x45 0x34 0x04

das 0x04 zeigt dem Empfänger an: Ende der Nachricht.

Jetzt willst du übertragen


  0x08 0x04 0x45 0x34

da kommt ein 0x04 vor. Das darf nicht sein. Du ersetzt die 0x04 durch 
0x05 0x01 und überträgst

  0x08 0x05 0x01 0x45 0x34 0x04

in den Daten kommt kein 0x04 vor, der Empfänger weiß, das er nach einem 
0x05 sich noch das nächste Byte ansehen muss, und wenn dieses 0x01 ist, 
dann muss die Sequenz 0x05 0x01 in den Daten nach dem Empfang durch 0x04 
ersetzt werden.

Du willst übertragen

  0x08 0x04 0x45 0x05

wieder: die 0x04 werden durch die Sequenz 0x05 0x01 ersetzt. Zusätzlich 
muss auch 0x05 durch 0x05 0x02 ersetzt werden. Du überträgst daher

  0x08 0x05 0x01 0x45 0x05 0x02 0x04

Die 0x04 zeigen wieder das Ende an. Der Empfänger ersetzt 0x05 0x01 
durch 0x04 und er ersetzt 0x05 0x02 durch ein einzelnes 0x05. Er erhält 
daher als übertragene Daten

  0x08 0x04 0x45 0x05

welches auffallend den zu übertragenden Daten entspricht.

BetonMicha schrieb:
> Ok das hört sich schonmal gut an.
>
> Mir fällt gerade noch ein, ich könnte weiterhin das Byte 0x04 als Ende
> definieren und bei meinen Kommandos zusätzlich auf länge prüfen. Und bei
> meinen Daten ebenfalls das 0x04 benutzen, da es dort nicht vorkommt.
> Also 0x04 erst als Endbyte interpretieren wenn Pos >= 6 ist (5 Byte für
> Kommando abziehen). Dann müssten meine Daten nur mindestens 5 Byte lang
> sein, was aber kein Problem darstellt.

Nicht zuviel künsteln.
Die Ersetzung kannst du ganz tiefen unten in deiner Aufrufhierarchie 
sowohl beim Sender als auch beim Empfänger erledigen. Darüber liegende 
Schichten müssen davon überhaupt nichts mitkriegen.

Moby schrieb:
> Hallo, wenn man nicht bestimmte Bytes für irgendwelche Kennungen
> verbrauchen will bzw. für beliebige Bytefolgen installiert man am besten
> einen Timer der solange neu gesetzt wird wie Bytes eintreffen und bei
> Ablauf das Übertragungsende anzeigt!

Timer ja.
Aber um eine fehlerhafte Übertragun zu erkenne, die aus irgendeinem 
Grund mitten drinn abgerissen ist.

Zur Erkennung des regulären Übertragungsendes und als Aussage, dass 
jetzt ein Datensatz komplett angekommen ist, taugt das nichts.

Karl Heinz Buchegger schrieb:
> [...]
> Zur Erkennung des regulären Übertragungsendes und als Aussage, dass
> jetzt ein Datensatz komplett angekommen ist, taugt das nichts.

Naja, je nach Sende-Logik schon... ;)

Volker

Volker Schulz schrieb:
> Karl Heinz Buchegger schrieb:
>> [...]
>> Zur Erkennung des regulären Übertragungsendes und als Aussage, dass
>> jetzt ein Datensatz komplett angekommen ist, taugt das nichts.
>
> Naja, je nach Sende-Logik schon... ;)

Bis dann jemand kommt und den UART Stecker zieht. Oder die Funkstrecke 
gestört wird oder ....

Ausserdem ist es lästig, wenn man nach einer Message erst mal eine 
Zwangspause einlegen muss bis die nächste Message beginnen darf.

Ein Timeout kann man benutzen um festzustellen ob die Gegenstelle noch 
da ist. Aber zur Synchronisierung ist es kein wirklich taugliches 
Mittel, weil du nie weißt, ob die Pause jetzt gewollt ist, oder nur 
deshalb entstanden ist, weil die Gegenstelle nicht mehr da ist (aus 
welchem Grund auch immer). Nich umsonst sagt man beim Funk 'Over' wenn 
man der Gegenstelle signalisieren will, dass sie jetzt quatschen kann 
und legt nicht einfach nur eine Pause ein.

Karl Heinz Buchegger schrieb:
> Volker Schulz schrieb:
>> Karl Heinz Buchegger schrieb:
>>> [...]
>>> Zur Erkennung des regulären Übertragungsendes und als Aussage, dass
>>> jetzt ein Datensatz komplett angekommen ist, taugt das nichts.
>>
>> Naja, je nach Sende-Logik schon... ;)
>
> Bis dann jemand kommt und den UART Stecker zieht. Oder die Funkstrecke
> gestört wird oder ....

Bei gestoerter Funkstrecke oder gerade erst wieder eingestecktem 
UART-Stecker hast Du im Zweifel bei Terminierung via Zeichen das gleiche 
Problem. Die "Zeitmethode" wird selbst im sicherheitskritischen 
militaerischen Bereich angewendet, natuerlich nicht ohne weitere 
Sicherheitsmechanismen wie einem 8-Bit-XOR als Checksumme und/oder 
Plausibilitaespruefung ueber mehrere Datensaetze.

Volker

Karl Heinz Buchegger schrieb:
> Ein Timeout kann man benutzen um festzustellen ob die Gegenstelle noch
> da ist. Aber zur Synchronisierung ist es kein wirklich taugliches
> Mittel, weil du nie weißt, ob die Pause jetzt gewollt ist, oder nur
> deshalb entstanden ist, weil die Gegenstelle nicht mehr da ist (aus
> welchem Grund auch immer). Nich umsonst sagt man beim Funk 'Over' wenn
> man der Gegenstelle signalisieren will, dass sie jetzt quatschen kann
> und legt nicht einfach nur eine Pause ein.

Deswegen schrieb ich ja "je nach Sende-Logik". Wir haben durchaus 
Messmodule, die ihre Werte alle X Millisekunden ueber die RS232 spucken. 
Wo liegt da das Problem?

Volker

Volker Schulz schrieb:
> Karl Heinz Buchegger schrieb:
>> Volker Schulz schrieb:
>>> Karl Heinz Buchegger schrieb:
>>>> [...]
>>>> Zur Erkennung des regulären Übertragungsendes und als Aussage, dass
>>>> jetzt ein Datensatz komplett angekommen ist, taugt das nichts.
>>>
>>> Naja, je nach Sende-Logik schon... ;)
>>
>> Bis dann jemand kommt und den UART Stecker zieht. Oder die Funkstrecke
>> gestört wird oder ....
>
> Bei gestoerter Funkstrecke oder gerade erst wieder eingestecktem
> UART-Stecker hast Du im Zweifel bei Terminierung via Zeichen das gleiche
> Problem.

Nein hab ich nicht.
Nach einem Übertragungsfehler wird alles bis zum Startbyte verworfen, 
wenn es ein Startbyte gibt. Gibt es kein dezidiertes Startbyte, dann 
wird alles bis zum nächsten Endbyte als ungültig verworfen. Und da die 
eindeutig sind, kann man die im (nicht gestörte Übertragung 
vorausgesetzt) Datenstrom immer eindeutig erkennen.
Egal ob Startbyte oder Endbyte, auf jeden Fall kann ich die Übertragung 
danach mit 100% Sicherheit wieder synchronisieren.

Hatten wir letztens erst wieder.
Die Abfrage eines entfernten Servers ist mit einem Timeout gesichert. 
Beim Abholen der Daten sind wir in einen Timeout gelaufen, der als 
solcher auch korrekt als Timeout Fehler in der Übertragung 
diagnostiziert wurde. Wenn es nach euch geht, hätten wir mit dem Timeout 
die Übertragung als abgeschlossen betrachten müssen und sagen sollen 
"das wars, mehr Daten liegen am Server nicht vor". In Wirklichkeit hat 
der Server einfach nur ein wenig länger zum Bereitstellen der Daten 
gebraucht.

Das man einen Datensatz noch zusätzlich ein Schema aufprägen kann, 
welches man testen kann, ist auch klar. Selbstverständlich verlässt sich 
kein Mensch darauf, dass das Ausbleiben eines Timeout eine saubere 
Übertragung garantiert.

Karl Heinz Buchegger schrieb:
> [...]
> Nach einem Übertragungsfehler wird alles bis zum Startbyte verworfen,
> wenn es ein Startbyte gibt. Gibt es kein dezidiertes Startbyte, dann
> wird alles bis zum nächsten Endbyte als ungültig verworfen. [...]

Gleiches in meinem Falle. Ist das letzte Byte nicht das XOR der 
vorherigen Bytes, wird der Datensatz verworfen und es geht nach der 
Pause erfolgreich weiter. Nun kann es natuerlich passieren dass das XOR 
rein zufaellig auf die invaliden Daten passt. Aber auch bei Deiner Idee 
koennte zufaellig ein Startbyte gesendet werden, das keins war aber nur 
als solches zu erkennen ist, weil das vorherige (verlorene) Byte die 
Maske war.


> Hatten wir letztens erst wieder.
> Die Abfrage eines entfernten Servers ist mit einem Timeout gesichert.
> Beim Abholen der Daten sind wir in einen Timeout gelaufen, der als
> solcher auch korrekt als Timeout Fehler in der Übertragung
> diagnostiziert wurde. Wenn es nach euch geht, hätten wir mit dem Timeout
> die Übertragung als abgeschlossen betrachten müssen und sagen sollen
> "das wars, mehr Daten liegen am Server nicht vor". In Wirklichkeit hat
> der Server einfach nur ein wenig länger zum Bereitstellen der Daten
> gebraucht.

Deswegen schrieb ich ja explizit "je nach Sende-Logik". Wenn auch 
waehrend der regulaeren Uebertragung Pausen von gleicher Laenge wie bei 
der Trennpause auftreten koennen, macht das natuerlich wenig Sinn.

Volker

Volker Schulz schrieb:
> Karl Heinz Buchegger schrieb:
>> [...]
>> Nach einem Übertragungsfehler wird alles bis zum Startbyte verworfen,
>> wenn es ein Startbyte gibt. Gibt es kein dezidiertes Startbyte, dann
>> wird alles bis zum nächsten Endbyte als ungültig verworfen. [...]
>
> Gleiches in meinem Falle. Ist das letzte Byte nicht das XOR der
> vorherigen Bytes, wird der Datensatz verworfen und es geht nach der
> Pause erfolgreich weiter. Nun kann es natuerlich passieren dass das XOR
> rein zufaellig auf die invaliden Daten passt. Aber auch bei Deiner Idee
> koennte zufaellig ein Startbyte gesendet werden, das keins war aber nur
> als solches zu erkennen ist, weil das vorherige (verlorene) Byte die
> Maske war.

Ich sag nicht, dass im Datensatz keine Check-Mechanismen vorhanden sind.
Die spielen eine Ebene höher.
Hier geht es um die Aufteilung eines Datenstroms in Datenframes. Und 
zwar im allgemeinen Fall.

Wenn ich einen Sensor aufs AUg gedrückt bekomme, der Pausen macht kann 
ich eh nichts dagegen tun. Wenn ich das aber steuern kann, werd ich 
einen Teufel tun und mir künstliche Übertragungspausen ins System holen.

Karl Heinz Buchegger schrieb:
> Wenn ich einen Sensor aufs AUg gedrückt bekomme, der Pausen macht kann
> ich eh nichts dagegen tun. Wenn ich das aber steuern kann, werd ich
> einen Teufel tun und mir künstliche Übertragungspausen ins System holen.

Also in 99% der Spezifikationen von Messsonden (die ich auf meinen 
Schreibtisch bekomme) ist die Wiederholungsrate von vornherein 
festgelegt und fuehrt somit automatisch zu Zwangspausen... In einem 
solchen Falle kann man die durchaus sinnvoll nutzen...

Volker

Wenn man schon die ASCII-Tabelle für die Ende-Kennung nimmt, dann muß 
man auch die ASCII-Tabelle für die restlichen Daten verweden. Also: 
Datenübertragung als ASCII-Zeichen.

Der Binärwert 0000_0100 wird also mit Endekennung nicht als 0x04 0x04 
übertragen, sondern als die drei "Buchstaben": '0', '4', 0x04

Der Binärwert 1100_0110 wäre dann 'B', '6', 0x04

Volker Schulz schrieb:
> Ist das letzte Byte nicht das XOR der vorherigen Bytes, wird der
> Datensatz verworfen und es geht nach der Pause erfolgreich weiter.
Auch die Prüfsumme müsste dann logischerweise als zwei Zeichen und nicht 
als ein Byte versendet werden.

... schrieb:
> Erst kommt die Länge des Datensatzes (bei mir 1 Byte), dann eine Kennung
> für die Art der übertragenen Daten, danach die Daten und dann noch
> CR/LF, damit ich mir das notfalls mit einem Editor ansehen kann.
Aber was macht das Terminal, wenn vor dem CR/LF schon Sonderzeichen 
kommen?
Ergo: wenn ich mit dem Terminalprogramm mitlesen möchte (und das ist 
eine sehr schöne Sache), muss ich mich auf "richtige" ASCII-Zeichen (von 
0..127) beschränken.

Moby schrieb:
> Hallo, wenn man nicht bestimmte Bytes für irgendwelche Kennungen
> verbrauchen will bzw. für beliebige Bytefolgen
Dann nimmt man ein Protokoll, dass sowas abhandeln kann. Man sollte sich 
aber immer vergegenwärtigen, für WAS die verwendete Schnittstelle 
ursprünglich mal ausgelegt war. Und das war bei RS232 eben NICHT eine 
binäre Dtenübertragung. Deshalb bietet diese Schnttstlle von sich aus 
(abgesehen vom Parity) keine Fehlererkennungsmechanismen.
> installiert man am besten einen Timer der solange neu gesetzt wird
> wie Bytes eintreffen und bei Ablauf das Übertragungsende anzeigt!
Kreativ: eine künstliche Protokollverzögerung...

Lothar Miller schrieb:
> Wenn man schon die ASCII-Tabelle für die Ende-Kennung nimmt, dann muß
> man auch die ASCII-Tabelle für die restlichen Daten verweden. Also:
> Datenübertragung als ASCII-Zeichen.
>
> Der Binärwert 0000_0100 wird also mit Endekennung nicht als 0x04 0x04
> übertragen, sondern als die drei "Buchstaben": '0', '4', 0x04
>
> Der Binärwert 1100_0110 wäre dann 'B', '6', 0x04

Muss man nicht. Kann man natuerlich. Im NMEA-Protokoll ist fuer die 
Checksumme "HexASCII" vorgesehen (also das, was Du meinst), fuer die 
Nutzdaten ist die dezimale Schreibweise vorgesehen (getrennt durch 
Kommata) und es gibt definierte Start- und Stop-Bytes. Und, zu allem 
Ueberfluss, zwischen zwei Paketen (NICHT Saetzen) noch eine Zwangspause. 
;)

> ... schrieb:
>> Erst kommt die Länge des Datensatzes (bei mir 1 Byte), dann eine Kennung
>> für die Art der übertragenen Daten, danach die Daten und dann noch
>> CR/LF, damit ich mir das notfalls mit einem Editor ansehen kann.
> Aber was macht das Terminal, wenn vor dem CR/LF schon Sonderzeichen
> kommen?
> Ergo: wenn ich mit dem Terminalprogramm mitlesen möchte (und das ist
> eine sehr schöne Sache), muss ich mich auf "richtige" ASCII-Zeichen (von
> 0..127) beschränken.

Naja, wie toll kann ein Mensch im Terminalprogramm denn 0x00 mitlesen? 
CR ist auch nicht unbedigt zu erkennen wenn es alleine rumschwirrt (bzw. 
ist dann im Zweifel gar nichts mehr zu erkennen, weil ein Satz den 
vorherigen ueberschreibt). Man muesste sich dann schon auf's 
Alphanumerische beschraenken, den Rest kann man zum Steuern / Separieren 
benutzen.


> [...] Und das war bei RS232 eben NICHT eine
> binäre Datenübertragung. [...]

Sondern?


Volker

Kopfschüttel

BTW: Bei NMEA dient die Pause nicht zur Satzendeerkennung. NMEA schickt 
da ganz banal ein \n als Satzende.
Die Pause ist willkommen um in dieser Zeit den Satz auszuwerten und 
dabei den Anfang des nächsten Satzes nicht zu verpassen.

Aber was red ich mir den Mund fusselig. Sagt mir einfach in welchen 
Produkten mit externem UART Anschluss euer Code drinnen ist, damit ich 
einen großen Bogen da drumm machen kann.

Und was an einer Timer Lösung einfach sein soll, gegenüber 6 Zeilen Code 
in den Sende/Empfangs Interrupts, die für die darüberliegenden Schichten 
völlig transparent auf der Übertragung ein oder zwei Bytewerte 
freischaufeln, entzieht sich meinem Verständnis.

Wenn ich, wie im Falle von zugekauften Sensoren, nicht auskann sieht es 
anders aus. Aber wenn ich es in der Hand habe Sender und Empfänger so 
zugestalten, wie ich will, werd ich mir doch nicht so eine Krücke ins 
Boot holen.

Karl Heinz Buchegger schrieb:
> Kopfschüttel
>
> BTW: Bei NMEA dient die Pause nicht zur Satzendeerkennung. NMEA schickt
> da ganz banal ein \n als Satzende.

Eigentlich ist es \r\n...


> Die Pause ist willkommen um in dieser Zeit den Satz auszuwerten und
> dabei den Anfang des nächsten Satzes nicht zu verpassen.

Die Pause findet man, wie oben erwaehnt, natuerlich nicht nach jedem 
Satz. Und ich habe ja auch nicht geschrieben dass diese Pause zum 
Erkennen verschiedener Pakete da ist, sondern dass sie schlichtweg 
aufgrund der Wiederholungsfrequenz gegeben ist.


> Und was an einer Timer Lösung einfach sein soll, gegenüber 6 Zeilen Code
> in den Sende/Empfangs Interrupts, die für die darüberliegenden Schichten
> völlig transparent auf der Übertragung ein oder zwei Bytewerte
> freischaufeln, entzieht sich meinem Verständnis.

Das "Einfache" verlagert sich in diesem Falle ganz klar auf den Sender. 
Die Timer-Empfangs-Logik mit Timer duerfte aber auch nicht viel mehr 
Codezeilen verschlingen.

Fuer den Fall dass wir uns missverstanden haben: Ich will hier 
keinesfalls die Pausen-Erkennung als tollste Loesung fuer jedes Problem 
bewerben (ganz im Gegenteil sogar), sie ist aber dennoch eine valide 
Option mit eigener Berechtigung. Und ist nicht nur in Theorie oder 
Bastelkeller anzutreffen.


> Wenn ich, wie im Falle von zugekauften Sensoren, nicht auskann sieht es
> anders aus. Aber wenn ich es in der Hand habe Sender und Empfänger so
> zugestalten, wie ich will, werd ich mir doch nicht so eine Krücke ins
> Boot holen.

Am bequemsten ist es natuerlich, die Daten "menschenlesbar", 
alphanumerisch zu uebertragen und Sonderzeichen als Steuer-Bytes zu 
verwenden. Wuerde ich wenn moeglich (gerade auch bei eigenen Projekten) 
auch so machen. Nun ist bequem nicht immer zwangslaeufig auch das 
sinnvollste. Und moeglich ist es eben auch nicht immer. ;)


Volker\r\n