CFW: Problem mit ftrobopy-Apps im Store beim Release

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

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 29 Dez 2016, 08:16

Ja klar gibts die Sachen noch bzw. irgendwann wieder. Man muss sie halt ab jetzt per Web-Interface manuell installieren. Die Apps, die ich betreue gibt es in Zukunft unter https://github.com/harbaum/cfw-apps. Da fehlen noch alle Apps, die auf ftrobopy aufbauen, also alle, die die FT-Ein- und Ausgänge verwenden. Sobald ich genau weiss, wie die in der nächsten Firmware-Version angesteuert werden müssen stelle ich auch die wieder Stück für Stück dort ein.

Ich denke, dass sich der App-Store auch wieder füllen wird, wenn die neue Firmware-Version sich etwas verbreitet hat und wenn mehr Leute Apps schreiben.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 31 Dez 2016, 11:45

Gibt es schon Pläne, was die Audio-Ausgabe im nächsten Release angeht? Laufen die aktuellen Sound-Aufrufe nur ins Leere oder erzeugen sie in dem Fall einen Fehler? Dann würde ich in meinen Wrappern entspechend darum herum coden. Und wenn wieder Sound implementiert wird, wird das dann weiterhin via ftrobopy gehen? Und wird es die Original-TXT-Sounds dann noch geben? Die müsste ftrobopy dann ja seinerseits aus dem internen Flash lesen.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 31 Dez 2016, 12:04

Aktuell gibt ftrobopy einfach eine Ausgabe auf die Shell, dass Sound nicht verfügbar seien. Ein Feer entsteht nicht.
An einem neuen System zur Audioausgabe über ALSA arbeite ich noch.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 31 Dez 2016, 15:51

ski7777 hat geschrieben:Aktuell gibt ftrobopy einfach eine Ausgabe auf die Shell, dass Sound nicht verfügbar seien. Ein Feer entsteht nicht.
An einem neuen System zur Audioausgabe über ALSA arbeite ich noch.
Da ich unter Brickly stdout in den Browser und in die App umleite würden diese Meldung dann auf dem Bildschirm und im Browser auftauchen, wahrscheinlich auf Englisch irgendwo zwischen den eigentlichen Programmausgaben, Und Dein Ansatz, das via ALSA zu machen scheint mir ja a) in recht weiter ferne zu liegen und b) auch nicht mit Richard abgestimmt zu sein. Also fange ich jetzt die Sound-Request in allen meinen Apps ab und schreibe Extra-Code, um die alte Funktion mit viel Aufwand wieder hertzustellen?

Ich muss sagen, dass ich sehr unzufrieden mit der Tatsache bin, dass hier größere Umbauten gestartet werden, bevor alle Konsequenzen überhaupt erkannt und durchdacht sind. Wir sind jetzt bei Firmware 0.9.3-RC. RC steht für Release-Candidate. Im Klartext: Nur noch Bug-Fixes bis zu Release, aber keine neuen Features. Ergo auch kein Sound, sondern stattdessen Fehlermeldungen. Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 31 Dez 2016, 16:33

Ich habe diese ganzen Veränderungen nicht angestoßen und habe die Version nicht auf Release Candidate gesetzt. Mein Ansatz ist im Moment nur eine Idee. Sobald ich erste Erfolge habe, werde ich diese präsentieren und bei Bedarf dann in ftrobopy implementieren. Mein Ziel ist es ohne Kollisionen mehrere Töne gleichzeitig abspielen zu können. Mein Plan:
Bild
Ferner könnte man so auch externe Soundkarten ansteuern.
Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?
Bin ich hier der Chef? nö

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 31 Dez 2016, 17:16

Du hast alle Apps im Apps-Repository wegen eurer Ànderungen als inkompatibel markiert. Du wirst wohl einen Plan gehabt haben, wie es danach weitergeht. Was das angeht hast du dich in der Sache selbst zum Chef gemacht.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 31 Dez 2016, 17:43

Ich habe ur mit Richard zusammen mich auf das nächste Release vorbereitet und dabei einige Apps als inkompatibel zur 0.9.3 makiert. Das war auch kein Anlass diese für alle anderen Versionen zu entfernen. Für das Soundproblem bin auch nicht ich verantwortlich, da ich nicht für ftrobopy verantwortlich bin.
Vielleicht sollten wir einfach mal mit den Schuldzuweisungen aufhören und uns zusammen überlegen, wie es weitergeht.

Raphael

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 31 Dez 2016, 18:00

MasterOfGizmo hat geschrieben: Ich muss sagen, dass ich sehr unzufrieden mit der Tatsache bin, dass hier größere Umbauten gestartet werden, bevor alle Konsequenzen überhaupt erkannt und durchdacht sind.
Der "größere Umbau" war am 19. 11., mit der aktuellen Version von ftrobopy und in Konsequenz der Abschaltung des TxtMainControl-Hintergrund-Prozesses

Die Änderungen jetzt waren eigentlich dazu gedacht, die dadurch notwendigen Änderungen an den Apps (deren Notwendigkeit mir selbst auch erst jetzt aufgefallen ist) durchführen zu können ohne dieselben Apps für die 0.9.2-er Version der Firmware kaputtzumachen. Hätte denke ich auch prima funktioniert, aber Du hast es vorgezogen deine Apps stattdessen gleich aus dem Store zu nehmen.
MasterOfGizmo hat geschrieben: Wir sind jetzt bei Firmware 0.9.3-RC. RC steht für Release-Candidate. Im Klartext: Nur noch Bug-Fixes bis zu Release, aber keine neuen Features. Ergo auch kein Sound, sondern stattdessen Fehlermeldungen. Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?
Wir sind bei Version 0.9.3-irgendwas. Wichtig dabei ist lediglich das 0.9.3 vorne, damit der Store weiss dass die API eben nicht mehr die 0.9.2 ist. Wenn Du Dich am "rc" störst, dann benenne es halt in -alpha oder -dev oder sonst was um...

Und Sound in ftrobopy wird es wieder geben, sobald ich a) txt_snd_cat aus der MP3-App rausgepult und direkt in die Firmware integriert habe (falls Du nichts dagegen hast), b) ftrobopy beigebracht habe, im Direct-mode txt_sind_cat zu benutzen und c) einen PR dafür an Torsten gestellt habe. Das mach ich alles, sobald ich am nächsten Wochenende wieder aus dem Urlaub zurück bin...

Benutzeravatar
PHabermehl
Moderator
Beiträge: 1782
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von PHabermehl » 31 Dez 2016, 18:28

Hallo Jungs,

bitte streitet Euch nicht! Vertagt das Thema auf nächstes Jahr...

Guten Rutsch und bis dann!
Moderative Beiträge sind explizit gekennzeichnet!

Torsten
Beiträge: 190
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Torsten » 31 Dez 2016, 18:36

Hallo Richard,
richard.kunze hat geschrieben:Und Sound in ftrobopy wird es wieder geben, sobald ich a) txt_snd_cat aus der MP3-App rausgepult und direkt in die Firmware integriert habe (falls Du nichts dagegen hast), b) ftrobopy beigebracht habe, im Direct-mode txt_sind_cat zu benutzen und c) einen PR dafür an Torsten gestellt habe. Das mach ich alles, sobald ich am nächsten Wochenende wieder aus dem Urlaub zurück bin...
ich habe bereits damit angefangen, Sound-Support für den "direct"-Mode von ftrobopy zu implementieren. Ich verwende dafür das Python-Modul "SpiDev 3.2" (zu finden unter https://pypi.python.org/pypi/spidev). Ich schlage deshalb vor, das SpiDev-Modul per Default in das nächste CFW-Release mit aufzunehmen.
Der "direct" Sound-Support wird völlig transparent sein, so dass an bestehenden ftrobopy-Programmen keine Änderungen bei der Soundausgabe notwendig sein werden.

Ich werde in den nächsten Tagen eine neue ftrobopy-Version auf github hochladen.

Ich wünsche allen einen Guten Rutsch !

Viele Grüße
Torsten

Edit:
@richard: über welchen Directory-Pfad soll ich am Besten auf die original ft-Soundfiles zugreifen ? oder sollte der Pfad ein (optionaler) Parameter bei der Initialisierung von ftrobopy sein ?

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 31 Dez 2016, 18:51

Torsten hat geschrieben: ich habe bereits damit angefangen, Sound-Support für den "direct"-Mode von ftrobopy zu implementieren. Ich verwende dafür das Python-Modul "SpiDev 3.2" (zu finden unter https://pypi.python.org/pypi/spidev). Ich schlage deshalb vor, das SpiDev-Modul per Default in das nächste CFW-Release mit aufzunehmen.
Ok, das ist noch besser - ich baue das Spidev-Modul dann nächstes Wochenende ein.
Torsten hat geschrieben: "direct" Sound-Support wird völlig transparent sein, so dass an bestehenden ftrobopy-Programmen keine Änderungen bei der Soundausgabe notwendig sein werden.
Eigentlich kann man im Direktmode über SPI ja sogar zusätzliche eigene Sounds abspielen und muss sich nicht auf die paar "fest eingebauten" Soundfiles beschränken...
Torsten hat geschrieben: Ich werde in den nächsten Tagen eine neue ftrobopy-Version auf github hochladen.
OK, ich baue das dann ein.
Torsten hat geschrieben: Ich wünsche allen einen Guten Rutsch !
Von mir ebenfalls Guten Rutsch an alle!

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 31 Dez 2016, 20:25

Torsten hat geschrieben:@richard: über welchen Directory-Pfad soll ich am Besten auf die original ft-Soundfiles zugreifen ? oder sollte der Pfad ein (optionaler) Parameter bei der Initialisierung von ftrobopy sein ?
Die Original-Firmware wird in der CFW unter /rom eingehängt (read-only), der Pfad ist also derselbe bis auf das Präfix.

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 31 Dez 2016, 21:15

richard.kunze hat geschrieben: Der "größere Umbau" war am 19. 11., mit der aktuellen Version von ftrobopy und in Konsequenz der Abschaltung des TxtMainControl-Hintergrund-Prozesses
Dann stimme ich hiermit dafür, diese Änderung rückgängig zu machen bzw. in einen eigenen Entwicklungszweig zu verschieben bis alles Konsequenzen erkannt und gemeinschaftlich geklärt wurden. Da die aktuelle Lösung absolut stabil läuft ist gibt es m.E. keinen Grund zur Eile.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 01 Jan 2017, 16:43

Nach einigen Mühen habe ich aloop jetzt zum Laufen gebracht. Der Rest sollte jetzt ein Kinderspiel sein. Das ganze könnte man dann noch einfacher in ftrobopy implementieren.

Raphael

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 01 Jan 2017, 18:09

Ich revidiere.
Irgendwas scheint mit den sample rates nicht ganz zu stimmen, aber vielleicht kann man das auch einfach in der txt_snd_cat lösen.
Mein Grundaufbau findet sich hier: https://github.com/ski7777/ftcommunity- ... e/alsa-spi
Der entscheidende Commit: https://github.com/ski7777/ftcommunity- ... 5b5247a5c8
Nach dem starten führe ich folgendes aus:

Code: Alles auswählen

sudo modprobe snd-aloop
Jetzt brauche ich zwei Terminals:
  • Im aktuellen Ordner muss die txt_snd_cat kompiliert liegen

    Code: Alles auswählen

    arecord -fS16_LE -r22050 -c1 -traw -Ddsnoop:Loopback,1 | ./txt_snd_cat
  • Code: Alles auswählen

    aplay -twav -Dplug:dmix:Loopback pfad_zu_einer_wav_datei
Problem:
arecord will nicht arbeiten:

Code: Alles auswählen

Recording raw data 'stdin' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
arecord: set_params:1297: Sample format non available
Available formats:
- S32_LE
Wo soll da das Problem sein?

Raphael

Torsten
Beiträge: 190
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Torsten » 04 Jan 2017, 12:04

Hallo,

die neue Version 1.6 von ftrobopy mit Sound-Unterstützung im 'direct'-Modus ist jetzt online auf github. Ausserdem werden die Werte 'auto', '127.0.0.1' und 'localhost' für den host-Parameter bei der Initialisierung von ftrobopy aus Gründen der Abwärtskompatibilität nun identisch behandelt.

Alle alten Apps aus dem App-Store sollten damit unverändert auch mit dem neuen Firmware-Release laufen.

Edit: Falls die Version 1.6 auch mit dem alten Firmware-Release im 'direct'-Modus verwendet werden soll, muss das spidev-Modul zusätzlich zur Verfügung gestellt werden. (die Datei spidev.so könnte ich bei Bedarf noch hochladen).

Viele Grüße
Torsten

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 05 Jan 2017, 15:58

Das klingt gut. Ein paar Anmerkungen habe ich noch:

- Du machst am Hostname fest, ob ftrobopy direkt auf dem TXT. Vor dem Problem, das festzustellen, stehe ich auch manchmal. Vielleicht sollten wir uns da mal einen rebusten Weg überlegen. Hostname scheint mir etwas unsicher. Ich habe es schon von der Anwesenheit der /etc/fw-ver.txt und /etc/sysversion bzw. /rom/etc/sysversion abhängig gemacht. Ist aber beides auch irgendwie nicht das wahre ...

- Dass Du "localhost" und "auto" nun synonym verwendest verstehe ich als Angebot an mich. Danke sehr. Aber ich kann die Argumente dagegen durchaus verstehen. Daher mein Vorschlag: "auto" bleibt wie's ist. Aber bei localhost versucht ftrobopy wirklich nur auf dem lokalen Gerät einen Dienst anzusprechen (weil ja "localhost" auch genau das bedeutet). Also wenn ftrobopy auf dem TXT läuft und TxtControlMain aktiv spricht es TxtControlMain via localhost an. Wenn es auf einem TXT läuft und TxtControlMain nicht aktiv ist nimmt es den Direct-Modus. Das ist m.E. ein schlüssiges Verhalten zumal man mit der Angabe von "localhost" auf einem TXT ohne TxtControlMain ja auch wirklich nichts erreichen könnte. Aber der TXT sollte in dem Fall dann nicht versuchen, die anderen IP-Adressen anzusprechen (also 192.168.X.2). Das wiederspricht in der Tat dem Gedanken hinter "localhost" recht deutlich. Dazu würde ich gerne auch Richards Meinung hören.

- An manchen Stellen gibst Du Daten auf stdout aus. Könnte man das bitte komplett unterdrücken? Bei Prorammen, die auch selbst Daten auf stdout ausgeben mischen sich so die programmeigenen Ausgaben mit denen der ftrobopy. Das könnte User ggf. verwirren. Wenn ftrobopy Fehler, Infos u.ä. melden muss, dann m.E. über Rückgabewerte, so dass man das als App-Entwickler z.B. auch in andere Sprachen übersetzen könnte.

- Wo sind denn Deine Sound-Routinen über SPI her? Hast Du mit Deinen Routinen schonmal Hänger bei der Audio-Ausgabe gehabt? Ich habe sowas sporadisch mal. Ich sehe, dass Du immer 441-Byte-Frames sendest und zur Not mit Nullbytes auffüllst. Warum sendest Du am Ende der Datei keine kürzeren Frames? Zweitens hatte ich das Problem, dass in den Sound-Daten das Reset-Kommando nicht vorkommen darf (also das Byte 0x90), daher filtere ich das raus. Ich sehe nirgends, dass Du das machst. Hast Du das Problem nicht? Oder sind die Sound-Files auf dem TXT entsprechend vorbereitet, so dass das Byte da nicht drin vorkommt?

Edit: In den Sound-Files sind auch 0x90-Bytes drin. Wieso hast Du das Problem nicht, die abzuspielen? ... hmmm ...
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Torsten
Beiträge: 190
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Torsten » 05 Jan 2017, 23:15

Hallo MoG,
MasterOfGizmo hat geschrieben:- Du machst am Hostname fest, ob ftrobopy direkt auf dem TXT. Vor dem Problem, das festzustellen, stehe ich auch manchmal. Vielleicht sollten wir uns da mal einen rebusten Weg überlegen. Hostname scheint mir etwas unsicher. Ich habe es schon von der Anwesenheit der /etc/fw-ver.txt und /etc/sysversion bzw. /rom/etc/sysversion abhängig gemacht. Ist aber beides auch irgendwie nicht das wahre ...
Ja, da stimme ich Dir zu. Die Abfrage des Hostnamens ist eine Notlösung, bis ich etwas Besseres habe.
MasterOfGizmo hat geschrieben: [...] "auto" bleibt wie's ist. Aber bei localhost versucht ftrobopy wirklich nur auf dem lokalen Gerät einen Dienst anzusprechen (weil ja "localhost" auch genau das bedeutet). Also wenn ftrobopy auf dem TXT läuft und TxtControlMain aktiv spricht es TxtControlMain via localhost an. Wenn es auf einem TXT läuft und TxtControlMain nicht aktiv ist nimmt es den Direct-Modus.
Das macht mehr Sinn ... habe ich jetzt so implementiert.
MasterOfGizmo hat geschrieben: - An manchen Stellen gibst Du Daten auf stdout aus. Könnte man das bitte komplett unterdrücken? Bei Prorammen, die auch selbst Daten auf stdout ausgeben mischen sich so die programmeigenen Ausgaben mit denen der ftrobopy. Das könnte User ggf. verwirren. Wenn ftrobopy Fehler, Infos u.ä. melden muss, dann m.E. über Rückgabewerte, so dass man das als App-Entwickler z.B. auch in andere Sprachen übersetzen könnte.
Ein vernünftiges Error-Handling steht schon seit Längerem auf meiner ToDo-Liste, bin bloss bisher noch nicht dazu gekommen... muss ich mir mal wieder anschauen.
MasterOfGizmo hat geschrieben: - Wo sind denn Deine Sound-Routinen über SPI her?
Die habe ich mir aus den (unvollständigen) Sourcen und durch Ausprobieren zusammengereimt.
MasterOfGizmo hat geschrieben: Hast Du mit Deinen Routinen schonmal Hänger bei der Audio-Ausgabe gehabt? Ich habe sowas sporadisch mal.
s.u.
MasterOfGizmo hat geschrieben: Ich sehe, dass Du immer 441-Byte-Frames sendest und zur Not mit Nullbytes auffüllst.
Ich fülle nicht mit 0x00-Bytes auf, das hatte ich zuerst versucht, das ergab aber Knackser im Sound. Ich fülle jetzt mit 0x80-Bytes auf, das knackst nicht mehr.
MasterOfGizmo hat geschrieben: Warum sendest Du am Ende der Datei keine kürzeren Frames?
Zunächst hatte ich am Ende der Dateien den (wie ich dachte) korrekten kürzeren Frame gesendet, das führte aber immer wieder zu Audio-Hängern und unvorhersehbarem Verhalten (möglicherweise durch 0x90 Bytes, habe ich aber nicht genau untersucht). In einem Kommentar in den ft-Sourcen habe ich aber dann einen Hinweis gefunden, der darauf hindeutet, dass ROBOPro auch nur volle 441 Frames sendet. Nachdem ich das dann auch so implementiert hatte, waren die Probleme weg. Die DMA-Routinen der Motorplatine, die die Daten vom SPI-Bus entgegen nehmen, liegen mir leider nicht im Sourcecode vor. Es ist deshalb schwierig, genau zu sagen, was da vorgeht.
MasterOfGizemo hat geschrieben: Zweitens hatte ich das Problem, dass in den Sound-Daten das Reset-Kommando nicht vorkommen darf (also das Byte 0x90), daher filtere ich das raus. Ich sehe nirgends, dass Du das machst. Hast Du das Problem nicht? Oder sind die Sound-Files auf dem TXT entsprechend vorbereitet, so dass das Byte da nicht drin vorkommt?

Edit: In den Sound-Files sind auch 0x90-Bytes drin. Wieso hast Du das Problem nicht, die abzuspielen? ... hmmm ...
s.o.

Gruß
Torsten

Benutzeravatar
MasterOfGizmo
Beiträge: 1826
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 06 Jan 2017, 21:31

Ich habe gerade gesehen, dass Du das Data-Kommando und die Nutzdaten in einem SPI-Transfer schickst. Bei mir sind das zwei getrennte. Kann mir gut vorstellen, dass das der Grund für meine Probleme mit den Reset-Bytes ist.

Und wenn man nur volle Vielfache von 441 Bytes schicken könnte wäre das ja schade ... vielleicht gibt's dazu ja irgendwann mal ein Statement von den Machern des TXT ...
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Antworten