Ich habe den hier bestellt
Und der läuft auch im o.g. Board?
Dadurch, dass ich die Box zu einem bestimmten Termin verschenken wollte, blieb mir nur der heute-bestellt-morgen-da Service. Zu dem Preis will man ohne Zeitdruck sicher nicht bestellen.
Ja die haben funktioniert bei mir an zwei Boxen. Aber bei den Chinesen weiß man ja nie was man so bekommt, kann in der nächsten charge schon wieder anders sein.
Ich habe jetzt meine Platte komplett fertig inkl Headphone PCB.
Ich habe folgende Probleme:
- Beim drehen vom Rotary Encoder oder wenn ich in WEG UI die Lautstärke verändere hört man leichtes Knistern
- Beim HEADPHONE PCB, wenn ich den Kopfhörer einstecke wird der Lautsprecher nicht gemutet, der Flag in Firmware gesetzt.
- Wenn nichts abgespielt wird, hört man in dem Kopfhörer leichtes Rauschen / Brummen
Habt ihr welceh Ideen/ Tipps was zu überprüfen wäre?
Das kann ich bestätigen. Leider habe ich dafür keine Lösung, sonst hätte ich das schon abgestellt. @Wolle Ist dir das mal aufgefallen (und kannst ggf. was dazu sagen)? Bei mir ist das kein Knistern, sondern es klingt bissl abgehakt.
Das ist eigentlich über die Kopfhörerplatine hardwareseitig gelöst. D.h. wenn man SD mit GND beschaltet, dann geht der MAX in den Shutdown. Wenn du dir den Schaltplan anschaust, dann macht der Mosfet Q1 genau das. Er invertiert nämlich das Verhalten der Klinkenbuchse, denn diese würde GND ausgeben, wenn nix eingesteckt ist. Also genau falsch rum.
mit abgehakt / Knistern ist ok, ist nicht so, dass es gewaltig stört. Aber gut zu wissen, dass es nicht an meinen zwei linken Händen liegt 
Mit Kopfhörerplatine verstehe ich so, wenn es nicht abgeschaltet wird, dann wird Pin6 nicht durch die Platine auf GND gesetzt. Evtl irgendeine Lötstelle noch nicht ok. Werde es überrpüfen.
Ich habe jetzt mal einen neuen PCB bei JLCPCB in Auftrag gegeben, der folgende Eckdaten besitzt:
- Lolin D32 pro (wie gehabt)
- SD_MMC (externer Reader wie sonst üblich, der interne wird nicht benutzt)
- MAX98537a (wie gehabt)
- PN5180 (RC522 kann man natürlich auch anschließen, der braucht dann halt nicht alle Pins; IRQ-jumperbar)
- PCA955 (Port-Expander mit 16 Ein/Ausgängen)
- Fünf Buttons (JST.PH, alle am Port-Expander angeschlossen)
- I2C-Konnektor (JST-PH, wie üblich auf meinen PCBs)
- Reset-Anschluss (Pin-Header, 2,54mm)
- Serial-Anschluss (Pin-Header, 2,54mm)
- Neopixel-Anschluss (JST-PH)
- HP_DETECT und PA_EN sind jetzt über den Port-Expander entkoppelt, so dass man per Software den MAX an- und abschalten kann
- Restliche (freie) Pins des Port-Expanders auf einen Konnektor rausgeführt (2,54mm, doppelreihig)
- Widerstände und Mosfets in SMD-Technik (0805 hand solder / SOT23)
Also in erster Linie dient das Ganze erstmal für Tests für mich, da ich aktuell noch keinen PCB habe, auf dem ein Port-Expander drauf ist. Ich habe auch nix, um mal fünf Buttons zu testen (ich selbst nutze das nicht). Ich wollte also einfach mal einen Plattform haben, mit der ich möglichst viele Sachen testen kann.
@thebino Wenn das soweit funktioniert, dann werde ich kurzfristig darauf basierend einen PCB machen, der ohne SMD-Technik auskommt. Der hat dann zwar keinen Port-Expander, aber das muss er auch nicht. Das Augenmerk wird dann darauf liegen, neben dem PN5180 auch SD_MMC anzubieten. Es ist halt nur so, dass es dann mit den GPIOs bei einem ESP32-WROVER schon seeeehr eng ist.
Das hört sich alles fantastisch an. Ich würde dann gerne die Kosten für dein Test-PCB übernehmen. Näheres dann gerne via PN
Gemach gemach! 
Ich muss erstmal schauen, ob der überhaupt funktioniert 
Habe das erst am WE bestellt. Normalerweise brauchen die PCBs so zwei Wochen, bis sie hier sind. Also zumindest war es bisher so.
Hat diesmal irgendwie länger gedauert. Die PCBs sind erst vorgestern auf die Reise gegangen.
Also ich melde mich, wenn ich das getestet habe.
Die PCBs kamen gestern (Dienstag) an. An für sich läuft alles so, wie ich mir das gedacht hatte - ist ein schöner PCB geworden, bei dem man endlich alles beisammen hat:
- WROVER (mit 16MB Flash; somit hat man PSRAM und OTA-Support)
- SD_MMC (der interne SD-Slot des Lolin D32 pro wird nicht genutzt)
- PN5180 (RC522 geht aber auch)
- Port-Expander (unbenutzte Pins werden rausgeführt)
- Kopfhöreranschluss
- Bis zu fünf Buttons (mehr unterstützt ESPuino nicht)
- I2C-Anschluss (könnte man z.B. perspektivisch ein Display anschließen)
An einer Stelle ist mir jedoch ein Fehler unterlaufen. Und zwar ist beim Lolin D32 pro ja auf GPIO5 eine LED drauf, die dann leuchtet, wenn der GPIO auf LOW gezogen wird. Also z.B. dann, wenn man einen Button anschließt und diesen drückt. Und da dachte ich mir: Wär’ doch cool, genau dort den Interrupt des Port-Expanders (PE) drauf zu legen. Für das reine Interrupting im Betrieb klappt das auch wunderbar. Das Problem ist nur, dass ich ja alle Buttons am PE angeschlossen habe und daher das Interrupting auch verwende, um den ESP32 aufzuwecken. Blöderweise ist ausgerechnet GPIO5 kein RTC-Pin und daher klappt das Aufwecken nicht. Ich bin daher mal hingegangen und habe eine Brücke von GPIO5 auf GPI36 gelötet (war vorher unbeschaltet) und damit ist das Problem behoben (GPI36 ist ein RTC-Pin).
@tueddy Ich habe den IRQ des PN5180 einfach an den PE drangehängt, weil ich dachte, dass es ja im Endeffekt auch nur ein „Button“ ist. Darüber habe ich jetzt allerdings noch ein bisschen nachgedacht: Das hat natürlich zur Folge, dass der Interrupt des PN5180 zu einem sich anschließenden Interrupt des PE führt und somit für den ESP32 eine „normale“ Aufweckaktion ist, wie die von anderen Buttons auch. Ohne es getestet zu haben, gehe ich davon aus, dass es einerseits nicht wirklich mit dem bereits existierenden PN5180-IRQ-Code kompatibel ist und andererseits sowas wie „Oh, Falschalarm! Na dann lege ich mich wieder schlafen…“ nicht funktioniert. Korrekt?
Ist so ein bisschen die Frage, wo ich RFID.IRQ alternativ drauflegen könnte.
5 ist kein RTC-Pin und 0 wird für Bootstrapping benutzt. Weiß nicht, ob 0 ggf. problematisch ist; der darf beim Booten auf jeden Fall nicht low sein, weil sonst der ESP32 in den Programmind Mode geht.
Weiß nicht, ob man vielleicht I2C_CLK von GPIO4 auf GPIO5 schieben kann und legt PN5180.IRQ dann auf GPIO4. Allerdings will man vermutlich einen Taktausgang (I2C_CLK) nicht unbedingt mit einer LED belastet haben…
Der PN5180 IRQ Pin wird immer aktiv bei einem Interrupt, das können im aktiven Betrieb ganz verschiedene sein. Im LPCD Modus wird der Interrupt nur ausgelöst wenn sich das RF-Feld geändert hat (Karte oder Metall erkannt). Ist der ESP32 durch den IRQ Pin aufgewacht findet ja eine vollständige Kartenabfrage statt.
Ob das jetzt mit einem zwischengeschalteten Port-Expanders so klappt kann ich nicht beantworten - Müsste man einfach mal ausprobieren…
Das ist eben genau die Einschränkung. Man hat, wie es aktuell implementiert ist, ja einen dedizierten GPIO, den man zum Aufwachen für den PN5180 konfiguriert. D.h. wenn darüber aufgeweckt wird, dann weiß man sicher, dass der PN5180 „schuld“ ist. Das wäre über Port-Expander anders: Dort belegt RFID.IRQ einen Eingang, wie jeder andere Button auch. Wenn der ESP32 nun schläft und es wird durch eine Änderung an einem Pin des PE ein Interrupt vom PE ausgelöst, dann wacht der ESP32 auf, aber es ist halt nicht unterscheidbar, was (welcher Eingang am PE) den Interrupt ausgelöst hat.
Andererseits ist die Frage, ob das so dramatisch wäre: Man verliert man halt die Möglichkeit, dass man bei einem Falschalarm den ESP32 sofort wieder schlafen legt. Andererseits geht er nach ein paar Minuten idle (10 per Default) eh wieder schlafen.
Also ich vermute mal, dass viel von der aktuellen Implementierung nur dann Sinn macht, wenn RFID.IRQ tatsächlich ein richtiger GPIO ist. Am Port-Expander ist es vermutlich einfach ausreichend, nur einen Interrupt auszulösen, dann wacht der ESP32 auf wie üblich. Und dann wird die Karte halt gescannt.
Ich muss endlich mal bei dem PN5180, den du mir mal geschickt hast, die Pinleiste ablöten und Drähte für JST-PH 10fach dran, damit ich eine Testbasis für das Feature habe. Eigentlich ja keine große Sache… 
Den neuen PCB gibt es jetzt hier: Lolin D32 pro mit SD_MMC, PN5180, max. fünf Buttons und Port-Expander (SMD).
Habe gestern ansonsten bisschen was hochgeladen:
- Neues Config-File für neuen HAL (für den neuen PCB)
- Entfernung einer Race-Condition im Shutdown bei Nutzung von LPCD
- LPCD mit Port-Expander kompatibel gemacht
- LPCD-IRQ ist im aktiven Zustand nun LOW und nicht mehr HIGH
- Audiolib auf neue Version gepinnt
Ich werde die Tage für diejenigen, die keine SMD-Platine löten wollen, jedoch gerne PN5180/SDMMC hätten, nochmal einen PCB machen, der folgende Features hat:
- Lolin D32 pro
- Mosfet-Abschaltung mit IRL3103 + NDP6020p (wie gehabt)
- Externer SD-Reader (wegen SD_MMC)
- PN5180 (RC522 geht auch)
- Drei Buttons
- Drehencoder
- Reset-Button
- Anschluss für Kopfhörerplatine
1 „Gefällt mir“
Nochmal ein FollowUp in dieser Sache:
Der PCB, um den es hier geht, bindet SD per SPI an. Das ist insofern total praktisch, weil dann kann man den SD-Reader benutzen, der auf dem Lolin D32 pro integriert ist. Macht Sinn. Der PCB war einer der ersten, die ich entworfen hatte und damals konnte ESPuino noch kein SDMMC. Vorteil an SDMMC ist: Es ist locker doppelt so schnell und braucht dabei (im 1Bit-Modus) nur drei statt vier GPIOs. Blöd daran ist: Die GPIOs müssen zwingend 2, 14 und 15 sein, weswegen man den internen Reader des Lolin D32 pro nicht nutzen kann. Ist halt so 
.
Jetzt kann man natürlich sagen: „Egal, ich habe Zeit - dauert’s halt bissl länger!“. Problem: Es gibt einen Bug, der dazu führt, dass Dateitransfers (egal ob Transfer über die Webgui oder FTP) abbrechen können. Und zwar abbrechen in der Form, dass scheinbar weitergeschrieben wird, aber ab einem Zeitpunkt x nix mehr geschrieben wird. Ob und wann das passiert, scheint völlig zufällig zu sein. Jedenfalls ist das Ergebnis daraus, dass es passieren kann, dass unvollständige Dateien geschrieben werden. Diesem Problem war ich mir lange nicht bewusst, aber ich habe es auch leider nicht geschafft, das zu fixen. Heißt: Ich würde von SD-Anbindung per SPI für ESPuino inzwischen absehen. Zumindest mal dann, wenn man Daten per WLAN auf die SD-Karte kopieren will. Baut man sie eh immer aus und befüllt sie am Rechner, dann ist der Punkt egal und man hat keinerlei Probleme.
Da jedoch der Transfer über WLAN eines DER Features von ESPuino sind, habe ich vor ein paar Monaten Lolin D32 pro mit SD_MMC, PN5180, max. fünf Buttons und Port-Expander (SMD) entwickelt. Das erwähnt zwar den PN5180 explizit, aber läuft mit dem RC522 ebenfalls (man benötigt nur manche Pins nicht). Verwendet halt (aus o.g. Gründen) einen externen Kartenleser, der jedoch schön in den PCB integriert ist.
Wie auch immer: Ich erwähne das, weil ich ab und an noch Anfragen wegen der hier beschriebenen Platine kriege. Und an der Stelle möchte ich sagen: Ja, ein paar wenige habe ich noch da, ich würde jedoch, primär wegen Geschwindigkeit und Dateiabbruch, zur neuen Platine greifen. Diese ist auch kompakter, unterstützt auch den PN5180 und kann auch bis zu fünf Buttons (statt deren drei).
Dann möchte ich nochmal Bezug nehmen auf:
Die Idee dieser Platine habe ich letztlich dann doch wieder verworfen, weil man die SMD-Variante kompakter bauen kann und ich diese auch wahlweise gelötet abgebe, so dass die SMD-Bestückung für niemand ein Nachteil ist. Schlussendlich erspart es mir auch den Support einer weiteren Platine.