-
        
+ Antworten
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

Thema: RS485 Protokoll

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    16.06.2004
    Alter
    29
    Beiträge
    77

    RS485 Protokoll

    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

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    25.10.2004
    Ort
    Pinneberg
    Alter
    56
    Beiträge
    48
    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

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    28.04.2004
    Ort
    Nähe Köln
    Alter
    49
    Beiträge
    247
    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

  4. #4
    Gast
    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.

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    25.10.2004
    Ort
    Pinneberg
    Alter
    56
    Beiträge
    48
    @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.

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    16.06.2004
    Alter
    29
    Beiträge
    77
    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

  7. #7
    Gast
    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

  8. #8
    Benutzer Stammmitglied
    Registriert seit
    16.06.2004
    Alter
    29
    Beiträge
    77
    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

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    16.06.2004
    Alter
    29
    Beiträge
    77
    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

  10. #10
    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
    MfG
    Michael Holoubek

    http://www.holoubek.co.at

    Ach Ja,....wer Fehler findet darf sie behalten ich habe genug davon ! \/

+ Antworten
Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •