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
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
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
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
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
Seine herangehensweise ist in etwa identisch mit dem Profibusprotokoll, das genau diese Art der Kommunikation erfordert. Schau mal unter Profibus
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.
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).
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
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...
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
"Wieso steht in der Überschrift eigentlich "rs-485 can"?" Wie heißt es so schön? WER LESEN KANN IST KLAR IM VORTEIL!
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
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)
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
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
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.
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
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...
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.