Community-Firmware für den TXT

[Torsten]

Hallo Richard,

In der Community-Firmware können wir den I2C-Bus auch direkt ansprechen ohne über die Fischertechnik-API zu gehen. Dafür gibt es so wie es aussieht auch schon ein paar Bibliotheken (z.B. python-smbus oder quick2wire), ...

ja, python-smbus funktioniert (sogar ohne Community-Firmware mit der original fischertechnik-Firmware), das habe ich bereits ausprobiert. Es setzt aber voraus, dass das Python-Programm auf dem TXT "im Downloadmodus" läuft. Im Python-"Online"-Betrieb, bei dem das Python-Programm z.B. auf einem Linux oder Mac OS X Rechner läuft, ist zur Ansteuerung des I2C-Ports des TXT der Weg über den Socketport 65000 notwendig und dieser Weg (d.h. das ROBOPro-Kommunikationsprotokoll für I2C) ist noch nicht von fischertechnik dokumentiert (oder kann man I2C im Online-Modus mit ROBOPro gar nicht verwenden ? Ich weiss es nicht.).

Generell will ich auf längere Sicht (nach Version 0.9) für die Community-Firmware eh von der Fischertechnik-API als einzigen Weg für die Ansteuerung der IO-Pins weg. Einmal, weil eine direkte Ansteuerung effizienter ist als alles über den Fischertechnik-Blob zu schleusen. Und zum anderen, weil wir auf diesem Weg - mit einer eigenen Implementation der ROBOPro-API auf Basis unserer eigenen I/O-API statt wie bisher andersrum - auch ROBOPro-Programme besser (z.B. als direkt aus der Community-Firmware heraus startbare Apps) in die Community-Firmware integrieren können.

Ja, das verstehe ich schon. Bis zur Python-"Online"-Unterstützung einer Community-Firmware eigenen I/O-API ist es dann aber immer noch ein langer Weg. Im Prinzip müsste man dafür ein neues Socket-Protokoll (ähnlich dem von ROBOPro) neu erfinden, da kann man doch auch gleich das nehmen, was es schon gibt, nämlich das Protokoll von ROBOPro. Das ist ja nicht schlecht. Es fehlt halt nur noch ein Teil der Doku.

Aber grundsätzlich steht das ja nicht im Wiederspruch, zu dem, was Du gesagt hast. Für Programme im "Download"-Modus befürworte ich auch eine Community-Firmware eigene I/O-API, die wird auf jeden Fall wesentlich flexibler sein. Aber auch dafür fehlt ja noch die Dokumentation von fischertechnik, sonst hätte ich mich sicherlich schon damit beschäftigt .

Viele Grüße
Torsten

[richard.kunze]

Hallo Torsten,

Ja, das verstehe ich schon. Bis zur Python-"Online"-Unterstützung einer Community-Firmware eigenen I/O-API ist es dann aber immer noch ein langer Weg.

Ja. Das wird mindestens bis zur Version 1.0 dauern, wenn nicht länger.

Im Prinzip müsste man dafür ein neues Socket-Protokoll (ähnlich dem von ROBOPro) neu erfinden, da kann man doch auch gleich das nehmen, was es schon gibt, nämlich das Protokoll von ROBOPro. Das ist ja nicht schlecht. Es fehlt halt nur noch ein Teil der Doku.

"Schlecht" ist das existierende Protokoll nicht, aber es hat ein paar - meiner Meinung nach entscheidende - Schwächen:

• Es ist kompliziert (ich sag nur "ftIF2013Command_ExchangeDataCmpr" )
• Es ist (bedingt durch die Definiton als C-Strukturen) nicht einfach um neue Funktionalität erweiterbar (z.B. um darüber dann per USB angeschlossene Geräte wie den Lego-WeDo-Controller oder demnächst den ROBO LT anzusprechen)
• Aus demselben Grund ist es relativ kompliziert, Bindings für andere Sprachen als C zu implementieren
• Es funktioniert (wegen der eng getakteten Polling-Loop) nur gut in Netzwerken mit wenig Latenz und
• Es bietet überhaupt keine Möglichkeit, die Kommunikation abzusichern und/oder zu authentifizieren (das wird spätestens dann zum Problem, wenn der TXT nicht mehr ausschließlich seine eigenen privaten Netzsegmente verwendet - z.B. mit der Community-Firmware oder dem nächsten offiziellen Firmware-Update von Fischertechnik)

Deshalb wird es wenn es nach mir geht wohl doch eher ein eigenes Protokoll geben. Idealerweise eins, das auf existierenden Standards aufsetzt, Funktionen zur Absicherung bietet (z.B. Websockets), ein Nachrichtenformat verwendet das eine formale Spezifikation erlaubt und leicht (automatisiert) in möglichst viele sprachspezifische Bindings übersetzbar ist (z.B. JSON mit JSON Schema oder Protobuf) und das asynchron und möglichst Latenz-tolerant arbeitet.

Aber grundsätzlich steht das ja nicht im Wiederspruch, zu dem, was Du gesagt hast. Für Programme im "Download"-Modus befürworte ich auch eine Community-Firmware eigene I/O-API, die wird auf jeden Fall wesentlich flexibler sein. Aber auch dafür fehlt ja noch die Dokumentation von fischertechnik, sonst hätte ich mich sicherlich schon damit beschäftigt .

Da haben MoG und ich schon mal was von Fischertechnik bekommen, das muss aber noch in eine vernünftige Form gebracht werden. Steht bei mir als erster Punkt auf der Liste sobald Version 0.9 der Community-Firmware raus ist

[MasterOfGizmo]

Da ja nun der TXT anfängt Spass zu machen habe ich uns neulich mal den ElectroPneumatic gekauft. Und eben habe ich mal eine App für den Flipper geschrieben. Mit Qt kann man recht einfach eigene Widgets machen (das sind die Grafikelemente aus denen die User-Oberfläche besteht, also Buttons, etc).

Ein neues Widget ahmt diese Flipper-typischen LED-Balken nach und scollt einen Text durch. Ein weiteres malt einfach die verbleibenden Kugeln. Für die Score-Anzeigt bringt Qt schon diese 7-Segment-artige Anzeige mit. Und der Progressbar unten läuft jedesmal 5 Sekunden runter, wenn die linke Lichtschrake passiert wird und verteilt Extra-Punkte, wenn man dort innerhalb der 5 Sekunden ein zweites Mal durch kommt. Das macht das Original-RoboPro-Programm auch, dass es Punkte vergibt, wenn man da schnell nochmal durchkommt. Aber da es das nicht anzeigt, dass da die Zeit verrinnt, versteht man es kaum, was die linke Lichtschranke eigentlich macht ...

Achja, Sound gibt's natürlich auch.

Ist sicher keine Mega-App. Macht aber schonmal deutlich mehr Spass als das RoboPro-Original.





Source code unter: https://github.com/ftCommunity/ftcommun ... es/pinball

Edit: Auf dringenden Wunsch des Nachwuchses speichert das nun den aktuellen Highscore auf SD-Karte.

[LarsKusch]

Liebe Entwickler,
ich wollte euch nur sagen dass mein txt nun wieder lauffähig ist und der SD-Karten Boot aktiviert ist.
Könnte mir mal jemand die Boot/Root Dateien schicken. Ich habe zwar welche auf der SD-Karte drauf aber die funktionieren nicht!
Erleichtert Grüße,
Lars

[MasterOfGizmo]

Haben die Kollegen von FT Dir das gleich freigeschaltet? Oder hast Du es selbst sofort nochmal probiert?

[LarsKusch]

Nein ein Kollege von Fischer Technik
Vielen Dank für die schnelle Bearbeitung!

[MasterOfGizmo]

Wow ... dann besteht ja eine gewisse Chance, dass bei FT schon einmal jemand die Community-Firmware benutzt hat.

[LarsKusch]

Ja scheint so!
Aber der SD-Karten Boot funktioniert aufgrund der SD-Karten Datein nicht!
Könnte mir mal irgendwer seine SD-Karte Datein schicken? Damit ich sie vergleichen kann!
Liebe Grüße,
Lars

[ski7777]

Nach doppeltem make auf meinem neuen Debian Server ist es nun soweit.
Mit folgendem Kommando habe ich den TXT nachmanipuliert:

Code: Alles auswählen

fw_setenv bootcmd "run sdboot;run nandboot"

Dann habe ich gemaked und das eine oder andere Paket nachinstalliert. Nach ca 4h habe ich mit Steg+c abgebrochen und am nächsten morgen fortgesetzt. Leider hat das ganze noch gebootet und der FTDI hat was von Kernelpanic gesagt.
Also encore und fois. Make clean und dann wieder make. Nach gefühlt einer halben Ewigkeit hatte ich dann eine neu geflashte SD Karte. Jetzt gibt der FTDI einen anderen Fehler.

Code: Alles auswählen

[    1.450022] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.469339] spidev spi1.0: buggy DT: spidev listed directly in DT
[    1.781964] omap_voltage_ny▒e▒ini▒;▒Woltagg friver"support not added
/bin/busybox: error while loading shared libraries: libpam.so.0: cannot open shared object file: No such file or directory
[ 0 02.305767] Ke▒oel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[    2.305767]
[    2.315579] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00▒▒[>( (2.31▒579}

Könnt ihr mir da helfen? Liegt am Debian?

Raphael

P.S.: Der zweite build Prozess lief ohne Abbruch. Ich habe Zugriff auf uboot.

[MasterOfGizmo]

Die Community-Firmware kann jetzt auch einfache reine Text-Apps laufen lassen. Auf dem TXT erscheinen die dann in einem Textfenster:



Das Programm dazu enthält dann keine TXT-spezifischen GUI-Elemente, sondern sieht dann so aus:

Code: Alles auswählen

#! /usr/bin/env python3
import time

print("Hello world!")

for i in range(5):
    print("Counter:", i)
    time.sleep(1)

print("Done")

exit(42)

Das ganze als App besteht dann aus ein paar wenigen Dateien: https://github.com/ftCommunity/ftcommun ... ages/hello

Man kann natürlich auch in so einer App auf ftrobopy u.ä. zugreifen.

[MasterOfGizmo]

Und noch ein kleins Extra: Es gibt nun eine Art "App store" auf dem TXT:





Damit kann man Apps direkt auf dem TXT aus dem ftcommunity-apps-Repository installieren.

[steffalk]

Tach auch!

Wenngleich ich hier nur interessehalber mitlese und gar keinen TXT besitze, muss ich aber doch mal fett loben. Ihr lasst's ja ganz schön krachen hier! Das ist echt Hammer, was Ihr hier gerade macht, in jeder Beziehung. Möge auch weiterhin alles gut gelingen!

Gruß,
Stefan

[MasterOfGizmo]

Wenngleich ich hier nur interessehalber mitlese und gar keinen TXT besitze, muss ich aber doch mal fett loben. Ihr lasst's ja ganz schön krachen hier! Das ist echt Hammer, was Ihr hier gerade macht, in jeder Beziehung. Möge auch weiterhin alles gut gelingen!

Danke! Mal schauen was draus wird. Bisher verhält sich FT ja weitestgehend passiv. Schauen wir mal, ob sie noch in Schwung kommen.

Ich habe immerhin munkeln hören, dass Knobloch jetzt, da sich gezeigt hat, dass WLAN mit aktuelleren Treibern besser funktioniert, die neuen Treiber auch in die offizielle Firmware integrieren will.

[ski7777]

Hallo,

könnt ih r mir mit meinem build Fehler helfen? Ich habe jetzt schon drei mal sauber gemaked ohne Abbruch oder Fehler und jedes mal hat der TXT nicht gebootet.

Raphael

[richard.kunze]

könnt ih r mir mit meinem build Fehler helfen? Ich habe jetzt schon drei mal sauber gemaked ohne Abbruch oder Fehler und jedes mal hat der TXT nicht gebootet.

Nach dem Log in Deinem ersten Post ist entweder deine serielle Konsole sehr falsch eingestellt (dann sollte der TXT aber trotzdem booten), oder die Image-Dateien auf der SD-Karte sind kaputt (wahrscheinlicher).

Dafür kann es einen Haufen Gründe geben, angefangen von einer kaputten SD-Karte, über ein "hilfreiches" Tool, das beim Kopieren der Images Unix-Zeilenenden in DOS/Windows-Zeilenenden konvertiert (das ist nur für Textdateien ansatzweise sinnvoll, aber Binaries macht es zuverlässig kaputt) bis zu irgendwelchen Seltsamkeiten in Deinem Buildsystem.

Ohne genauere Informationen was Du genau gemacht hast und wie Dein System genau aussieht ist es schwer, da konkret zu helfen.

[ski7777]

Die SD ist gerade mal 1 Monat alt. Gemaked habe ich über mein script gemacht und ich nutze zwei Partitionen (Das script mach nichts anders, als im wiki)

Raphael

[TiniTech]

Dann probier mal, die SD-Karte unter Windows mit FAT32 zu formatieren und dann die Dateien für das simple layout draufzukopieren. Die Dateien (aus dem Build-Prozess, der bei mir ein funktionierendes System ausgespuckt hat) von gerade eben findest du hier: https://www.dropbox.com/sh/fm1b4qj6qg5l ... kgl9a?dl=0.

[ski7777]

I can only say: It works fine!!!

Leider fährt der TXT nicht herunter, wenn ich lange auf den Knopf drücke und es kommt auch kein Shutting down... .

Raphael

[TiniTech]

In welcher Variante denn? Simple Layout ohne partitionierte Karte?

Ich habe hier das Advanced Layout und da bekomme ich durchaus den Shutdown-Dialog zu sehen bei einem mittellangen Druck auf den Knopf. Ganz lange drücken führt ja zu einem harten Abschalten, erkennbar daran, dass der Knopf noch blau leuchtet, auch wenn das Display schon aus ist.

[ski7777]

Getestet habe ich jetzt mit simple. Den extrem langen Druck wollte ich jetzt nicht machen also einfach kabel raus.

Ich habe dem Updatemechanusmus noch nicht ganz verstanden. Wie habt ihr das vor? Kann man die rootfs.IMG im laufenden Betrieb ersetzen?
Ich wäre bereit ein Logo für Eibe APP 'Einstellungen' zu zeichnen.

Raphael