Dokumentation interner TXT-APIs

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Dokumentation interner TXT-APIs

Beitrag von MasterOfGizmo » 14 Okt 2016, 10:28

Wir Community-Entwickler suchen nach wie vor nach Dokus zu den kompletten internen APIs des TXT.

Generell kann man sich da auch mit etwas Halbwissen drumrum hacken. Bei der Ansteuerung der FT-Anschlüsse bedienen wir uns so eines Hacks. Beim Audio habe ich nun auch was zusammen gestrickt. Das mag erstmal so aussehen, als sei dann doch alles gut. Aber am Beispiel der Audio-Anbindung zeigt sich auch, wo die Grenzen liegen:

Die ganze interne API sieht für einen, der sich da per Reverse-Engineering reinhackt, ziemlich kaputt aus. Erstmal muss man einige Dinge erraten (maximale Bitrate auf dem SPI-Interface, Takt-Polarität, ...). Sowas klappt dann wenn man Pech hat auf dem eigenen TXT, aber nicht auf dem einer anderen Person, weil man da leider eben doch nicht die genauen Wetre kennt, sondern halt irgendwas nimmt, das eben bei einem selbst klappt. Dazu kommt, dass manche Dinge dem Anschein nach keinen Sinn geben. Zum Beispiel kann ein Audio-Buffer bis zu 441 Samples enthalten. Das Längenfeld dazu ist aber nur ein Byte groß. Ein 0-Byte bedeutet "kompletter 441-Bytes-Buffer wird benutzt" und der Wert 1-255 bedeutet ebensoviele Bytes. Aber was ist wenn man 256 bis 440 Bytes schicken will? Na dann schickt man einfach zwei kleinere Puffer, einen mit 255 und einen mit X-255 Bytes. Ja, das scheint auch zu gehen, ist aber wohl nicht im Sinne des Erfinders, denn: Der TXT checkt auch, ob man mehr als 441 Bytes senden will und kennt dafür sogar einen Fehlercode. Den wird er aber nie senden, denn man kann ja mit der Ausnahme von 441 Bytes gar nicht nach mehr als 255 Bytes fragen. Noch merkwürdiger wird es aber, wenn man sich die Nutzdaten anschaut. ich hatte zunächst ständig Aussetzer, Knackser und die ganze Kommunikation kam dauernd aus dem Tritt. Dann ist mir aufgefallen, dass sich das Muster der Aussetzer Song-abhängig ändert und wenn man z.B. völlige Stille sendet ist alles gut. Etwas mehr Testen hat dann ergeben, dass der TXT anscheinend auch in den Nutzdaten nach Kommandos sucht. Und wenn in den Nutzdaten das Byte 0x90 vorkommt, dann setzt er aus. 0x90 ist der Code für das Reset-Kommando der Audio-Schnittstelle. Aber es sollte den TXT-Sound nur dann resetten, wenn auch wirklich gerade Kommandos übertragen werden. In den Nutzdaten sollte ihn sowas nicht stören. Tut es aber ... also enthält mein Sound-Treiber nun eine Routine, die sämtliche Vorkommen des Wertes 0x90 durch 0x91 ersetzt. Das hört man praktisch nicht, aber Sinn gibt das Ganze so trotzdem nicht. Der Code von dem ich rede ist hier: https://github.com/ftCommunity/ftcommun ... _snd_cat.c

Nun besteht die Chance, dass diese Fehlerchen gar nicht so sind, wie ich sie beschreibe, auch wenn ich mir da recht sicher bin. Hätte ich eine ordentliche Doku der internen Audio-Schnittstelle, dann könnte ich die Kommunikationsparameter auf die vom Hersteller dafür vorgesehenen Werte stellen und ich könnte sehen. ob ich nur irgendeinen Aspekt in der Kommunikationsschnittstelle falsch verstehe oder ob das wirklich so merkwürdig ist wie's zur Zeit aussieht.

Daher nach wie vor unsere Bitte an FT: Gebt uns komplette Unterlagen. Ein Ziel ist, die Funktionen der Original-Firmware so nachzubauen, dass die Community-Firmware einen vollwertigen Ersatz darstellt und z.B. die RoboPro-Integration direkt, elegant und benutzerfreundlich wird. Aber auch erweiterte Funktionen wie das MP3-Abspielen werden damit ermöglicht. Ich würde z.B. gerne einen echten Linux-Audio-Treiber schreiben. Zur Zeit gehen die Daten durch mein txt_snd_cat-Tool. Aber schöner wäre ein echter Alsa-Treiber. Dann könnte jede Linux-App wieüblich direkt und ohne mein Tool Sound ausgeben. Aber das macht erst Sinn, wenn die API dokumentiert ist und klar ist, dass das was ich da mache halbwegs korrekt so ist.

Der MP3-Player: https://youtu.be/ojUwmBWIvpw
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Antworten