AVR Mega168p bei Unterspannung in "Parkposition" fahren

Jürgen S. schrieb:
> oder spricht
> vielleicht doch eher etwas dafür, doch den internen Brownout für das
> Vorhaben zu verwenden?
Ja, die unnachahmliche Naivität dieser Lösung!


Übrigens:
Was hilft dir ein Schlaf, wenn du dich anschließend nicht auf RAM oder 
Registerinhalte verlassen kannst?

Naivität, ja das hört sich gut an. Aber die Interruptmasken 
auszuschalten und das cli() sind jetzt auch nicht wesentlich komplexer 
;))

Die Nodes dienen nur als Sender (bzw. jetzt. mit der quarzgenauen 
Zeitbasis kann man auch Wecker/Timer) draus basteln. Insofern schieben 
die einfach nur in festen Zeitintervallen ihre Daten zum Server, der 
speichert die in einer Struktur und auch auf SD-Card.

Die RAM- oder sonstigen Inhalte der Nodes interessieren also nicht, bzw. 
über eine erweiterte Acknowledge-Funktion kann der Server die Nodes 
relevante RAM- oder EEpromseitig wieder auffrischen, sobald sie sich 
wieder angemeldet haben (nach Batteriewechsel).

Beim Brownout würde die Batterie halt noch eher tiefentladen werden bzw. 
es ist einfach so, daß die Node bei Unterspannung nutzlos geworden ist, 
da brauche ich den Brownout nicht wirklich. Und er frißt halt dann doch 
noch etwas mehr Strom in dem ca. 100ms-Intervall, wenn die Node wach 
ist.

Da müßte ich tatsächlich nochmal komplex nachdenken, ob das überhaupt 
möglich ist. Interrupts gesperrt, Timer, CPU-Takt auch - wie sollte der 
da rauskommen? Die Register sind zu dem Zeitpunkt, zu dem er geparkt 
wird, ja noch in Ordnung. Und er hat gar keinen Takt mehr, um den Flash 
durchzusteppen.

Verstehe ich nicht.
Tatsächlich sind auch 2 Nodes draussen, und die Überlegung mit 
Temperatur/spannungsschwankung ist realistisch.

Aber genau deswegen frage ich hier ;)

Naja, ich grüble besser nochmal wegen der undefinierten Register/Takt, 
aber ... hm.

Auf jeden Fall scheint der Brownout schon beliebt zu sein (klar, ich 
habe auch schon EEpom-Corruption gehbat, das ist nicht schön).

Wißt ihr was? Ich bin jetzt mal ganz pragmatisch und glaube euch, daß 
die Register dazu führen können, daß der AVR wieder losrennt.

Es ist sowieso schon ein Kreuz mit dem Denken, der macht nämlich 
manchmal Sachen, die ich ihm nicht programmiert habe. Das ist schon eine 
Schweinerei manchmal.

Die Alternative würde auch bedeuten, sich (wieder) ziemlich tief in die 
Register des AVRs reinwühlen zu müssen, und dabei die verflixten Zufälle 
wie z.B. beim Beschreiben von MCUSR etc. nochmal alle anschauen zu 
müssen. Das ist wohl kaum machbar. Insofern gehe ich einfach davon aus, 
daß es sein kann, daß sich auch die Taktfreigabe von Registern bei 
Spannungsschwankungen verändern kann.

Und programmiere den BOD mit ein. Danke euch!

Jürgen S. schrieb:
> würde die Batterie halt noch eher tiefentladen

Ist das jetzt ein theoretisches Denkmodell oder ist die Batterie 
wiederaufladbar?

Korrekter Einwand, das könnte einem dann wirklich egal sein. Tatsächlich 
sind es LiIonen-Akkus ;)


Erheblichen Hirnschmalz habe ich neulich investieren müssen, weil ich 
eine 1N4148 zur Spannungsreduzierung von 3.7 auf ~ 3.3V eingesetzt habe 
(an der alle 'Verbraucher' dranhängen. Der DS18B20 mißt ca. 650ms und 
zieht dabei ca. 700µA. Wenn er fertig ist, geht er runter auf ~10µA. 
Jedes Mal, wenn also Timer2 (nach 10 Sekunden oder einer Minute, je nach 
Anwendung) die Node aufweckt, wird der DS18B20 gelesen und danach sofort 
wieder neu gestartet, um den Meßwert für den nächsten Aufwachzyklus 
parat zu haben. Der DS läuft also noch lange weiter, während die Node 
längst wieder pennt. Sobald er die Spannungsquelle nicht mehr mit 700µA, 
sondern nur noch mit 10µA belastet, gibt es eine Spannungserhöhung an 
der Diode.
Und die führte dazu, daß der AM312 triggert und 'Bewegung' signalisiert. 
Also jedes Mal, wenn die Node aufwachte, wurde ca. 550ms danach 
'Bewegung' entdeckt ... auweia. Abhilfe schaffte es (nach Versuchen mit 
einem großen Kondensator hinter der Diode), den AM312 nicht hinter die 
Diode, sondern direkt an den Akku zu klemmen. Dessen Innenwiderstand ist 
dann doch erheblich kleiner, den kratzen Strombelastungen im µA-Bereich 
hinsichtlich seiner Klemmenspannung weniger.

Auch deswegen, nach dieser schweißtreibenden Erfahrung, lasse ich mich 
lieber auf die Erfahrungen anderer ein, auch beim BOD. Besser ist das, 
wenn man schon so seine Ahnungen hat ;)

Jürgen S. schrieb:
> So sollte der AVR eigentlich bis zum Sankt-Nimmerleinstag oder bis die
> Betriebsspannung (z.B. bei Batteriewechsel) unterbrochen wird, unweckbar
> pennen

Der Trugschluss liegt darin, dass bei weiter entladender Batterie ein 
bestimmtes Verhalten, nämlich weiteres Verbleiben im Sleep angenommen 
wird. Tatsächlich ist das Verhalten bei zu geringer Versorgungsspannung 
unbestimmt. Gerade dafür gibt's den BOD, dieser hält bei Unterspannung 
den Controller sicher im Reset und verhindert damit, dass der Blödsinn 
anstellt. Etwas das diese Konstruktion nicht kann.

Ah, ich glaube, man kann erkennen, daß ich mich mit dem BOD und 
Einschaltverhalten noch nicht so auseinandergesetzt habe. Da war auch 
ufufs Einwand bezüglich Register schon sachdienlich.

Karl K. schrieb:

> Das wäre also durchaus ein richtiges Vorgehen: BOD per Fuses enable, BOD
> abschalten vor Sleep / PowerDown, BOD wird von allein aktiv bei Wake-Up.
>

So mache ich's. Ist ja nur ein Befehl. Muß nur noch nachschauen, ob BOD 
in den Fuses tatsächlich gesetzt sein muß, oder ob die Software (wie 
beim WDT) das alleine kann. Aber vermutlich weißt Du das schon, daß die 
Fuse gesetzt sein muß. Macht auch Sinn, denn sleep_bod_disable() hat ja 
keinen Parameter für die Schwellenspannung. Da wird wahrscheinlich auf 
die Fuse-Einstellung zurückgegriffen.

MWS schrieb:
> Der Trugschluss liegt darin, dass bei weiter entladender Batterie ein
> bestimmtes Verhalten, nämlich weiteres Verbleiben im Sleep angenommen
> wird. Tatsächlich ist das Verhalten bei zu geringer Versorgungsspannung
> unbestimmt. Gerade dafür gibt's den BOD, dieser hält bei Unterspannung
> den Controller sicher im Reset und verhindert damit, dass der Blödsinn
> anstellt. Etwas das diese Konstruktion nicht kann.

Ja, tatsächlich hatte ich mir den AVR in Parkposition als statisch 
festgeklemmtes Gebilde vorgestellt, der spannungsunabhängig wartet, bis 
der Akku leer ist - oder, wenn er wieder über ein paar 
CMOS-Schaltschwellen wegen Sonnenschein/Wärme kommt, trotzdem in diesem 
gelockten Zustand verharrt. Eben weil er keinen BOD hat, der ihn 
resettet und auch keinen externen Reset bekommt. Aber das ist jetzt 
wackelig, ich glaube zu verstehen, daß er nicht wirklich gelockt ist ;)

Nochmal danke.

Jürgen S. schrieb:
> Auch deswegen, nach dieser schweißtreibenden Erfahrung, lasse ich mich
> lieber auf die Erfahrungen anderer ein,

Und jetzt haben wir beide die Erfahrung gemacht dass Dioden sehr 
schlechte Spannungsregler sind. Für deine Anwendung würde ich 
wahrscheinlich nach einem kleinen LDO mit "power good" Ausgang suchen 
und den mit Reset verschalten.
P.S. das fiese am brown out ist, das auch Register irgend welche Werte 
annehmen können. Im ungünstigsten Fall läuft der Takt wieder an und dein 
AVR rennt mit kaputtem RAM Inhalt irgendwo los.

Andre schrieb:
> Und jetzt haben wir beide die Erfahrung gemacht dass Dioden sehr
> schlechte Spannungsregler sind.
Du also auch ;). Dieser unterschiedliche Strombedarf über mehrere 
Dekaden ist ein Problem, das ich unterschätzt habe.
> Für deine Anwendung würde ich
> wahrscheinlich nach einem kleinen LDO mit "power good" Ausgang suchen
> und den mit Reset verschalten.
Wäre und ist eine saubere Sache. Ich muß mal schauen, wieviel Strom die 
ziehen. Und das war eigentlich auch nicht angedacht, hier professionell 
zu arbeiten. Immerhin kam zuerst die eine Idee, dann die andere, dann 
die Diodenlösung und erste Erfolge, dann weiterer Fortschritt in der 
lowpower-Sparte...dies alles zu vernichten mit einem schnöden, modernen 
LDO-Regler mit powergood-Ausgang, wäre unsportlich g
> P.S. das fiese am brown out ist, das auch Register irgend welche Werte
> annehmen können. Im ungünstigsten Fall läuft der Takt wieder an und dein
> AVR rennt mit kaputtem RAM Inhalt irgendwo los.
Damit nimmst Du aber auch wieder etwas Hoffnung, daß dieses Node-Ding 
mit Brownout unter allen Umständen stabil läuft. Das ist unfair g

Reinhard R. schrieb:
> nur ein paar Gedanken von mir.
> Warum willst du die Spannung überhaupt reduzieren?
> Der ATmega168p und der DS10B20 arbeiten bis 5V und der AM312 ist von
> 2,7V bis 12V spezifiziert (wenn ich das richtig gelesen habe, den AM312
> habe ich noch nicht verwendet).
> Der DS18B20 ist lt. DB erst ab 3V Betriebsspannung spezifiziert, da bist
> du bei 3,7V und Diode in Reihe schon an der Grenze.
Es hängen an manchen Nodes auch I2C-Chips mit 3.3V dran, und die Funke 
selbst (RFM69) verträgt auch nur 3.6V. Ich bin da eigentlich eher 
respektlos, aber frischgeladene LiIons liefern bis zu 4.1V und es kann 
dann passieren, daß man doch den Halbleiter an sich zerstört. Eine 
Fehlersuche dort wäre dann anstrengender als eine Fehlersuche in der 
Spannungsversorgung, das ist es nicht wert.

Du hast mich aber wegen des DS18B20 und seines Spannungsbereiches auf 
eine Idee gebracht. Denn daß die DS standardmäßig bei den Nodes dabei 
sind, ist auch eine Neuerung - so erklärt sich auch, daß ich deren Werte 
noch nicht gecheckt habe, wenn die Messung der Betriebsspannung unter 
1.8V fällt. Ich muß das mal messen, bis wohin die tatsächlich 
runtergehen. Von einem weiß ich, daß er bis 2.8V zuverlässig mißt, aber 
habe das nicht untersucht.
Mit der neuen Idee meine ich aber, daß man den DS auch erst bezüglich 
neuer Messung starten kann, wenn der RFM69 gesendet und den ACK 
empfangen hat. Nur im TX- und RX-Zustand verbraucht der milliamps. 
Danach schaltet er in Sleep und an der Diode liegt demzufolge wieder 
eine höhere Spannung an (~300 -500mV). Durch das Starten des DS nach dem 
Betrieb des RFM käme man also für den DS wieder in einen günstigeren 
Betriebsspannungsbereich. Das ändere ich auch noch ;)

(Nur für den Fall: Das ist kein Geschwafel, ich beobachte die µAs am 
Oszi und kann die einzelnen devices und den jeweiligen Strombedarf fast 
alle zuordnen)

Karl K. schrieb:

> Aber genau dafür sind ja der Brown-Out-Detektor und der Brown-Out-Reset
> eingebaut: Um in diesem Unterspannungsbereich definierte Verhältnisse zu
> schaffen, nämlich den Controller stillzulegen - und das heisst nicht nur
> Programm anhalten, sondern ein Reset mit abgeschalteten Ausgängen,
> abgeschalteter PWM..., und bei steigender Spannung wieder kontrolliert
> anzuschalten, nämlich mit dem Neustart des Programms.

Ganz genau so ist das. Und das ist auch sehr gut für den µC selber.

Es ist allerdings weniger gut für daran angeschlossene Peripherie, 
zumindest für deren Stromverbrauch. Denn alles, was durch Ausgänge des 
µC angesteuert wird, hat dann seinerseits undefinierte Pegel an den 
Eingängen, da die Ausgänge des µC im Reset-Zustand ja eben keine 
Ausgänge mehr sind.

Man muss also für jeden einzelnen Pin des µC, der im Betrieb Ausgang 
ist, überlegen, ob und was zu unternehmen ist, damit auch hier für 
definiertes Verhalten gesorgt ist, wenn der µC in den BOR geht. 
Idealerweise natürlich ein Verhalten, was den Energiebedarf auch der 
Peripherie minimiert.

Am einfachsten ist das, wenn man noch einen freien Pin hat. Dann kann 
man den nutzen, um mittels eines Highside-Switch und Pullup bzw. -down 
im Resetfall einfach die gesamte Peripherie abzuschalten. Ggf. 
vielleicht sogar schon dann, wenn man den µC schlafen schickt und nicht 
erst dann, wenn er in den Reset geht.

Oft genügen aber auch Lösungen, die ohne so einen Switch auskommen. Das 
alles hängt schlicht von der Peripherie ab.

Karl K. schrieb:
> genau dafür sind ja der Brown-Out-Detektor und der Brown-Out-Reset
> eingebaut:
WIMRE aktiviert der BOD die interne Bandgap-Referenz und die zieht lt. 
Datenblatt typischerweise 10 µA.

Karl K. schrieb:
> Aber sorry, mit einer Diode die Spannung runtersetzen? Das haben wir
> früher so gemacht, aber da hatten wir och nüscht, nachm Kriech.
Ja klar, wobei ich den LDO mit powergood für die Nodes schon fast zu 
luxuriös finde (aber eben auch sinnig), denn die Nodes laufen mit der 
Diodenlösung schon eine längere Zeit. Ziemlich zuverlässig (ich hatte 
früher RFM12, da war es wahrscheinlich auf Serverseite kritischer, 
schnell den FiFo zu leeren, es kam schon zu Abstürzen von Nodes oder dem 
Server-RFM12, die sich irgendwann beleidigt verabschiedeten).

Andrerseits ist es albern, zu sparen: Das ist/wird kein kommerzielles 
Ding, und bei 10 oder 20 Nodes kann man wirklich sauberer arbeiten, auch 
wenn es mehr kostet. Trotzdem muß man sich das 'saubere arbeiten' auch 
erst erarbeiten - sprich Datenblätter präziser wälzen oder Probleme, auf 
die man selbst nicht kommt, im Forum ansprechen ;). Danke für den 
konkreten Tip mit dem MAX884, ich schaue mir den an.

Sieht so aus, als ob die Strombilanz dann noch einmal um ~10µA verteuert 
wird, aber das scheint es wert zu sein (sei es nun durch LDO oder BOD).


c-hater schrieb:
> Man muss also für jeden einzelnen Pin des µC, der im Betrieb Ausgang
> ist, überlegen, ob und was zu unternehmen ist, damit auch hier für
> definiertes Verhalten gesorgt ist, wenn der µC in den BOR geht.
> Idealerweise natürlich ein Verhalten, was den Energiebedarf auch der
> Peripherie minimiert.
>
> Am einfachsten ist das, wenn man noch einen freien Pin hat. Dann kann
> man den nutzen, um mittels eines Highside-Switch und Pullup bzw. -down
> im Resetfall einfach die gesamte Peripherie abzuschalten. Ggf.
> vielleicht sogar schon dann, wenn man den µC schlafen schickt und nicht
> erst dann, wenn er in den Reset geht.
>
> Oft genügen aber auch Lösungen, die ohne so einen Switch auskommen. Das
> alles hängt schlicht von der Peripherie ab.
So ist es, für die I2C-Pheripherie habe ich einen Ausgang des AVRs als 
Highside-Switch, und schaue jetzt mal die Chips an, ob sie nicht mit 
einem anständigen Sleep- oder Standby-Befehl nicht genauso gut bedient 
sind. Bei 7 potentiellen Kandidaten muß man halt dann nochmal 7x 
Datenblätter mit dem Aspekt 'Strombedarf' neu wälzen, selbst wenn die 
Treiber für die Daten selbst längst geschrieben und funktionstüchtig 
sind.
Wenn nur einer keinen zauglichen Sleep-Mode hat, bleibt der Switch drin.

Ansonsten ist das mit den schlackernden Pins bzw. der Vermeidung deren 
in allen Betriebszuständen wirklich hirnschmalzlastig, um es richtig zu 
machen, braucht man schon eine gute Vorstellung von allem, was passiert 
oder passieren könnte. Diesbezüglich bin ich schon recht nah dran, muß 
aber auch da nochmal drüber.

Und dann muß ich mir nochmal den neuen CSMA-Teil anschauen. In weiser 
Voraussicht hatte ich einen Timeout vorgesehen, falls der Kanal nicht 
frei wird, aber da passieren noch merkwürdige Nebeneffekte - manche 
Nodes verklemmen sich und man kommt per Funk nicht mehr heran.


Viel Detailarbeit notwendig bei dem Lowpower-Kram pfeif
Aber um auf den Ausgangspunkt zurückzukommen, wäre es vielleicht doch 
nicht schlecht, die MCUs so zu konstruieren, daß einen Parkplatz-Befehl 
gibt ;))

Danke auch für die letzten Abwägungen bzgl. BOD.