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?
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.
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.
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 ;)
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.
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.
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
OK, habe gerade nochmal dein Ausgangsposting gelesen, das mit dem Messen der Betriebsspannung machst du ja schon.
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)
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.
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.