Hallo,
ich habe folgendes Problem: Mehrere µcs sollen miteinander verbunden
werden und Daten austauschen. Siehe Bild:
| | | |
+----+ +----+ +----+ +----+
| | - | | - | | - | |-
|µC1 | |µC2 | |µC3 | |µC4 |
+----+ +----+ +----+ +----+
| | | |
+----+
- | | -
|µC5 |
+----+
| | |
+----+ +----+ +----+
- | | - | | - | |_
|µC6 | |µC7 | |µC8 |
+----+ +----+ +----+
| | |
+----+
- | | -
|µC9 |
+----+
|
Ein µC soll also immer mit seinen direkten Nachbarn kommunizieren. Es
ist auch wichtig wo sich die Nachbarn befinden
(vor/hinter/links/rechts). Beispiel: 7 muss mit 5,6, 8 und 9 reden
können, 6 allerdings nur mit 7. Es sollen also flexible µCs mit 4
Kommunikationsschnittstellen entstehen, die man beliebig zusammen
koppeln kann. Man soll es nach belieben um weitere µCs erweitern können.
Wir dachten zuerst an UART, aber wir brauchen an jedem µC eine UART für
eine andere Anwendung.
Wie könnte man dies lösen? Vielleicht einen weiteren UART an jedem µC
dazu, aber wie geht das?
Vielen Dank schon mal für Eure Hilfe.
Wenn die Topologie nicht zwingend vorgeschrieben ist: Hausbus-Technik,
d.h. jeder kann technisch mit jedem über shared media. Ist auf jeden
Fall flexibler als solch ein mesh.
Hi,
wieviele Daten werden denn ausgetauscht und wie zeitkritisch ist der
Vorgang?
Wenn beides in ertraeglichen Bereichen liegt waere ein simples Bussystem
doch auch gut, oder? Jeder uC bekommt seine eigene ID. ist die
kommunikation immer zielgerichtet wars das schon, ist sie "variabel"
koennte jeder uC ausserdem eine kurze tabelle (max 4 bytes gesamt) mit
den ids der kommunikationsberechtigten nachbarn.
der rest ist ein relativ einfacher softwarebus...z.b. I2C.
der ist relativ einfach aufgebaut, braucht nur 2 portpins und
entsprechende softwareimplementierungen finden sich fuer alle gaengigen
controller zuhauf.
Hallo,
@ lippy: Jeder µc soll vier Kommunikationsaus/eingänge haben. Da reichen
dann zwei UART wohl nicht und wir brauchen auch jeweils noch eine freie
UART. Meiner Rechnung bräuchte ich fünf.
|
+----+
- | | -
|µC5 |
+----+
|
@ all: Datenmenge fällt an ist aber nicht so wichtig. Hauptprobleme
sind:
1. alle µcs sollen wie der hier abgebildete 5 sein, d.h. man kann sie
beliebig an andere µcs koppeln.
2. Es können auch Stern/Linien/Schleifen-Anordnungen entstehen. Deshalb
soll jeder µc auch nur wissen wer seine direkten Nachbarn sind und auch
mit diesen maximal vier kommunizieren. Da es nicht eine reine
Linienschaltung wird denke ich, dass Bus Systeme auch nichts werden.
Dachte erst an CAN.
hey,
als ich das gelesen habe, habe ich erstmal das autor fld gesucht und
wollte nachschauen ob ich das geschrieben habe!
Das ist exakt gleich zu dem was ich auch will.
Ich nehme zwei atmega162 welche ich über eine parallele Schnittstelle
verbunden habe. Somit habe ich allerdings nur 4Schnittstellen.
Zurzeit suche ich noch Material für Layer1 und L2. Für L3 habe ich
eventuell schon eine Idee aber ich weiß selber noch nicht genau wie
sauber ich das alles für meinen zweck implementieren muss
Planst du auch so dinge das dann Verbindungen über dieses Netzwerk
getunnelt werden können?
>2. Es können auch Stern/Linien/Schleifen-Anordnungen entstehen.
Was soll das denn werden? Reicht es nicht, wenn jeder µC mit jedem
anderen über ***einen gemeinsamen Bus*** ("Keep it simple, stupid!")
kommunizieren kann (*)? Wenn ein weiterer C dazukommen soll, wird er an
den Bus gesteckt, mit einer eindeutigen ID versehen - fertig. Im
Fünfeck oder herzförmig oder baumstrukturiert auf den Tisch legen kannst
Du Deine 28 Controller dann ja immer noch.
Just my 2 cents...
(*) Ja, es gibt Fälle, wo das nicht reicht, z. B. wenn die Zeit bei
großen Datenmengen eine Rolle spielt. Du hast aber geschrieben, dass
das kein kritischer Punkt bei Dir ist.
Also es könnten durchaus mehrere Hundert µcs werden. Und die sind auch
nicht alle in Reihe. Könnte z.B so aussehen:
******
*
*
**********
*
* *****
******
***
Jeder Stern ein µc. Man könnte es beliebig fortsetzten. Und dann geht es
mit einem Bus in Linienstrukutur einfach nicht.
Ich habe soetwas auch mal durchdacht...
Jeder uC hat 1 UART. Die TX-Pin geht an die RX-Anschlüsse der 4
Nachbarn. Dazu wird jeder RX-Pin mit einem Widerstand gegen High gezogen
und die 4 TX-Pins der Nachbarn werden über eine Diode entkoppelt.
Werden Daten gesendet, wird jeweils ein Adreßbyte vorangestellt (da gibt
es auch Hardware-Möglichkeiten mit dem 9. Bit), daß den Nachbarn
adressiert.
z.B. 1=links, 2=oben, 3=rechts, 4=unten
Beim Empfang kann man dann anhand der verwendeten Adresse erkennen, von
wo die Nachricht kommt:
1=rechts, 2=unten, 3=links, 4=oben !
Jetzt können sich die Nachrichten noch überlagern, also stören.
Also, numerierte Pakete, Prüfsumme und ACK-Pakete, oder so !
>Und dann geht es mit einem Bus in Linienstrukutur einfach nicht.
Ich sehe keinen Grund, warum es mit einem einzigen gemeinsamen Bus nicht
gehen sollte. Der Bus darf ja beliebig Abzweigungen haben,
vorausgesetzt, Du fährst ihn mit genügend niedrigen Taktraten.
>Also es könnten durchaus mehrere Hundert µcs werden.
Mehrere HUNDERT?? lach Ohne Dir zu nahe treten zu wollen: Ich glaube,
wenn Du diesem Projekt gewachsen wärst, würdest Du hier nicht solche
Fragen stellen...
Technisch einfach: Ein Controller mit 2 UARTs (z.B. Mega162) verwenden,
und die Links in eine Richtung betrieben, d.h. links rein rechts raus,
und dann am Ende ganz zurück nach links. Dann entstehen horizontale und
vertikale Ringe.
Bei niedriger Datenrate sind auch in Software gestrickte Schnittstellen
möglich. Ansonsten musst du dann Controller suchen, die 4 gleiche
Schnittstellen haben, was nicht allgemein üblich ist. 4x UART wird's
sicher irgendwo geben, aber nicht bei AVRs. Der LPC2294 hat 4x CAN (aber
144 Pins), was man auf kurze Distanz auch ohne Transceiver nur mit Diode
bewaffnet verwenden kann.
Alternative bei Bussen: Je Node 2 Busse, einer vertikal, einer
horizontal. Solange die Anzahl Nodes nicht in die Tausende geht ist das
kein Problem. Und Controller mit 2 gleichen Schnittstellen sind leichter
zu finden als mit 4. Bleibt dann die Frage, ob du in der Lage bist,
jedem Bus einen dedizierten Master zuzuordnen, oder ob die alle
gleichberechtigt sein müssen.
@AVRFAn: Danke für deine Hilfe, aber bitte halte dich von nun an zurück!
Zu deinem Bus: Mit zuvielen Stichleitungen funktioniert der nicht
mehr...
Vielleicht sollte ich meine Frage umstellen:
Wie bekomme ich FÜNF UART-Schnittstellen an ein µC? Dies ist für uns im
Moment die richtige Lösung dafür. Eine andere Idee wäre auch klasse.
Vielen Dank für Eure Antworten.
> Wie bekomme ich FÜNF UART-Schnittstellen an ein µC? Dies ist für uns im> Moment die richtige Lösung dafür. Eine andere Idee wäre auch klasse.TL16C554 extern anschliessen. Gibt 1x intern 4x extern. Oder die
internen durch beliebig viele DS2480 1-Wire/UART Bridges ergänzen.
Software SPI .. pro Kanal werden 3 Leitungen benötigt (wenn man
SlaveSelect fest auf Masse legt). Ist einfach zu implementieren und
recht schnell. Für 4 Kanäle braucht man 12 Pins. Evtl. pro Kanal noch
einen slaveselect leitung, dann sinds 16 leitungen.
Im Softwareprotokoll könnte man ja die Master/Slave zuweisung im Betrieb
umschalten
Ach ja: Warum eigentlich 5? Weil du irgendwo einen Herrn und Meister
sitzen hast? Den kannst du auch über einen der 4 anderen Links
einkoppeln, irgendwie addressieren muss du sowieso.
@ A-K: Das klingt alles interessant. Jeder µC muss nur mit den vier µCs
links,rechts,vor und hinter ihm kommunizieren.
Die vertikalen und horizontalen Ringe könnten eine Lösung sein, könntst
du mir das noch etwas genauer erläutern. Was passiert, wenn nur 3 µCs um
ein µC herum sind? Geht das dann auch noch.
Das Ziel ist, nicht jedes µC einzeln zu programmieren (außer einer
individuellen Erkennungsnummer).
> Die vertikalen und horizontalen Ringe könnten eine Lösung sein, könntst> du mir das noch etwas genauer erläutern. Was passiert, wenn nur 3 µCs um> ein µC herum sind? Geht das dann auch noch.
Solange du in der Fläche bleibst (also nicht in die dritte Dimension),
geht alles, egal wieviele Nodes. Dass dabei Ringe entstehen, die nur aus
einer Node bestehen, stört nicht.
> Jeder µC muss nur mit den vier µCs> links,rechts,vor und hinter ihm kommunizieren.
Über die unidirektionale Ringstruktur kann eine Node Information nur an
den rechten und unteren Nachbarn direkt weitergeben und nur von den
linken und oberen Nachbarn direkt erhalten. An die linken und oberen
Nachbarn kann er Information nur senden, in dem er in die andere
Richtung sendet und alle Zwischennodes die Information weiterreichen.
Um Unterschied zu Bussen jedweder Art hat man mit Punkt-zu-Punkt
Verbindungen wie dieser die Möglichkeit einer automatischen
Topologieerkennung.
Ja, wurde mir so gesagt. An dem UART sollen Daten eingelesen werden.
Zur "unidirektionale Ringstruktur" - kann man dann beliebig weitere µCs
anschließen ohne diese überall von Hand einzuprogrammieren - wenn ja,
dann könnte das ein Lösungsweg sein.
@ Ulrich: Wenn ich durch ein einen Zusatzbaustein noch ein
UART-Schnittstelle bekomme, dann sollte das gehen. Herr Kaiser hat ja so
etwas angedeutet, da lese ich mich gerade ein.
@ Ulrich: Ich weiß ja noch nicht genau wie es gelöst werden soll. Es kam
bei uns die Idee mit UART auf, da jeder µC nur mit den vier umgebenden
µCs reden muss.
An CAN hab ich auch gedacht, aber laut Wiki spricht da einiges dagegen,
viele Stichleitungen zum Beispiel, oder die Kabellänge die durchaus über
100 m gehen könnte.
> Zur "unidirektionale Ringstruktur" - kann man dann beliebig weitere µCs> anschließen ohne diese überall von Hand einzuprogrammieren
Klar. Nur sollte jede Node eine eindeutige ID haben, damit sie
adressiert werden kann. Beim Start läuft in jedem Ring eine
Topologieerkennung und jede Node kennt danach die IDs ihrer
unmittelbaren Nachbarn.
@ A-K: Eine eindeutige ID wird jeder bekommen.
Und dies würde auch bei folgender beispielhafter Topologie
funktionieren?
****
*
**********
*
* *****
******
***
Jeder * ein µC. Und beliebig erweiterbar in alle Richtungen (in zwei D
natürlich)
@ A-K: Ich wollte nur sicher gehen, dass ich es richtig verstanden habe.
Vielen Dank für Ihre Mühe.
Könnten Sie mir das nun erläutern, wie wir das ausführen müssen. Oder
gibt es vielleicht eine Seite im Netz auf der das erklärt wird?
Naja, was auch gelegentlich gemacht wird ist ein Ring.
Dabei braucht's pro Microcontroller nur einen UART. Tx des ersten
Controllers geht auf Rx des zweiten, Tx des Zweiten geht auf Rx des
Dritten ... und vom letzten Controller führt die Leitung wieder zu Rx
vom ersten Controller.
So kannst du mit jedem Controller kommunizieren (es braucht halt eine
Adresse dazu).
> wie funktionieren die freifunktnetze? Da gibts auch keinen Master und> trotzdem gehts.....
Weil dich bei solchen Netzen üblicherweise die Topologie garnicht oder
nur mittelbar interessiert. Du willst den Kollegen 12345 erreichen, wo
immer er sitzt, nicht aber den 2 Schritte nach Norden und dann einen gen
Westen. Wenn jedoch die Anordnung bildhaft relevant ist, muss die auch
jemand kennen. Oder steckt in der Kommunikationstruktur bereits drin.
@Andreas:
ja, theoretisch schon. Aber das Problem lässt sich einfach lösen:
Die uCs haben (mal angenommen) an allen Portpins integrierte Pullups.
Nun - du machst eine Software, die über diesen Ring kommunizieren kann,
und gleich nach dem Reset überprüft die Software erst mal einen
festgelegten Pin. Ist er unbeschaltet (also High) so "konfiguriert" sich
die Software auf Slave; ist er Low (Weil man beim Master z.B. einen
Jumper gegen Masse installiert hat), so wird der uC Master. Und jetzt
sendet der Master nacheinander Telegramme, die jeweils eine neue Adresse
enthalten. Der erste Slave leitet das Telegramm nicht weiter,
stattdessen nimmt er die Adresse und behält sie für sich. Aber alle
anderen Telegramme leitet er weiter, und immer der nächste Slave, der
noch keine Adresse hat, nimmt sich die Adresse. Und wenn ein Telegramm
mit der letzten gesendeten Adresse wieder beim Master ankommt, weiss
der, dass alle Slaves nun adressiert sind - fertig ist der Ring.
Also ich finde das eine unheimlich intelligente Architektur... Verwende
ich zwar nicht, weil ich ja eh nur mit einzelnen uCs bastle, aber wenn
man sowas macht... Einziger Nachteil des Rings:
- Slaves, für die die aktuelle Nachricht nicht bestimmt ist, müssen sie
weiterleiten -> belastung der CPU
- Wenn irgendwo im Ring eine Leitung unterbrochen ist, funktioniert der
ganze Ring nicht mehr....
Hallo Dirk,
Du könntest Dir auch selbst eine 1-Anschluß Schnittstellte basteln. Ich
habe das mal für die Atmegas experimenthalber gemacht:
http://www.roboterclub-freiburg.de/AtmelAVR/Software/chEinAnschlussKom_V1.0.c.zip
Man könnte die Kommunikation mit den 4 Nachbarprozessoren dann mit
getrennten Pins realisieren.
Gruß,
Christoph
Dürft ich Fragen, was das Projekt für einen Sinn hat bzw. was du
überhaupt baust?
Ich glaube wenn das geklärt lässt sich vllt. das Problem besser
analysieren bzw. lösen.
> Mehrere HUNDERT?? lach Ohne Dir zu nahe treten zu wollen: Ich glaube,> wenn Du diesem Projekt gewachsen wärst, würdest Du hier nicht solche> Fragen stellen...
Ich lese erst seit kurzer Zeit mit und wundere mich immer wieder über
einige Newbies, die verstehen nicht wie ein Pin umgeschaltet wird und
wollen allerhand entwickeln, oder fragen wie ein Befehl in VB aussehen
muss um den uP auszulesen. Ich habe mir (noch vor der Internetzeit)
eigentlich fast alles selbst angeeignet durch Lesen von Büchern,
Programmierung in meiner Freizeit,...). Vorher ein Elektrotechnik
Studium, war nützlich für die Grundlagen. Dann habe ich eine Firma
gegründet und bin jetzt 7 Jahre selbständig und noch nicht Pleite - es
funktioniert also. Manche glauben hier, alles sei simpel und für jede
Aufgabe gäbe es einen fertigen Code in der Codesammlung oder im Netz.
Ohne Know How (wie fließt Strom, HF, uP, Stromteiler, Spannungsteiler)
ist es schwierig.
