Hi Matz,
Ja. Der DF ist für minimal 3,2V spezifiziert. Der USB Treiber für 3,3V und der RFID Reader für 3V. der ATMEL darf sogar unter 3V. Wobei mit fallender Spannung die Taktfrequenz reduziert werden müsste (siehe Initialpost). Praktisch läuft er für das was wir treiben auch mit 16Mhz klaglos. Mit 3,9V also kein Problem.
Es macht aber Sinn, dem DF-Player an die Spannungsversorgung noch nen dicken Elko mit > 200µF zu geben, weil der gegen Spannungsschwankungen sensibel reagiert (siehe Initialpost).
Siehe:
Laut Datenblatt 3,2 bis 5V. Je kleiner die Spannung, desto wichtiger, dass sie Stabil ist (ggf. Regler + Elko, kurze Leitungen usw.).
Ich habe in meinem Aufbau den 5V Regler auf dem Nano durch einen 3,3V Regler ersetzt und direkt am DF 200µF zum Abblocken von Spannungsschwankungen. Man könnte auch den VIN frei lassen und einen externen 3,3V Regler als Einspeisung an den 5V hängen,
Aber mit den Trick mit 5V über VIN gewinnt man schon so viel, das sich der Aufwand nicht wirklich lohnt.
Diese vorgehen hat auch den Vorteil, dass du keine Problem mit dem USB Anschluss auf dem Nano bekommst.
Beispiel: Mal angenommen, du stellst alles auf 3,3V über einen externen Spannungsregler um, und irgendeiner der Verbraucher ist nicht 5V Tolerant. Und du steckst den USB Stecker in den Nano, dann hebt dir der USB dein Boardnetz plötzlich auf 5V an, und die betreffende Baugruppe kann Schaden nehmen.
Wenn du aber die Originalbeschaltung so lässt, das alle 3,3V Baugruppen an dem 3,3V Ausgang hängen, und nur VIN unterversorgst, dann richtet die Versorgung mit 5V über den USB keinen Schaden an.
Ja, auf den ersten Blick schon.
Bei dem Mix von Spannungsebenen musst du vorsichtig sein. Das ist beim Tonuino mit dem 5V Nano und dem 3,3V RFID Reader schon grenzwertig, auch wenn die Praxis belegt, dass es tut. Als ich mein System durchgängig auf 3,3V umgestellt habe, war auffällig, wie viel dunkler die LED auf dem RFID Reader wurde, obwohl der auch vorher schon mit 3,3V lief. Scheinbar kamen dazu aber noch relevante Ströme über die Signalleitungen. Ich habs nicht ausprobiert, aber allein das Abziehen der Datenleitungen der SPI Schnittstelle dürfte diesen Effekt schon zeigen. In jedem Fall zeigt, es, dass da was nicht ganz sauber ist.
Wenn du also andere Komponenten auf 5V laufen lässt, darf es keinen Rückkanal geben. Diese Anderen Komponenten dürfen also keine 5V auf den Nano zurück schicken, sonst killt das die Digitaleingänge.
Wenn du also vom Nano mit einem DO auf eine 5V Baugruppe gehst, passiert da nichts, weil der Nano mit den 3,9V der 5V Baugruppe nichts antun kann. Umgekehrt aber schon. Daher dann nur in eine Richtung, und mal mindestens 1k Ohm dazwischen schalten.
Ja, so könnte man es machen. Problem ist dann aber, dass millis z.B. auch in den JC_Buttons fürs Entprellen & Longpress genutzt wird. Und die bekommen von deinem Aufschlag nichts mit. Da muss man dann die Zeitangaben verkürzen.
Ich sehe da zwei Möglichkeiten.
1.) Man rechnet generell für längere Zeiten in Sleep Zyklen, und lässt millis für alles aus dem Spiel, was über eine Loop Durchlauf hinaus geht.
2.) Ich werde vermutlich den millis Programmcode um eine Funktion „AddMillis(time)“ ergänzen. Die rufe ich nach jedem Wakeup auf und die schlägt dann direkt im millis die 128ms auf die Zählervariable. Dann bekommen es auch alle mit. Die von dir beschriebene Ungenauigkeit muss man dann in Kauf nehmen. Aber das sollte für uns auch keine Rolle spielen.
Wichtig ist nur, dass man mit dem Sleep keine laufende Kommunikation der Softserial oder des SPI unterbricht. Sollte aber kein Problem sein, weil der Code aktuell sowieso auf die Kommunikation wartet.