Hi @compactflash,
das wird alles in der Port.cpp gemacht. Muss zugeben, dass ich es mit normalem gpio nicht getestet habe. Müsste ich wohl nochmal machen.
Nochmal eine Frage dazu: Wie ist deine Schaltung aufgebaut? Weil ich habe das als Output konfiguriert, d.h. das ist nicht einfach nur ein Pullup. Sorgt deine Schaltung für Strombegrenzung?
Ist bei mir auch ein Output , die Schaltung entspricht dem Original von AI-Thinker und es funktioniert ja auch .
Das in der Port.cpp hatte ich gefunden , da fehlt mir aber nach
#ifdef GPIO_PA_EN
…
sowas wie ein else
um auch ohne PA den GPIO zu schalten .
Aber vielleicht sehe ich das auch nicht .
Also es gibt in der Port.cpp eine Behandlung die greift, wenn HEADPHONE_ADJUST_ENABLE nicht aktiv ist.
Wenn HEADPHONE_ADJUST_ENABLE aktiv ist, dann greift eine Behandlung, die in Audioplayer.cpp liegt. Ich gebe zu, das ist nicht so ultimativ geschickt, das an zwei Stellen zu haben. Das werde ich nochmal in Ordnung bringen. Die Idee kam mir auch schon bei der Implementierung.
Hallo @biologist
Meine Probleme waren selbstverschuldet , Tippfehler in den settings . Deine Umsetzung funktioniert wieder mal hervorragend , danke dafür . Jetzt kann ich mein PCB final fertigstellen . War es eigentlich schon aber ich habe einen Fehler gamacht , der sich aber mittels Drahtbrücke korrigieren läßt . Aber eine andere Sache kann ich nicht korrigieren und erfordert ein neues PCB . Vielleicht hat ja jemand eine Lösung oder Antwort zu dem Problem .
Ich verwende ja den On/Off- Controller LTC2954 . Dieser hat zum Abschalten den Pin Kill .
Auf meinem ersten PCB , was auch schon lange online gestellt ist habe ich für den Pin Power(Kill) den GPIO21 benutzt . Dies war zufällig ausgewählt und funktioniert einwandfrei . Auf meinem neuen PCB habe ich wegen des einfacheren Routings den Pin auf GPIO13 verlegt . Dabei tritt ein merkwürdiges Problem auf , und ich weiß nicht warum . Der LTC2954 gibt beim Spannungseinschalten den Pin Kill erst nach ca. 0,5 Sekunden frei . In dieser Zeit muss der ESP32 den GPIO auf HIGH gezogen haben , wenn dies nicht erfolgt schaltet der LTC2954 wieder aus . Mit GPIO21 geht das , mit GPIO13 nicht . Ich habe leider kein Oszilloskop um die Länge des Impulses zu messen aber scheinbar braucht der ESP32 für GPIO13 länger als 0,5 Sekunden . Im Datenblatt des ESP32 Seite 50 ist eine Übersicht des Pinverhaltens nach Reset . Dort gibt es eine Unterschied aber ich weiß es nicht richtig zu deuten . Wahrscheinlich macht das weak pull_down den Unterschied auch wenn es nur ein paar Millisekunden sind .
Hat jemand Erfahrung und kann mir da helfen ?
Wenn ich den GPIO13 im Setup als erstes auf HIGH setze funktioniert es auch nicht . Ich habe mittels Drahtbrücken die beiden GPIO13 und GPIO21 getauscht und es funktioniert . Ich habe das schon im Layout geändert , es interessiert mich aber trotzdem warum da ein Unterschied ist .
EDIT: Habe diese Doku gefunden . Dort geht es eindeutiger hervor und es gibt einen Unterschied zwischen den beiden Pins. Die Angabe auf Seite 60 scheint bei GPIO13 fehlerhaft zu sein . Hatte bei der Auswahl der Pins Pech .
VG
Noch eine Anmerkung : ohne PSRAM ständig Aussetzer mit Radiostreams auch mit externer WLAN-Antenne , mit PSRAM bisher nie .
Fazit für mich : nur Wrover verwenden . Ich benutze z.Zt. Wrover IE 16Mb
1 „Gefällt mir“
Hi
bei mir floatet der Pin HP_detect , da fehlt der Pullup in der Audio.cpp
#ifdef HEADPHONE_ADJUST_ENABLE
pinMode(HP_DETECT, INPUT_PULLUP);
Beim Ausschalten habe ich ein leichtes Knacken , kannst du bitte den GPIO_PA_EN vor Abschalten deaktivieren . Je nach verwendeter Hardware passiert das auch beim Systemstart . Auch da wäre ein kurzer delay 200-500ms von Vorteil
VG
Edit: Ich habe es beim Abschalten mit der aktuellen Version noch nicht getestet ob es da auch passiert , war vorher irgendwann mal so .
Ok, danke für dein Feedback.
Das muss ich dann aber auf den Fall einschränken, dass es ein GPIO und nicht der Port-Expander ist. Ich überlege jetzt nur gerade: Was machen wir denn, wenn DETECT_HP_ON_HIGH gesetzt ist? Dann muss ich ja nen Pulldown setzen, oder?
Das mit den Delay müsste einfach machbar sein.
Ja , das hatte ich auch schon überlegt und war mir unsicher .
Ich habe im Moment mit der Cliff ( bei gestecktem Hörer ist Kontakt offen )
#define DETECT_HP_ON_HIGH , das funktioniert . Umgekehrt müßte es doch auch gehen . Da frage ich doch auf LOW ab . Ich denke das klappt . Werde ich mal ausprobieren . In der Praxis ist man ja vor Überraschungen nicht sicher
Das delay habe ich schon drin und ich denke so max 500 ms sind ok
Gruß Willmar
Also … es funktioniert mit dem Pullup in beiden Fällen. Ich hatte mal diese Buchsen bestellt und ein Layout erstellt mit der Möglichkeit HIGH oder LOW-aktiv zu jumpern . Damit habe ich es probiert . Die Buchsen sind sehr billig , wirken aber robust und sind damit eine sehr gute Alternative zu den recht teuren Cliff-Kopfhörerbuchsen . Außerdem sind zusätzlich zu den Schaltkontakten für Audio noch 2 potentialfreie Umschaltekontakte vorhanden .
VG
So, ich habe das jetzt mal angepasst. Wenn ich so drüber nachdenke: Vielleicht bringt das auch dem ein oder anderen hier was, der Probleme mit meinen PCBs ohne Kopfhörerplatine hatte.
Teste bitte mal, ob das jetzt passt. Ich habe beim Einschalten ein Delay derart eingebaut, dass die Amps frühestens nach 500ms Uptime aktiviert werden. Und beim Ausschalten werden die Amps zuerst deaktiviert.
Funktioniert natürlich nur, wenn man GPIO_PA_EN und/oder GPIO_HP_EN definiert hat. Ich habe bei mir keinen Testaufbau, um das testen zu können. Es ist also ungetestet, aber kompilieren lässt es sich auf jeden Fall 
Hi @biologist
Ich glaube meine Idee zum Pullup an HP_detect ist für Nutzer des MAX98357 eher kontraproduktiv .
Da war doch mal was .
Die Arbeitsweise des MAX98357 wird doch mit Widerständen an Pin SD eingestellt . Damit verändert ein Pullup die Werte und ich weiß im Moment nicht was dann passiert . Ich verwende auf meinem neuen Board keinen MAX mehr und daher tritt das Floaten bei meiner Hardware auf .
Das müßte man nochmals in allen Hardwarevarianten testen . Ich glaube ja auch dass es durch die damals eingeführte Variante Play_Mono_Speaker nicht mehr passiert .
Gruß Willmar
Die andere Änderung werde ich am WE mal ausprobieren .
Ich weiß es nicht sicher. Aber ich habe mal den PCB genommen für den Lolin D32 pro. Ohne HP_DETECT und ohne Kopfhörerplatine habe ich was gehört. Mit aktiviertem HP_DETECT und nur INPUT ging es nicht. Mit Pulldown auch nicht. Mit PullUp aber schon.
Vielleicht kann das mal noch jmd hier testen, weil ich habe es auch in den Masterbranch eingecheckt.
Ich hab mir hierzu mal das notiert, aber finde die Quelle gerade nicht:
- Die Verstärkung des MAX kann über die Beschaltung des GAIN Pins wie folgt angepasst werden.
| Gain Rate | Gain Pin Connection |
|---|---|
| 15 dB | Connected to GND through a 100k resistor |
| 12 dB | Connected to GND |
| 9 dB | Unconnected (Default) |
| 6 dB | Connected to VDD / Vin |
| 3dB | connected to VDD / Vin through a 100k resistor |
Das kommt aus dem Datenblatt vom max98357a. Aber Gain ist nochmal was Anderes. Der Pin zum Mute heißt glaube ich sd oder so (müsste nachschauen).
Ich habe das hier gefunden
One thing! A very loud POP at both power on and when the mpd/mpc “play” command was issued. Solved the
power on POP with a 10K pull-down resistor on the SD (mute) pin. Worked around the “play” POP by delaying
the un-mute for 2 seconds after starting “play”.
1 „Gefällt mir“
So, das neue Partitions-Layout ist nun im Refactoring-Branch aktiv. Es gibt ein Profil für 4 MB Flash und eines für 16 MB.
Wenn ihr also ein Update macht, dann beachtet das hier: 📗 Wechsel zum Refactoring-Branch: Was ist zu beachten?
Beim Neustart wird eine Warnung angezeigt, die nach fünfmaliger Anzeige nicht mehr erscheint.
@tuniii Du hattest ja mal eine Anzeige eingebaut, bei der man den derzeit größt-möglichen „Heap-Brocken“ angezeigt bekommt. Mit aktiviertem PSRAM wird da offenbar der PSRAM dazugezählt. So habe ich auf einem Lolin D32 pro gerade 3.881.772 Bytes. Ist halt nicht so zielführend 
Wollte es nur hier mal erwähnen, weil das erschwert dann die Fehlersuche ggf bei den WROVERn.
@MusikHexe / @tuniii Habe den Bug mit Bluetooth im Refactoring-Branch eben gefunden und gefixt.
Problem war, dass der Audiotask nicht gestartet werden darf, wenn der BT-Mode aktiv ist.
@compactflash Ich habe eben im Refactoring-Branch eine Anpassung eingecheckt, die dafür sorgt, dass die JSON-Objekte aus dem PSRAM allokiert werden (sofern dieser halt vorhanden ist). Kannst das mal auf deiner Hardware etwas testen? Auf dem Lolin D32 pro funktioniert es auf jeden Fall.