www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik rs-485 can ???


Autor: Der Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

ich möchte gerne mehrere avr's miteinander vernetzten und frag mich
nu, wie ich das am besten anstelle. ich habe auch schon mit max485 nen
bus aufgebaut, frage mich nur, wie ich mir nu nen protokoll bastele.
dass ich adressieren, daten schicken und vielleicht auch noch prüfen
muss ist mir klar, aber wie stell ich das am besten an?
baud rate ist ziemlich egal, ist nicht viel zu schicken.
programmieren tu ich in c...

und die zweite frage: was ist denn nu genau der can bus (controller
area network, jaja...). ich habe mir da heute auch schonmal nen buch
zum überfliegen geholt, bin aber noch nicht zu gekommen...

wär nett,wenn ihr da mal nen paar tipps für mich hättet!

gruß

DerDirk

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema RS485:

1. Byte: Anzahl nachfolgender Bytes
2. Byte: Adresse des anzusprechenden bzw. antwortenden Systems
3. Byte: Befehlscode
4. .. x. Byte Daten
x+1. Byte Checksumme

Das ist jedenfalls das Protokoll wie ich (und viele andere, hab´s auch
nur abgekupfert) es verwenden. Es ist relativ sicher bzgl. der
Richtigkeit der Daten und mit der Info aus dem 1. Byte weiß ich genau
wann die Übertragung zuende ist.

Die zweite Frage lässt sich nicht so schnell beantworten. Da solltest
Du doch erst mal dein Buch lesen. auf jeden Fall wirst Du darauf
zurückkommen wenn sich mehrere Systeme untereinander über einen Bus
unterhalten (Multi-Master System). Das geht zwar mit der RS485 über
sonstwas für Kopfstände auch aber die RS485 ist nunmal nicht dafür
gedacht. Für CAN gibt es da fertige IC´s die alles händeln. Die sind
allerdings etwas teuer, so dass ich meist versuche alles mit der RS485
zu erschlagen.

Steffen

Autor: DerDirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank erstma!
aber wie stelle ich das dann an, dass einer der slaves auch mal was
senden möchte, zum beispiel eine empfangsbestätigung, eine
fehlermeldung oder einfach nur nen paar bytes. die dürfen sich dann ja
auf der leitung nicht kreuzen. ich hab übrigens halb-duplex
aufgebaut...


Dirk

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am einfachsten ist es, wenn die Slaves nur dann antworten, wenn sie
gefragt werden. Ansonsten lassen sich Kollisionen nicht vermeiden. Es
ist eh sinnvoll, wenn jeder Slave auf einen Befehl ein Antworttelegramm
sendet.

Steffen

Autor: Carsten Sch. (soulfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Steffen,
ich bin gerade über den etwas älteren Beitrag gestoplert.
Da ich mit einem Toshiba-Controller arbeite gibt es leider sehr wenig
support für den Betrieb eines RS485 Protokoll.
Könntest du mir vielleicht die prinzipielle herangehensweise
verdeutlichen oder deinen Quelltext senden.
So komme ich hier nicht vorwärts

Danke Carsten

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seine herangehensweise ist in etwa identisch mit dem
Profibusprotokoll, das genau diese Art der Kommunikation
erfordert. Schau mal unter Profibus

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Carsten,

ist ja wirklich schon Asbach der Thread, macht ja aber nichts.

Im Prinzip ist es so, dass die einzelnen Slaves am RS485-Bus nur
antworten, wenn sie gefragt werden. Dazu hat jeder Slave eine
einstellbare Adresse (ist meist im EEPROM abgelegt).

Zum Beispiel sind x-Slaves angeschlossen und der Slave mit Adresse 0x03
soll LED5 einschalten. Der Befehl dazu könne wie folgt aussehen:

0x04 - es folgen noch 4 Byte
0x03 - Slave-Adresse 3
0x53 - Befehlscode für Einschalten (0x53=ASCII Code von 'S')
0x05 - Ausgang (LED) 5
0x51 - XOR aller Bytes für Gültigkeitsprüfung

Der Master schaltet seinen RS485-Treiber auf senden, schickt die 5
Bytes über die UART raus und schaltet den Treiber wieder zurück auf
Empfang.
Die Daten werden von allen Slaves empfangen und die Adresse wird
ausgewertet. Der Slave mit der Adresse 0x03 fühlt sich angesprochen,
testet die Befehlssequenz auf Gültigkeit, setzt seine LED und sendet
Beispielsweise folgende Antwortsequenz:

0x03 - es folgen noch 3 Byte
0x03 - Antwort von Slave Nr. 3
0x06 - Antwortcode für ACK
0x06 - XOR aller Bytes für Gültigkeitsprüfung

Zum Senden muss er natürlich ebenfalls seine Treiber auf Senden
schalten

Wie gesagt, das ist nur eine Möglichkeit. Andere Protokolle nutzen z.B.
das gesetzte 9. Bit als Adressierung.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man mit 8 statt 9 Bits arbeitet, sollte man das Protokoll so
anlegen, dass bestimmte 8-Bit Codes ausschliesslich am Anfang und Ende
eines Übertragungspakets verwenden werden, und nicht im Inhalt des
Pakets vorkommen können (8bit-transparent ist das dann natürlich
nicht).

So stellt man sicher, dass keine Missverständnisse vorkommen,
unabhängig davon wer grad wann eingeschaltet wird, zumal wenn man
Prüfsumme oder XOR statt CRC verwendet.

Beispielsweise
   00 <adresse> <inhalt> <checksum> FF
Der Empfangscode ist dann weitgehend statusfrei und ignoriert
normalerweise alles ausser 00.

Hat man wenig Stationen, kann man das auch weiter reduzieren, z.B.
   01 <inhalt> <checksum> 00    für Station 01
   02 <inhalt> <checksum> 00    für Station 02
und verwendet den Codebereich 00-0F ausschliesslich für's den Rahmen,
nie in Inhalt oder Checksum.

8bit-Daten wie die Checksum müssen dabei natürlich umcodiert werden
(z.B. AB => 3A 3B).

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Bei sowas ist es durchaus sinnvoll, mit Parity zu arbeiten.

Autor: Carsten Sch. (soulfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke euch wie verrückt ür die vielen Antworten.
Habe nat jetzt auch gleich ein paar neue Fragen.
mit den 8 bzw 9Bit das hat mich die ganze zeit schon verwirrt
8 bit pro Byte? und wie soll das dann mit der Adressierung bei einem
bit mehr funktionieren?
Jetzt bin ich mal ganz dreist und frag noch danach ob jemand vielleicht
mal einen Codeschnipsel für mich hat? Verwenden kann ich ihn sowieso
nicht direkt bei meinem Toshiba Controller

Gruß Carsten

Autor: Artur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss gerade in meiner Diplomarbeit das Protokoll und Packetbildung
programmieren. Besser gesagt, auf bestimmte Packete als Slave mit
Antwortpacketen antworten. In meinem Fall die aktuelle Uhrzeit.
Und ich machs genau so, wie schon oben jemand beschrieben hat:

1. Startzeichen
2. Anzahl der Datenbytes (nur Daten)
3. CMD
4. Sender
5. Destination
6-x. Data
x+1 CRC8

Und so hast du die Kommunikation schon einigermaßen abgesichert...

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso steht in der Überschrift eigentlich "rs-485 can"?

RS-485 oder CAN: Den Transceiver muß man eh in beiden Fällen
beschaffen.

CAN macht hochsichere Übertragung mit Hardware-CRC, automatische
Wiederholung bei Fehler, ist Multi-Master-fähig, arbeitet
objektorientiert (Akzeptanzfilterung), d.h., ist nicht von der Hardware
des Netzes abhängig, um ein paar Stichworte zu nennen.

Laß den Controller mit CAN doch mal etwas teurer sein. Dafür hat man
auch viel mehr Fun in der Anwendung. Den Löwenanteil kostet doch eh
nicht die Hardware. Die Lizenzgebühren der Hersteller an Bosch pro CAN
Controller in einem µC betragen übrigens 0,10 Euro.

Gruß

Dietmar

Autor: +-+-+-+-+-+ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wieso steht in der Überschrift eigentlich "rs-485 can"?"

Wie heißt es so schön?

WER LESEN KANN IST KLAR IM VORTEIL!

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ja, du mich auch...

Autor: Oma-mit-Dackel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Mach doch neben dem RS485-Bus noch ne zusätzliche Handshakeleitung.
Über Transistoren und einem Widerstandsnetzwerk zieht jeder Teilnehmer
der Senden möchte die Leitung auf ein bestimmtes Spannungsniveau so das
alle Teilnehmer vor dem Senden und empfangen den Pegel überprüfen. Sind
zufällig 2 Sender Gleichzeitig aktiv wird der Pegel auf einen
verbotenen Bereich heruntergezogen, so das alle Empfänger die Daten
verwerfen, und die beiden Sender den Versuch abrechen. Nach einer
kleinen Zufallszeit versucht er es dann von vorne.

müsste so ohne grossen Aufwand Funktionieren.

Gruss

Autor: Oma-mit-Dackel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol einmal zurückgeklickt ... dann sendet er den Beitrag 3 mal ^^^sorry

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt noch eine Möglichkeit, Kollisionen auf einem RS485-Bus elegant
zu umgehen: Man nehme einen CAN-Treiber (82C250) und verwende ihn als
RS485. Der Vorteil: Kollisionen machen nichts, weil sich der aktive
Pegel durchsetzt, man kann sie durch Arbitrierung ähnlich wie bei I²C
herausfiltern. Die gesendeten Daten werden gleichzeitig empfangen -
dadurch kann man soll mit ist vergleichen. Klappt bei mir wunderbar.
(Diesen Tipp habe ich irgendwann mal hier gefunden - danke an den
unbekannten Autor im Nachhinein)

Autor: Carsten Sch. (soulfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
ich verstehe die Sache mit dem 9bit für die Adressierung immer noch
nicht. Ich dachte bis jetzt ein Byte hat immer 8Bit und wie soll ich
denn mit einem Bit (dem 9.??) mehrere Geräte Adressieren?
Könnte mir nicht mal jemand so ein Protokoll im Beispiel (am besten in
C) zur Verfügung stellen, so dass ich mal einen Anfang sehe?

Danke Carsten

Autor: Detlef Wilken (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Byte hat nach wie vor 8 Bit. Ein zusätzliches Bit (eben dieses 9.
Bit)wird genutzt, um die Verwendung der 8 Bit zu steuern.
Meist wird dieses 9. Bit genutzt, um ein Byte als Adresse zu
identifizieren.(Die Adresse selbst ist dann innerhalb der 8 Byte
abgelegt).
Man kann den Controller so einrichten, dass eine UART-ISR nur dann
ausgeführt wird, wenn eben ein Byte mit einem gesetzten 9. Bit
empfangen wurde. Das hat den Vorteil, dass alle anderen Bytes dieser
Botschaft keine Aktion im Controller auslösen(keine ISR wird
aufgerufen), sofern mit der Adresse nicht dieser Controller gemeint
ist.

In der ISR für die UART ist das Vorgehen dann folgendes (Die UART ist
so initialisiert, dass nur Bytes mit gesetztem 9. Bit die ISR
aufrufen):
Es wird das erste Byte mit dem gesetzten 9. Bit empfangen und die ISR
wird aufgerufen. In der ISR wird dann folgendes gemacht:
Prüfen, ob mit der Adresse dieser Teilnehmer gemeint ist. Wenn dieser
Teilnehmer gemeint ist, dann ISR umschalten auf Empfang aller Bytes.
Ist dieser Teilnehmer nicht gemeint, wird nicht reagiert, da die
anderen Botschaftsbytes für diesen Controller nicht von Interesse
sind.

Bei den AVR ist die Geschichte mit dem 9. Bit das Thema MPCM

Gruß
Detlef

Autor: der inoffizielle WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Multiprocessorcommunicationmode gibt es seit dem 8051.
Manche Controller unterstützen disen Modus, manche nicht.
Es gibt Protokolle bei denen die Daten als ASCII-Zeichen
aufgeschlüsselt werden. Dann besteht ein Byte auf einmal aus zweien,
weil das Byte in oberes und unteres Nibble aufgeteilt wurde, und die
dann als Zahl zwischen 0 und F dargestellt werden.
Das Protokoll kommt auf die Anwendung drauf an: Muß es besonders
störsicher sein, braucht man noch Checksums und so, manchmal reicht es
aber auch aus, wenn der Empfänger einfach nur den Empfang innerhalb
einer gewissen Zeit quittiert. Das kann man auch dadurch machen, dass
der Sklave das Datagramm zurückschickt.
Wenn man sich das leben einfach machen will, nimmt man einen
CAN-Controller und überlässt dem die Kommunikation. Man kann natürlich
auch eine Art Token-Ring-Netzwerk aufbauen, bei dem die gesendeten
Daten auch wieder beim Sender ankommen müssen. Das geht aber nicht
wirklich gut mit RS485.

Autor: Carsten Sch. (soulfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
danke für die sehr ausfühliche Antworten.
Jetzt wird es ganz dumm...aber leiber mal gefragt
Bei der Programmierung von solch einem Protokoll stelle ich mir
folgendermaßen vor:
Ich lege mir ein Array an in das ich die Zieladresse schreibe und das
9.bit. Dann noch ein Array für meine Adresse usw. ..
Wenn ich jetzt senden will gibt es einen Ausgangspuffer in den ich das
hinein schreibe (alle Byte oder einzeln?) und dann dem UART mit einem
Befehl sage sende es ab?
Kommst das so ungefähr hin....

Carsten

Autor: der inoffizielle WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Controller benutzt du?
Wie oben schon erwähnt, können manche AVR den MPCM per Hardware.
Da braucht man sich dann nur um de Daten (inkl. Adresse) kümmern.
Dem UART übergibt man dann das zu sendende Byte (uns setzt bei Bedarf
das 9.Bit). Um den Rest kümmert sich das UART. Das meldet dann auch, ob
das "Byte" (8+1 Bit) komplett übertragen wurde.
Dazu gibt es natürlich im Datenblatt auch ein paar Beispiele...

Autor: Carsten Sch. (soulfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort,
ich benutze von Toshiba einen TMP92FD54AIF und dort habe ich im
Datenblatt schon einiges entdeckt.
Ich kann es mir nur von der Programmiertechnischen Seite noch nicht
vorstellen wie und wo ich Anfangen muss

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.