Liebe Forenmitglieder, ich hätte eine Frage bezüglich einer Busstruktur in einem Projekt von mir. Es geht um folgendes: Ich habe einen ATMega64, der als Master arbeitet. Dieser ist an einen Bus angeschlossen, an dem 30-40 (genaue Zahl ist noch nicht fixiert) ATMega 16 hängen (Slaves). Nun muss des Mega64 Daten an die Slaves verteilen. Die Controller sind maximal 3 Meter auseindander, also keine aufregenden Kabellängen. Des weitern senden die Slaves keine Daten zurück, also die Kommunikation findet nur in eine Richtung statt. Nun habe ich in der Vergangenheit noch nichts derartiges gebaut und wollte mal hier nachfragen, ob ihr mir ein paar Tips für die Realisierung geben könnt. Habe mich schon im Internet eingelesen, allerdings hat dies nur beschränkt meine Entscheidungsfähigkeit beeinflusst. Grundsätzlich stelle ich mir die Frage: SPI oder USART im Multiprozessor Mode. Habe im Internet gelesen, dass die SPI teilweise relativ anfällig für Störeinflüsse ist (könnte ein Problem sein, da ich in der Umgebung Leiter mit relativ hohen Störmen (~2A) habe). Aber dies könnte man ja durch gut geschirmte Kabel unterdrücken? Hätte daran gedacht USB2.0 Kabel zu missbrauchen, da die recht günstig und gut geschirmt sind. Über USART im Multiprozessormode kann ich nur spärlich Informationen finden. Funktioniert das anständig? Bitte um kurze Aufklärung :) Danke vielmals!
Was meinst Du mit USART? Du musst Dich schon zwischen UART (asynchron) oder USRT (Synchron) entscheiden, wenn Du das USART benutzen willst. Asynchron, also RS232 bzw. UART geht gut mit einer Leitung (und Masse), braucht aber Quarze an den Controllern. Der Multicontrollermode nutzt das neunte Bit zur Unterscheidung zwischen Controllerwahl und Daten. Alle Slaves außer dem Adressierten ignorieren den Datenfluss, der Master kann also den gewünschten Slave aktivieren und dann mit Daten zuschütten, während alle andere Slaves weghören. Zu USRT kann ich nichts sagen, das habe ich mir mangels Bedarf noch nicht näher angesehen. SPI braucht normalerweise für jeden Slave eine CS-Leitung. Man kann es auch anders organisieren, muss das Protokoll aber selbst schreiben. Z.B. kann man mit einer Steuerleitung zwischen Adressierung und Daten umschalten und mit der Adressierung alle nichtgemeinten Controller deaktivieren. Es ist auch möglich, einen Ring aufzubauen und die Daten mit einer Strobe-Leitung in die Slaves zu übernehmen. Das ist aber nur dann sinnvoll, wenn mit jedem Telegramm alle Controller gleichzeitig ein neues Datenbyte bekommen sollen. Viele Wege sind möglich, welcher der günstigste ist, hängt von Deiner Anwendung ab. ...
Nimm die UART im Multiprozessormodus und entweder CAN-Bustreiber (kollisionsfest) oder gleich RS485-Treiber. Sofern die Anzahl der Slaves die Grenzen der Bustreiber übersteigt, kann man Repeater einsetzen. Auch wenn die Slaves zur Zeit nichts zurückschicken sollen, den Weg würde ich mir immer offen halten. Selbst wenn die Slaves nicht weit auseinanderstehen, würde ich auch eine galvanische Trennung der Module (Optokoppler) zumindest als Option offen halten. Das hängt auch vom (störenden) Umfeld und der Stromversorgung ab.
Erst mal danke für die Antworten! Das Stichwort RS485 ist schon mal gut. Hab mich ein bisschen eingelesen, scheint ein sehr brauchbares System zu sein. Hier ist der Bus recht einfach und brauchbar beschrieben: http://www.wiki.elektronik-projekt.de/mikrocontroller/rs485_bus Außerdem ist ein Beispiel angeführt:http://www.wiki.elektronik-projekt.de/mikrocontroller/rs485_bus#beispiel Mir ist bewusst, dass es kein standartisiertes Protokoll für den Bus gibt, allerdings gibt es doch sicher (vielleicht auch von Usern hier im Forum) Anwendungsbeispiele etc. an dem ich mich orientieren kann, ich muss ja das Rad nicht neu erfinden? Wie lässt sich zum Beispiel die Adressierung am besten realisieren? Wie ist das 9. Bit zu handlen? Was wird mir von der Hardware abgenommen bzw. was ist softwaremäßig zu realisieren? Sorry für die vielen Fragen, aber mir sind viele Dinge bei diesem Thema unklar und es lassen sich nicht viele Informationen zu diesem Thema finden. Selbst das sonst so umfangreiche Handbuch des ATMega32 gibt nur eine magere Seite bezüglich MPCM her. Danke vielmals, Hans
Hi >Wie lässt sich zum Beispiel die Adressierung am besten realisieren? >Wie ist das 9. Bit zu handlen? Programmiersprache? MfG Spess
Ich sehe dass du wenig Erfahrung hast. Kannst dir vorstellen wie viel Erfahrung würdest du brauchen um das alles unter z.B. RS-485 zu realisieren. Das alles hast du mit dem CAN-Bus schon fertig. CAN-Bus ist das Beste was man für solche Fälle nehmen kann. Jede Nachricht hat feste ID und du hast keine Kollisionen. Egal mit was für einen Prozessor du verwendest. Nur CAN-Bus garantiert dir Erfolg. Lässt sich nicht blenden mit dem „xxx für wenig Geld im LAN“
Hi Ich sehe dass du wenig Erfahrung hast. Kannst dir vorstellen wie viel Erfahrung würdest du brauchen um das alles unter z.B. RS-485 zu In seinem Fall nicht mehr als eine RS232. > Das alles hast du mit dem CAN-Bus schon fertig. CAN-Bus >ist das Beste was man für solche Fälle nehmen kann. Mit ATMega64/16???? MfG Spess
RS485 tut´s völlig. Und der finanzielle Aufwand bleibt auch im Rahmen.
RS485 ist Busfähig aber du muss selber den ganzen Softkram schreiben. Mit dem CAN-Bus hast du das alles fertig inklusiv die Vermeidung von Lästigen Kollisionen. Mit einem AVR lässt sich auch CAN-Bus realisieren? Ich verstehe die Abneigung gegen den CAN-Bus nicht. In meinem Leben habe ich das alles erlebt und ich schreibe das aus einem Distance. Ausserdem man muss immer „Reserve für zukünftige Entwicklung haben“. Wenn jemand bei der Programmierung eine feste Zahl vorschreibt, dann für mich bedeutet das immer „X“. Gute Sachen sind immer einfach…
Entschuldigung, hab ich vergessen anzuführen: Ich programmiere in "C". Ja, es ist richtig, gerade in Sachen Bussystemen habe ich sehr wenig Erfahrung (dies ist ja gerade der Grund, dass ich mich hier im Forum zu Wort melde). In sachen uC lässt sich sehr viel über das Internet lernen und verstehen, es gibt viele Tutorials und Erkärungen. Bedauerlicherweise ist das in sachen Busverbindungen nicht so. Gerade zur UART im MPCM findet man so gut wie nichts. Soweit so gut, ich brauche jedenfalls für ein Projekt einen Bus, also muss ich mich damit auseinandersetzen (außerdem interessiert mich das Thema privat auch :) ). Ich weiss einfach nicht woher ich meine Informationen beziehen soll (ich erwarte mir von euch ja nicht dass ihr über das Forum den kompletten Bus erklärt, nur ein paar Tips wären hilfreich). Zum CAN-Bus: warum sollte der so erfolgsversprechend sein? Bis jetzt hat er mich eher abgeschrekt, weil das Protokoll (für meine verhältnismäßig einfache Aufgabenstellung (Datenverkehr nur in eine Richtung etc.)) ziemlich kompliziert ist. Das ist meine Einschätzung, ihr seid aber herzlich eingeladen mir das Gegenteil zu erklären :) Weiß keiner wo ich mir mal ein einfaches Projekt mit Single Master/Multi Slave Busen ansehen könnte? Einfach damit ich mal einen Überblick bekomme wie so etwas in der Realität gelöst wird. Ich finde diese Projekte, die auf diversen Elektronikseiten zu finden sind immer sehr interessant und Aufschlussreich. Leider kann ich - wie schon erwähnt - keine zum Thema "Bus" finden. Danke!
Zur Klärung: Ich hatte CAN-Bustreiber vorgeschlagen, aber kein CAN-Bus Protokoll mit entsprechenden Bausteinen. Das wäre völlig überzogen. Mit RS485-Treibern braucht man neben den RXD- und TXD-Signalen noch ein Signal zur Richtungsumschaltung, wenn man bidirektional übertragen möchte. Das würde ich auf jeden Fall beschalten, aber zunächst bei den Slaves nur auf Empfangspegel setzen. Das MPC-Protokoll ist simpel. Beim Versenden einer Nachricht wird das Zeichen (Byte) zur Adressierung mit gesetztem 9. Bit verschickt. Alle Slaves sind so programmiert, daß bei gesetztem 9. Bit ein RX-Interrupt ausgelöst wird. Die gesendete Adresse wird mit der eigenen verglichen und der Empfang fortgesetzt, wenn beide übereinstimmen. Ist die gesendete Adresse nicht die eigene, wird der Interrupt abgeschaltet und der restlich Datenverkehr ignoriert. Erst bei neuer Adressierung wird wieder ein Interrupt bei allen Slaves ausgelöst. Ohne weitere Erklärung hänge ich eine Empfangsroutine an; sollte so verständlich sein. Wenn das zu kompliziert sein sollte, mache Dir Dein Protokoll selber. Beispielsweise kannst Du eine beliebiges Zeichen als Startzeichen einer Nachricht nehmen, dem dann direkt die Adresse folgt; meinetwegen auch dezimal. z.B. $34..... Der $ darf dann aber nicht mehr als reguläres Zeichen in der Nachricht auftauchen.
Perfekt! Danke, genau so etwas in der Art habe ich gesucht!
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.