Hallo zusammen, ich habe einen ATmega324 und bis zu vier ATmega88. Die Entfernung zwischen den Controllern beträgt bist zu 15m. Der 324er ist quasi die Zentrale und soll Nachrichten mit einer Id und Befehl an die 88er schicken und der entsprechende 88er reagiert darauf, führt Messungen durch und antwortet dann, wenn er fertig ist. Habe ich es richtig verstanden, dass ich dafür MAX 488 ICs verwenden kann und dann die Kommuniakation wie "normales" RS232 funktioniert, oder muss ich etwas beachten? Und wie verbinde ich die MAX 488 miteinander? Ich hätte gern ein simples CAT5e Kabel genommen... Reicht es dann einfach die 4 Adern zu verbinden, oder muss ich GND mitführen? Die Controller werden jeweils ein eigenes Netzteil haben - eine gemeinsame Stromversorgung würde ich gerne vermeiden.
Troll A. schrieb: > oder muss ich GND mitführen? Oder Im Datenblatt des MAX488 ist für die Eingangsspannng ein definierter Bereich vorgegeben. Wie willst du die Einhaltung dieser Spezifikation sicher stellen? Ein mit geführter Gnd wäre die einfachste Lösung.
Troll A. schrieb: > Habe ich es richtig verstanden, dass ich dafür MAX 488 ICs verwenden > kann und dann die Kommuniakation wie "normales" RS232 funktioniert, oder > muss ich etwas beachten? Wenn man 5 Teilnehmer hat, will man eigentlich einen Bus haben, meistens Halbduplex. Dafür braucht es eher den MAX485 oder 483 (langsame Variante), die sind Halbduplex. Dann reicht eine verdrillte Leitung + GND. Außerdem hängen dann alle am Bus. Passende Abschlußwiderstände nicht vergessen. https://www.mikrocontroller.net/articles/RS-485#Weitere_Hinweise > Und wie verbinde ich die MAX 488 miteinander? Ich hätte gern ein simples > CAT5e Kabel genommen... Reicht es dann einfach die 4 Adern zu verbinden, Nein. > oder muss ich GND mitführen? Ja.
Troll A. schrieb: > muss ich GND mitführen? Es gibt immer wieder welche, die schaffen RS422/RS485 ohne die GND-Verbindung. Aber du musst dann eben anderweitig dafür sorgen, dass du den Gleichtaktbereich aus den Absolute Maximum Ratings oder besser noch aus den Recommended Operating Conditions des Empfängers einhältst. Einfach mal den Beitrag "Re: Datenübertragung über >100m" durchlesen. Was da für den bidirektionalen RS485 steht, gilt auch für den unidirektionalen RS422.
Troll A. schrieb: > und dann die Kommuniakation wie "normales" RS232 funktioniert, oder > muss ich etwas beachten? Deine Slaves dürfen nur auf Anforderung vom Master antworten, und sie dürfen ihren RS422-Treiber nur während ihrer Antwort aktivieren. Sonst blockieren sie sich gegenseitig den Bus. Da das in der Handhabung kaum einen Vorteil gegenüber RS485 bietet, kannst Du den Verdrahtungsaufwand auch reduzieren, und RS485 einsetzen. Der Unterschied bei RS485 ist der, daß alle Slaves die Antworten aller Slaves mitbekommen, das bedeutet nur, daß Du bei der Protokollgestaltung entsprechend Sorgfalt aufwenden musst, so daß Slaves nicht die Antworten anderer Slaves mit Anfragen des Masters verwechseln.
Harald K. schrieb: > Deine Slaves dürfen nur auf Anforderung vom Master antworten, und sie > dürfen ihren RS422-Treiber nur während ihrer Antwort aktivieren. Sonst > blockieren sie sich gegenseitig den Bus. Beim RS422 gibt es nur 1 Sender und 1 oder mehrere (=Multidrop) Empfänger. Und der Treiber ist deshalb immer aktiv. - https://www.sealevel.com/support/basics-of-rs-422-and-rs-485-communications/
:
Bearbeitet durch Moderator
Falk B. schrieb: > Wenn man 5 Teilnehmer hat, will man eigentlich einen Bus haben, meistens > Halbduplex. Dafür braucht es eher den MAX485 oder 483 (langsame > Variante), die sind Halbduplex. Dann reicht eine verdrillte Leitung + > GND. Außerdem hängen dann alle am Bus. Passende Abschlußwiderstände > nicht vergessen. Ok, ich dachte der Vorteil am MAX488 ist, dass ich mich nicht zu kümmern brauche ob die Leitung gerade "frei" ist, sondern jeder einfach senden kann. Aber du meinst, das ein MAX485 und halb-duplex für so etwas gebräuchlicher ist? Der ATmega324 (Master) forder dann von einem Slave quasi einen Messwert an. Wenn der Messwert erst noch errechnet werden muss (Was ein par Sekunden dauern kann), dann muss der Master solange pollen und den Slave zum Senden auffordern bis dieser fertig ist und den Messwert senden kann? Habe ich das so richtig verstanden? Und zum Senden muss beim MAX485 RE auf GND gezogen werden?
Troll A. schrieb: > Ok, ich dachte der Vorteil am MAX488 ist, dass ich mich nicht zu kümmern > brauche ob die Leitung gerade "frei" ist, sondern jeder einfach senden > kann. Wenn du mehrere Sender auf einem (in Zahlen 1) Bus hast, dann musst du immer irgendwie dafür sorgen, dass es keine Buskollision gibt. Und beim RS422 ist die Leitung für den Sender immer frei, weil es da per Definition von 1 Sender zu 1..10 Empfängern geht. Wenn du dann aber in der anderen Richtung von mehreren Sendern auf 1 Empfänger gehen willst, dann darf natürlich nur 1 Sender gleichzeitig auf dem Bus aktiv sein. Und dann kannst du gleich den RS485 nehmen. Troll A. schrieb: > Und zum Senden muss beim MAX485 RE auf GND gezogen werden? Für das Senden ist das Driver Enable DE zuständig. Mit dem Receiver Enable RE kannst du dann bestimmen, ob du das, was du grade sendest, selber auch "hörst".
:
Bearbeitet durch Moderator
Falk B. schrieb: > Wenn man 5 Teilnehmer hat, will man eigentlich einen Bus haben Das kann man auch in fertig bekommen in Form von CAN. Die Hardware erledigt die Kollisionerkennung und in Software muss man einfach nur noch Pakete senden & empfangen. Man braucht ein differenzielles Leiterpaar + GND welches über eine Bus-Topologie an alle Teilnehmer geht. Spart eine Menge Aufwand. Es empfiehlt sich aber einen Mikrocontroller mit integriertem CAN-Controller zu verwenden.
:
Bearbeitet durch User
Lothar M. schrieb: > Wenn du dann aber in der anderen Richtung von mehreren Sendern auf 1 > Empfänger gehen willst, dann darf natürlich nur 1 Sender gleichzeitig > auf dem Bus aktiv sein. Danke, jetzt ist es soweit klar und ich denke ich habe es verstanden!
Troll A. schrieb: > dass ich mich nicht zu kümmern > brauche ob die Leitung gerade "frei" ist, sondern jeder einfach senden > kann. Das geht nur mit dem CAN-Bus. UART basierte Busse können keine Kollisionen auflösen und nichtmal sicher erkennen. Es gibt daher nur einen Master, der reihum alle Slaves adressieren muß, ob sie Daten für ihn haben. Und für die Slaves gibt es Zeitfenster, einmal die minimale Zeit, nach der er auf Senden schalten darf und einmal die maximale Zeit nach der er den Bus wieder freigeben muß.
Troll A. schrieb: > ...MAX 488 ICs verwenden kann und dann die Kommuniakation wie > "normales" RS232 funktioniert > Ich hätte gern ein simples CAT5e Kabel genommen... > Reicht es dann einfach die 4 Adern zu verbinden, Troll A. schrieb: > Ok, ich dachte der Vorteil am MAX488 ist, dass ich mich nicht zu kümmern > brauche ob die Leitung gerade "frei" ist, sondern jeder einfach senden > kann. Niklas G. schrieb: > Das kann man auch in fertig bekommen in Form von CAN. Und das alles zusammen wäre "CAN für arme Leute", nämlich UART und statt dem MAX488 zwei CAN-Transceiver pro Teilnehmer und 4 Adern plus GND. Dann kann jeder jederzeit senden und muss sich um nichts weiter kümmern, wie bei RS-232. Das ist von Programm her mit Abstand die einfachste Lösung.
Lothar M. schrieb: > Und beim RS422 ist die Leitung für den Sender immer frei, weil es da per > Definition von 1 Sender zu 1..10 Empfängern geht. > > Wenn du dann aber in der anderen Richtung von mehreren Sendern auf 1 > Empfänger gehen willst, dann darf natürlich nur 1 Sender gleichzeitig > auf dem Bus aktiv sein. > > Und dann kannst du gleich den RS485 nehmen. Genau diesen Fall meinte ich. Der von Dir vorher beschriebene Fall der unidirektionalen Kommunikation (exakt ein Sender, n Empfänger) ist meist recht praxisfern. Real existierende Implementierungen von RS422 nutzen in Richtung Master->Slaves die von Dir beschriebene Variante, in der Gegenrichtung aber implementieren sie einen Bus (mit nur zum Antworten aktiviertem Treiber). Der Vorteil dieser Lösung ist, daß das Protokoll, das transportiert werden soll, primitiver ausfallen kann. Die Slaves können auf Aufforderung beliebige Daten an den Master zurücksenden, ohne darauf Rücksicht nehmen zu müssen, daß andere mithörende Slaves davon beeinflusst werden könnten - einfach, weil es keine mithörenden Slaves gibt. Hier genügt eine simple Protokollstrukturierung à la "Ein Telegramm ist (maximal) x Bytes lang oder wird mit einer speziellen Bytesequenz abgeschlossen oder wird durch eine Sendepause abgeschlossen". Bei RS485 hört jeder am Bus immer den gesamten Datenverkehr mit und muss daher das Geschehen gründlicher und zuverlässiger analysieren, um falsch verstandene Telegramme ausschließen zu können. Daher sind etwas höhere Anforderungen an die Protokollstrukturierung zu stellen. Ist jetzt aber auch keine Raketenwissenschaft; ein verbreitetes Verfahren ist z.B. Modbus/RTU. Wenn man hier den Protokollrahmen vom Nutzinhalt trennt, lassen sich mit dem gleichen Protokollrahmen auch ganz andere Inhalte als "Coils" und "Register" transportieren.
RS 485 mag keine sternförmige Verkabelung, du solltest alle Teilnehmer auf eine Leitung hängen. Die Enden dürfen durchaus auch an Slaves liegen und der Master in der Mitte sein. Die RS485 Transciver gibt es als sehr stromsparende BiCMOS Ausführungen und in unterschiedlichen Versorgungsspannungsbereichen. Üblich sind 5V und 3,3V, es gibt auch Typen, die beides abdecken oder welche, die auch unter 3,3V können. Die parametrische Suche beim Distri ist dein Freund. Danach machst du dann nochmal die Gegenprüfung im Datenblatt. Das Schöne ist ja, das der Bus selber nur mit ein paar hundert Millivolt differentiell arbeitet und so die Pegelwandlung zwischen den einzelnen Busteilnehmern ganz nebenbei mit erschlagen wird :-)
Gerald B. schrieb: > RS 485 mag keine sternförmige Verkabelung Damit hat RS485 keine Probleme, solange man sich mit der Datenrate in sinnvollen Bereichen bewegt. Und bei Anwendungen wie z.B. der Hausautomation sind hohe Datenraten eh' vollkommen sinnlos. Wenn man Werkzeugmaschinen betreiben will, wo es auf Reaktionszeiten im Millisekundenbereich oder sogar darunter ankommt, dann ist das eine andere Sache. Dann kann man sich auch um lehrbuchkonforme Verdrahtung Gedanken machen, aber für viele Anwendungen ist das nur überflüssiges akademisches Eierschaukeln. In der professionellen Gebäudeautomation (mit der z.B. Krankenhäuser, Bürogebäude etc. gesteuert werden) sind 9600 Baud weit verbreitet. Und damit können Busleitungen von mehreren hundert Meter Länge völlig problemlos beliebig wild verkabelt werden, und das auch bei > 50 Slaves am Bus.
Bauform B. schrieb: > Das ist von Programm her mit Abstand die einfachste Lösung. Man braucht immer noch eine Prüfsumme, eventuell Leitungskodierung, Paket-Anfang/Ende-Erkennung. Das gibt's beim CAN alles "gratis" von der Hardware schon erledigt. Einziger Nachteil vom CAN: Pakete sind auf 8 Bytes begrenzt.
Niklas G. schrieb: > Einziger Nachteil vom CAN: Pakete sind auf 8 Bytes begrenzt. Immerhin 8 mal mehr als ein "SIO-Paket" mit grade mal 8 Bits... ;-)
Ich muss jetzt doch noch zwei Sachen nachfragen. Ist nicht ganz Thema, betrifft aber den TO, wenn es eben doch nicht so stimmt. Bauform B. schrieb: > Und das alles zusammen wäre "CAN für arme Leute", nämlich UART und statt > dem MAX488 zwei CAN-Transceiver pro Teilnehmer und 4 Adern plus GND. > Dann kann jeder jederzeit senden und muss sich um nichts weiter kümmern, > wie bei RS-232. Wie ist das gemeint? Ein Bus vom Master zu den Slaves und einer von den Slaves zum Master? Un dwenn jetzt zwei Slaves gleichzeitig antworten wollen? Dann gibt es doch wieder eine Kollision. Kann man natürlich mit einhalten eines Zwitabstandes beheben. Zumindest sollte man sich da drüber Gedanken machen. Niklas G. schrieb: > Das gibt's beim CAN alles "gratis" von der > Hardware schon erledigt. Was ist jetzt in dem Sinne die Hardware? Der Transceiver (z.B. PCA82C251, Max305x) ist ja strunzdumm und macht nur physikalischen Bus. Die Atmega88 werden kein CAN können, bzw nur als Softwareemulation. Da ist der Vorteil aber auch dahin, dann geht auch RS485 mit etwas Protokoll.
Niklas G. schrieb: > Einziger Nachteil vom CAN: Pakete sind auf 8 > Bytes begrenzt. Nicht mehr: CAN-FD kann bis zu 64 Bytes in einer Botschaft. Die meisten aktuellen Controller können schon CAN-FD. Ansonsten muss man statt dem alten MCP2515 den neueren MCP2518FD verwenden. (Ich würde sowieso nur noch den MCP2518 statt dem 2515 verwenden)
:
Bearbeitet durch User
CAN Transceiver an UART haben gegenüber RS-485 den Vorteil, daß keine Richtungsumschaltung nötig ist. Auch kann man Kollisionen immer erkennen, da ein Pegel dominant ist. Bei RS-485 können 2 Sender gegeneinander kämpfen und abhängig vom Leitungswiderstand beide ihr Signal als kollisionsfrei bewerten. Viele CAN-Transceiver haben auch ein Timeout, d.h. werden inaktiv, wenn ein Slave sich mit dominantem Pegel aufhängt. Der Master kann dann noch weiter mit den restlichen Slaves reden.
Benjamin K. schrieb: > Was ist jetzt in dem Sinne die Hardware? Der Transceiver (z.B. > PCA82C251, Max305x) ist ja strunzdumm und macht nur physikalischen Bus. Ja, das macht der CAN-Controller. Benjamin K. schrieb: > Die Atmega88 werden kein CAN können, bzw nur als Softwareemulation. CAN Software-Emulation macht sehr wenig Sinn, man kann einen externen Controller verwenden, aber IMO ist es am Sinnvollsten einen Mikrocontroller mit integriertem CAN-Controller zu verwenden (was insbesondere auch die Software vereinfacht). Falls die ATmega88 nicht absolut fix in Stein gemeißelt sind, könnte man darüber nachdenken. Der gute alte STM32F103 hat einen CAN-Controller, ist billig, es gibt viele Informationen & gute Tools & günstige Debugger... Aber natürlich gibt es noch viele weitere zur Auswahl. Thomas F. schrieb: > Die meisten aktuellen Controller Es schränkt die Auswahl schon ein, gerade auch auf Tool-Seite und bei Eval-Boards.
:
Bearbeitet durch User
Wenn man aber von der Vorstellung, jeder Slave darf von sich aus ungefragt senden abkommt, dann vereinfacht das die Situation grundlegend. Klar, der Master muss dann die Slaves pollen, aber das kann man auch effizient erledigen, indem man das Protokoll entsprechend sinnvoll strukturiert und z.B. eine Art Kurzadressierung einführt, die wenig mehr als die Adressinformation des Slaves enthält, und auf die der Slave entweder mit zwischenzeitlich angefallenen Daten oder aber der Information "ist nix los" antwortet. Und wenn der Master auch aktiv Daten an einen Slave senden will, dann verwendet er statt der Kurzadressierung eine Art vollständiges Paket, in dem neben der Slaveadresse halt auch die Nutzdaten drinstehen. Mit etwas Hirnschmals bekommt man so ein Protokoll hin, und kann auch bei größeren Slaveanzahlen noch recht flottes Verhalten auf dem Bus realisieren. Der Slave müsste halt, wenn er feststellt, daß er Mitteilungsbedarf hat, nicht sofort lossenden, sondern die zu sendenden Daten z.B. zwischenspeichern und diese bei der nächsten Kurzadressierung übertragen. Hat er keinen Mitteilungsbedarf, ist nichts zwischengespeichert, und die Antwort fällt entsprechend knapp aus. Dieses Kurzadressierungs-Pingpong kann man schon mit einem Byte pro Telegramm veranstalten, wenn die Adressierung der Slaves das zulässt (weniger als 128 Slaves am Bus). Da könnte man das oberste Bit zur Fallunterscheidung zwischen Kurz- und Vollständig nutzen ...
Harald K. schrieb: > Mit etwas Hirnschmals bekommt man so ein Protokoll hin, Klar, aber es ist trotzdem die Millionste Neu-Erfindung des Rads, welche man sich sparen kann. Eventuell braucht das ständige Pollen auch mehr Energie als "echte" Multimaster-Systeme, die bei Bedarf direkt senden können, statt ständig pollen zu müssen.
Troll A. schrieb: > Ok, ich dachte der Vorteil am MAX488 ist, dass ich mich nicht zu kümmern > brauche ob die Leitung gerade "frei" ist, sondern jeder einfach senden > kann. Wie soll das gehen? Welche vernünftige Reaktion erwartest du von dem Chip, wenn die Leitung gerade nicht frei ist? Bei RS485: Troll A. schrieb: > dann muss der Master solange pollen und den Slave zum Senden > auffordern bis dieser fertig ist und den Messwert senden kann? Oder eine feste Zeit abwarten, falls diese bekannt ist.
Troll A. schrieb: > Und zum Senden muss beim MAX485 RE auf GND gezogen werden? Du musst DE auf High ziehen. Du kannst dabei auch /RE auf High ziehen, wenn Du kein Echo Deines eigenen Signals empfangen willst. Dann brauchst Du aber einen Pullup auf RO (interner Pullup des Controllers reicht), weil Du sonst beim Senden einen floatenden Eingang hättest.
Troll A. schrieb: > ich habe einen ATmega324 und bis zu vier ATmega88. Die Entfernung > zwischen den Controllern beträgt bist zu 15m. Man könnte auch alle in Reihe zu einem Ring verbinden. Das kostet nur eine Ader plus GND und 1 UART und man kann fast jeden beliebigen Transceiver verwenden. So ungefähr
1 | /---------------------------------------------\ |
2 | \->[RX 324 TX]->[RX 88 TX]->...->[RX 88 TX]->-/ |
Damit darf wirklich jeder jederzeit senden. Er muss nur im Mittel weniger als 20% der Zeit eigene Daten senden und in der restlichen Zeit fremde Pakete weiterleiten. Je nach Anwendung ist mit 4+1 Knoten auch die Latenz noch im Rahmen. Bonus: man spart die DIL-Schalter für die Adressen.
Bauform B. schrieb: > Man könnte auch alle in Reihe zu einem Ring verbinden. Das ist nur im Störungsfalle sehr ... lustig. Ein ausgefallener Teilnehmer, und der gesamte Bus ist tot.
Harald K. schrieb: > Ein ausgefallener Teilnehmer, und der gesamte Bus ist tot. Ja, so ist das, wenn man am falschen Ende spart ;) Aber bei 4 Stück wäre es noch überschaubar. Und mit wenig Aufwand ausbaufähig. Wer einen zuverlässigen Watchdog hat, hängt an den ein Relais, das das defekte Gerät überbrückt. Wer noch ein 2. UART übrig hat, baut einen zweiten Ring in Gegenrichtung dazu. Allerdings kann einem das auch auf einem "normalen" Bus passieren. Warum hat man wohl CAN-Transceiver mit eingebautem Time-Out erfunden? Woraufhin die Natur einen besseren Idioten erfunden hat. Woraufhin die Technik einen Guardian erfinden musste :) https://www.cs.york.ac.uk/rts/static/papers/R:Broster:2001a.pdf
Bauform B. schrieb: > Man könnte auch alle in Reihe zu einem Ring verbinden. Das kostet nur > eine Ader plus GND und 1 UART und man kann fast jeden beliebigen > Transceiver verwenden. So ungefähr Da ich Cat5r Leitungen verwenden möchte (und ins ausreichender Menge zur Verfügung habe), sind fehlende Adern kein Thema :) Ich werde jetzt erstmal mit RS485 experementieren.
Troll A. schrieb: > Ich werde jetzt erstmal mit RS485 experementieren. Viele MCs haben dazu den 9Bit-Mode. Ist das 9. Bit 1, d.h. eine Adresse wurde gesendet, gibt einen Interrupt. Ist es 0, dann werden die Daten ignoriert, wenn der MC nicht adressiert wurde. Einige MCs machen den Adreßvergleich in Hardware, d.h. nur bei passender Adresse gibt es einen Interrupt. Alle nicht adressierten Slaves haben also keinerlei Interruptlast.
Troll A. schrieb: > Der 324er ist quasi die Zentrale und soll Nachrichten mit einer Id und > Befehl an die 88er schicken und der entsprechende 88er reagiert darauf, > führt Messungen durch und antwortet dann, wenn er fertig ist. Eine Funk-Lösung wär bei bis 15m wesentlich simpler und flexibler. Denn das schaut nicht nach einem großen Datenvolumen aus.
Gerhard H. schrieb: > Eine Funk-Lösung wär bei bis 15m wesentlich simpler und flexibler. Klassiker: Wer Funk kennt, nimmt Kabel.
Harald K. schrieb: > Klassiker: Wer Funk kennt, nimmt Kabel. Meinst Du? Da hab ich aber gegenteilige Erfahrungen, mit mehreren seit Jahren laufenden Funknetzwerken und ähnlichen Aufgaben. Doch sei's drum. Wenn die Kabel schonmal da sind wollen (müssen) sie wohl genutzt werden :) Wer Kabel kennt nimmt Funk. Ausnahmen lass ich da in üblicher häuslicher Umgebung nur bei drei Punkten gelten: - hohes Datenvolumen - mitgeführte Spannungsversorgung - Gegnerschaft "überempfindlicher" Hausbewohner
Gerhard H. schrieb: > Ausnahmen lass ich da in üblicher häuslicher Umgebung Freistehendes Einfamilienhaus ohne Störeinflüsse aus der Nachbarschaft? Dann mag das zutreffen. Ich wohne in einem Mehrfamilienhaus, und hier brüllen locker über 30 verschiedene WLANs und ungezählte DECT-Stationen in die Gegend, ganz zu schweigen von Zigbee- und Bluetooth-Geräten.
Harald K. schrieb: > Ich wohne in einem Mehrfamilienhaus, Ich auch. > und hier brüllen locker über 30 > verschiedene WLANs und ungezählte DECT-Stationen in die Gegend, ganz zu > schweigen von Zigbee- und Bluetooth-Geräten. Das sollte Dir eigentlich was drüber verraten wie robust Funknetzwerke heutzutage sind. Allerdings brauche ich nicht im Bereich der Mutmaßung bleiben, ich weiß ja daß es problemlos funktioniert. Übrigens auf 433/868 MHz genauso wie bei 2,4 GHz (802.15.4) ... "Wer Funk kennt nimmt Kabel" nenn ich eine Losung vergangener Zeiten bzw. eine der Kabel-Lobby :)
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.