Update:Arduino mit TX Controller verbinden, Sensorwerte

[funmca]

Hallo zusammen,

ich möchte Sensorwerte durch den Arduino berechnen und dann an den TX Controller übergeben. Wie macht man das?

Was ich mich frage ist, man muss bei Sensoren im I Eingang doch immer die Erde mit dem TX Controller verbinden, ich bilde mir ein, dadurch entsteht ein geschlossener Stromkreis, kann ich auch einfach einen Arduino Ausgang in einen I Eingang des TX Controller stecken?

UPDATE********

Habe gerade etwas probiert, man muss nur auf einen gemeinsamen Ground achten, habe also den i2c kabel ground(Erde) in den Ground Eingang des Arduinos gesteckt, gescannt und voila:
I2C device found at address 0x50 !, I2C device found at address 0x51, I2C device found at address 0x52 usw. bis 0x57

Gut. Jetzt las ich in der Hilfe, diese Adressen seien intern vom TX Controller verwendet. Sind das zufällig die acht I Eingänge?

Vielleicht eine blöde Frage, bin da halt Laie.

Gruß Marco.

[Dirk Fox]

Hallo Marco,

I2C device found at address 0x50 !, I2C device found at address 0x51, I2C device found at address 0x52 usw. bis 0x57

das sind die I²C-Adressen des EEPROMS des TX, die sich über das I²C-Protokoll ansprechen und beschreiben bzw. auslesen lassen (etwas mehr steht in den "RoboPro Application Notes" im RoboPro-Verzeichnis). Dein Arduino erkennt also ein I²-Device auf dem Bus, das er ansprechen kann - hier wird der TX tatsächlich zum "Slave". Die Werte der Input-Ports erhälst Du auf diesem Weg allerdings nicht.

Beste Grüße,
Dirk

[funmca]

Hallo Dirk,

danke für die Antwort, bin inzwischen etwas weiter und in der Lage Messwerte EINES Sensors analog vom Arduino zum TX zu senden.

Ich frage mich aber gerade , und recherchiere wie wild im Internet, wie ich gezielt bestimmte Werte einzelner Pins des Arduino abfragen kann, kannst Du da helfen?

Gruß Marco.

[thkais]

Hallo,

wenn schon eine I²C-Verbindung zwischen den beiden besteht, dann macht es Sinn, sie zu nutzen.
Da der TX ausschließlich als Master arbeitet, muss der Arduino eine Slave-Software bekommen, d.h. der Arduino benötigt einen "Befehls-Interpreter" der auf I²C Kommandos reagiert.
Wie das Protokoll aussieht, kann man selbst bestimmen. Ich würde im Arduino eine Sub-Adresse implementieren, mit der festgelegt wird, welcher Eingang gelesen wird. Man könnte das Protokoll auch dahingehend erweitern, dass man vordefinieren kann, ob ein Eingang analog oder digital sein soll - oder ob er als Zähler arbeiten soll, der Flexibilität sind keine Grenzen gesetzt.

[Dirk Fox]

Hallo Marco,

tkais Vorschlag ist sicher der eleganteste Weg - zumal er keine Eingänge des TX belegt. Den Arduino musst Du dafür als Slave an den I²C-Anschluss (EXT 2) des TX anschließen - mit dem Arduino habe ich noch nicht gearbeitet, vermute aber, dass Du die vier I²C-Kabel vom EXT 2 direkt mit den entsprechenden Kontakten des Arduino (VCC, GND, SDA und SCL) verbinden kannst (Arduino-Experten: bitte ggf. widersprechen...). Dann musst Du softwareseitig dafür sorgen, dass der Arduino als Slave arbeitet - und die Werte auf Anfrage des TX an diesen übermittelt (kann der Arduino als I²C-Slave arbeiten?).

Der "Befehlsinterpeter" muss in der Lage sein, für das Auslesen jedes Eingangs des Arduino, den Du auswerten willst, einen Befehl zu verstehen.
Das Protokoll könnte dann in "Meta-Sprache" etwa so aussehen:

- Write-Befehl: TX->Arduino: [7-bit-I²C-Slave-Adresse des Arduino || 0][Adressbyte des Eingangswerts x] oder [Befehl für Auslesen Eingang x]
- Read-Befehl: TX->Arduino: [7-bit-I²C-Slave-Adresse des Arduino || 1][Lese Byte/Word]

Für den Anschluss kannst Du entweder das EXT-Kabel des TX zerschnippeln - oder (wie in ft:pedia 4/2013 beschreiben) vier F-Jumper mit einem 3x2-Wannenstecker versehen.

Beste Grüße,
Dirk

[funmca]

Hallo Dirk, hallo Thomas,

exakt so hatte ich das vor und mir einen Wolf im Internet gesucht.

Jetzt habe ich , glaube ich, genau die Anleitung die ich gebraucht habe. Ist zwar für den NXT , ist aber genauso auch für den TX zu gebrauchen:

http://www.dexterindustries.com/howto/c ... -together/

Danke Euch beiden nochmal!

Gruß und schönes Wochenende, Marco

[Dirk Fox]

Hallo Marco,

super, viel Erfolg!
Und ich hoffe ganz fest auf einen ft:pedia-Beitrag, sobald die Koppelung funktioniert...

Ein schönes ft-Wochenende,
Dirk

[funmca]

Hallo Dirk,
gerne, ist letztlich ganz einfach gewesen, hab jetzt drei Infrarotsensoren, die ich wahlweise über I2C abfrage....

[HerrLehmann]

Hallo zusammen,

auch ich habe schon lange großes Interesse einen Arduino oder Pi an den TX anzuschließen, da ich einfach mit der RoboPro Software nicht klar komme. Bitte jetzt nicht verbal verhauen, die Software läuft für mich auf dem "falschen" Betriebsystem und ich komme aus der tippenden Softwareentwicklung. Darum hatte ich ebenfalls die Idee Arduino oder Pi als treibendes Gerät zu nutzen und den TX als Zubringer/Interface für meine Modelle zu nutzen. Verstehe ich das also richtig, dass damit die Programmierung/Ansteuerung immer auf dem TX erfolgen muss und man den TX nicht einfach als Bindeglied einsetzen kann? Es geht mir also nicht nur um Berechnung der Werte, sondern meine Entwicklung soll nicht auf dem TX stattfinden.

Ich dachte, dass man drei weitere TX in Reihe schalten kann und die dann ebenfalls Slaves sind? Gäbe es da vielleicht eine Möglichkeit? Oder "sprechen" die dann ein anderes Protokoll?

Entschuldigt, dass ich mit dieser (Neuling-)Frage den Thread noch einmal anbreche und vielen Dank im voraus,
(ebenfalls ) Dirk

[Dirk Fox]

Hallo Dirk,

Verstehe ich das also richtig, dass damit die Programmierung/Ansteuerung immer auf dem TX erfolgen muss und man den TX nicht einfach als Bindeglied einsetzen kann?

zumindest beim I²C-Protokoll ist der TX immer der Master. Ausnahme: Das EEPROM reagiert als Slave (vom TX aus wird das eigene EEPROM ebenfalls als Slave via I²C adressiert) - das erklärt auch, warum Marco die EEPROM-I²C-Adressen vom Arduino aus "gesehen" hat.

Ich dachte, dass man drei weitere TX in Reihe schalten kann und die dann ebenfalls Slaves sind? Gäbe es da vielleicht eine Möglichkeit? Oder "sprechen" die dann ein anderes Protokoll?

Das "TX-Slave-Protokoll" läuft nicht via I²C, sondern verwendet (über denselben Stecker) RS485 oder Bluetooth. Wenn Du die Entwicklung auf einem Arduino machst, könnte dieser sicherlich das Protokoll emulieren und einen TX als Slave nutzen - allerdings weiß ich nicht, ob sich (ohne Reverse Engineering) genügend Informationen über das Protokoll beschaffen lassen, um es zu programmieren. Wenn Du aber den Arduino nutzen willst - warum dann nicht gleich die Sensoren dort anschließen und den TX ganz weglassen?

Beste Grüße,
Dirk

[Ad2]

Both RS485 and BT are possible, enough reverse engineering has been done but the protocol may change slightly at each firmware release. Control over RS485 is possible with an ATMega328 but not with Arduino because the 16MHz X-tal does not allow the baudrate of 921600 (requires 14.7456 MHz). But then you could theoretically control 8 slave TX controllers. Whether this is actually feasible with only 2K RAM remains questionable. The Pie seems a better alternative but I don't know if it is capable of generating the required baudrate (within a few percent). BT does not have these problems, you can connect a dongle to the Pie's USB host connector and simply connect over the linux BT stack using the serial communications profile. The missing link here is the X1 protocol layer that on a PC is implemented in the ftMscLib.dll. But also there, the documentation and some reverse engineering has brought us a long way . On the other hand, with BT there is no need to integrate the Pie into your model and since you need a computer (or at least screen and keyboard) anyway, why not run your program on a PC in online mode, with ftMscLib or a Linux equivalent? If, on the other hand, you would really prefer a standalone (offline) model then I would suggest an MBED which comprises a cortex M3 (ARM) processor and is programmable over USB using a cloud IDE somewhat similar to the Arduino IDE. Apparently it supports 921600 Baud but also USB host (you would have to do some soldering though) and I2C as well. An MBED however costs approx. €60 and you still need some additional components while at the same time you have a number of TX controller with ARM9 processors doing almost nothing. So the best way to go might still be to program the TX in C in offline mode. I do agree however that the YAGARTO environment that ft offers as download is not comparable in user-friendliness with either Arduino or MBED (BTW. has anyone managed to get it working with Eclipse?). Both environments offer support for other platforms (besides ATMega328 and LPC1768), Arduino also supports e.g ChipKit and MBED supports some Freescale processors. It would be just great if any of the two IDE's would also support the TX, it would make the programming and the exchange of program modules so much easier.

Ad

[HerrLehmann]

Hallo Dirk (Fox),

zunächst vielen Dank für die rasche Antwort.

zumindest beim I²C-Protokoll ist der TX immer der Master. Ausnahme: Das EEPROM reagiert als Slave (vom TX aus wird das eigene EEPROM ebenfalls als Slave via I²C adressiert) - das erklärt auch, warum Marco die EEPROM-I²C-Adressen vom Arduino aus "gesehen" hat.

Okay, ich verstehe.

Das "TX-Slave-Protokoll" läuft nicht via I²C, sondern verwendet (über denselben Stecker) RS485 oder Bluetooth. Wenn Du die Entwicklung auf einem Arduino machst, könnte dieser sicherlich das Protokoll emulieren und einen TX als Slave nutzen - allerdings weiß ich nicht, ob sich (ohne Reverse Engineering) genügend Informationen über das Protokoll beschaffen lassen, um es zu programmieren.

Schade, ich hätte gerne den einfacheren Weg gehen wollen. Ich hätte mich auch mit einer Art Master wird zu einem Slave Emulator auf dem TX anfreunden können - also eine Durchreiche der Signale; allerdings Protokoll Analyse und viel hin her geht mir doch zu weit. Eigentlich wollte ich meine 30 Jahre alten Steine noch einmal mit moderner Technik verbinden...

Wenn Du aber den Arduino nutzen willst - warum dann nicht gleich die Sensoren dort anschließen und den TX ganz weglassen?

Von wollen kann man nicht ganz sprechen - wie gesagt (ohne einen Flamewar starten zu wollen) wäre das (m)eine Möglichkeit den TX programmatorisch ansprechen zu können. Den TX weglassen ist für mich nur bedingt möglich/gewollt.

- der TX ist schon da und wartet auf seit einem Jahr auf Einsatz (Weihnachtsgeschenk)
- eigentlich wollte ich mich nicht um verschiedene Pegel (9V auf 5V oder 3,3V) z.B. bei den Motoren kümmern
- der TX hat einen "netten" Formfaktor und bringt schon die richtige Verbindungen in die Fischertechnik-Welt mit

Ich werde einen Thread starten und das Thema von einer anderen Seite aufzäumen. Ich bekomme die yagarto Toolchain schon zum Laufen, aber die Übertragung auf den TX funktioniert nicht so recht.

Beste Grüße,
Dirk

[HerrLehmann]

Hi Ad,

Both RS485 and BT are possible, enough reverse engineering has been done but the protocol may change slightly at each firmware release.

Right one cannot expect this to be stable over time.

Control over RS485 is possible with an ATMega328 but not with Arduino because the 16MHz X-tal does not allow the baudrate of 921600 (requires 14.7456 MHz). But then you could theoretically control 8 slave TX controllers. Whether this is actually feasible with only 2K RAM remains questionable. The Pie seems a better alternative but I don't know if it is capable of generating the required baudrate (within a few percent). BT does not have these problems, you can connect a dongle to the Pie's USB host connector and simply connect over the linux BT stack using the serial communications profile.

Okay, it is not Linux but a Mac, but I was already experimenting with BT. Problem is: it always needs a computer running and I haven't found anything (framework, lib) that could talk with the TX by code.

The missing link here is the X1 protocol layer that on a PC is implemented in the ftMscLib.dll. But also there, the documentation and some reverse engineering has brought us a long way . On the other hand, with BT there is no need to integrate the Pie into your model and since you need a computer (or at least screen and keyboard) anyway, why not run your program on a PC in online mode, with ftMscLib or a Linux equivalent?

My objective is to keep Windows out and let the model work on it's without occupying any computer by using BT.

If, on the other hand, you would really prefer a standalone (offline) model then I would suggest an MBED which comprises a cortex M3 (ARM) processor and is programmable over USB using a cloud IDE somewhat similar to the Arduino IDE. Apparently it supports 921600 Baud but also USB host (you would have to do some soldering though) and I2C as well. An MBED however costs approx. €60 and you still need some additional components while at the same time you have a number of TX controller with ARM9 processors doing almost nothing.

That sounds interesting, so I'll have a look for it. On the other hand, I'd like have it simple, because I just wanted to revive my 30 old bricks

So the best way to go might still be to program the TX in C in offline mode. I do agree however that the YAGARTO environment that ft offers as download is not comparable in user-friendliness with either Arduino or MBED (BTW. has anyone managed to get it working with Eclipse?).

I gave this a try and managed to compile a sample program with in Eclipse (C/C++ Version). At the end I had a binary, but wasn't able to upload it on the TX via XModem. Randomly I managed to upload something on the TX, but not my binary. Arduino IDEs makes the uploading process quite easy. This especially useful when you're not so experienced with the platform and you're in need of several programm/compile/upload cycles.

Both environments offer support for other platforms (besides ATMega328 and LPC1768), Arduino also supports e.g ChipKit and MBED supports some Freescale processors. It would be just great if any of the two IDE's would also support the TX, it would make the programming and the exchange of program modules so much easier.

I was also looking for other IDEs too, but didn't found anything like Processing or Eclipse. I think, I'm going to start another thread on this topic.

Dirk