www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USART im Multiprozessor Mode oder SPI?


Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Gruenschnabel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/mikrocontrol...

Außerdem ist ein Beispiel 
angeführt:http://www.wiki.elektronik-projekt.de/mikrocontrol...

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wie lässt sich zum Beispiel die Adressierung am besten realisieren?
>Wie ist das 9. Bit zu handlen?

Programmiersprache?

MfG Spess

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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“

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS485 tut´s völlig. Und der finanzielle Aufwand bleibt auch im Rahmen.

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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…

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Gruenschnabel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Perfekt!
Danke, genau so etwas in der Art habe ich gesucht!

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.