Wiedereinstieg, nicht Neueinstieg. Ganz habe ich noch nicht alles vergessen
Ich meine, der i2c-Teil dürfte der einfachste Part sein, der Arduino hat hierzu eine Library, die man nur einbinden und eine Slaveadresse setzen muss. Der kniffeligere Part ist daher von Dir schon erledigt, nämlich die Kommmunikation mit dem FT-Universal-Interface. Im Prinzip geht es ja nur noch darum, bei eingehend Read-Kommandos die Eingänge auszulesen und zurückzuliefern und bei Write-Kommandos die Ausgänge zu setzen.
Das dürfte an einem Tag zu schaffen sein. Bei mir scheiterts am fehlenden RoboTX, wie gesagt, werde ich mir jetzt keinen mehr kaufen, sondern warten, dass der TXT i2c bekommt und dann den nehmen.
Im Prinzip bleibt es bei dem bestehenden Programm, zwei Kommandos zum Initialisieren der i2c-Verbindung kommen an den Anfang und in der Hauptprogrammschleife wird gefragt, ob ein Kommando anliegt. Im einfachsten Fall wird schlicht bei Write das empfangene Byte 1:1 mit den vorhandenen Routinen an das Interface gegeben bzw. bei Read das Byte an den Eingängen zurückgeliefert. Also ca. 10 Zeilen Code, den man ergänzen müsste. Das Ansprechen in RoboPro über wäre dann aber komplex, weil man die Bit-Operationen dort definieren müsste. Besser wären gleich Kommandos im Datenbyte nach dem Muster:
0001 0001 Ausgang 1 setzen
0001 0000 Ausgang 1 löschen
0010 0001 Ausgang 2 setzen
0010 0000 Ausgang 2 löschen
0011 0001 Ausgang 3 setzen
0011 0000 Ausgang 3 löschen
... (Bis Ausgang 8)
1001 0000 Motor 1 stop
1001 0001 Motor 1 links
1001 0010 Motor 1 rechts
...
1101 0000 Schrittmotor 1 initialisieren
1101 0001 Schrittmotor 1 links (einen Schritt)
1101 0010 Schrittmotor 1 rechts (einen Schritt)
(alles unter der SUB-Adresse #0, alternativ kann man natürlich für jeden Ausgang und Eingang eine eigene Subadresse nehmen - aber irgendwie scheint mir es einfacher, nur das Datenbyte auswerten zu müssen)
Man bräuchte dan nur if-then-mäßig das Datenbyte auszuwerten und die Variable, die das an den Controller zu sendende Byte enthält, entsprechend zu manipulieren (für Ausgang 1 an also OR mit 00000001, für aus AND mit 11111110, für Analogmotor 1 entsprechend erst AND 11111100 und dann OR 00000010 für links oder OR 00000001 für rechts. Beim Stepper initialisieren das entsprechende Quadruppel setzen und bei links bzw. rechts eine Bitrotation durchführen).
Im Prinzip geradezu trivial und auch auf einen eigenen Arduino mit H-Bridges übertragbar (dort setzt man dann die Ausgänge des Arduinos direkt).
Unter Subadresse #01 könnte man dann die noch freien Ein- und Ausgänge des Arduino ansprechen (z.B. für Analogwerte lesen oder PWM-Ausgang (den man dann mit der alten FT-Leistungsstufe verstärkt) setzen).
Über i2c kann man eine Robo TX-Extension bei vorhandenem Altinterface also für 4-5€ realisieren. Arduino Mini oder Micro klebt man sinniger Weise mit etwas Heißkleber auf einen 20-pol Blachbandkabelstecker (ohne Kabel drin), den man auf den Expansion-Anschluss im Universal-Interface klebt. Das vorhandene Anschlusskabel des Universals nimmt man raus (ist in einem Quetschverbinder gepresst, der im Board eingelötet wurde) und quetscht ein buntes Flachbandkabel ein, dessen Adern man aufdröselt und direkt an den Arduino lötet. Hat den Vorteil, reversibel zu sein (man kann das Originalkabel bei Wunsch wieder anquetschen) und die bunten Adern sorgen beim Bau dafür, dass man nicht versehentlich Adern verwechselt.
Ein 8-pol Flachbandkabel versieht man mit einer Quetschwanne (oder zweien auf einem Kabel, um weitere i2c-Geräte anschließen zu können) und lötet die andere Seite am Arduino passend zu i2c-Belegung. Man kann auch noch eine 10- oder mehr-polige Wanne mit Flachbandkabel rausführen, an denen man unbenutzte Ein-/Ausgänge des Arduinos für Erweiterungen bereit stellt.
Kniffelig - da muss ich Dir recht geben - ist die Idee, das Intelligent-Interface nachzubilden. Die wird wahrscheinlich an der Zeit (und zumindest bei mir am Wissen und Können) scheitern. Ob das aber überhaupt noch sinnvoll ist, wenn man einen TX (oder, wenns endlich mit i2c klappt, den TXT) hat, ist eine andere Frage. Denn durch die Erweiterbarkeit mit i2c und komplette Steuerbarkeit des Programmablaufs mit RoboPro über i2c-Befehle - auch autark mit geladenem Programm - braucht man bei TX (und später auch TXT) ja gar keine direkte Ansprechbarkeit der Extension durch RoboPro mehr. RoboPro steuert nur den TX(T) und weist ihn an, die i2c-Geräte zu steuern. Einzig eine eigene Library (mit passenden Symbolen) wäre dann noch wünschenswert. Der Wunsch nach Inteligent-Interface-Emulationwar mir eigentlich eher wegen noch nicht vorhandemen TX/TXT gekommen...
Die Idde, gleich komplexere Schrittmotorunterroutinen einzubauen, dürfte technisch kniffelig sein, weil ein Arduino kein Multithreading kann. Selbst wenn die Steuerung eines Motors an sich kein Problem wäre - die parallele Kommunikation gleichzeitig aufrecht zu erhalten, dürfte nicht ohne vertiefende Kenntnisse gehen. Natürlich nur, wenn man mehr als einen Schritt in ein Kommando packen möchte, ein Schritt zur Zeit (Kommandos "Schritt nach links, Schritt nach rechts und natürlich Initialice Schrittmoror, um die Bitanfangskonfiguration an dem Motorportpaar zu schaffen) dürfte relativ einfach sein.
Andererseits ist beim Preis eines Arduino Micros/Nanos die Frage natürlich, ob man für Schrittmotoren nicht einfach Leistungstreiber (3,50€ mit Versand aus China für eine leitungsfähige H-Bridge) und Arduino in ein gesondertes Bateriegehäuse packt und als eigenständige i2c-Erweiterung betreibt. Quasi als eigene i2c-Schrittmotorsteuerung mit umfangreicherem Befehlssatz (man könnte Beschleunigung/Verzögerung etc. einbauen) für einen Schrittmotor. Das wäre dann aber ein gesondetes "Spezialteil".
Hoffentlich kommt bald i2c für den TXT, damit ich rumexperimentieren kann...
Edit:
Ich habe gerade festgestellt, dass auf Github schon vor 10 Monaten jemand "fishduino" veröffentlicht hat. Dies simuliert ein Intelligent Interface und spricht das Universal-Interface an. Das Hauptprogramm sieht ungefähr so aus, wie ich dachte (einfach Byte auslesen bzw. Zurücksenden, wenn der Befehlscode kommt), mit der Besonderheit der Unterstützung für Analogeingänge und Extension-Interface.
Nimmt man statt der seriellen Schnittstelle den i2c-Port, hätte man bereits eine Extension für den TX; allerdings würde ich da doch eher den Weg übers Ansprechen einzelner Ein- und Ausgänge statt blockweiser Übertragung gehen. Zwar bedeutet das mehr Traffic auf dem i2c.Bus, jedoch eine viel bequemere Einbindung in eigene Programme.
Aber es soll ja auch Leute geben, die lieber mit grauen Steinen bauen, als mit den Schwarzen. 
