bidirektionale Alternative zu I²C: RS232

[matren]

ü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 !!!

[Frank]

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

[matren]

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.

[Frank]

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

[matren]

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?

[Frank]

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.

[matren]

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.

[Kjion]

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...atei=Atmel.zip

MfG Kjion

[matren]

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.)