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.
Ich denke, I2C oder ähnliches ist da besser geeignet. Oder evtl. SPI? Ist nur so ne Idee. Wie schnell muss das ganze denn sein? Ralf
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.
Erinnert stark an das Konzept der Transputer aus den Anfang 90'. Parallelprocessing mit vier Highspeed-Kommunikationskanälen zu den Nachbarn...
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.
@ WARUM FÜNF? Wir brauchen an jedem µC einen freien UART an dem wir etwas anschließen.
> 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.
> @ WARUM FÜNF? Wir brauchen an jedem µC einen freien UART an dem wir > etwas anschließen. Und das muss unbedingt ein UART sein?
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.
kannst du nicht z.B. anstatt 5 einfach 4 machen und dort wo noch ein port frei ist einfach den 5. anschließen?
willst du auch noch redudanz erreichen? das wäre nämlich der einzigste Grund der gegen Ceien z.B. Can-Bus spricht
@ 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.
melde dich mal bei mir per email: fitBwyXEHfqqQArTsoRx <@> 1337group.de
@ 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?
Hi, zu Microcontroller mit vier gleichen Schnittstellen: Von TI gibt es MSP430 Microcontroller mit vier Hardware-SPI Schnittstellen. Schau einfach mal hier: http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?¶mResults=yes&familyId=342&uiTemplateId=PP-T-GSPA_T&techFamId=null§ionId=95&tabId=1200&appId=null&viewDeviceCallingPage=null&totalCount=130&showAdditionalParameters=no&lc=2000062&lc=2001227&lc=2001220&lc=2001219&lc=2000886&lc=2000121&lc=2001132&compare=yes&download=yes&sort=yes&customize=yes¶mResults=yes¶mCriteria=yes&familyTree=yes&military=no&baSystem=yes¶mTable=no&sortOption=PA_PARAMETER_2000158&sortMode=DESC&searchPaths=1000342&pageId=342&templateId=0&navigationId=0&family=mcu¶mTable=no&military=no&ul=MSP430FW427&ul=MSP430FW425&ul=MSP430FW423&ul=MSP430FG4619&ul=MSP430FG4618&ul=MSP430FG4617&ul=MSP430FG4616&ul=MSP430FG439&ul=MSP430FG438&ul=MSP430FG437&&uiTemplateId=PP-T-GSPA_T&techFamId=null§ionId=95&tabId=1200&appId=null&viewDeviceCallingPage=null#rt Alle Modelle mit zwei USCI Modulen, wie z.B. den MSP430F2418. Lediglich deine UART-Schnittstelle müsstest du in Software emulieren.
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).
Benötigt aber einen Master, der die Tolopogie definiert, d.h. den Nodes die ID der jeweiligen Nachbarn mitteilt.
wie funktionieren die freifunktnetze? Da gibts auch keinen Master und trotzdem gehts.....
> 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.
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.