Community-Firmware für den TXT

[MasterOfGizmo]

Also wenn "RoboPro" läuft ...

Nein, mit RoboPro hat das hier alles nichts zu tun. Da haben wir wie gesagt keinen Zugriff drauf. Wenn Du Features in RoboPro haben willst musst Du Dich an Fischertechnik wenden.

[ski7777]

Nein ich meinte die App, die immer auf der Dtock-FW läuft. Also die Standard-Software für.

[MasterOfGizmo]

Nein ich meinte die App, die immer auf der Dtock-FW läuft. Also die Standard-Software für.

Davon rede ich auch. Das ist ein Closed-Source-Binary auf dem TXT auf dessen Code haben wir keinen Zugriff.

[ski7777]

Aber man könnte doch den Prozess von der App killen und wieder zurück zu Hauptmenü kommen.

[richard.kunze]

habe ich das jetzt richtig verstanden, dass man auch die RGB-LED ansteuern kann und wie (RGB-CHANNELS, vordefinierte Farben, etc.)?

Nee, leider nicht. Die Originalfirmware hat nur den (internen) "Ausschalt-Pin" des TXT auf eine sehr kreative Art angesteuert.

Das einzige, was man mit dem ON/OFF-Schalter derzeit machen kann ist den Schalterzustand abfragen. Das geht aber auch schon mit der Originalfirmware.

Für die Ansteuereung der LED wird man wohl Zugriff auf den zweiten Prozessor des TXT brauchen. Den können wir entweder mit Unterstützung von Fischertechnik kriegen (sprich: Fischertechnik veröffentlicht die passende Entwicklerdokumentation) oder mit viel Geduld und Reverse-Engineering (sprich: wir kucken der Original-Software von Fischertechnik beim Arbeiten auf die Finger und dokumentieren was die so macht, füllen die Lücken mit kreativem Raten und Ausprobieren, und zerlegen dabei vermutlich auch den einen oder anderen TXT).

In jedem Fall passiert das weder heute noch nächste Woche

Wenn ja, wäre das eine tolle Funktion für RoboPro, um eine Status-LED zu haben.

Wenn Du das in RoboPro haben willst musst Du Fischertechnik fragen. Wenn wir das in der Community-Firmware hinbekommen, werden die Schnittstellen ehere C, Shellscript, Python und Snap! sein.

Neues Thema:Updates:
Seit einiger Zeit überlege ich, wie man die Firmware Updaten könnte und seit gestern habe ich eine Idee für OTA-Updates:
Wir brauchen eine zweites OS und somit noch eine weitere Partition. Zusätzlich kommt noch GRUB oder so auf die Sd-Karte. Normalerweise wird der Hauptkernel gebootet. Wenn dieser Updates gefunden hat, lädt er diese Runter und speichert die .zip-Datei im Temp ab (nicht löschen). Dann schreibt er eine andere Reihenfolge in den Grub, sodass die zweite Partition gebootet wird. Dieser Kernel wird nur Updates auspacken. Wenn das Update ausgepackt ist wird Grub nochmal gereinigt und es geht zurück zum Hauptkernel.
Was haltet ihr davon?

Im Prinzip OK, aber unnötig kompliziert. Das "zweite OS" braucht man nicht wirklich, man kann Updates (sowohl Kernel als auch Userland) auch im laufenden Betrieb einspielen.

Entweder quick-and-dirty mit "tar xf /tmp/rootfs.tar -C /" (das ist im Wesentlichen das, was auch die Original-Firmware bei Updates macht) oder etwas hübscher und sicherer indem man vorher die zum Update nötige Software (sprich: die busybox) in eine Ramdisk kopiert, die Benutzereinstellungen sichert, die alte Software löscht (oder verschiebt, wenn man auf den alten Stand zurückrollen könne will) und erst dann das Update einspielt. Aber das geht alles aus dem "normalen" System heraus.

Wenn man sich über Update-Prozesse Gedanken machen will, dann darüber wie und wo man vom Benutzer veränderte Sachen (Konfiguration, selbstgeschriebene Programme, ...) so speichert, dass man sie beim Update leicht sichern und wieder zurückspielen kann (da könnte dann die zusätzliche Partition ins Spiel kommen), und wie man dafür sorgt, dass das ganze vom Benutzer installierte Zeug auch nach dem Update noch funktioniert...

[richard.kunze]

Ich fände es cool, wenn da auch die Software drauf reagieren könnte. Also langes Drücken schaltet brutal ab. Kurzes Drücken empfängt die GUI. Wenn eine App läuft wird die durch den Button beendet. Wenn kein App läuft sondern der Launcher aktiv ist poppt ein "TXT abschalten? Ja/Nein"-Dialog auf. Fände ich zumindest chic ...

Edit: Oh, es SIND ganz normale Tastenevents bei kurzem Drücken. Damit kann ich genau das bauen, was ich beschrieben habe. Cool!

... und mit den Änderungen, die ich eben hochgeladen habe sollte das auch mit dem kurz/lang drücken klappen.

Im einzelnen:

• Der ON/OFF-Button kann jetzt auch Autorepeat (kann man im DTS einstellen)
• Triggerhappy wartet 20 Repeats (ca. 5 Sekunden) ab, bevor der TXT heruntergefahren wird. Wenn man den Knopf vorher loslässt passiert nichts.

Beim Testen ist mir übrigens auch noch aufgefallen, dass der I/O-Prozessor da wohl auch noch dran lauscht: Wenn man den Button wirklich lange (etwa 15-20 Sekunden) gedrückt hält, dann wird der TXT auch ohne laufenden triggerhappy-Daemon hart heruntergefahren - allerdings bleibt die blaue LED dann an (beim "normalen" poweroff geht sie aus).

Edit: Eventuell sollte man beim Start des Shutdown noch ein (akustisches?) Feedback geben - bis der TXT komplett runtergefahren ist, kann es durchaus noch ein paar Sekunden länger dauern. Und wenn man in der Zeit den Finger auf dem Knopf lässt, kann es passieren dass der "Watchdog" zuschlägt und den TXT brutal abwürgt.

Mach ich aber heute Nacht nicht mehr...

[MasterOfGizmo]

Ich habe mir mal ein paar Gedanken gemacht, wie User später abseits von RoboPro Anwendungen auf den TXT bekommen.

Dazu habe ich auf dem TXT den Web-Server aktiviert. Dort sieht man die Liste der installierten Anwendungen, genauso wie auf dem TXT selbst. Aber es gibt auch einen Upload-Button:



Dort kann man einfach ein ZIP-Datei hochladen, die neben dem eigentlichen Programm (also z.B. einem Python-Script) noch ein Icon und eine manifest-Datei mit ein paar Zusatzinfo enthält. Das ist alles leicht mit einem Texteditor bzw. Malprogramm zu machen und dürfte schon einiges ermöglichen. Der Upload funktioniert tatsächlich, ein ZIP mit einer Demo-App liegt unter https://github.com/ftCommunity/ftcommun ... extra_apps

Da fehlt noch das ein oder andere (man muss z.B. den TXT neu starten, damit er die neue App bemerkt). Aber so als Konzept reicht es m.E: schon fast.

[ski7777]

Da fehlt noch das ein oder andere (man muss z.B. den TXT neu starten, damit er die neue App bemerkt). Aber so als Konzept reicht es m.E: schon fast.

Das dürfte das kleinste Problem sein. Ich kenne deinen Quellcode zwar nicht 100%ig bzw verstehe ihn nicht 100%ig, aber man könnte doch einfach die Software neu starten oder man aktualisiert die Anzeige.

Raphael

[MasterOfGizmo]

Wenn ich das richtig verstehe, dann stehen offenbar immer noch keine weiteren Infos von ft zur Nutzung der IOs zur Verfügung
... Bleibt zu hoffen, dass da irgendwann noch was kommt.

Wenn ihr Euch nicht bei der Entwicklung der Firmware aktiv einbringen könnt oder wollt, wie wäre es denn dann, wenn ihr FT gegenüber deutlich macht, dass ehr euch mehr Support wünscht? Ihr seid wie's klingt da doch in Betatester-Programmen etc.

[MasterOfGizmo]

Das dürfte das kleinste Problem sein. Ich kenne deinen Quellcode zwar nicht 100%ig bzw verstehe ihn nicht 100%ig, aber man könnte doch einfach die Software neu starten oder man aktualisiert die Anzeige.

Nee, das ist 1. echt keine elegante Lösung und 2. woher soll denn der Launcher wissen, dass er sich neu starten soll? Oder willst Du das dann jedes Mal extra am TXT anklicken?

Ich werde einen kleinen TCP-Server in den Launcher einbauen, über den dann der Web-Server bzw. ein von dem gesartetes CGI-Script dem Launcher Befehle erteilen kann. U.a. um die Icons neu einzulesen, aber z.B. auch um eine App zu starten. Dann kann man aus dem Web-Browser raus auf dem TXT Programme starten.

[MasterOfGizmo]

Der TXT ist gerade mal 15 Monate im Verkauf, das bedeutet, noch kein Controller hat sein MHD erreicht. Ich denke, nach dem jeweiligen Ende der Gewährleistungszeit werden sich bestimmt mehr Helfer und Mitstreiter finden (wenn dann immer noch Interesse an dem Spielzeug besteht).

Die Argumentation habe ich jetzt schon ein paarmal gelesen. Aber ich verstehe sie nicht. Warum sollte jemand ein größeres Interesse haben, nach Ablauf der Garantie solche Experimente zu machen? Dann hat er doch eine geringere Chance irgendwas repariert zu bekommen als in der Gewährleistungszeit. Und komplett ablehnen kann FT das auch nicht guten Gewissens. Immerhin beschreiben sie den Root-Zugriff ja selbst. Wenn sie Dir den Root-Zugang in die Hand geben werden sie wohl damit rechnen, dass Du ihn auch nutzt.

Ich weiss auch nicht, was ihr glaubt, was mit den TXTs schlimmstenfalls passiert. Das allerschlimmste wäre, dass der Flash-Inhalt in einen Zustand kommt, in dem er nicht mehr bootet. Elektrisch kaputt ist dann noch nichts. Ja, Fischertechnik freut sowas sicher nicht, Aber die "Raparatur" wäre ein schlichtes Neu-Flashen mit den passenden Adaptern. Wenn wir mal davon ausgehen, dass nicht gerade jedermann und sein Nachbar genau das macht (aufgemerkt: Noch ist gar kein TXT be solchen Experimenten beschädigt worden), dann reden wir hier von ein paar Euro für Porto und ein paar Minuten Arbeit. Ich wäre erstaunt, wenn FT darüber sonderlich verärgert wäre angesichts der Chance, die sich hier auftut.

[MasterOfGizmo]

Ich werde einen kleinen TCP-Server in den Launcher einbauen, über den dann der Web-Server bzw. ein von dem gesartetes CGI-Script dem Launcher Befehle erteilen kann. U.a. um die Icons neu einzulesen, aber z.B. auch um eine App zu starten. Dann kann man aus dem Web-Browser raus auf dem TXT Programme starten.

Genau das ist jetzt implementiert. Der Launcher lässt sich nun per Browser dazu bringen seine App-Liste zu aktualisieren und man kann per Web-Browser auf dem TXT installierte Apps starten. Das ist zur Zeit für wenig gut, da man die App dann ja eh direkt am Gerät bedienen muss. Aber später, wenn das mal irgendeine Funktion am TXT ausführt und Modelle steuert, dann kann man einfach vom Handy oder PC per Browser die Modelle starten und anhalten.

Ich brauche langsam driiiiingend Zugriff auf die IOs ... ich will endlich ein Modell steuern

[MasterOfGizmo]

Die Community-Firmware kann nun eigenständig ins WLAN. Dazu gibt es eine kleine App auf dem TXT:



Ein einfacher Dialog erlaibt die Eingabe des Netzwerk-Schlüssels:



Aber das muss man ja nur einmal machen. Der TXT speichert die Einstellungen sobald eine WLAN-Verbindung zustande gekomme ist.

P.S: Erwähnte ich, dass wir dringend Zugriff auf die FT-Ein- und Ausgänge brauchen?

[richard.kunze]

P.S: Erwähnte ich, dass wir dringend Zugriff auf die FT-Ein- und Ausgänge brauchen?

Ist zwar im Moment noch etwas sehr gefrickelt, aber prinzipiell läuft TxtControlMain mit der Community-Firmware. RoboPro lässt darüber hier gerade einen Motor im Leerlauf drehen

Zum nachbauen für Ungeduldige (alles auf dem TXT mit Community-Firmware, wenn nicht anders angegeben als root):

Code: Alles auswählen

mkdir /rom
ubiattach -p /dev/mtd10
mount -t ubifs -o ro /dev/ubi0_0 /rom

... legt den Mountpoint /rom an und mountet da die Originalfirmware hin (Read-Only, damit man nichts kaputtmachen kann) ...

Code: Alles auswählen

for dir in /dev /dev/shm /dev/pts /proc /tmp /sys ; do
  mount --bind $dir /rom/$dir
done

... blendet die nötigen Runtime-Filesysteme in /rom ein ...

Code: Alles auswählen

chmod go+rw /dev/input/event0 /dev/ttyO2 /dev/spidev1.0

... vermurkst die Rechte auf den von TxtControlMain benötigten Gerätedateien so dass ROBOPro drauf zugreifen kann (ich sag ja, ist noch sehr frickelig ) ...

Code: Alles auswählen

chroot /rom su ROBOPro

... startet ein Chroot-Jail als ROBOPro in der Umgebung der originalen Firmware ...

Code: Alles auswählen

cd /opt/knobloch
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_CALIBFILE=/etc/pointercal
export SDL_MOUSEDRV=TSLIB
export SDL_MOUSEDEV=$TSLIB_TSDEVICE
./TxtControlMain /dev/ttyO2 65000 1

... und startet schließlich (als ROBOPro im Chroot-Jail) TxtControlMain. Zum Testen erstmal von Hand, sonst könnte man auch /opt/knobloch/run.sh nehmen.

Nach einem ersten schnellen Test mit RoboPro (Motoren/Ausgänge, Zähler und Eingänge mit dem in RoboPro eingebauten Test-Tool manuell schalten) sieht alles soweit gut aus. Sound geht ebenfalls. Komplexere Sachen (Kamera, I2C, ...) hab ich bisher nicht getestet.

Permanentes Hochladen von Programmen dürfte aktuell noch schiefgehen weil das Filesystem nicht beschreibbar ist, und ein Firmware-Update über RoboPro funktioniert ebenfalls nicht (das soll auch gar nicht gehen).

Offene Baustellen:

• TxtControlMain und die Community-Firmware reagieren beide auf Touch-Events und malen sich gegenseitig auf dem Display rum.
• die Rechte für die diversen Geräte sollten etwas selektiver gesetzt werden
• Start-/Stop-Scripte für TxtControlMain fehlen
• Idealerweise liesse sich TxtControlMain aus unserer Oberfläche heraus starten (als Sahnehäubchen wahlweise mit Zugriff aufs Display für volle Kompatibilität mit RoboPro oder ohne Display als reine IO-Schnittstelle) und stoppen (mit dem ON/OFF-Button?)
• Wo sollen in unserem Szenario permanent auf den TXT geladene RoboPro-Programme hin? Ins passende Verzeichnis der Originalfirmware (dann müssten wir die aber beschreibbar mounten) oder in ein Verzeichnis in der Community-Firmware (dann kann man aber nicht auf die Porgramme zugreifen wenn man die Originalfirmware bootet)?

... aber nicht mehr heute Abend ...

[MasterOfGizmo]

Hier ein Foto des billigen USB-Serial-Adapters von EBay:



Die beiden 120-Ohm-Widerstände begrenzen den Strom über RX und TX wenn man den TXT eingeschaltet hat aber der USB-Adapter nicht mit dem PC verbunden ist. Man muss die Widerstände nicht einbauen, aber sie schützen den TXT zusätzlich etwas.

[Rei Vilo]

Some of those FTDI adaptors run on 5V and other on 3.3V.

As the Robotics TXT operates at 3.3V, check you're using the 3.3V-rated FTDI adaptor.

[MasterOfGizmo]

Some of those FTDI adaptors run on 5V and other on 3.3V.

As the Robotics TXT operates at 3.3V, check you're using the 3.3V-rated FTDI adaptor.

See that little jumper? It's the voltage selector and it's set to 3.3V. But a 5V adapter is also fine as long as you add two more resistors as a voltage divider in the TXTs RX line. That's what i used sp far.

The two 120 ohms series resistors give additional protection and setting the adaptor to 5V would probably not harm the TXT that way. But it's not worth trying if that actually works ...

[MasterOfGizmo]

[*]TxtControlMain und die Community-Firmware reagieren beide auf Touch-Events und malen sich gegenseitig auf dem Display rum.

Ich versuche auch für andere nicht-QT-Apps eine Möglichkeit zu bauen, dass mein Launcher den Framebuffer temporär freigibt.

[*]Start-/Stop-Scripte für TxtControlMain fehlen
[*]Idealerweise liesse sich TxtControlMain aus unserer Oberfläche heraus starten (als Sahnehäubchen wahlweise mit Zugriff aufs Display für volle Kompatibilität mit RoboPro oder ohne Display als reine IO-Schnittstelle) und stoppen (mit dem ON/OFF-Button?)

Diese Bastellöung ist hoffentlich eh nicht für die Ewigkeit. Von daher würde ich das eher aus der GUI starten als direkt per Init. Ggf. machst Du ein paar Shell-Scripte, die das entsprechende Setup starten und ich mache da eine Launcher-App für.

[*]Wo sollen in unserem Szenario permanent auf den TXT geladene RoboPro-Programme hin? Ins passende Verzeichnis der Originalfirmware (dann müssten wir die aber beschreibbar mounten) oder in ein Verzeichnis in der Community-Firmware (dann kann man aber nicht auf die Porgramme zugreifen wenn man die Originalfirmware bootet)?

Ich plädiere definitiv für die SD-Karte. Wir sollte m.E. vermeiden ins NAND zu schreiben. Es würde mich auch verwirren, wenn ich in der Community-Firmware was mache und Spuren davon in der Originalfirmware finde. Das widerspricht auch unserem "wir fassen Euere Original-Firmware nicht an"-Mantra. Lass uns wirklich die Finger davon lassen. Selbst wenn die Community-Firmware am Ende an einem Porblem gar nicht Schuld ist wird es immer den Verdacht geben. Den Verdacht wollen wir gar nicht erst entstehen lassen, oder?

[richard.kunze]

Ich versuche auch für andere nicht-QT-Apps eine Möglichkeit zu bauen, dass mein Launcher den Framebuffer temporär freigibt.

OK, dann mach ich da nichts weiter und verlass mich drauf, dass Launcher das können wird.

[*]Start-/Stop-Scripte für TxtControlMain fehlen
[*]Idealerweise liesse sich TxtControlMain aus unserer Oberfläche heraus starten (als Sahnehäubchen wahlweise mit Zugriff aufs Display für volle Kompatibilität mit RoboPro oder ohne Display als reine IO-Schnittstelle) und stoppen (mit dem ON/OFF-Button?)

Diese Bastellöung ist hoffentlich eh nicht für die Ewigkeit. Von daher würde ich das eher aus der GUI starten als direkt per Init.

Jein. Wir brauchen aktuell TxtControlMain in zwei Szenarien:

• Um RoboPro-Programme auszuführen und
• Als Backend (z.B. für ftrobopy) um Zugriff auf die I/O-Anschlüsse zu bekommen

Im ersten Szenario sollte TxtControlMain auch die Kontrolle über den Bildschirm bekommen, damit die Anzeigefunktionen aus RoboPro auch funktionieren. Das sollte man aus der GUI starten und auch direkt am TXT wieder beenden können.

Im zweiten Szenario brauchen wir TxtControlMain nur für den IO-Zugriff. Die Anzeige steuern wir selber, TxtControlMain kriegt in diesem Modus weder Zugriff auf den Bildschirm noch Events vom Touchscreen. Diesen Modus brauchen wir allerdings so gut wie immer (zumindest solange, wie wir die IO-Funktionen nicht ohne TxtControlMain direkt ansteuern können), von daher sollte der eigentlich automatisch gestartet werden.

Ggf. machst Du ein paar Shell-Scripte, die das entsprechende Setup starten und ich mache da eine Launcher-App für.

Soll mir recht sein. Passt das mit diesen Funktionen?

• start-service - startet TxtControlMain als "IO-Service" im Hintergrund (ohne Bildschirmzugriff).
• start-main - startet TxtControlMain mit Zugriff auf den Bildschirm.
• stop-main - stoppt TxtControlMain im Vordergrund.
• stop-service - stoppt den IO-Service.
• stop - stoppt TxtControlMain komplett

Die Launcher-App kann dann mit start-main/stop-main die volle RoboPro-Unterstützung steuern, und wir können unabhängig davon den IO-Zugriff über start-service/stop-service steuern.

Im Hintergrund läuft dabei immer nur eine Instanz von TxtControlMain (mehrere würden wahrscheinlich nicht funktionieren), die start-x/stop-x-Funktionen sorgen dafür, dass diese Instanz immer im passenden Modus läuft (vermutlich per Neustart, es sei denn ich finde noch einen Weg eine SDL-Applikation im laufenden Betrieb vom echten auf ein Dummy-Display und zurück zu schieben).

Bei TxtControlMain im Vordergrund haben wir allerdings das Problem, dass alle Touchscreen-Events zu TxtControlMain gehen. wir brauchen also noch irgendein Event, mit dem wir in dem Fall "stop" signalisieren können.

Mein Vorschlag wäre hier ein kurzer Druck auf den ON/OFF-Button, und zwar nicht nur für TxtControlMain sondern generell für alle Apps.

Das hält die Bedienung konsistent, und wir haben auch für eigene Sachen die Option, den kompletten Bildschirm zu benutzen ohne oben einen "Close"-Knopf einblenden zu müssen.

Ich plädiere definitiv für die SD-Karte. Wir sollte m.E. vermeiden ins NAND zu schreiben. Es würde mich auch verwirren, wenn ich in der Community-Firmware was mache und Spuren davon in der Originalfirmware finde.

Die "Spuren in der Originalfirmware" findest du nur, weil Du Dich mit dem System auskennst. Ein "Nur-Benutzer" würde sich vermutlich eher darüber wundern, warum seine auf dem TXT gespeicherten RoboPro-Programme plötzlich weg sind.

Aber ich denke auch, dass wir trotzdem besser nur auf die SD-Karte schreiben.

[MasterOfGizmo]

OK, dann mach ich da nichts weiter und verlass mich drauf, dass Launcher das können wird.

Müsste mit der Version von heute schon gehen. Ein

Code: Alles auswählen

echo "msg Starting legacy" | nc localhost 9000

öffnet einen Dialog wie den beim Shutdown. Der reagiert nicht auf Tastendrücke.

Jein. Wir brauchen aktuell TxtControlMain in zwei Szenarien:

Klar. Aber ich hoffe ja noch, dass Fischertechnik irgendwann doch noch irgendwas liefert.

Soll mir recht sein. Passt das mit diesen Funktionen?

• start-service - startet TxtControlMain als "IO-Service" im Hintergrund (ohne Bildschirmzugriff).
• start-main - startet TxtControlMain mit Zugriff auf den Bildschirm.
• stop-main - stoppt TxtControlMain im Vordergrund.
• stop-service - stoppt den IO-Service.
• stop - stoppt TxtControlMain komplett

Die Launcher-App kann dann mit start-main/stop-main die volle RoboPro-Unterstützung steuern, und wir können unabhängig davon den IO-Zugriff über start-service/stop-service steuern.

Der Launcher startet per GUI dann nur "start-main" und "stop-main" versuche ich via Launcher und Power-Knopf zu machen. Sollte klappen. Ich wollte den Power-Knopf ja eh zu einem globalen "stop"-Knopf machen. Das passt dann vom Konzept.