Archiv verlassen und diese Seite im Standarddesign anzeigen : bidirektionale Alternative zu I²C: RS232
Hallo,
Ich habe folgendes Problem:
Ich habe mehrere AVR's und diese sollen dann bidirektional Daten austauschen. Da reicht I²C nicht mehr aus.
Könnte man nicht alle mit MC's mit der seriellen Schnittstelle (also dieses RS232) verbinden.
Schon ma Danke.
mfg God
Matthias
09.05.2004, 08:56
Ja, einfach TX des Ersten mit RX des Zweiten, dessen TX mit dem RX des Nächsten usw.
Nennt mein auch Ringbus. Die Daten werden so lange weitergeschickt, bis sie den Richtigen erreicht haben.
Matthias
Ok, schickt der MC das dann automatisch zum nächsten weiter? Oder wie?
mfg God
Das mußt Du selbst machen. Immer wenn was rein kommt was nicht für dich bestimmt ist, dann einfach weiter zum nächsten schicken.
Minifriese
09.05.2004, 12:19
Moin,
Klappt das tatsaechlich? Ich dachte immer, man braucht beide Leitungen von der RS232, auch um nur ein Telegramm zu senden. Wenn jetzt der erste und zweite Teilnehmer des Ringbusses nur ueber die Leitung zwischen TX1 und RX2 verbunden sind, wie funktioniert denn da die Flusskontrolle? Sind RS232 nicht nur fuer Punkt-zu-Punkt-Verbindungen gedacht (z.B. zwischen PC und Modem oder so)? Was ist mit den uebrigen Leitungen der Schnittstelle? Werden die auch ringfoermig verdrahtet??
Nils
Die Flußcontrolle, also die übrigen Leitungen braucht man in der Regel nicht. RX und TX reichen. Das sollte schon so gehen
Allerdings sind die Möglichkeiten vom I2C Bus wesentlich vielfältiger. Beschäftige mich gerade damit etwas intensiver. Da können sogar mehrere Master vorhanden sein und wechselseitig senden ohne sich abzusprechen
Minifriese
09.05.2004, 12:41
Jo, dass RX und TX reichen, hab ich auch schon gehoert. Aber in so nem Ring hast du ja zwischen zwei Teilnehmern nur einen Draht (von TXA auf RXB). Wie soll das gehen?
Ok, Vielen Dank erstmal.
Das mit dem Ringbus leuchtet mir ein. Könnte man auch einfach alle Rx und Tx von den MC's verbinden?! Oder geht da was kaputt oder schließt sich kurz?
mfg God
Dino Dieter
09.05.2004, 13:02
Hallo
Wenn du mehr als 3 oder 4 uC verbinden möchtest, würde ich mir mal RS485 anschauen.
MFG
Dieter
Jo, dass RX und TX reichen, hab ich auch schon gehoert. Aber in so nem Ring hast du ja zwischen zwei Teilnehmern nur einen Draht (von TXA auf RXB). Wie soll das gehen?
Ein Draht reicht für die Übertragung in eine Richtung aus da bei des RS232 ja eine feste Geschwindigkeit zur Übertragung genutzt wird, daher braucht man keine Rückmeldung.
Daher gibts aber auch manchmal Übertragungsfehler!
Das mit dem Ringbus leuchtet mir ein. Könnte man auch einfach alle Rx und Tx von den MC's verbinden?! Oder geht da was kaputt oder schließt sich kurz?
Würde ich nicht machen! Denke schon das da ein Baustein schaden nehmen kann, zumindest bei TX! Mit RX gehts vielleicht
das kann ja nicht funktionieren
wenn du alle rx verbindest, wer soll dann auf rx was senden? du musst rx und tx ja immer kreuzen.
Das mit dem Ringbus sollte klappen. Aber ich würde mir auch mal das RS485 Netzwerk anschauen. Evtl. kannst du auch CAN verwenden. Je nachdem, was du machen willst
Grüße Flite
das kann ja nicht funktionieren
wenn du alle rx verbindest, wer soll dann auf rx was senden? du musst rx und tx ja immer kreuzen.
Einer müsste natürlich per TX verbunden sein! Aber selbst wenn es geht, dann ja nur in eine Richtung.
Ringbus oder I2C ist schon interessanter. RS485 natürlich auch, aber da braucht man wieder etwas Hardware (Max485 hat nicht jeder am Board)
Matthias
09.05.2004, 19:34
Man kann sich einen kleinen Adapter, den man (z.B. bei der C-control) in die MAX232-Fassung steckt basteln.
Das mit dem Ringbus leuchtet mir ein. Könnte man auch einfach alle Rx und Tx von den MC's verbinden?! Oder geht da was kaputt oder schließt sich kurz?
Würde ich nicht machen! Denke schon das da ein Baustein schaden nehmen kann, zumindest bei TX! Mit RX gehts vielleicht
Würde es vielleicht gehen, wenn man vor den Tx Dioden setzt? Bei Rx müsste das ja wie gesagt gehen.
mfg God
Möglich! Aber Ringbus ist besser. Oder eigenen Bus aus ein paar Datenleitungen basteln, so wie man ihn braucht!
Danke,
aber bei einem eigenen Bus müsste man ja auch noch das ganze Protokoll programmieren, wär aber ne nette Herausforderung.
mfg God
würde bei diesem Ringbus dann nicht praktisch wenn man etwas zum MC davor (also dessen TX an Senders RX anliegt) senden will erst durch den kompletten Ring gehen statt direkt zu dem MC der daneben liegt.
gruß Fengel
So ist es! Aber der geringe Zeitverlust dürfte bei 3 bis 5 Teilnehmern oft hinnehmbar sein. Ich finde das schon recht praktisch da sich jeder mit jedem verständigen kann.
über den I²C Bus sollte es doch auch möglich sein bidirektional zu kommunizieren. Es ist doch prinzipiell möglich mehrere Master an einem Bus zu betreiben, die sich gegenseitig die Steuerung übergeben.
Habe ich schon mehrfach gelesen !!!
Ja das geht mit dem I2C-Bus sogar sehr einfach ohne Absprache unter den einzelnen Slaves/Mastern. Wenn beide Leitungen High haben kann jeder anfangen zu senden. Im übrigen nicht nur an einen Slave sondern auch gleichzeitig an mehrere, falls die die gleiche Slave Adresse haben.
Es gibt natürlich den seltenen Fall das versehendlich 2 oder mehr Master gleichzeitig beginnen zu senden. Aber auch das ist kein Problem, da dies die offizielle Norm vorsieht. Jeder Controller muß beim belassen des High Pegels auf einer Datenleitung prüfen, ob die auch noch High ist. Wenn mehrere gleichzeitig senden wird irgendwann einer statt High Low senden wollen. Das wird dann von den Slaves die High senden wollen zum Anlass genommen sich einfach zurückzuziehen. Somit kommt immer der Slave durch, der Datenübertragung mit den meisten Nullen beginnt.
Eine einfache aber praktikable Lösung die so von Philips vorgesehen ist.
Das einzige Problem scheint mir, das viele I2C Routinen die so im Umlauf sind noch nicht ganz korrekt diesen Umstand berücksichtigen. Einige prüfen noch nicht mal den Signalpegel nach sondern senden sturr weiter. Da oft beim I2C Bus nur der Master Slave Mode genutzt wird funktionieren diese Treiber dann auch oft.
Der bidirektional Mode beginnt aber langsam mehr Freunde zu finden, so das die Treiber besser werden sollten.
Gruß Frank
Ich habe mir jetzt das neue Roboternetz-Board bestellt (so zum Einsteigen).
Bei diesem sind doch 2 Controller drauf die auch über I²C Kommunizieren können. Da schlägst Du doch in der Doku vor einen Programmgesteuerten "Master-Switch" zur Kommunikation zu verwenden.
Wenn man den "Master-Switch" bei allen angeschlossenen Controllern implementiert sollte es doch möglich sein ohne Probleme Daten bidirektional auszutauschen (mit entsprechenden Aufwand).
Wo ich gerade dabei bin :
Ist der I²C Bus bereits auf den Atmel Controllern (speziell Mega16) eingebaut (wovon ich ausgehe) oder wurde dieser auf dem Board mit Zusatz-Bausteinen realisiert ?
Prinzipiell wäre es ja denkbar einen zweiten Bus einzusetzen damit die Controller kommunizieren können ohne "Master-Switch". Problem wird aber sein das die Controller vermutlich nur einen I²C Bus haben , oder ?
Dies führt mich dann zur Frage wie man Subsysteme realisiert, wenn man nur einen Bus hat ? Mit 2 I²C Bussen wäre das wunderbar. Sonst müsste man ja den RS-232 nehmen und ein eigenes Kommunikationsprotokoll entwickeln.
Ja, das mit einem Master Switch geht natürlich. Aber wie im Beitrag zuvor erwähnt, ist es eigentlich viel einafcher möglich. Die Master müssen sich nicht absprechen. Jeder kann senden wenn I2C-Bus gerade frei ist. Es ist nur wichtig das man I2C-Routinen verwendet die das auch können.
Da ich meist in Bascom programmiere nehme ich oft die bascom Funktionen. Die sind schon ganz gut implementiert, ich hab jedoch noch nicht 100% ausgetestet ob die Probleme mit dieser Betriebsart haben da ich gewöhnlich eigentlich nur in eine Richting übertrage.
Das kann man aber recht einfach ausprobieren indem du ein Programm schreibst das eine LED´s am Powerport blinken läßt. Das gleiche Programm aber für andere LEDs schreibst du für CoController. Man müsste dann optisch nur genau prüfen ob es nicht irgendwann doch eine Kollision/Aussetzer bei einer LED gibt. Man könnte auch eine etwas aufwendigeres Programm schreiben wo sich die Controller gegenseitig Nachrichten schicken.
Der Mega hat auch einen Hardware I2C-Port. Das heißt er kann auch über Register angesteuert werden. Die wird abe rnoch nicht von bascom unterstützt, wäre also etwas aufwendiger. In den nächsten Wochen will der Bascom Entwickler aber hier was nachliefern. Der Co-Controller hat keine I2C-Bus Hardware Unterstützung!
Mehrere unterschiedliche I2C-Busse wären denkbar, aber eigentlich wäre es ja dann kein Bus mehr wenn man für jedem Slave ein Bus nimmt ;-)
Ne, ich meinte ja nur den 2ten Bus zur Kommunikation zwischen den Controllern. So ne Art geheime Kommunikation von der die Sklaven nichts mitkriegen.
Eigentlich habe ich jetzt gedacht, daß das Problem von den Controllern oder den anderen I²C Komponenten ausgeht. Also nicht 100%ig nach den I²C Spezifikationen arbeiten und somit die Verwendung von mehreren Mastern erschwert.
Habe ich das jetzt eigentlich richtig verstanden:
Der Mega16 hat einen hardware I²C Bus, welcher aber bei Verwendung von Bascom nicht unterstützt wird. D.h alles wird softwareseitig erledigt womit sich auch softwareseitig ein I²C Bus auf dem Co-Controller realisieren lässt (bzw. bei Bascom als fertige Library zur Verfügung steht?
Also die fertigen i2C Komponenten wie die PCF-Bausteine etc., die unterstützen sicherlich das I2C Protokoll richtig. Nur halt selbst programmierte I2C Softwaretreiber sind nicht immer ganz perfekt, sicherlich stecken da auch in so manchem Compiler Libarys noch ein paar Bugs!
Ja der i2C-Bus wird von Bascom rein softwaremäßig gesteuert. Die Befehle sind aber in der Libary. Im übrigen ist so eine Software Implementation garnicht so sehr lang. Nur weil es halt noch schneller ging ohne an Master Master zu denken, haben da einige im Assemblercode etwas geschludert. Aber für die üblichen I2C Bausteine reichen auch diese "geschluderten" Implementationen.
Wie gesagt, der Bascom ENtwickler arbeitet daran die I2C hardware Register zu unterstützen. Wenn das fertig ist, dann wird man das nach außen ganricht merken. Vermutlich braucht man dann noch nicht mal Basic Programm ändern sondern nur neu compilieren. Der Vorteil der Hardware Unterstützung ist der, das der Controller entlastet wird. Die i2C Ports müssen dann nicht ständig kontrolliert werden, ein großen Teil der Zeit nimmt der Controller dann ab. Er meldet sich dann glaub erst wenn er als Slave angesprochen wird.
Na, dann lassen wir uns mal überraschen !
Wo wir gerade bei Bascom sind.
Ich habe gelesen, daß es die Möglichkeit gibt den AVR mit C++ zu programmieren (mit AVR GCC). Was mich interessiert ist die OO-Programmierung, weil ich hauptsächlich nur noch so programmiere (in PHP).
Gibt es für die C++ programmierung des AVR hier irgend ein Tutorial ? Hab da nichts gefunden.
Wenn es nicht C++ sein muss, sondern auch normales C sein kann gibts ein paar Sachen:
http://www.kreatives-chaos.com/index.php?seite=avrgcc
Und noch ein Tutorial speziell für C:
http://www.mikrocontroller.net/articles/c/Index.htm
http://www.kreatives-chaos.com/count.php?datei=Atmel.zip
MfG Kjion
Ok, danke.
Ich denke ich werde das Roboterboard erstmal zusammenlöten
und dann die Bascom Testprogramme laufen lassen.
Danach könnte ich mir vorstellen die Programme in C umzuschreiben
um danach auf C++ umzusteigen.
(Es gibt ja zw. C und C++ keinen riesigen Unterschied).
Ich liege aber richtig damit dass es definitiv möglich ist mit C++ (mit AVR GCC) den Mega16 zu programmieren ?
ich hoffe Speicher und Leistung des Controllers reichen aus !
Ich glaube ich bin hier etwas am Thema des Threads vorbeigeschrammt.
Ich poste das noch woanders (ich such mal wos reinpasst.)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.