Vorgehensweise beim einlesen eines Telegramms variabler Länge

[peterfido]

Jo, stimmt. Binäre Daten in dem Sinne nutze ich so nicht. Da hängt das Protokoll dann vom anderen Baustein ab. Rein nach RS... werden Werte allerdings in Textform übertragen. Da braucht dann eine 200 halt 3 Bytes. Binäre Daten in dem Sinne sind dann was für 1 Wire, TWI und so. Bei komplett eigenen Projekten, wo ich beide Kommunikationspartner programmiere, wird alles so gemacht, wie ich es gepostet habe. "Binäre" Daten werden dann mit gesetztem 7.Bit übermittelt. So erkenne ich immer noch sicher den CHR(13) als Telegrammende. Bisher nur in meinem T300x Projekt (T-Hack) so gemacht.

[Wsk8]

http://de.wikipedia.org/wiki/Type-Length-Value
Am Schluss noch eine Checksum anfügen und schon hast du ein zu 99% sicheres und einfaches Protokoll.

mfg

[Andre_S]

Jo, stimmt. Binäre Daten in dem Sinne nutze ich so nicht. Da hängt das Protokoll dann vom anderen Baustein ab. Rein nach RS... werden Werte allerdings in Textform übertragen. Da braucht dann eine 200 halt 3 Bytes. Binäre Daten in dem Sinne sind dann was für 1 Wire, TWI und so. Bei komplett eigenen Projekten, wo ich beide Kommunikationspartner programmiere, wird alles so gemacht, wie ich es gepostet habe. "Binäre" Daten werden dann mit gesetztem 7.Bit übermittelt. So erkenne ich immer noch sicher den CHR(13) als Telegrammende. Bisher nur in meinem T300x Projekt (T-Hack) so gemacht.

Hallo,

ja,… das funktioniert in der Form dann auch!
Es gibt halt immer mehrere Wege zum Ziel…

Allerdings möchte ich gern noch ergänzen:
„Rein nach RS... werden Werte allerdings in Textform übertragen“…
Das würde ich nach meinen Erfahrungen nicht verallgemeinern. Ich habe mit verschiedenen Geräten zu tun, welche auf dieser Basis binär Daten übertragen und erwarten, da oft nur die elektrischen Schnittstellen aber nicht das Protokoll definiert wurde. Ein einfaches Beispiel wäre das M-Bus Protokoll, welches durch Pegelwandler auch auf RS4../RS2.. umgesetzt wird.
Bei allen wo ich wiederum Einfluss habe, nehme ich aus Gründen der Störsicherheit das komplette „Gedeck“ mit allen Sicherungen wie oben teilweise angedeutet.


Gruß André

[demmy]

Wow, da ist ja jetzt einiges an Information zusammengekommen.

Also es ist so, das mein Telegramm momentan rein Binär aufgesetzt ist, weil ich glaube das ich so die länge des Telegrammes und somit die Übertragungszeit drastisch reduzieren kann.
Das bringt aber auch den Nachteil mit sich, das es für mich schwierig ist ein Startbyte bzw. Endbyte zu definieren, da ja jedes Nutzdatenbyte theoretisch jeden beliebigen Wert zwischen 0 und 255 annehmen kann. Wie soll ich also verhindern das ein Nutzdatenbyte den Wert des Startbytes bzw. Endbytes annimmt und diese dann nicht mehr eindeutig sind?

Ich hatte mir überlegt eine Überwachung über die Zeit zu realisieren.

Und zwar soll das einlesen des Telegramms in zwei Stufen erfolgen.
Zunächst wird gewartet bis die Anzahl an Bytes für den Telegramkopf im Eingangspuffer sind, da der Kopf ja immer die selbe Länge hat.
Im zweiten Schritt wird dann der Rest des Telegramms anhand der variablen Länge eingelesen. Diese variable Länge ist ja inzwischen durch den Kopf bekannt.
Ist dann der Rest des Telegramms komplett eingegangen kann es weiter überprüft und verarbeitet werden (Richtige Teilnehmeradress, CRC usw.).

Nun zur zeitlichen Überwachung:
Parallel mit dem Eintreffen des ersten Bytes wird eine Zeitüberwachung angestartet.
Die Zeit der Überwachung ist abhängig von der Anzahl der Bytes die eingelesen werden sollen und wird nach dem Einlesen des Kopfes nochmals korrigiert wenn die Länge der variablen Daten feststeht.
Ist nun die Zeit abgelaufen und das Telegramm nicht vollständig eingegangen oder es stehen Daten über die erwartete Länge hinaus im Eingangspuffer.
Weiß man schon mal, das was schiefgelaufen ist und der Puffer wird geleert. Somit steht er wieder für den Empfang eines neuen Telegramms bereit.
Ist das Telegramm korrekt empfangen wird die Zeitüberwachung gestoppt.

Im Fehlerfall hat ja der Master keine Rückmeldung erhalten, somit muss er irgendwann sein Telegramm wiederholen und erneut versuchen den Slave zu erreichen um die Kommunikation wieder aufzunehemen.

Was haltet Ihr davon?

[peterfido]

Kann man machen. Würde ich aber nicht so lösen. Was ist so zeitkritisch, wenn es im Fehlerfall eh wiederholt werden kann? Der Master muss sich bei mehreren Slaves dann auch eine Menge merken, um es nochmal zu senden, wenn keine Antwort kam. Stehen da evtl. schon neue Daten an, braucht es weitere Puffer. Was lässt Dich an einer zuverlässigen Übertragung zweifeln?

Wieviele Slaves gibt es, was sollen die so machen und wieviel neue Daten kommen in welchem Zeitraum zusammen? Das würde ich alles berücksichtigen und darauf das Protokoll aufbauen. Die Baudrate wähle ich anhand der Verbindungsqualität und Leitunsglänge.

[demmy]

Naja eine Fehlerbehandlung muss ja in irgendeiner Form rein!? Das mit der Überwachungszeit ist rein nur als Fehlerbehandlung gedacht um im Fehlerfall wieder auf einen grünen Zweig zu kommen, also den Telegrammempfang zu bereinigen.

Und wenn ein Fehler im Buszyklus auftritt muss das doch auch irgendwie behandelt werden!? Oder feuert ihr einfach alle Telegramme nacheinander einfach raus und wartet gar nicht nach jedem anpollen eines Slaves auf dessen Antwort?

Ich meine man muss doch immer mal damit rechnen das ein Telegramm mal zerstört wurde durch Einstreuungen oder was weis ich!

Also Ziel soll es sein, einen Ausgangsdatenspeicher, welcher im Master permanent aktualisiert wird an die Slaves zu verteilen und umgedreht die aktuellsten Daten abzuholen um einen Eingangsdatenspeicher zu füllen. Die Daten stehen also so und so die ganze Zeit in der Steuerung zur Verfügung und werden dann nur nochmal in der zu diesem Zeitpunkt aktuellsten Form gesendet.