Stimmt, voll gut 
. Warum bin ich da nicht drauf gekommen? 
.
Brauchst nicht. Den Schaltplan habe ich schon. Ich hab’s gestern auch mal testweise autorouten lassen.
So, ich hab’ da mal was vorbereitet…
Von oben:
Von unten:
Im Gegensatz zu sonst hatte ich auf dieser Platine mal fürstlich viel Platz .
Die Anschlüsse für Lautsprecher und Akku habe ich ausgespart.
Das Ganze dann natürlich in schwarz. Bin gespannt .
EDIT: Das geht so nicht habe ich gesehen, weil GPIO21 ja verwendet wird, um die Endstufe für den Lautsprecher ein/auszuschalten.
Überall noch bisschen C raufpacken, wenn der Platz denn da ist
Ich verpasse einfach jedem IC und jedem Anschluss mit VCC/GND dann noch ein 100nF, schaden kann es nicht…
Dann vielleicht noch paar große Cs für VCC allgemein, kostet ja kein Brot…
Ich nehmen bei sowas auch immer eine Lage komplett für VCC und eine Lage für GND, dann wird die VCC Anbindung auch nicht so dünn 
Ja stimmt, Kondensatoren fehlen noch. Platz gibt’s massig.
Ich hab’s jetzt aber eh noch nicht abgeschickt, da mir noch aufgefallen ist, dass GPIO21 für die Amp verwendet wird. Habe dann mal Drehencoder am Port-Expander getestet, aber das funktioniert bisher nicht gut. @fizze Du hattest das doch mal gelöst, oder? Also man kann ja im Interrupt das Auslesen des Drehencoders triggern, nur das Problem ist halt, dass man vorher auch noch den Port-Expander auslesen muss. Also wenn der ESPuino im Leerlauf ist dann lief es sehr gut, wenn ich in der Mainloop Port_Cyclic() mehrfach aufgerufen habe. Das wird ja eh durch den Interrupt begrenzt. Aber beim Abspielen lief das schon bisschen zähler und beim Hochladen von Files ging quasi gar nix mehr.
Weiß nicht, ob es vielleicht eine Lösung wäre, RFID.CS an GPIO 0 zu hängen. So ganz wohl ist mir dabei nicht.
Mit espuino hat das nicht funktioniert. Die Ursache konnte ich nicht finden. Ich habe aber den Verdacht dass es durch Software i2c in Arduino zu locks bzw. Race conditions kommt.
In meiner Variante mit esp-idf funktioniert das, auch während der wiedergabe. Wenn man sehr schnell dreht kommt es auch zu fehlern bzw. wird die Eingabe ignoriert, aber das stört mich nicht weiter.
@biologist Leider nicht… Habe nicht mal einen Ton aus dem Minimalbeispiel bekommen, weil ich scheinbar eine neue Version des Boards habe, das nicht mehr den AC101 Chip hat, sondern den ES8388 und damit bekomme ich nur ein Rauschen… Könnte natürlich auch sein, dass mein Board eine Macke hat. Ich dachte es könnte mit dem PN532 über I2C funktionieren, aber da ich schon am Ton gescheitert bin habe ich erst gar nicht versucht den Reader zum Laufen zu bringen.
@janis Schau mal hier: ESP32 A1S Eval - Mikrocontroller.net
Bzw hier: ESP32-audioI2S/ESP32_A1S.ino at bdace9288dba8a094d04bb5d72b33eb6ecc67f99 · schreibfaul1/ESP32-audioI2S · GitHub
Zum zweiten Link: Das ist die Lib, die die mp3s dekodiert für ESPuino. Schau mal, ob du das mit den neuen Einstellung zum Laufen kriegst.
Wo ich da so durchschaue sehe ich auch direkt, dass GPIO 0 auch nicht frei ist, sondern für i2s gebraucht wird. Tja, das wird dann wohl nix mit SPI für RFID bei meinem HAT.
@biologist danke für den Link! Habe es gerade mal schnell probiert und tatsächlich hat es jetzt geklappt, nachdem ich die Pins von I2S_DSIN und I2S_DOUT getauscht hatte. Das Webradio läuft nun einwandfrei 
. Dann werde ich mich als Nächstes mal an den RFID Reader machen…
Dein HAT für das Board, wäre natürlich spitze. Bin gespannt ob du es hinbekommst.
Hier noch meine Pinbelegung (A1S V2.2 A149)
#define I2S_DSIN 26
#define I2S_BCLK 27
#define I2S_LRC 25
#define I2S_MCLK 0
#define I2S_DOUT 35
Also grundsätzlich fertig hatte ich das ja schon, nur GPIO 0 passt dann halt nicht. Ergo kann man nur einen i2c-RFID-Reader nehmen. Ich habe aber ehrlich gesagt nicht so Lust, jetzt auch noch Code für nen dritten Reader zu schreiben.
Eija, ich designe das nochmal um. Ist jetzt nicht so die große Sache. Gibt’s halt kein SPI.
@kkloesener Welchen i2c-Reader in Sachen RC522 verwendest du? Du hattest ja den Code beigesteuert für diesen Part.
Also bei mir läuft der aktuelle Code sehr gut.
Als RC522 habe ich einige Boards dieser Bauart mit I2C am laufen.
Ich habe aber auch noch einen PR in Vorbereitung der u.a. den Code insbesondere bei Verwendung des Feature PAUSE_WHEN_RFID_REMOVED enorm verbessert. Bin aber beruflich gerade schwer eingebunden und es wird noch ein paar Tage dauern. Wer mag kann den Stand bei github laden
Rückmeldungen sind gerne gesehen!
Zum Thema I2C und dem ESP gibt es leider selbst in der ESP-IDF ein Problem: Die Grundlegenden Funktionen sind nicht Thread-Safe!
Wenn also mehrere Geräte an einem I2C hängen und viele Abfragen über mehrere Threads/Cores stattfinden, kann dies zu unverhersehbaren Verhalten und Fehlern führen.
Da ich hier noch ein I2C-OLED Display und einen MPR121 Touch Controller liegen habe, muss ich mir dazu noch was einfallen lassen
Ich dachte schon daran, einen I2C-Thread zu schreiben, der dann nacheinander die Funktionen zum Abfragen/Schreiben der Werte verarbeitet. Also erst RC522 lesen, dann prüfen ob der MPR121 neue Daten hat und dann dem Display die Befehle schicken.
Ein extra Thread/Task ist nicht unbedingt notwendig.
Die Zugriffe kann man auch über ein Binary Semaphore synchronisieren:
Super Tip!
Ich habe es direkt mal ausprobiert und es scheint sehr gut zu klappen. Ich habe dafür ein Mutex definiert und alle Funktionen die direkte I2C Befehle nutzen müssen über eine Hilfsfunktion aufgerufen die zunächst die Semaphore prüft.
Das muss noch schön gemacht werden, aber es wird…
1 „Gefällt mir“
Ich habe das auch verändert um die Erkennung zu verbessern. Klappt das bei Dir gut, auch wenn Du keine Fehler abfängst? Ich prüfe bei mir mehrfach bevor ich wirklich davon ausgehe dass die Karte entfernt wurde. Mag aber ja auch am Reader liegen…
Gute Idee mit „sameCardReapplied“ - wie löst Du das mit Modifikations-Karten? Da will man ja evtl. die gleiche mehrfach auflegen.
Bei mir war es übrigens so, dass eine Veränderung von „SetAntennaGain“ den größten Anteil zur Verbesserung beigetragen hat. Ich habe den Wert verringert (!) Zusammen mit den anderen Änderungen führt das bei mir zu einer sehr schnellen Reaktion / Erkennung mit dem MFRC522.
Ich habe generell das Problem, dass ich die i2c Verbindung nur über die CPU verwenden kann, über die die Verbindung auch initialisiert wurde.
Ist das bei Euch anders?
When you issue the first
Wire.begin()the i2c interrupts are tied to core executing theWire.begin()call. so, whenever an I2C interrupt is triggered, it has to process that interrupt on that specific core. So you can set the core affinity by creating a task on a specific core and initializing i2c from that core. You can submit i2c transaction from either core, but the ISR only executes on initial core.
I2C ist natürlich nicht thread-safe, auch in der ESP-IDF nicht, völlig richtig.
Ob Mutex, Locks etc. da gibts viele Varianten.
Ich persönlich setze da eine Semaphore ein (SemaphoreHandle_t), da können die tasks ewig drauf warten ohne grossartig CPU-Zyklen zu verbraten.
Bei mir ruft der Port Expander via Interrupt eine Routine auf, die die Semaphore freigibt. Das wäre der First-Level Interrupt Handler.
In einem anderen Task wird in Endlosschleife auf die Semaphore gewartet, allerdings mit portMAX_DELAY. Da werden dann alle 2 Register des Port Expanders via I2C gelesen. Ein Register sagt welcher Input sich geändert hat, das andere welchen Wert das Register gerade hat. (Ich verwende den MCP23017).
Das sind 2 I2C Transaktionen, man könnte das denke ich auch in eine packen, das spart dann wieder Bus-Zeiten. Bei der ESP-IDF wird dafür I2C in Hardware verwendet, daher kann man das mit dem Arduino-Code nicht vergleichen. Mit Wire.Begin() etc werden effektiv mittels Timern Ports high bzw. low gesetzt. Dass das CPU-Zyklen braucht ist denke ich klar.
Der I2C bus läuft mit 100kHz, da hängt auch noch der ES8388 dran, sonst nichts mehr.
Ich habe den HAT jetzt nochmal angepasst. Das mit SPI habe ich aufgegeben und stattdessen einfach mal zwei I2C eingeplant. Dort kann man auch jumpern, ob die 3.3 V dauerhaft vorhanden sind oder ob sie im Deepsleep weggeschaltet werden.
2 „Gefällt mir“
So, Bestellung ist abgeschickt.
In zwei Wochen wissen wir dann mehr
1 „Gefällt mir“
@Christian hat mir netterweise einen RC522 mit i2c-Support zukommen lassen; vielen Dank an dieser Stelle! Kam gestern ist; ist ja ordentlich klein muss ich sagen:
Der HAT ist seit gestern auch auf dem Weg zu mir. Da kann es dann hoffentlich bald losgehen .
1 „Gefällt mir“
Den kleinen habe ich auch hier. Ist leider etwas teurer, vor allem der Versand , und wird auch nur von wenigen Verkäufern angeboten. Ist trotzdem für das Redesign meiner Boxen vorgesehen. Die Empfindlichkeit entspricht dem des RC-522 , da merke ich keinen Unterschied.