Echt schlafender µC ?

[PICture]

Hallo!

Mir ist wieder eine "verrückte" Idee eingefallen, die ich später ausprobieren möchte, aber vielleicht hat jemand schon damit experimentiert und es sinnlos ist.

Der RC Oszillator vom mein Solarspielzeug steuernden µC wäre nur aus einer Solarzelle versorgt (z.B. aus einem Solartaschenrechner) und sollte nur am Tag bei ausreichender Helligkeit oszillieren und in der Nacht ohne Taktung müsste der µC echt stromlos "schlafen". Das vereinfacht die ganze Software, weil in Schlaf setzen und Aufwecken entfallen würde. Könnte es funktionieren ?

D
D = Schottky Diode
+----+->S-+--------+
| | |+ | S = Solarzelle
.---. .-. - |
| S | | |R --- A | A = Akku
'---' | | |- |
| '-' === .---. µC = Mikrocontroller
=== | GND | |
GND | OSC | |
+---------->| µC|
| Pin | |
--- | |
--- C '---'
| |
=== ===
GND GND

(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

Vielen Dank für jede Antwort im voraus ! ;)

[markusj]

Du wirst den µC definierter in einen Energiesparmodus versetzen können, wenn du es via Software machst, als wenn du ihm den Takt mitten im Betrieb abhackst. Dafür sind sie auch gar nicht ausgelegt, wenn der Takt verrückt spielt, kommt der µC in hoher Wahrscheinlichkeit in undefinierte Zustände.

mfG
Markus

[PICture]

Hallo markusj!

Dass alles stimmt, ist aber bekannt und ich suche immernoch etwas neues, was nicht besser seien muss. :)

Weil es sich um Spielzeug handelt, sind undefinierte Zustände willkomen. Ich weiss nur nicht wie sich ein µC bei extrem langsam wachsender bzw. fallender Versorgungspannungs des RC Generators verhält. Könnte bei fehlerfreiem Program etwas pasieren, weil ich denke, dass es wie eine Unterbrechung der Versorgungsspannung ist ? Das werde ich ausprobieren müssen und falls unrealisierbar verwerfen. Ich suche eben immer das Einfachste sowohl hard- als auch softwaremässig und bin bereit alles nötiges jederzeit ändern.

Die µC's sind dafür sicher nicht ausgelegt, aber ich war noch nie mit etwas Fertiges zufrieden und musste alles, was möglich war, an meine Bedürfnisse anpassen. Meinst du, dass es sich gar nicht lohnt zu probieren ? :confused:

[Besserwessi]

Neuer µC haben für den Fall ungleichmäßiger Versorgung einen Brownout-detektor. So etwas soll verhindern das sich der µC versehentlich umprogrammiert - bei neuen µCs (mit Bootloader Finktion) mit Flash kann das sonst in seltenen Fällen passieren.

Auch mit wenig Spannung am RC takt Eingang wird der µC ggf. immer noch Strom verbrauchen. Wenn man Pech hat ggf. sogar mehr als ein einem normalen Schlafmodus, weil der Eingang einen nicht definierten Pegel hat. Oft ist auch ein externer Quarz sparsamer als der RC Takt.

[PICture]

Hallo Besserwessi!

Deine kompetente Antwort lässt mich glauben, dass es zwar "verrückt", aber nicht sinnlos ist, also besten Dank ! :D

Ich werde das irgendwann ausprobieren und falls nötig Brownout aktivieren. Den EEPROM werde ich nicht benutzen, aber im flash darf sich nix ändern. Sonst bin ich bereit sogar alten OTP µC dafür verwenden, weil er gegen Änderungen im Programmspeicher immun ist.

Selbstverständlich werde ich alles nötiges messen und danach berichten, wollte bloss vorab fragen, weil ich momentan nicht dazu kommen kann.

[Besserwessi]

Bei einigen µC (einige AVRs, 68xx) soll es vorkommen das sich ohne Brownout auch das Flash verändert, wenn auch eher selten. Wie es bei den PIC... aussieht weiß ich nicht. Für die Entwicklung kann man Brownout ja aktivieren. So viel Strom braucht der auch nicht.

Rein vom schlechten Takt würde ich eher keine Fehler im Speicher erwarten, nur halt ein hängen beim Anlaufen und ggf. mehr Stromverbrauch als nötig.

[PICture]

Momentan kann ich noch nix konkretes sagen, werde aber sicher später die "verrückte" Idee genau testen. Ich möchte eben, dass mein Artanel (Kunsttier) bei wechselnder Beleuchtung der Solarzelle nicht permanent stehen bleibt. Zuerst muss er sich aber bewegen und so weit ist es noch nicht. ;)

[markusj]

Rein vom schlechten Takt würde ich eher keine Fehler im Speicher erwarten, nur halt ein hängen beim Anlaufen und ggf. mehr Stromverbrauch als nötig.
Im Worst-Case bleibt er stehen und springt nicht mehr an oder macht RAM und Register ungültig. µCs sind ja relativ robust, aber mit dem Takt sollte man echt nicht spielen, außer man will in Teufels Küche kommen. Und der Brownout-Detector (der übrigens den Ruhestrombedarf immens erhöht, bei den ganz neuen AVRs hat sich das wohl etwas gebessert) schützt nicht vor wildgewordenen Taktquellen!

mfG
Markus

[Thomas E.]

Ich würde theoretisch sagen, der läuft nicht wieder an. Denn es gibt nicht um sonst die Einstellungen zum "wieviele-takte-warten-bis-anlaufen" und der Startup-Time.

ABER:
Meine Clock-Temp, auf einer Streifenrasterplatine zusammengelötet und mit relativ langer Leitungsführung zwischen Quarz und µC bekam in der Entwicklungsphase einen aufsteckbaren Quarz. Alleine die Entfernung zwischen Quarzanschluss und Kondensatoren betrug zwei Zentimeter. Mehr als einmal steckte ich den Quarz im laufende Betrieb ab und wieder ein und siehe da; das Programm blieb einfach stehen und lief an der exakt selben Stelle wieder problemlos weiter! Es erfolgten auch nach einiger Zeit keine Fehler oder ähnliches. Ich war sehr erstaunt über dieses Verhalten.

Also: Lieber PICture, probiere es einfach aus! Das Datenblatt sagt definitiv nein, aber es hat auch zum "Steck-Quarz" nein gesagt. Ich würde wetten, es funktioniert!

Viel Erfolg dabei und halte uns bitte auf dem Laufenden! :)
*zuversichtlichbin*

[PICture]

Hallo Thomas E. !

Herzlichen Dank für deinen Erfahrungsbericht, der für mich wichtiger ist, als jede wissenschaftliche Diskussion ! :D

Ich habe immer mehr einem Experiment, als dem Wissen auf Papier getraut. Sonst könnte ich wahrscheinlich nie auf "verrückte" Ideen kommen, die meistens sich in der Praxis gut bewährt haben und Theoretiker ins Staunen versetzt haben.

Ich bin gewöhnt das machen, was ich will (zumindest in der Elektronik) und werde es sicher später weitermachen und berichten. :)

[Thomas E.]

Herzlichen Dank für deinen Erfahrungsbericht, der für mich wichtiger ist, als jede wissenschaftliche Diskussion ! :D

Gerne. Ich bin schon gespannt auf deine Resultate. :)

[PICture]

Mir ist gerade eingefallen, dass wenn mein Controller für Getriebestepper mit RC Oszillator fertig programmiert wird, schliesse ich die R und C an Solarzelle, den Motor an Akku, lege das Ganze am Boden in meinem Zimmer und werde genug Zeit haben um es zu beobachten bis mein Fahrgestell fertig wird.

Bei negativem Ergebnis werde ich die Idee modifizieren und noch andere Hardwarelösungen testen, z.B. Aus- und Einschalten der Versorgungsspannung des µC's per Komparator mit Hysterese. Erst im schlimmsten Fall werde ich die softwaremässige Standartlösung mit "sleep" & Co im Artanel verwenden müssen. :cheesy:

[oberallgeier]

... die Idee modifizieren und noch andere Hardwarelösungen testen ...Ok ok, es war/ist boshaft von mir, dass ich mich nicht melde, aber ich warte seit Tagen, dass euch die NAHEliegende Lösung auffällt. Denn bei zwei sooo nahe beisammenliegenden Threads von den gleichen Leuten . . . oder habe ich ein Brett vorm Kopf?

Thomas hatte ja bereits berichtet, (https://www.roboternetz.de/community/threads/58961-Wie-macht-man-eine-Battery-low-LED?p=558368&viewfull=1#post558368) dass er die Low-Batt-LED-Schaltung auf 170 µA Ruhestrom gebracht hatte, also wenig genug, um bei einer Solarversorgung nicht zuuu unangenehm aufzufallen. Nun würde ich doch einfach (?) die LED -- nein, natürlich nicht die, nur die Spannung -- an den Resetknopf des Controllers leiten - besser noch an einen Interrupteingang. Beim /RES fürchte ich Flattern der Schaltung (wenn mal die Sonne kurz weg ist). Bei einer ISR könnte man den Controller in einen Schlafmodus schicken, aus dem er zeitweise aufwacht (wenn er nicht wegen Energiemangel schlafen bleibt) und nachsieht, ob genug Spannung/Strom da ist . . . .

Vorteil? Kein eher unkontrollierter Absturz durch Strommangel, sondern ein kontrolliertes Einschlafen durch "sleep" - aus dem es erst bei genug Energie wieder ein Aufwachen gibt.

Oder läuft das so nicht?

[PICture]

Hallo oberallgeier!

Das läuft sicher so, ich suche aber immer einfachere Lösung, die ich nach positivem Testergebnis anwende und nach negativen verwerfe. ;)

[oberallgeier]

... µC bei extrem langsam wachsender bzw. fallender Versorgungspannungs des RC Generators ...Ich habe mal die neueren Doc´s bei Atmel überflogen. Dort gibts Controller (z.B. Familie ATmega164A/PA/324A/PA/644A/PA/1284/P - klick für Datenblatt-Beispiel) (http://www.atmel.com/Images/doc8271.pdf) - bei denen in der PicoPower-Variante, das sind die mit dem Anhang "P", extrem wenig Energie verbraucht wird - auch wenn im Brownout-Fall der Brownout-Detektor in seinem spezielllen "sleep"-Modus Strom verbraucht. Zitat: Power-down Mode: 0.1μA. Dort dürfte wohl ziemlich sicher der entsprechende Reset im Power-low-Fall ohne Datenverlust oder Gesamtreset ablaufen. Und - 0,1 µA könnte ´n klitzekleiner Akku doch ne ganze Weile halten *ggg*.

ZUSÄTZLICH kann bei PicoPower-Variante die Brownout-Überwachung abgeschaltet werden. Dann brauchts noch weniger Strom. Allerdings sollte in beiden Fällen eine ausreichend lange Startup-Zeit gewählt werden, damit der Controller und die Peripherie beim Aufwachen stabil zu laufen beginnen, wenn der Controller seine ersten Takte akzeptiert. Ausführliches steht auf eher vielen Seiten in der Dokumentation, das würde den Beitrag sprengen, das alles zu zitieren.

[PICture]

Hallo oberallgeier!

Vielen Dank für deine für andere Forummitglieder nutzliche Infos, weil ich immer sowohl hard- als auch softwaremässig einfachste für mich Kompromislösung suche und optimale ausprobierte davon anwende.

Es sieht aber so aus, dass ich die Lösung mit "sleep" & Co verwenden muss, weil zufällig gemessener Stromverbrach von einem PIC mit daran hängender Hardware und abgetrenntem Oszillator doppelt so hoch war, als mit laufendem (über 100-fach grösser als nach "sleep" Befehl). :confused: