Habe da mal eine Frage: Ich möchte gerne mehrere ATmegas (16 oder 32er) miteinander kommunizieren lassen. Da ich mich mit I²C nicht auskenne und noch nie was damit gemacht habe, habe ich mir überlegt, einfach den UART der Controller zu verwenden. Hatte mir das folgendermaßen vorgestellt: Ich nehme einen Controller als Master und z.B. 2-3 Slave's. Die TX-Leitung des Masters wird auf alle RXs der Slaves geführt, und der TX der Slaves auf den RX des Masters. Somit würde alles was der Master sendet ja an den Slaves ankommen. In den Daten die der Master schickt würde ich dann eben einen Code einbauen, auf den dann immer nur ein einziger Slave anspricht und den nachfolgenden immer gleich langen Befehl dann umsetzt. Alle anderen verwerfen diese Nachricht. Die Slaves sollen später auch Daten an den Master senden können. Hierfür ist mir noch nicht ganz klar, wie ich das anstellen soll, aber irgendwann möchte ich auch das gerne eingebaut haben. Wie sieht das von der Hardware-Seite aus? Kann ich diese Datenleitungen des UARTS direkt verbinden, oder treten unerwünschte Effekte auf, wenn ich die Datenleitungen parallel an mehreren Controllern anlege?! Oder soll ich besser Dioden zwischenschalten? Dann bekäme ich aber Probleme wegen des TTL-Pegels?! Vielen Dank im Voraus für Eure Hilfe!
> und der TX der Slaves auf den RX des Masters.
Das geht so nicht. Da musst Du schon noch Logik dazwischenklemmen, da
sich sonst die Ausgänge gegenseitig kurzschließen. Ein AND-Gatter mit
entsprechend vielen Eingängen könnte helfen.
Oder mittels open collector Transistorstufen an eine mit PullUp nach Vcc gezogene Leitung klemmen. Prinzipiell reichen dafür auch schnelle Schaltdioden (1N4148) deren Anoden an die PullUp-Leitung geschaltet werden, die Kathoden gehen an die einzelnen TX-Pins der Slaves. Der Spannungsabfall über den Dioden ist noch innerhalb der Spezifikationen der Portpins.
Mach doch einen Ring: Der 1. Prozessor sendet an den 2. Prozessor, der 2. Prozessor sendet an den 3. Prozessor usw. Der letzte Prozessor sendet an den 1. Prozessor. Jeder Prozessor empfängt und sendet die Daten die nicht für ihn bestimmt sind unverändert weiter. Sollte ein Prozessor eine Nachricht senden wollen, hängt er sein Datagramm mit einer Empfänger ID und seiner Absender ID an das Ende der Daten, die er empfangen hat. Der Prozessor, für den die Daten bestimmt sind löscht das Datagramm aus dem Stream. So kann jeder Prozessor mit jedem anderen Prozessor kommunizieren.
@ Reiner: Ich möchte das Ganze gerne sternförmig. Denn wenn es später funktioniert, bin ich damit flexibler, und muss immer nur vom Master aus weg zu den Slaves fahren, und kann ganz einfach noch um einen weiteren Slave erweitern. @ Travel Rec.: Du meinst, dass der TX-Pin der Slaves einfach eine Transistorstufe schält, welche das Signal dann auf den RX-Pin des Masters gibt. Habe ich das richtig verstanden? PullUp zwischen Collector und Vcc, Emitter auf TX-Pin des Slaves, ja? @ Rufus: Da bräuchte ich bei 2 Slaves aber ja schon richtig viel Logik. Wenn ich das richtig verstanden habe, soll ich mit der Logik das ganze gegeneinander verriegeln, damit immer nur einer senden kann, oder? Vielen Dank für Eure Antworten :-)
Hallo, je nach Leitungslänge und Geschwindigkeit könnte auch Wired-OR gehen, PullUp an den RX des Masters, damit ist der H und in Ruhe. Die Slaves ziehen diesen Punkt über eine Diode (Anode zum Master, Kathode zum Slave-TX) dann auf L. Du muß natürlich dafür Sorge tragen, daß alle Slaves TX in Ruhestellung auf H halten und nur einer sendet. Gruß au8s Berlin Michael
> Da bräuchte ich bei 2 Slaves aber ja schon richtig viel Logik.
Stimmt, "richtig viel". Genau ein AND-Gatter mit zwei Eingängen und
einem Ausgang.
Davon sind vier in einem 74xx08 enthalten.
Wie beim von Michael und Travel Rec. beschriebenen Verfahren muss auch
hier darauf geachtet werden, daß "nicht redende" Slaves ihre TX-Leitung
auf High-Pegel halten, aber das ist bei einer nicht sendenden UART eh
der Fall.
Was soll denn R245 sein? Finde dazu nichts im Netz. Hoffe ich kann das bald testen, wenn ich wieder etwas Zeit habe. Vielen Dank für eure Antworten!
RS485 geht auch, ist bei langen Leitungen und im Multimasterbetrieb soagar von Vorteil. Dazu nutzt man den MAX485 oder günstigere Differenzialtreiber-ICs. Dieses 2-Leitungssystem arbeitet im Halbduplex, einer sendet, alle hören, dann sendet ein anderer, alle hören. Zur Umschaltung haben die Differenzialtreiber einen oder zwei Pins, die vom sendenden Controller angesteuert werden. Bei kurzen Leitungen (<3m) und niedrigen Baudraten (<56kBit) hingegen reicht die Diodenvariante bei einem Master vollkommen aus.
Noch viel einfacher ist es mit dem PC82C250 (CAN-Treiber, kann aber ohne Probleme für RS485 eingesetzt werden), da kann man sich die Umschaltung senden/empfangen komplett sparen, Kollisionen auf dem Bus sind zumindest physikalisch kein Problem mehr. Diese Treiber setze ich schon in mehreren Multi-Slave Projekten ein. Theoretisch ist auch Multi-Master möglich, sofern man per Software Kollisionen erkennen und behandeln kann.
Ich darf dich auf den Code verweisen, den ich mal gepostet hatte. Beitrag "RS485 Funktionen" Die Theorie hinter dem Protokoll ist hier beschrieben: http://www.drgw.net/~maverick/pmwiki.php/Electronics/MRBus Multi-Master-fähig, hohe Kollisionssicherheit, Paket-orientiert Grüße Michael
Werde mich bezüglich RS485 mal schlau machen und dies in Betracht ziehen. @ Michael Prd: Werde mir den Code später mal anschauen, eventuell ist das auch eine alternative, zumindest als Orientierung. Vielen Dank euch!
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.