Platine für ESPuino

Ich war die Tage bei Hörbert zum ersten Mal auf der Website. Ich kann dieser Lösung mit den ganzen Tasten irgendwie nix abgewinnen. Aber das muss ja jeder selbst wissen.

Ich weiß allerdings auch nicht, wieviele Buttons man analog diskriminiert bekommt - da habe ich keine Erfahrungswerte. Aber ja, ich gebe zu, so 2-3 GPIOs würde man damit gewinnen.

Da bin ich voll bei dir. Ich kann dem auch nix abgewinnen. Zumal die Konfiguration der 15 Tasten nerven würde. Mein Sohn hört sich öfters an Hörspielen satt und dann wäre ich immer verdonnert die Sachen zu ändern.
Die Kids sind zwar pfiffig aber jedes Mal die Hörspiele hinter den Tasten neu lernen - naja. Da finde ich Figuren und Bilder selbsterklärender.

Ich meinte nur, man könnte überlegen ob man die Option bei einer neuen Platine mit vorsieht, wenn Platz ist. Ich vermute, es wird wenige geben, die das Umsetzen wollen.

Ich hänge nicht an dem Feature - ich wollte es nur erwähnt haben

Nee, ist auch ok :slight_smile:
@compactflash ist sich dessen mit analogRead() auch bewusst. Ich habe das mit ihm auch schon diskutiert. Vermutlich hängt es mehr an mir als an ihm, weil ich das auch in Software implementieren und testen müsste. Und naja, aktuell komme ich mit den GPIOs aus, hehe.

Danke für die schnelle Rückmeldung. Ich hatte übersehen, dass das EN-Signal auch zum LDO-Regler geht.

Da würde ich gerne mal nachfragen. Ich habe das Thema mit einer eigenständigen Platine ebenfalls noch weiterverfolgt und habe einen ersten Prototypen fertig. Dabei bin ich zur Zeit beim WM8978 als DAC gelandet. Aber unschlüssig.
Benutzt Du einen MAX98357? Lässt Du nur die Platinen fertigen und lötest selbst?

WM8978 kenne ich nicht persönlich . Ich glaube der wird auf diversen Audioboards für den Raspberrypi verwendet . Meine neue Idee habe ich mal kurz im Github von @biologist unter Discussion vorgestellt . Dazu habe ich Wolle ( Schreibfaul1) gebeten seine Library zu ändern , was er freundlicherweise gestern gemacht hat . Danke auch von hier nochmals dafür .
Ich löte selbst .

@compactflash :
unter welcher Lizenz stehen denn deine KiCad-Dateien?
ich würde gerne alle KiCad-Dateien für alle bisherigen Platinen sammeln und auf Github stellen. Deine Kopfhörerplatine ist ja schon im offiziellen Repository gelandet.

@biologist :
aus welchem Grund hast du denn die KiCad-Dateien gelöscht?
Ging es da nur um den Namen? Weil ich den gerne überall zu ESPuino ändere, falls das nötig wäre, um die Dateien wieder bereitzustellen.

Da hast du richtig vermutet: Ich war zu faul es umzubenennen :rofl:.
Ja, also wenn du den Part übernehmen möchtest, dann lade ich das gerne wieder hoch ins Repository.

@compactflash . Der Link funktioniert bei mir nicht mehr?
Ich wollte mal nach der genauen Verwendung vom LTC2954 schauen. Sehe ich das richtig, das der „nur“ die Pushbutton-Logik abbildet, ich aber zusätzlich noch einen Mosfet benötige um die Last zu schalten?

Vielen Dank

Hier ist der aktuelle Link ESPuino ESP32pro - pCloud

Wer bastelt eigentlich jetzt alles an einer Platine?
@QDaniel
@Christian
@StefSo

Ich Blicke nicht mehr durch…Welche Baustellen gibt es noch?

1 „Gefällt mir“

Hi @Christian
Habe mal was geschrieben

1 „Gefällt mir“

Ich experimentiere gerade mit dem Port-Expander PCA9555 und werde diesen dann demnächst auch unterstützen. Ne extra Lib braucht es für diesen nicht, da kommt man mit Wire.h aus.

Dieser Expander besitzt zwei Ports mit jeweils acht Kanälen. Da kann man also einiges an Buttons dranhängen wenn man möchte. Das Erkennen, ob ein Kopfhörer eingesteckt ist, geht darüber natürlich dann auch. D.h. mit drei Buttons + Drehencoder-Button + Kopfhörer-Erkennung sparen wir fünf GPIOs, es kostet jedoch nur zwei für i2c (+ggf ein weiterer GPIO für den Interrupt, aber ich bin mir noch unsicher, ob ich den nutzen will). Mit dem zusätzlichen Vorteil, dass man dann auch ein i2c-Display anschließen könnte oder auch RFID via i2c. DT+CLK des Drehencoders könnte man prinzipiell auch darüber auswerten, aber da müsste die Drehencoder-Lib angepasst werden, was mir ehrlich gesagt zu viel Aufwand ist. Ich denke wenn man die Buttons von den GPIOs wegholt, dann sollte das schon reichen, um keine Limitierungen mehr zu haben. Auch sowas wie eine Erkennung, ob eine SD-Karte eingesteckt ist, ist denkbar, aber das werte ich aktuell nicht aus.

Für eure Planung:
Ansonsten gibt’s dieses Bauteil auch bei JLC als extended part. Ich hab’s mir im TSSOP24-Gehäuse bestellt, was relativ klein ist und auf ein Breakout-Board gelötet. Man kriegt es aber (siehe Datenblatt) auch als SOP24, dann sollte sich das (für ein SMD-Bauteil) relativ einfach löten lassen von Hand. Das Größenverhältnis zwischen beiden kann man auf dem Bild für das Breakout-Board gut sehen (das kann beides - man muss die Platine nur rumdrehen).

Externe Beschaltung braucht’s nicht viel:

  • Pullups für SCL, SDA und INT
  • Die Eingänge A0, A1, A2 würde ich auf Masse legen, so dass man die Adresse 0x20 verwenden kann. Aber diese Adresse würde ich eh konfigurierbar halten im Code. Beschaltet man diese Eingänge nicht, so ist es halt 0x27 stattdessen.

Hier hat jmd. damit ein bisschen experimentiert: Arduino Interface PCA9555 GPIO Expander With Code

1 „Gefällt mir“

Wenn man die Buttons (vor allem den Drehencoder-Button) für das Aufwachen aus dem Tiefschlaf nutzen möchte wäre der Interrupt-Pin nützlich, oder?
Eventuell kann man dann IRQ und BUSY vom PN5180 auch über den Extender laufen lassen und könnte trotzdem LPCD nutzen.

Wenn man den Port-Expander auch für das Aufwachen aus dem Deep-Sleep nutzen möchte und dauerhaft mit Strom versorgt, wäre noch der Stromverbrauch ganz interessant.
Man könnte sich deshalb den PCA9535 mal anschauen und ich habe einen MCP25017 hier.
Für den MCP25S17 (SPI-Variante) bräuchte man sogar nur einen Pin (SPI Cable Select).
Für den bräuchte man aber eine Library, glaube ich.
Wichtiger als der konkrete Port-Extender ist aber, dass nur einer unterstützt wird oder zumindest der Code kompatibel ist, deshalb hole ich mir auch mal den gleichen wie du @biologist .

Also dass man Busy darüber laufen lassen kann, glaube ich eher nicht. Aber IRQ könnte ich mir vorstellen. Tatsächlich muss ich zugeben, dass ich auf die Idee mit dem Interrupt-Aufwachen noch nicht gekommen bin. Find ich gut :slight_smile:

Habe hier auf einen Lolin32 den Testsketch mit dem Expander laufen und kann auf meinem USB-Multimeter in Sachen Stromaufnahme keinen Unterschied feststellen, wenn ich den PCA9555 entferne. Die Stromaufnahme liegt immer bei 47 mA.

Ich habe das gerade mal ausprobiert: Klappt ohne Probleme :+1:

1 „Gefällt mir“

Hi @biologist

Reicht als I/O Expander nicht auch einer mit 8 I/O´s . z.Bsp. PCF8574 . Den habe ich schon in TTL vor 30 Jahren eingesetzt . Soviel Pins werden doch garnicht benötigt , oder ?

Naja, wenn man mal durch zählt mit 5 Buttons, Drehencoder-Button, PN5180-RST, Headphone-DETECT… Da hat man die 8 Pins schon voll.
So wie ich die Community hier erlebt habe, kommen bestimmt wieder neue Ideen dazu. Noch ein paar Pins für LEDs oder so kann man ja in Reserve haben.

Ich denke auch, dass man mit 16 auf der sicheren Seite ist. Weil ich will das Thema nicht nochmal anfassen müssen. Aktuell habe ich allerdings noch Probleme, die Taster verlässlich auszulesen. Oftmals klappt nur drücken, aber nicht loslassen.

Hi,

Ich verfolge das Projekt schon eine Weile und bin sehr begeistert. Deshalb würde ich gerne meinen ersten ESPuino bauen. Da hier ja verschiedene PCBs vorgestellt wurden:
Gibt es eine Empfelung welcher PCB zur Zeit am vielversprechensten ist?

Moin,

die Frage ist letztlich, was dir wichtig ist. Ich habe hier einen längeren Beitrag dazu geschrieben: 📗 Welche Hardware nutzen? (Develboard, RFID, SD)

Wobei ich anmerken muss, dass die Reichweite des RC522 wohl tatsächlich besser wird, wenn man ihn Codetechnisch nicht im Task laufen lässt. Das muss ich aber nochmal verifizieren. Also ich hatte es schon getestet, hatte ohne Task jedoch Probleme mit den Laufzeiten bei pn5180. Da muss ich nochmal bissl Zeit reinstecken.