Schönen Guten Abend,
danke für die Anerkennung. Ich fand spannend was möglich ist, und gemeinsam kann man ja was draus machen.
@stephan: Ja, ist advanced. Sieh es als Inspiration für den nächsten Fork ;o). Über die PB Probleme hatte ich gelesen. Aber wie vieles könnte man die verschiedenen E-Sparfunktionen als DEFINE aktivieren. Dann kann jeder so weit gehen, wie es ihm passt. Alleine implementieren wird sich das keiner. Das gibt die aktuelle Programmstruktur gar nicht her. Aber @Thorsten backt ja schon eine neue Software. Vielleicht reizt es ihn.
Nun, wie du richtig erkannt hast, die Schlaffunktionen für NANO und RFID Reader sind die dicken Fische. Das ist reine Software. Die Sache mit dem Verstärker habe ich beschrieben. Wenn man den DF-Player frisiert hat, ist es eben eine IO Verbindung mehr. Den Shutdown raus zu legen scheint mir auch weniger Aufwand als die externen FET Beschaltungen. Beim AIO ist es eh schon drin.
Die getrennten Spannungsebenen für MP3 Decoder und Verstärker machen denke ich nur in einem AIO Konzept mit fertiger Leiterplatte Sinn, weil da die Spannungsversorgung zunehmend heikel wird. Das muss das Design abfangen.
Was die Bedienbarkeit angeht, ist das denke ich kein Problem. In meiner Bastelversion hatte ich pauschal für die Relevanten Tasten und Busy bereits den Pin Change Interrupt aktiviert. Bei jeder Statusänderung wacht der NANO sofort auf. Die Pausenzeit des Watchdog (am Ende 120 ms) ist also eine Worst Case Zeit. Die er maximal schläft, bevor er den Reader einschaltet und schaut ob die Karte noch da ist.
Die Frage habe ich befürchtet ;o). Mein Bastelcode taugt nicht zu Veröffentlichung. Das Kernproblem ist die Integration in den Original Code. Ich habe erstmal einen Fork Loopfähig gemacht, damit ich nicht ständig in irgendwelchen Schleifen verhungere. Aber da habe ich mich bereits vor dem Adminmenü gedrückt. Wenn das im Standard gegeben wäre, wäre der Aufwand gar nicht mehr so groß.
Nach jedem Durchlauf rufe ich dann die Schlaffunktionen auf.
Die Schlaffunktion für den RFID ist im Befehlssatz der MFRC522 Lib enthalten. Für die Schlafmodi des ATMEL empfehle ich die LowPower Lib. Sehr einfach in der Handhabung.
Für den MP3 und RFID habe ich zwei eigene Klassen geschrieben. Die erben erstmal alle Methoden vom Original. Somit reichen sie im ersten Moment alle Methodenaufrufe einfach durch. Im zweiten Schritt habe ich dann für die relevanten Funktionen (z.B. Play, Pause, Stop bzw. Read & Write), die Methoden überladen und hier die Ein-/Abschaltung des Verstärkers bzw. RFID Readers integriert, bevor diese den Aufruf dann an die original Methode weiter reichen. Der Vorteil an diesem Vorgehen ist, dass ich im Original Code dann nur bei der Objekt Deklaration auf meine Klasse verweisen musste. Aber in der Testphase habe ich das leider nicht ganz konsequent verfolgt (verfolgen können). Für Quick & Dirty OK. Ich kann dir das gerne mal schicken.
Wenn man das ordentlich implementieren will, wird man den Code großflächig überarbeiten müssen. Es macht Sinn die ganzen Player und Card Aktionen in diesen erwähnten Klassen zu kapseln, so das man das Power- und Datenmanagement innerhalb der Klasse intelligent abwickeln kann. Das sollte nicht Aufgabe des Hauptprogramms sein. Der Aufwand schreckt mich noch ab. Außerdem bleibt dann kein Stein mehr auf dem Anderen. Macht also nur Sinn, wenn die Hauptakteure die regelmäßig Änderungen und Erweiterungen einbringen sich für das Thema begeistern können. Sonst wird die Code Pflege zu aufwändig.
Ich habe dazu mal die Library ClickEncoder verwendet. Dies basiert auch auf dem Pin change interrupt. Damit läuft sie an allen Pins gleichermaßen und kann auch einen Beschleunigungswert ableiten. Die sollte kein Problem sein.
Bei LED Animationen bin ich raus. Aber generell hängt das stark von der Dynamik deiner Animation ab. Für die laufende kurze Animationen kannst du natürlich die Schlafzeit kürzen, oder auch erstmal den NANO weiter laufen lassen. Ich meine auch, dass die PWM Ausgänge in „leichteren“ Schlafmodi weitgehend unabhängig weiter laufen können. Muss man sich anschauen.
Thomas hat es schon auf den Punkt gebracht. Die berüchtigten Einschaltgeräusche. Oder ein Zirpen wenn der Nano mit dem MP3 Decoder Kommuniziert. Manche haben im Forum auch von einem hörbaren Rauschen in Pause berichtet.
@raznz_snasna : Hallo Stefan, stimmt schon, die Hardwarevariante hätte ihren Scharm. Habe das auch ausprobiert. Problem ist die Einschaltverzögerung des Verstärkers. Die liegt bei 1 µF Bypass Kondensator bereits bei ca. 100 ms. Das führt dazu, dass die Ansagen vorne abgeschnitten werden. Wenn du den Player einfach mal zählen lässt: Eins, Zwei, Drei, dann hörst du durch diesen Effekt nur noch: nz, wei, rei. Daher ist die zeitliche Koordination über den Nano erforderlich. Mit den Optimierungen von Johannes (Bypass 11µF) geht das Delay noch höher, ca. 900 ms. Das Delay an sich stört nicht wirklich, vorausgesetzt das Timing stimmt. Hinzu kommen die von Thomas beschriebenen Vorteile in der Flexibilität.
Wenn er ein paar ms länger läuft, ist es kein Beinbruch. Aktuell läuft er vollgas durch. In der Messwerttabelle siehst du, dass ich am Ende die Pause auf 120 ms gekürzt habe, um die Reaktion auf den Card Reader zu verbessern. In meiner aktuell noch sehr gebastelten Software lasse ich den Nano auch über den Pin Change Interrupt auf allen relevanten IO wecken. Wenn man in den 125 ms Tiefschlaf auf eine Taste geht, oder der Busy wechselt, wacht der Nano auch sofort auf.
Wenn man das sauber implementiert, hat das Thema denke ich interessantes Potential, auch für die Breite. Ich lauer da auf Torstens nächsten Wurf.
Einen Haken hat die Sache mit dem Deepsleep. Millies schläft auch. Für Timings die über einen Zyklus hinausgehen muss man sich also was überlegen.