Forum: Mikrocontroller und Digitale Elektronik AVR Mega168p bei Unterspannung in "Parkposition" fahren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jürgen S. (avus)


Lesenswert?

Moin Sachverständige,

vor 3 Tagen habe ich mich entschlossen, meine fleißig vor sich 
hingackernden ATMega168p-Nodes ein bißchen zu ändern. Einfach aus 
Neugier wollte ich mal sehen, ob an den Gerüchten, daß der Timer2 mit 
Uhrenquarz im Asynchronbetrieb und PowerSave tatsächlich weniger braucht 
als mit Watchdog und PowerDown, etwas dran ist.
Heureka, es ist! Im Standby (also wenn die Nodes nicht senden) werden 
jetzt 25µA gebraucht. Mit dem Watchdog waren es 100µA. Es hängt noch 
permanent ein AM312 und ein DS18B20 dran - also das ist nicht schlecht 
und ich bin rundum glücklich. Vor allem auch wegen der präziseren 
Taktung und somit verlässlichen Timeslots, so kann die CSMA-Geschichte 
beim Senden auch weniger penibel ausfallen.


Nun habe ich den PowerDown-Sleepmode, der ja nun 'frei' ist, nochmal 
hinsichtlich Unterspannung angedacht. Und zwar will ich den 
Brownout-Detektor nicht unbedingt benutzen (klar, man könnte ihn vor dem 
Sleep disablen und nach dem Aufwachen enablen, aber mir schwebt etwas 
anderes vor). Die Nodes messen in der Applikation sowieso standardmässig 
ihre eigene Betriebsspannung über das Bandgap und senden sie an einen 
Server, also habe ich die Volts bereits permanent als Zahl zur Verfügung 
(ich weiß dadurch auch, daß sie tatsächlich bei 1.8V schlappmachen, wie 
es sogar im Datenblatt der Picopower-AVRs steht g).
Zusätzlich zum Timer2 benutze ich für das Aufwachen noch den PCINT, also 
wahlweise könnte die Node durch Timer2 oder ein externes Ereignis zum 
Aufwachen kommen. Das soll verhindert werden.

Wenn nun also eine Node ca. 2 Volt erreicht hat, möchte ich sie 
abschalten und unaufweckbar machen. Dazu würde ich den PCINT (und 
INT0/1) löschen, ein doppelt bombensicheres cli() machen und dann in den 
PowerDown-Mode gehen. Damit wäre Timer2 auch gekillt.

So sollte der AVR eigentlich bis zum Sankt-Nimmerleinstag oder bis die 
Betriebsspannung (z.B. bei Batteriewechsel) unterbrochen wird, unweckbar 
pennen und kann kein Unheil mit EEprom-Corruption oder dergleichen 
anrichten. Oder?


Und das ist eigentlich auch schon die Frage: Ist das gut so oder spricht 
vielleicht doch eher etwas dafür, doch den internen Brownout für das 
Vorhaben zu verwenden?

von Einer K. (Gast)


Lesenswert?

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?

von Jürgen S. (avus)


Lesenswert?

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.

von Karl K. (karl2go)


Lesenswert?

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

Das ist optimistisch. Wenn sich nach einem Spannungseinbruch die 
Batterie erholt (Frostnacht, dann Sonne scheint drauf) kann der AVR mit 
irgendwelchen Registern in irgendeinem Zustand wieder loslaufen.

Ich würde gerade bei solchen fragwürdigen Spannungsquellen mit langsam 
wandernden Spannungen nicht auf den per Fuses gesetzten BOD verzichten.

von Jürgen S. (avus)


Lesenswert?

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).

von Jürgen S. (avus)


Lesenswert?

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!

von Manfred (Gast)


Lesenswert?

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

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

von Jürgen S. (avus)


Lesenswert?

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 ;)

von Karl K. (karl2go)


Lesenswert?

Manfred schrieb:
> Ist das jetzt ein theoretisches Denkmodell oder ist die Batterie
> wiederaufladbar?

1,8V Unterspannung könnten zwei NiMH Akkus sein, und es ist nicht nett, 
wenn das Gerät die weiter runternuckelt. Ich hatte mal einen MP3-Player, 
der hat permanent AAA-Akkus gefressen, wenn man sie ihm nicht 
weggenommen hat.

Jürgen S. schrieb:
> Interrupts gesperrt, Timer, CPU-Takt auch - wie sollte der
> da rauskommen?

Nur durch einen "External Reset", wenn der BOD deaktiviert ist. 
Allerdings heisst das nicht, Spannung weg und Spannung wieder dran, 
sondern Spannung sinkt unter die Reset Schwelle und Spannung steigt 
wieder über die Reset Schwelle. Dann versucht der µC mit den per Fuses 
gesetzten Einstellungen zu starten, und da wird ja wohl irgend ein Takt 
vorgesehen sein, sonst würde er gar nicht loslaufen.

Ohne BOD und mit beliebig langsam steigender Spannung kann der µC dann 
ungewollt reagieren.

Aber: Atmel schreibt in Kapitel 10.2 BOD Disable, dass bei gesetztem BOD 
und disable durch das Programm der BOD bei einem Wake-Up wieder aktiv 
wird und die Fortsetzung des Programms dann verzögert wird bis der BOD 
sicher arbeitet.

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.

Vor Eeprom-Corruption hätte ich jetzt weniger Bedenken, das passiert ja 
nur, wenn der Eeprom in dem Moment geschrieben wird (ist ja kein 
AT90S1200 mehr). Aber zum Beispiel zyklischer Neustart mit Runternuckeln 
der Akkus ist ohne BOD schon wahrscheinlicher.

von MWS (Gast)


Lesenswert?

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.

von Jürgen S. (avus)


Lesenswert?

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.

von Andre (Gast)


Lesenswert?

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.

von Reinhard R. (reirawb)


Lesenswert?

Hallo,

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.

Unterspannung erfassen kannst du ja auch mittels internerm ADU. 
Betriebsspannung als Referenz und interne Referenzspannung als Messwert. 
Das ergibt dann einen Reziprokwert, d.h. je niedriger die 
Betriebsspannung um so höher der ADC-Wert. Also bei Überschreiten eines 
Triggerwertes CPU pennen legen. Ist schon öfter hier im Forum 
beschrieben worden.

Nur meine 2 Cent

Reinhard

von Reinhard R. (reirawb)


Lesenswert?

OK, habe gerade nochmal dein Ausgangsposting gelesen, das mit dem Messen 
der Betriebsspannung machst du ja schon.

von Jürgen S. (avus)


Lesenswert?

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

von Jürgen S. (avus)


Lesenswert?

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)

von Karl K. (karl2go)


Lesenswert?

Jürgen S. schrieb:
> Damit nimmst Du aber auch wieder etwas Hoffnung, daß dieses Node-Ding
> mit Brownout unter allen Umständen stabil läuft. Das ist unfair

Nene, das ist wohl anders gemeint: Mit einem unkontrollierten Brown-Out, 
sprich Betriebsspannung unterhalb des zugelassenen Bereiches, kann der 
Controller Ram teilweise korrumpieren oder Befehle falsch ausführen. 
Letztlich sind das ja Gatter, die geschaltet werden, und wenn da die 
Spannung im nicht definierten Bereich liegt schaltet das Gatter eben 
nicht so wie vorgesehen.

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.

von Karl K. (karl2go)


Lesenswert?

Jürgen S. schrieb:
> Ich bin da eigentlich eher
> respektlos, aber frischgeladene LiIons liefern bis zu 4.1V

Für LiIons ist der MAX884 Dein Freund. Mit Unterspannungsabschaltung, 
11µA Eigenverbrauch und im handlichen SO-08 Gehäuse.

Deutlich billiger ist der MCP1703, aber der hat keine 
Unterspannungserkennung, der nuckelt Dir gnadenlos den Akku leer.

Mit sowas wie den gern verbauten xx1117 brauchst Du nicht anfangen, die 
haben zu viel Eigenverbrauch.

Aber sorry, mit einer Diode die Spannung runtersetzen? Das haben wir 
früher so gemacht, aber da hatten wir och nüscht, nachm Kriech.

von c-hater (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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.

von Karl K. (karl2go)


Lesenswert?

Bernd schrieb:
> WIMRE aktiviert der BOD die interne Bandgap-Referenz und die zieht lt.
> Datenblatt typischerweise 10 µA.

Deswegen gibt es ja die Möglichkleit, den BOD bei einem PowerDown so zu 
disabeln, dass er bei einem Wakeup wieder enabled wird.

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.

Das muss man sowieso, denn diese undefinierten Zustände gibt es auch bei 
einem Reset, bei einem unprogrammierten Chip, beim Programmieren...

Eingänge tendieren dazu, nach Vcc zu ziehen, deswegen ist es gut bei 
angehängten LL-Mosfets oder Enable-Leitungen einen Pull-Down im 
100k-Bereich vorzusehen. Bei I2C dagegen hat man eh die externen 
Pull-Ups, und ohne Daten zieht der Bus nix.

von Jürgen S. (avus)


Lesenswert?

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.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.