ftduino am TX-Pi per i2cslave mit Verbindungsproblem

[Uwe]

Hallo liebe ft-Freunde,

ich versuche mich gerade an meinen ersten python Schritten zusammen mit dem TX-Pi, an dem über den Pi-Hat ein ftDuino hängt.
Dank der community-Firmware war die Einrichtung des TX-Pi (Raspi 4) ein Kinderspiel.

Wenn ich den ftDuino mittels USB-Kabel an den TX-Pi anschließe und den Sketch ftduino_direct nutze klappt alles perfekt. Ich kann testweise auf die IOs des ftDuino zugreifen bzw. diese steuern. So weit so gut.

Mein Zielsetup war aber eine Verbindung von TX-Pi und ftDuino über i2c + zus. Spannungsversorgung. Hierfür habe ich den Sketch I2cSlave mit Standardadresse 43 hochgeladen.
Auf den ersten Blick scheint auch die Verbindung zu klappen. Wenn ich mit dem I2C Scanner das "/dev/i2c-1" auswähle blinkt die rote LED des ftDuino kurz auf und die Adressen 2b und 3c werden initialisiert. Also wird die 43 auch korrekt erkannt. Hat jemand einen Tipp wo die 60 noch herkommt? Ist das der Pi-Hat?

Problem:
Wenn ich Tills App "ftDuino I2C" starte, bekomme ich dort die Fehlermeldung: "Unable to connect to the ftDuino. Make sure one is connected to the TXTs EXT port and runs the I2cSlave sketch."

Ich hatte vermutet, das der TX-Pi hier analog zum TXT mit der App funktionieren müsste. Muss ich hier noch etwas einstellen? Gibt es alternativ eine einfache Möglichkeit den korrekten Zugriff vom Pi auf den ftDduino per i2c zu testen? Ich wäre über einen Tipp dankbar.

Das Ganze ist nicht Eilig, da die Verbindung über USB ja funktioniert. Aber was funktionieren sollte, soll auch funktionieren.

Danke & LG
Uwe

[PHabermehl]

Hallo Uwe,

mein spontaner Gedanke, nachdem ich gerade mal auf GitHub in den Quellcode vom Scanner und ftDuino I2C geschaut habe.

Der I2C Slave hat tatsächlich Adresse 43.

Und im Quellcode der cfw-App steht:

Screenshot_20210318_234706.png (22.17 KiB) 8250 mal betrachtet

I2C-Adresse 42...

Gruß
Peter

[Uwe]

Hallo Peter,

bei den Vorgonen, auf die 42 hätte ich auch selbst kommen können.
Das wars, damit klappt jetzt die Verbindung!

Dann werde ich mich morgen mal an ein paar einfachen Beispielen probieren.

Ich Danke Dir.

So long, and thanks for all the fish
Uwe

[MasterOfGizmo]

Es gibt zwei I2C-Client-Sketches für den ftDuino. Einen ganz einfachen, als Beispiel, wie sowas prinzipiell funktioniert unter:

https://github.com/harbaum/ftduino/blob ... cSlave.ino

und einen mit allen möglichen Funktionen eher zur direkten Benutzung unter:

https://github.com/harbaum/ftduino/tree ... C/I2cSlave

Ersterer kann nur einen Ausgang an oder aus schalten und nutzt Adresse 42. Letzterer kann alle Ein- und Ausgänge bedienen und nutzt Adresse 43.

Die TX-Pi-App wurde für den ersten geschrieben. Es macht ggf. Sinn, die zu erweitern, so dass sie auch den erweiterten Slketch unter Adresse 43 ansteuern kann. Welche Variante angeschlossen ist kann man ja eben genau an der Adresse erkennen. Im zweiten Fall ist das zu sendende Kommando etwas komplexer.

Die Adresse 60 ist die Adresse eines OLED-Displays. Du hast wohl einen ftDuino mit eingebautem Display. Du könntest Dir den Spass machen, das OLED vom Pi aus anzusteuern. Diese Anleitung müsste dafür gehen: https://learn.adafruit.com/adafruit-pio ... -pi/usage

[Kali-Mero]

...dabei weiß doch jeder, dass die Antwort auf alle wichtigen Fragen die "42" ist...

[MasterOfGizmo]

...dabei weiß doch jeder, dass die Antwort auf alle wichtigen Fragen die "42" ist...

Hups ... wie konnte mir das denn passieren? So ein Zufall ...

[MasterOfGizmo]

Dank der community-Firmware war die Einrichtung des TX-Pi (Raspi 4) ein Kinderspiel.

Das musst Du übrigens mal laut verkünden. Der Lars glaubt manchmal, dass wir kaum TX-Pi-User haben. Und demnächst hängen wir uns mit dem TX-Pi an RoboPro-Coding ran. Das wird ein Spass ...

[Karl]

Hallo,

Und demnächst hängen wir uns mit dem TX-Pi an RoboPro-Coding ran. Das wird ein Spass ...

Wow, da freue ich mich schon, hoffentlich nicht vergebens.
Raspberry Pi 400-Kit kpl. da, TX-Pi sowie großen 22er Monitor für meine alten "Guckerchen" auch schon vorhanden.
Fehlt nur noch Robo-Pro-Coding und das Flachkabel welches ich noch herstellen muß, - Entwicklungssystem, wenn
das "Robo-Pro-Coding" auch unter dem Raspberry-Betriebssystem läuft, fertig.
Dann noch einen "Controllino" auf Mega2560 Basis als Slave für TTL und 24 V.... Ports haufenweise.
Mehr bräuchte der Großteil der Menschheit für Hobby und Industrie eigentlich nicht. Da fallen dem großen
Klemmbaustein-Hersteller bestimmt die Augen aus.
Leider in den meisten Fällen für stationäre Anwendungen. Für kleinere Mobilteile müsste man sich dann
etwas einfallen lassen...., Pi Zero, kl. I/O-Baugruppen etc.
Na ja, hat auch noch ein bischen Zeit. Muß noch viel sortieren und eine IKEA-Einkaufstüte in blau voll
mit Fischertechnik-Mix wartet auch noch auf das Selektieren.

[MasterOfGizmo]

Und demnächst hängen wir uns mit dem TX-Pi an RoboPro-Coding ran. Das wird ein Spass ...

Wow, da freue ich mich schon, hoffentlich nicht vergebens.

Wie ich schon schrieb: "wir". Ob das vergebens ist hängt u.a. davon ab, ob Leute wie Du sich bei "wir" ausnehmen und die anderen eher als Dienstleister verstehen oder selbst was beitragen wollen.

[Uwe]

Hallo,

ich brauche nochmal Eure Hilfe. Ich habe nun meine ersten Python Programmierversuche unternommen. Ich bin weiter beim Eingangs beschriebenen Setup und verwende den umfangreicheren I2cSlave Sketch, diesmal mit der Standardadresse 43. Am ftDuino hängt an M1 ein einfacher ft-Motor und an O3 und O4 je eine Lampe. Der unten gezeigte Python-Code soll den Motor für 4 Sek. drehen lassen und gleichzeitig die Lampen abwechselnd blinken lassen.

Das Ganze funktioniert in 3 von 4 Fällen perfekt. Sowohl vom TX-Pi direkt gestartet, als auch per ssh Console. Leider kommt es sporadisch zu Aussetzern, die mir Kopfzerbrechen bereiten. Der Code scheint hängen zu bleiben, an völlig unterschiedlichen Stellen. Das sieht man am Modell, die Lampe bleibt dauerhaft brennen und Motor läuft dauerhaft weiter, und auf der Console wird der Fehler auch bei verschiedene Zeilen ausgeworfen. Z.B.:

Traceback (most recent call last):
File "/opt/ftc/apps/user/0640ad90-88f1-11eb-b538-0800200c9a66/test.py", line 40, in <module>
bus.write_byte_data(CLIENT, 0x06, 0x01);
OSError: [Errno 121] Remote I/O error

Code: Alles auswählen

if bus:
    print("Client gefunden, lasse Lampe an Ausgang O1 blinken ...");
    # Motor an M1 starten
    bus.write_byte_data(CLIENT, 0x00, 0x12);
    bus.write_byte_data(CLIENT, 0x01, 0xff);

    #Lampen an O3 und O4 abwechselnd für 4 Sek blinken lassen
    for i in range(10):    
        bus.write_byte_data(CLIENT, 0x04, 0x01);
        bus.write_byte_data(CLIENT, 0x05, 0xff);    
        bus.write_byte_data(CLIENT, 0x06, 0x01);  
        bus.write_byte_data(CLIENT, 0x07, 0x00);  
            
        time.sleep(0.2) 
    
        bus.write_byte_data(CLIENT, 0x04, 0x01);
        bus.write_byte_data(CLIENT, 0x05, 0x00);  
        bus.write_byte_data(CLIENT, 0x06, 0x01);    
        bus.write_byte_data(CLIENT, 0x07, 0xff);
            
        time.sleep(0.2) 
    
    #Motor M1 gebremst abschalten 
    bus.write_byte_data(CLIENT, 0x00, 0x11);
    bus.write_byte_data(CLIENT, 0x01, 0xff);
    time.sleep(0.2) 

    # alle Ausgänge ausschalten -> 16 0-Bytes senden
    bus.write_block_data(CLIENT, 0x00, [ 0x00 ]*16 );
else:

Habt Ihr Eine Idee was die IO Schluckaufs verursachen könnte?

Zusatzfrage:
Beim Abbremsen des Motors bin ich ins Grübeln geraten, was ich neben dem Mode auch für einen PWM Ausgangswert mitgeben muss und ob bzw. wie lang ich warten muss. Ich vermute ich muss Power mitgeben (ff) um den Motor mit max. Kraft abzubremsen und dem Prozess auch etwas Zeit lassen. Passt das oder bin ich hier auf dem Holzweg?

Danke & LG
Uwe

[MasterOfGizmo]

So ein I²C-IO-Error kann auftreten, wenn der Client dem Host nicht schnell genug reagiert. Und der ftDuino als Client kann schonmal recht langsam sein, da er I²C zum Teil in Software macht und nebenbei noch ein paar andere Dinge tut.

Das kann man nun untersuchen. Tritt das mit dem alten 0x42-Sketch auch auf? Der ist einfacher und macht weniger nebenbei. Tritt das mit einem anderen (ggf. älteren und langsameren) Pi auch auf? Kann natürlich auch ein wackeliges I²C-Kabel, schlechte Stromversorgung und alles mögliche andere sein.

Mein erster Versuch, das in den Griff zu bekommen wäre, um "bus.write_byte_data(CLIENT, a, b)" eine kleine Funktion zu basteln, die den Fehler per "try/except" abfängt. Interessant wäre dann, ob es dann nach so einem Fehler trotzdem problemlos weiterläuft, also ob irgendwas dauerhaft klemmt. Wenn das nur einzelne Aussetzer sind, weil zufällig der Pi wenig Geduld hat und der ftDuino gerade mit anderen Tasks abgelenkt ist, dann sollte ein einfaches Retry an der Stelle eigentlich helfen.

Wie Du den Motor bremst ist Deine Entscheidung, ob Du ihn langsam auslaufen lassen willst oder ob Du ihn aktiv bremsen willst. Und wie lange das dauert hängt dann auch davon ab, was an dem Motor so mechanisch dran hängt. Im ftDuino-Handbuch gibt es dazu ein Experiment.

[Uwe]

Danke für die Rückmeldung. Ich habe noch etwas experimentiert, musste aber einsehen, dass ich mich erst mal etwas besser in Python einarbeiten muss um mich solchen Problemen zielführend anzunähern. Daher habe ich das Thema zunächst zurückgestellt.

Stattdessen habe ich den TX-Pi jetzt per USB mit dem ftDuino verbunden und arbeite mit dem ftduino_direct Sketch. Mit meinen Jungs habe ich erst eine Ampel und dann eine Schiebetür mit Lichtschranke aufgebaut und die Programmierung im ersten Schritt per Brickly umgesetzt. Das funktioniert perfekt und ohne IO-Schluckaufs und führte nicht nur bei den Kids zu leuchtenden Augen.

Im nächsten Schritt versuche ich das Schritt für Schritt in Python zu schreiben. Anhand von ein paar Beispieldateien aber vor allem von Python Tutorials. Danach mangelt es auch nicht an Ideen und Bauteilen das weiter auszubauen . Ggf. komme ich dann nochmal mit der ein oder anderen Frage um die Ecke.

Danke auch für den Hinweis zum ftDuino-Handbuch mit der Motorbremse. Das Kapitel hatte ich leider nicht mehr auf dem Schirm. Aber mit der skizzierten Funktionsweise ist auch klar was ich für Parameter mitgeben muss.

LG
Uwe

[H.A.R.R.Y.]

Hallo Zusammen,

Der Code scheint hängen zu bleiben, an völlig unterschiedlichen Stellen. Das sieht man am Modell, die Lampe bleibt dauerhaft brennen und Motor läuft dauerhaft weiter, und auf der Console wird der Fehler auch bei verschiedene Zeilen ausgeworfen.

Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?

Grüße
H.A.R.R.Y.

[tintenfisch]

Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?

Jein. Sofern der ftDuino an einer weiteren Stromquelle angeschlossen ist, um die Aktoren versorgen zu können, laufen die Aktoren weiter, wenn man das USB-Kabel trennt. Dient allerdings nur der USB-Port als Stromquelle, ist der Effekt nach Trennung der USB-Verbindung nicht mehr sichtbar.

Viele Grüße
Lars

[MasterOfGizmo]

Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?

Das kommt drauf an, wie man es macht. Das Verhalten des TXT ist ab Werk fest einprogrammiert. Beim ftDuino programmiert man dagegen alles selbst und da kommt es drauf an, was man macht. Programmiert man ein "Keep-Alive", dann kann man den ftDuino machen lassen, was man will, wenn die Kommunikation ausfällt. Man könnte einen Roboter bei Kommunikationsausfall z.B. auch in eine "sichere Position" fahren lassen.

Das ist ja der Trick am ftDuino: Es gibt kaum vorgefertigtes Verhalten und damit z.B. auch nicht sowas wie den I²C-5-Sekunden-Bug des TXT, der seinen Ursachen ggf. in genau so einem Mechanismus hat.

[tintenfisch]

Jein. Sofern der ftDuino an einer weiteren Stromquelle angeschlossen ist, um die Aktoren versorgen zu können, laufen die Aktoren weiter, wenn man das USB-Kabel trennt. Dient allerdings nur der USB-Port als Stromquelle, ist der Effekt nach Trennung der USB-Verbindung nicht mehr sichtbar.

[...] Programmiert man ein "Keep-Alive", dann kann man den ftDuino machen lassen, was man will, wenn die Kommunikation ausfällt. Man könnte einen Roboter bei Kommunikationsausfall z.B. auch in eine "sichere Position" fahren lassen.

Das stimmt, meine Antwort bezog sich auf die Programmierung via ftduino_direct. Dort würde der jetzige Status, vor Trennung des Kabels / der Kommunikation, beibehalten werden, weil, ohne ftduino_direct anzupassen, eine Überprüfung, ob die Verbindung aktiv ist, nicht stattfindet somit auch das System nicht in einen "sicheren Zustand" zurückgefahren werden kann.

Das wäre aber m.E. auch mit ftduino_direct machbar, sofern man das Sketch entsprechend anpassen würde.