Ich glaub nicht, dass es am Lesen der Karte liegt, wenn die Wiedergabe läuft, dann stoppt diese zwar kurz, aber es kommt kein Geräusch.
Nur wenn ich die Karte nochmal lesen lasse bevor die eigentliche Wiedergabe kommt.
SPI Mode habe ich noch nicht probiert, da müsste ich erstmal schauen, welche Pins überhaupt noch frei sind.
Ich hab irgendwie den ES8388 im Verdacht, dass der das Geräusch macht, wenn der über I2S das erste Signal bekommt und das irgendwie noch nicht richtig „gültig“ ist.
Ist ja beim Webstream auch so. Wenn ich Pause drücke und dann scanne kommen die Geräusche.
Läuft die Wiedergabe bereits und ich scanne kommen keine.
Hier ist der aktuelle Stand der Implementierung des PN532 Readers.
Bin gerade im Urlaub und leider ist mir mein USB Kabel kaputt gegangen, daher kann ichs gerade nicht auf dem Gerät testen.
Ich glaub die Erkennung, dass immer noch die gleiche Karte auf dem Reader fehlt noch, ansonsten sollte das schon laufen.
So Sachen wie IRQ oder die Optimierung des Stromverbrauchs müsste man sich vielleicht auch noch anschauen. Xento/ESPuino at PN532 (github.com)
Für die Implementierung des ES8388 wollte ich noch schauen, ob ich mit ner Stumschaltung die Knackers wegbekomme, aber das kann ich erst testen, wenn ich nen neues Kabel habe.
Vielleicht könnte ja schonmal wer über die Ansätze der Implementierung schauen, ob das so ins Konzept passt.
Wegen den komischen Geräuschen am Anfang: Gehe mal in die Platformio.ini und ersetze mal
https://github.com/schreibfaul1/ESP32-audioI2S.git
durch https://github.com/schreibfaul1/ESP32-audioI2S.git#b2b5312
Dann neu kompilieren und hochladen. Ich habe demletzt festgestellt, dass ich da auch Probleme mit solchen Geräuschen habe und meine Vermutung ist, dass das in den letzten Wochen in die Lib reingekommen ist.
Danke, werd ich am Freitag oder am Samstag mal ausprobieren.
Ich hab da auch noch nen Vorschlag für einen Offline Modus wo man dann über den AP trotzdem auf den ESPuino kommt.
Vielleicht könnte man auch einen Dualen Modus einbauen, also AP und Client in einem.
Hier im Urlaub hab ich zwar WLAN, aber die Geräte sehen sich untereinander nicht.
Ich hatte das jetzt erstmal Quick&Dirty umgesetzt.
Also eigentlich verhindern, dass die Seite des APs geladen wird und stattdessen die normale Seite laden wenn kein Wlan da ist.
Dann im Ordner .html eine angepasste HTML-Seite wo die ganzen Javascripte und CSS Dateien durch zwei einzelne lokale Dateien ersetzt werden in denen alle JS und CSS Dateien zusammengefasst sind + zwei Dateien von FontAwesome in dem Ordner ablegen.
Im webServerstart() reicht dann die zusätzliche Zeile
Das reicht aus meiner Sicht so nicht aus, weil damit bietest du die MGMT-GUI an, während du einen ungesicherten AP stellst. Damit kann sich ja jeder verbinden und beliebigen Quatsch machen.
Ich will da eigentlich nix mehr dran ändern, da @sonovice an dem Thema ja eh dran ist. Aber das soll dich natürlich nicht abhalten, das in deinen Branch aufzunehmen.
Ja klar, das war jetzt ja auch nur Quick&Dirty, weil ich über das Wlan vom Park nicht auf die GUI gekommen bin. Man könnte das ja auch nur aktivieren, wenn ein Passwort für den AP gesetzt ist.
Weiter hab ich dann auch nicht mehr gemacht, weil dann ja das Kabel kaputt gegangen ist.
Hey @Xento , ich versuche deinen Branch gerade für mein ESP Muse Proto zu bauen - zusammen mit PN532, drei Buttons und einem HW-040 Rotary Encoder.
Für welches Env Platform baust du letztendlich in Platform.io? Und muss ich die settings-muse-luxe.h irgendwo explizit includen?
Danke
Lukx
Nimm am besten diesen Branch: GitHub - Xento/ESPuino at dev
Ich weiß gerade nicht, ob ich die letzten Änderungen für den PN532 schon gepusht habe.
Da hatte ich noch ein paar Fehler drin.
Ich hab für den Muse Luxe eine eigene Plattform erstellt, dann kann man im VS Code direkt dafür bauen lassen.
Ich schau morgen mal, ob ich alle Änderungen gepusht habe.
Super, danke! Bei mir scheint etwas in platformio.ini zu fehlen, nach dem Flashen lande ich in einer Reset Loop mit 0x33, keine Ahnung was das bedeutet
Würd mich freuen Deine Plattform und ggf. noch andere Settings zu bekommen!
Ich habe gerade meinen aktuellen Stand gepushed.
An der Plattform hat sich aber nichts geändert.
Ich hatte am Anfang auch Abstürze, da lags aber daran, dass ich die falsche Partitionen genommen habe.
Mit dem 4 MB hats dann funktioniert.
Ich habe ESPuino gestern auf dem Muse Proto Board zum laufen bekommen:
NeoPixel on-board vom Muse Proto Board
Drehencoder KY-040 für Lautstärke
3 Taster für Play/Pause, Next, Prev
PN532 als NFC-Reader via I2C
Externer An/Aus-Schalter, weil ich das schon so im Gehäuse hatte
Visaton FX 10/4 Ohm 2-Wege-Koaxlautsprecher
2x 18650 Akkus die vom MuseProto gemessen werden
Ich habe auf Basis des Branches von @Xento begonnen, musste aber an zwei oder drei kleinen Stellen etwas anpassen. Am Wochenende räume ich meinen Fork auf und versuche ihn so sauber zu kriegen dass er auch anderen hilft, die ein Muse Proto Board als Basis verwenden möchten.
ich habe @Xento s Branch genommen und etwas reduziert, um für das Raspiaudio Muse Proto Board mit der genannten Peripherie zu funktionieren.
Danke an dieser Stelle an alle beteiligten, dass ich ein so tolles Projekt und so viel Forschung einfach „verwenden“ konnte.
Ich habe meinen Branch gesäubert und mal als PR gestellt, da ich glaube dass Muse Proto ein niederschwelliger Einstieg in ESPUino ist:
Es freut mich, dass ihr das jetzt mit ESPMuse ans Laufen bekommen habt. Aber…
Ihr habt mir jetzt insgesamt 29 Commits über den Zaun geworfen. Dabei werden mitunter wild irgendwelche Sachen wild hin und her verschoben/konfiguriert, wieder gelöscht und weiß nicht was. Ich möchte mir ehrlich gesagt nicht die Arbeit machen, das alles in einen gesitteten Feature-Branch zu überführen und als squash commit zu mergen, um die History clean zu halten.
In der Vergangenheit habe ich im Prinzip so ziemlich alles in meinen Master aufgenommen, da ich die Feature-Forkerei im Nachbarforum irgendwie unübersichtlich fand. Das hat große Vorteile, bringt jedoch auch den Nachteil mit, dass das Feature-Set inzwischen so groß ist, dass das keiner mehr alles testen will und kann. Und so schleichen sich dann immer mal wieder Bugs in Funktionen ein, die mir nicht auffallen, da ich sie nicht nutze (und auch in Zukunft nicht nutzen werde). Das gefällt mir irgendwie nicht.
Also seid mir nicht böse, aber nachdem ich vor Ewigkeiten das Audiokit aufgenommen habe und es aber (mangels Zeit und Lust) nicht wirklich supporte, bin geneigt zu sagen, dass man ESPMuse lieber forken sollte. Spricht ja nix dagegen, dass ihr das hier supportet - ich freue mich ja, wenn das auch auf anderer Hardware läuft. Ich verlinke eure Branches auch gerne zentral.
Also ich habe nochmal drüber nachgedacht:
Ich werde es doch aufnehmen, jedoch es ganz klar so kennzeichnen, dass es experimentell ist und ich dafür keinen Support übernehme.
Ich denke damit sollten alle Beteiligten leben können.
Hey,
Danke!
Ich hatte zwischenzeitlich überlegt, dass es reichen würde den PN532 zu mergen. Die Settings für das ESPMuse könnte man dann als settings-custom anderswo dokumentieren.
Falls das eine Option ist mit der du als Maintainer besser zufrieden bist würde ich
dir ein PN532 zur Verfügung stellen (klar, löst das Zeitproblem nicht)
den PR auf meinen Fix in der Sample-Override reduzieren
Xentos PR für den 532 squashen und ggf aufräumen, sodass da weniger History und Nebenschauplätze sind
Wenn du auch den ESPMuse als experimental reinlassen magst, räume ich meinen PR auf und squashe ihn auf 3 Einheiten mit guten Messages (PN532, ESPMuse, sonstige Fixes)
Nein, wir müssen das nicht über Overrides machen. Wir können das normal integrieren. D.h. RFID_READER_TYPE_PN532_I2C als neuen RFID-Typ. Und auch ein eigenes Setting-File mit entsprechendem Eintrag in der platformio.ini.
Was aus meiner Sicht der optimale Zustand wäre:
PN532 als eigener squashed commit. Hinter RFID_READER_TYPE_PN532_I2C steht als Kommentar „use PN532 via I2C (experimental! Please review ESPMuse)“
ESPMuse als eigener squashed commit. Im Settings-File von ESPMuse oben im Kopf bitte ebenfalls auf den Thread hier verweisen und hinschreiben, dass offiziell nicht supportet wird.
An den Grundeinstellungen, die aktuell im Master sind, werden keine Änderungen vorgenommen.
Wie ihr das mit der Autorenschaft beim sq. Commit macht, das müsst ihr unter euch ausmachen
Alternativ, anstelle hier in den Thread zu verlinken, kannst du auch einen neuen Thread aufmachen, indem ESPMuse so ein bisschen beschrieben wird und was es braucht, um das mit ESPuino zum Laufen zu bringen. Also dass man einfach direkt im ersten Post sieht, was gemacht werden muss, ohne sich durch den kompletten Thread zu hangeln. Und darauf verweist du dann in den settings-Files. Wäre denke ich clean. Ich würde das hier auch in meine Doku aufnehmen.
Das würde ich dann ad hoc in den Master-Branch aufnehmen. Den PN532 habe ich auch hier, so dass ich das ggf. mal kurz antesten könnte. Aber ganz grundsätzlich werde ich das nicht regelmäßig testen.
