RS485 Protokoll

[Baui]

Hi,
ich habe mal ne Frage zu einem Protokoll für den RS485 Bus. Wie der elektrische Aufbau ist hab ich glaube ich verstanden.
Allerdings weiss ich nicht, wie ein Protokoll aussehen könnte in Basic (möglichst). Kann mir da jemand ein Beispiel geben (URL oder so).
Stimmt es, dass wenn der Master einen Datenframe sendet, alle Slaves immer "mithören" müssen? Bei einer grossen Datenrate sind die Slaves dann ja nur mit dem "Hören und vergleichen" beschäftigt.

Bin dankbar über jeden Tipp

Gruß
Baui

[roboguy]

Ich kann dir leider kein direktes Programmbeispiel liefern, habe aber beruflich öfter mit RS485-Steuerungen von Videoüberwachungsanlagen zu tun.
Zunächst musst du dir überlegen, ob du eine Punkt-zu-Punkt-Verbindung (wahrscheinlich eher nicht - entnehme ich zumindest deiner Anfrage) oder einen Bus ("Daisy chain") aufbauen willst. Ich vermute bei dir letzteres.
Außerdem musst du dich entscheiden, ob du eine Vollduplex-Verbindung (gleichzeitiges Senden und Empfangen über getrennte Sende- und Empfangsleitungen) oder eine Halbduplex-Verbindung (wechselweises Senden und Empfangen). Diese Unterscheidung wirkt sich sowohl auf deine Hardware als auch auf dein Protokoll aus.
Wenn du dich für Halbduplex entscheidest, musst du dir darüber im Klaren sein, dass du in deinem Protokoll festlegst wer wann senden darf, z.B. in Form von Timern, d.h. nach Senden eines Befehls darf eine Antwort nicht vor xxx ms erfolgen und sollte andererseits nicht später als yyy ms verschickt werden (damit der Sender weiß, ob sein Befehl/ Abfrage (was auch immer) angekommen ist und verarbeitet wurde.
Außerdem solltest du ein Start- und ein Endezeichen für dein Protokoll festlegen, d.h. mit einem bestimmten Zeichen (in meiner Videotechnik ist es Hex 02) beginnt dein Senderahmen und mit einem anderen Zeichen (bei meiner Technik Hex 03) endet er.
Was du zwischen Beginn und Ende treibst bleibt deiner Phantasie überlassen. Du könntest beispielsweise überlegen, zu Beginn eine Längeninformation mitzugeben (also wieviele Zeichen noch kommen), das macht aber nur Sinn, wenn deine Rahmen keine festgelegten Längen haben (wenn du weißt, jeder Rahmen ist x Zeichen lang, brauchst du die Info nicht extra zu übermitteln). Was auf jeden Fall bei einem Busbetrieb erforderlich ist, ist die Angabe der Zieladresse und unter Umständen (falls das bei dir in Frage kommt) auch des Absenders.
Sinnvoll dürfte eine Quittierung sein, um sicherzugehen, dass der gewünschte Empfänger die Message auch erhalten hat, d.h. der Empfänger sollte den Empfang einer gültigen Message positiv quittieren oder falls er Probleme mit der empfangenen Message hat, mit einer negativen Quittung (bei uns heißt so etwas ACK für ACKNOWLEDGE und NAK für NO ACKNOWLEDGE). Die Quittung kann entweder mit einem festgelegten Befehl (z.B. ACK) oder mit einer passenden Antwort auf die Message erfolgen, die Negativquittung mit einem (oder mehreren) festen Nachricht(en), z.B. "ungültige Message empfangen" oder "kann gerade nicht, weil ich zu tun habe...".
Ansonsten hängt es davon ab, was genau du machen willst. Eine Möglichkeit wäre ein Befehl/ Antwort- bzw. Abfrage/ Antwort-Protokoll, also nach dem Motto: "Empfänger xy tue dies (oder jenes)" und der Empfänger xy antwortet "Jawoll wird gemacht" oder "Nee, geht nicht, keine Zeit".
Eine Abfrage- Antwort-Struktur wäre beispielsweise
"Empfänger xy was hast du für Daten für mich" und xy antwortet "Nischt" oder "Hier sind meine Daten".
Wie gesagt, der Phantasie sind kaum Grenzen gesetzt.
Ich denke wichtig ist auf jeden Fall der geregelte Ablauf (wozu das Protokoll ja auch dienen soll) mit Festlegungen für zeitliche Verhalten, damit du einerseits keine Kollisionen kriegst, andererseits aber auch definierte Antwortzeiten erhältst.
Ich hoffe, diese Infos haben dir ein bisschen geholfen.
Volkhard
bei längeren Rahmen

[Dino Dieter]

Hallo

Schau dir mal

http://www.hth.com/filelibrary/pdffiles/snap.pdf

von

http://www.hth.com/snap/

an. Da sind auch Beispiele in Bascom dabei. Erfüllt eigentlich alles, was du brauchst.

MFG
Dieter

Wirf lieber nicht Bus und Daisy Chain durcheinander. Daisy Chain findet man eher bei RS422.
Warum klemmst du nicht z.B. den USART bzw. den I²C-Bus an einen RS485 Transceiver? Zumindest bei I²C existiert ja bereits ein Protokoll.

[roboguy]

@Gast:
Du hast recht - hängt ein bisschen mit meiner persönlichen Vorbelastung zusammen. Bei meinem Zeug ist der "Bus" eigentlich immer als "Daisy chain" aufgebaut.

[Baui]

Besten Dank für die ausführlichen und schnellen Antworten.
Dann werd ich mich mal mit dem SNAP Protokoll beschäftigen. Also stimmt es auch das die Slaves immer den Bus "abhorchen" müssen. Will nur hoffen das sie dann auch noch in der Lage sind ihre Aufgaben zu erfüllen ;-)

Gruß
Baui

Tja, genau darin liegt der Sinn eines Hardware-Interface wie z.B. bei I²C. Du bekommst erst dann einen Interrupt, wenn dein Slave auch wirklich angesprochen wurde. Aber mach nur, was du denkst :-)

[Baui]

Hallo Gast,
da hast du natürlich recht. Mein Problem ist dann allerdings, dass ich nich weiss, wie man einen AVR als Slave programmiert (Basic)

Ansonsten würd ich mich ja dafür entscheiden

Gruß
Baui

[Baui]

So mir is da noch ne andere Idee gekommen.
gibt es eine Möglichkeit (beim RS485 Bus) adressierbare Bausteine vor die AVRs zuschalten?
Diese leiten dann erst die Nachricht weiter (SNAP-Format o.ä.), wenn die Adresse mit der eigenen übereinstimmt?
Man würde dann praktisch ein Hardware Interface nachrüsten.

Gruß
Baui

[Michael Holoubek]

Hi

Die meisten AVRs (zumindest MEGA8/16) sowie die meisten PICs mit nem Hardware UART, können außer den normalen 6-,7-,8-Bit Modes einen 9-Bit Modus.
Mit dem neunten Bit wird definiert ob die restlichen acht Bit eine Adresse oder Daten sind. Wenn es eine Adresse ist und die auch der eingestellten
Adresse im MEGA/PIC entspricht, dann gibt es nen Interrupt. Damit sollte sich die notwendige Aufmerksamkeit für den Datenbus auf ein Mindestmaß reduzieren.
Das einzige Problem wird dann darin liegen einem PC das 9-Bit Format beizubringen(sofern du einen an dem Bus hängen willst), da die UARTS in normalen Rechnern meist nur 6,7,8-Bit können.....
->Dongle für den PC bauen

[Baui]

Hallo Michael,
das hört sich interessant an. Ich habe da aber noch zwei Fragen:

1. Hast du vielleicht ein Programmierbeispiel in Basic für die 9bit Modes und
2. Wie kann ich so einen Dongle bauen. Ich dachte mir einen AVR zwischen PC und den anderen AVRs schalten, aber der hat ja nur ein uart und kann dann ja nicht als Adapter dienen.

Wäre dankbar wenn du jmir ncoh einen kleinen Tipp geben könntest

Gruß
Baui

[Michael Holoubek]

Hi

Ich habe nichts fertiges, da ich gerade an einem Bussystem programmiere und noch viel zu tun ist . Schau mal ins MEGA16 Datenblatt auf Seite 150 & 153, da ist das Senden und Empfangen im 9-Bit Modus beschrieben, inkl. Sourcecode in C und Assembler.
Den Adapter muss ich erst bauen, aber HW-UART für den Bus und ein SW-UART für die Verbindung zum PC sollte für einen AVR ohne Probleme möglich sein. Eine andere Möglichkeit wäre es, den AVR an den Parallelport des Rechners anzuschließen, nur ist da der Aufwand beim PC-Programm größer.

MfG
Mike

[Baui]

hallo Mike,
danke für die schnelle Antwort. Das Beispiel hab ich gefunden steht auch im Mega8 Datenblatt.
Ich werd mir das dann alles mal weiter anguckenund evtl. ein bisschen C lernen. Wenn ich noch eine Frage habe melde ich mich nochmal.
Ich befürchte nämlich, dass Bascom den 9 Bit modus nicht unterstützt. :-(

Gruß
BAui

[Kjion]

Quatsch...
Bascom kann doch die Register einzeln Ansprechen. Und darüber lässt sich das auf jeden Fall programmieren. Ist halt nur ein bißchen mehr Arbeit ( wenn es wirklich nicht unterstüzt wird ).

Aber C ist natürlich auch nicht schlecht. Nur da wirst du es genauso machen müssen...

MfG Kjion