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