Protokoll RS485

W

Werner Brennecke

Guest
Hallo,

ich möchte mehrere Controller ( AT Mega 32) mittels
RS485 verbinden. Einzig das übertragungsprotokoll
macht mir noch Kopfzerbrechen.
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?

Ich bin für jeden Tip / Link dankbar.

Werner
 
Hallo Werner,

"Werner Brennecke" <werner.brennecke@gmx.de> schrieb in
news:9635564678233.NC-1.61.werner.brennecke@news.individual.de:

ich möchte mehrere Controller ( AT Mega 32) mittels
RS485 verbinden. Einzig das übertragungsprotokoll
macht mir noch Kopfzerbrechen.
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?
Die Fehlererkennung kann man per LRC machen. Je nach
Geschwindigkeitsanforderung bin ich ein Freund von "Echo"-
Protokollen, bei denen der Empfänger die Nachricht als Quittung
zuruecksendet.
Die Start/Stop-Erkennung kann man entweder per Timeout machen, also
wenn einige Zeit Ruhe ist, kommt ein neues Paket, oder man
definiert ein nicht auftretendes Telegramm, das alle Empfaenger
synchronisiert.
Wofuer und wie schnell soll denn das Protokoll sein?

Gruss, Kurt

--
PiN - Präsenz im Netz GITmbH
Kurt Harders
http://www.pin-gmbh.com
 
Hallo Werner,

Möchtest Du ein Master-/Slave-System aufbauen oder sind alle Teilnehmer
gleichberechtigt?
Welche Störungen muß Du beherrschen (einzelne Bitfehler, Ausfall der
Übertragung über mehrere ms, Empfang von Zufallsdaten, ...)?
Wie sieht Deine Topologie (Ausdehnung, Baudrate, Struktur, ...) aus?
Hast Du eine zeitkritische Übertragung oder legst Du mehr Wert auf eine
sichere Datenübertragung?

Gruß
Martin

"Werner Brennecke" <werner.brennecke@gmx.de> schrieb im Newsbeitrag
news:9635564678233.NC-1.61.werner.brennecke@news.individual.de...
Hallo,

ich möchte mehrere Controller ( AT Mega 32) mittels
RS485 verbinden. Einzig das übertragungsprotokoll
macht mir noch Kopfzerbrechen.
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?

Ich bin für jeden Tip / Link dankbar.

Werner
 
Am Wed, 19 May 2004 09:51:05 +0200, "Martin Konopka" schrieb:

erst mal danke :) Ich gebe zu, das meine Informationen zu wenig waren.
Was ich versuchen möchte, ist ein kleines "Hausnetz" aufzubauen.
d.h. Themperatur, Luftdruck u.s.w. messen, Rollos verfahren, Aussenlicht
schalten,
eventuell Alarmanlage?

Die Übertragungsgeschwindigkeit ist mir relativ egal. 110 Bps sollten
reichen,
nur habe ich noch kein Konzept einer _sicheren_ Übertragung.

Mit dem I2C Bus kenne ich mich schon gut aus, nur ist dieser für diese
Anwendung überhaupt nicht geeignet.

Ausserdem wollte ich mir einer 2 Draht Verbindung auskommen. Ehrgeiz
halt :))



Möchtest Du ein Master-/Slave-System aufbauen oder sind alle
Teilnehmer gleichberechtigt?
Welche Störungen muß Du beherrschen (einzelne Bitfehler, Ausfall der
Übertragung über mehrere ms, Empfang von Zufallsdaten, ...)? Wie
sieht Deine Topologie (Ausdehnung, Baudrate, Struktur, ...) aus?
Hast Du eine zeitkritische Übertragung oder legst Du mehr Wert auf
eine sichere Datenübertragung?
 
Am 19 May 2004 07:49:45 GMT, Kurt Harders schrieb:

Die Fehlererkennung kann man per LRC machen. Je nach
Geschwindigkeitsanforderung bin ich ein Freund von "Echo"-
Protokollen, bei denen der Empfänger die Nachricht als Quittung
zuruecksendet.
Ging mir auch durch den Kopf, nur verliere ich hier mindestens 50%
Bandbreite.

Die Start/Stop-Erkennung kann man entweder per Timeout machen, also
wenn einige Zeit Ruhe ist, kommt ein neues Paket, oder man
definiert ein nicht auftretendes Telegramm, das alle Empfaenger
synchronisiert.
Beim Timeout habe ich die Befürchtung, das 2 Sender doch gleichzeitig
senden.
Eine Art CSMA/CD hier aufzubauen ist noch ein wenig aufwändig.

Wofuer und wie schnell soll denn das Protokoll sein?
Nicht schnell, vielleicht 110 Bps.

danke
Werner
 
On 19 May 2004 19:58:32 +0100, "Werner Brennecke"
<werner.brennecke@gmx.de> wrote:

Am 19 May 2004 07:49:45 GMT, Kurt Harders schrieb:

Die Fehlererkennung kann man per LRC machen. Je nach
Geschwindigkeitsanforderung bin ich ein Freund von "Echo"-
Protokollen, bei denen der Empfänger die Nachricht als Quittung
zuruecksendet.

Ging mir auch durch den Kopf, nur verliere ich hier mindestens 50%
Bandbreite.
Nein, Bandbreite verlierst du nicht. Du verlierst allerhöchstens
Übertragungsrate. Obwohl letzterer Begriff auch nicht 100% korrekt
ist.

--
Laurent
 
Werner Brennecke wrote:
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?
http://www.p-net.dk/download/schul_konz.pdf
vielleicht?
 
ich möchte mehrere Controller ( AT Mega 32) mittels
RS485 verbinden. Einzig das übertragungsprotokoll
macht mir noch Kopfzerbrechen.
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?
schau mal im Dez 03 ... da gabs hier schon ma einen Thread
dazu - los gehts mit <3FDD80AB.EEA99FE@bar.de>


bye,
Michael
 
Gunther Mannigel <newsgroups@mannigel.net> schrieb:

Da hat sich wirklich jemand Gedanken dazu gemacht, interessantes
Dokument :) Danke für den Tip

Werner Brennecke wrote:
Wie kriegt man hier eine brauchbare Start/Stop-
und Fehlererkennung hin?

http://www.p-net.dk/download/schul_konz.pdf
vielleicht?
 
Ging mir auch durch den Kopf, nur verliere ich hier mindestens 50%
Bandbreite.
Das ganze Telegramm als Antwort zurueckzuschicken, halte ich nicht fuer
sinnvoll, die "Sicherheit" ("wenn die Antwort identisch mit dem
gesendeten identisch ist, passt alles") ist truegerisch. IMHO ist es
besser, Pruefsummen (CRC) in den Telegrammen zu verwenden und
spezielle, kurze "ACK"-Telegramme zu definieren.

Beim Timeout habe ich die Befürchtung, das 2 Sender doch gleichzeitig
senden.
Pakettrennung mit Timeouts ist grundsaetzlich eher schlecht, solche
Protokolle funktionieren i.a. nur "fast immer" :)
Problematisch wird sowas vor allem dann, wenn Teilnehmer mit
verschiedenen "Reaktionszeiten" kommunizieren sollen, z.B. ein
Controller und ein PC mit einem Desktop-Betriebssystem Deiner Wahl
(Linux, Windows, ...). Da kommt man mit Timeouts schnell ins stolpern.

Sinnvoller ist es, ueber eine Laengenangabe und Pruefsummen zu arbeiten.
Es ist auch noch zu ueberlegen, ob das Protokoll ASCII oder Binaer sein
soll (ASCII ist einfacher, aber weniger effizient).

Eine Art CSMA/CD hier aufzubauen ist noch ein wenig aufwändig.
Es ist zu unterscheiden, ob nicht doch ein Master/Slave System ausreicht
(ein Master hat die "Befehlsgewalt" ueber den Bus und sendet an die
Slaves Telegramme, falls er was will, ein Slave sendet nur, wenn er dazu
aufgefordert ist --> keine Kollisionen moeglich).

Multimaster ist SEHR aufwaendig zu implementieren und hat i.a. lausige
Performance, vor allem mit RS485 ist sowas nur schlecht implementierbar,
weil auf Bit/Byteebene Kollisionen nicht erkennbar sind, sondern erst
auf Telelgrammebene (bei Interesse kann ich das noch erlaeutern).

LG,

--
Bernhard Roessmann
 
Mit dem I2C Bus kenne ich mich schon gut aus, nur ist dieser für diese
Anwendung überhaupt nicht geeignet.
Fuer sowas gaenzlich ungeeignet, sagt eh schon der Name "InterIC Bus" ;-)

Ausserdem wollte ich mir einer 2 Draht Verbindung auskommen. Ehrgeiz
halt :))
Bei "groesseren" Entfernungen kriegst Du auch mit RS485 und nur zwei
Draehten Probleme mit den Spannungsabfaellen, da muss dann eventuell
noch GND als dritte Leitung mitgefuehrt werden.

Ausserdem sollten die Draehte verdrillt sein (z.B. ein CAT5-Adernpaar).

LG,

--
Bernhard Roessmann
 

Welcome to EDABoard.com

Sponsor

Back
Top