Wir haben ein MC-Projekt mit Wemos Mini D1 (ESP8266), das über ein gepuffertes Solarmodul versorgt wird: Solarmodul -> DC-Converter -> 5V-Goldcap -> Wemos. Das Problem: Wenn (zB. wegen Dunkelheit) das Goldcap leer ist und am nächsten Tag erst nach und nach wieder Spannungswerte erreicht, bei denen der Wemos funktioniert, "verschluckt" sich dieser aufgrund des langsamen Spannungs-Anstieges. Mache ich in dieser Situation jedoch einen Reset, funzt er einwandfrei. Die Frage ist nun: Wie bekomme ich es mit minimalem Aufwand hin, dass die Betriebsspannung (bei einstellbarer Höhe) hinreichend "abrupt" bereigestellt wird?
Frank E. schrieb: > Wir haben ein MC-Projekt mit Wemos Mini D1 (ESP8266), das über ein > gepuffertes Solarmodul versorgt wird: Solarmodul -> DC-Converter -> > 5V-Goldcap -> Wemos. > > Das Problem: Wenn (zB. wegen Dunkelheit) das Goldcap leer ist und am > nächsten Tag erst nach und nach wieder Spannungswerte erreicht, bei > denen der Wemos funktioniert, "verschluckt" sich dieser aufgrund des > langsamen Spannungs-Anstieges. Mache ich in dieser Situation jedoch > einen Reset, funzt er einwandfrei. > > Die Frage ist nun: Wie bekomme ich es mit minimalem Aufwand hin, dass > die Betriebsspannung (bei einstellbarer Höhe) hinreichend "abrupt" > bereigestellt wird? Einen Reset-Controller verwenden. TL7705, MAX698, MAX699
... einen RC sollte man IMMER drin haben. ... und hier auch eine Pufferbatterie und einen guten StepDownConverter dessen Ausgang erst anschaltet, wenn die Spnnung deutlich oberhalb des Grenzwertes ist.
B. schrieb: > einen RC sollte man IMMER drin haben. Immer? Auch bei µC mit per default eingeschaltetem Brownout Detektor und sowieso schon eingebautem Reset Controller?
Hallo, man könnte auch eine eFuse verwenden. Bsp. von TI den TPS259620. Gibt es in verschiedenen Konfigurationsvarianten. Kann man Unter- und Überspannungslimits einstellen inkl. Slewrate vom Ausgang. Als Bonus gibts noch eine Überstromsicherung mit Auto-Reset oder manuellen Reset.
Wf88 schrieb: > TL7705 Gibt es den noch? Mit dem hatten wir vor ca. 30 Jahren mal Ärger, weil der Ausgang unterhalb seiner minimalen Betriebsspannung einen undefinierten Zustand annimmt. Es gab kaputte Daten, weil die Entwicklerin das nicht wusste und zog eine Änderung der Leiterplatte nach sich, war ein Seriengerät. Dazu muß man im Datenblatt suchen, steht natürlich nicht präsent im Kopftext. Siehe am Ende "Figure 9. Eliminating Undefined States Using a pnp Transistor"
Manfred P. schrieb: > Gibt es den noch? > TI z.B. verkauft den noch und für den TO würden ja auch Restbestände reichen - er braucht 1 Teil + eventuell 2 zum Basteln. > Mit dem hatten wir vor ca. 30 Jahren mal Ärger, weil der Ausgang > unterhalb seiner minimalen Betriebsspannung einen undefinierten Zustand > annimmt. Es gab kaputte Daten, weil die Entwicklerin das nicht wusste > und zog eine Änderung der Leiterplatte nach sich, war ein Seriengerät. > > Dazu muß man im Datenblatt suchen, steht natürlich nicht präsent im > Kopftext. Siehe am Ende "Figure 9. Eliminating Undefined States Using a > pnp Transistor" Oh mann, ja sowas ist richtig ärgerlich. Ich bin darüber auch schon gestolpert, als ich das Teil für eine Unterspannungsabschaltung benutzt habe.
Norbert schrieb: > Immer? Auch bei µC mit per default eingeschaltetem Brownout Detektor und > sowieso schon eingebautem Reset Controller? Bei einigen MCs ist das Power-On leider nicht zu ende gedacht. Z.B. läuft im Reset schon der Quarzoszillator an und verbraucht einige mA Strom. Erst sobald die CPU läuft, kann man einen Sleepmode einschalten, um auf <1µA zu kommen.
Frank E. schrieb: > Solarmodul -> DC-Converter -> > 5V-Goldcap -> Wemos. Normale Goldcaps sind aber nicht geeignet, da sie einen recht hohen Innenwiderstand haben (etwa 100Ω). Ein ESP8266 will aber bis zu 300mA sehen. Welchen Kondensator willst Du verwenden?
Peter D. schrieb: > Frank E. schrieb: >> Solarmodul -> DC-Converter -> >> 5V-Goldcap -> Wemos. > > Normale Goldcaps sind aber nicht geeignet, da sie einen recht hohen > Innenwiderstand haben (etwa 100Ω). Ein ESP8266 will aber bis zu 300mA > sehen. > Welchen Kondensator willst Du verwenden? Das ist evtl. Argument. Bei den Goldcaps hab ich einfach in die Grabbelkiste gegriffen, da liegen noch einige 2..3 Jahre alte von Mitsubishi (?) mit 5V und 2F, etwa so groß wie 5 20ct-Münzen übereinander. Wenn der voll auf 5V aufgeladen ist, reicht es absolut aus, dass der Wemos D1 Mini (ganz sicher nicht für sowas otimiert), aufwacht, WLAN verbindet, die Werte eines BMP280 einliest, in eine MySQL einträgt und sich wieder schlafen legt. Der Innenwiderstand des Goldcap hat dabei bisher keine Rolle gespielt, das läuft wirklich zuverlässig. Nur eben, wenn sich das Ganze nachts entlädt (oder ich das simuliere), kommt das Ding nicht wieder auf die Beine. Trenne ich das Goldcap kurz vom Wemos, gehts wieder ...
Frank E. schrieb: > Trenne ich das Goldcap kurz vom Wemos, gehts wieder ... Das ist aber nicht das selbe wie ein Reset am Reset-Pin. Dazu eine kleine Anekdote: ich hatte bei einem AVR schon den Fall, dass wegen mit einer langsam (und evtl. nicht ganz stetig) in 3s von 0..5V ansteigenden Versorgung der RC-Oszillator nicht zuverlässig angelaufen ist. Da hat dann auch kein Reset per Reset-Pin mehr geholfen und es musste eine Trickschaltung her. > Trenne ich das Goldcap kurz vom Wemos, gehts wieder ... Im Fall hier würde ich deshalb den GoldCap aufladen lassen und bei ausreichend hoher Spannung mit einem ICL7665 über einen P-Mosfet die Versorgung einschalten. Denn so ist bei Unterspannung der Mofset (und der µC) sicher aus. Und wenn er einschaltet, dann reicht die Energie für den µC sicher zum loslaufen.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Dazu eine kleine Anekdote: ich hatte bei einem AVR schon den Fall, dass > wegen mit einer langsam (und evtl. nicht ganz stetig) in 3s von 0..5V > ansteigenden Versorgung der RC-Oszillator nicht zuverlässig angelaufen > ist. Da hat dann auch kein Reset per Reset-Pin mehr geholfen Das kenne ich von den ersten AT90S1200 und dem ATtiny22. Da wurden bei langsamen Anstieg der VCC die Fusebits nicht korrekt eingelesen und statt des internen RC auf einen externen Quarz gewartet. Ein externes Reset konnte nicht helfen, da es die Fusebits nicht neu einliest. Das hatte ich auch probiert (MAX690). Zumindest beim ATtiny22 wurde das nie behoben, sondern der wurde wieder aus dem Programm genommen. Conrad hatte danach noch jahrelang die fehlerhaften ATtiny22 angeboten.
Lothar M. schrieb: > Frank E. schrieb: >> Trenne ich das Goldcap kurz vom Wemos, gehts wieder ... > Im Fall hier würde ich deshalb den GoldCap aufladen lassen und bei > ausreichend hoher Spannung mit einem ICL7665 über einen P-Mosfet die > Versorgung einschalten. Wenn noch ein extra Mosfet rangebammelt werden muss, kann man auch gleich eine erwähnte eFuse dafür verwenden. Die übernimmt alles in Einem. Nur mal so als Tipp.
Es gibt Spannungsregler mit eingebauter Unterspannungsabschaltung, für 3.3V z.B. TPS7B8833QKVURQ1R2. Der schaltet bei 2.6 bis 2.8V ein.
Lothar M. schrieb: > Dazu eine kleine Anekdote: ich hatte bei einem AVR schon den Fall, dass > wegen mit einer langsam (und evtl. nicht ganz stetig) in 3s von 0..5V > ansteigenden Versorgung der RC-Oszillator nicht zuverlässig angelaufen > ist. Da hat dann auch kein Reset per Reset-Pin mehr geholfen und es > musste eine Trickschaltung her. Unabhängig davon machte schon der R6502 Ärger, wenn die Betriebsspannung sehr langsam anstieg. Die ganze Menge an "Voltage-Supervisor-ICs" wurde nicht erfunden, weil die Firmen Langeweile hatten. Lothar M. schrieb: >> Trenne ich das Goldcap kurz vom Wemos, gehts wieder ... > Im Fall hier würde ich deshalb den GoldCap aufladen lassen und bei > ausreichend hoher Spannung mit einem ICL7665 über einen P-Mosfet die > Versorgung einschalten. Es gibt bestimmt billigere Spannungsüberwacher als den ICL7665. Der punktet natürlich damit, dass er ab 1,6 Volt definiert arbeitet und sehr wenig Strom braucht.
Man wird über einen Resetcontroller die Schaltung zuschalten müssen. IC haben hohe oft erhöhte Stromaufnahmen unterhalb der erlaubten Versorgungsspannung. Und komplett undefiniertes Verhalten. Das normalerweise ziemlich egal, weil der Bereich schnell durchfahren wird und der Strom auch nicht groß ist. Hier ist das aber eventuell relevant, weil es das Aufladen des Kondensators verhindern kann, und der Zustand lange andauert. Beim Resetcontroller ist z.B: die Stromaufnahme bei Unterspannung im Datenblatt angegeben. Beispiel für die Spezifikation: https://www.ti.com/lit/ds/symlink/tps3435.pdf?ts=1707504764681&ref_url=https%253A%252F%252Fwww.mouser.com%252F Figure 7-10 Auch beachten, dass der Resetcontroller eine ordentliche Hysterese hat, und das Zuschalten der Schaltung nicht gleich wieder die Versorgung unter die Schwelle reißt. Veit D. schrieb: > Wenn noch ein extra Mosfet rangebammelt werden muss, kann man auch > gleich eine erwähnte eFuse dafür verwenden. Die übernimmt alles in > Einem. Nur mal so als Tipp. Das Problem mit der EFuse ist das oft das gleiche wie bei vielen IC - hohe Stromaufnahme, undefiniertes Verhalten....
Es gibt auch noch die "Voltage Detectors" in TO92. Ich habe aber grade keinen Typen parat im Kopf. Ricoh baut die u.A. Die brauchen nur µA und man direkt mit einem Mosfet ran. In 90er-Jahre Videorekordern hab ich die schon oft gefunden+geschlachtet. Ich kann dieses Wochenende mal nach den Bezeichnungen sehen, jetzt liege ich schon flach... Auch wenn die mittlerweile outdated sein dürften, als Einzelstück zum Basteln für den TO eventuell interessant+beschaffbar.
:
Bearbeitet durch User
Hihi, aus den tiefen des "doc" Ordners kam dieses PDF zum Vorschein. Habe noch ein paar andere in meinen Kisten, da kommt die Bezeichnung aber nicht mehr heute...
ArnoNym schrieb: > Veit D. schrieb: >> Wenn noch ein extra Mosfet rangebammelt werden muss, kann man auch >> gleich eine erwähnte eFuse dafür verwenden. Die übernimmt alles in >> Einem. Nur mal so als Tipp. > > Das Problem mit der EFuse ist das oft das gleiche wie bei vielen IC - > hohe Stromaufnahme, undefiniertes Verhalten.... Ich bezog mich auf meine vorherige Antwort auf eine konkrete eFuse. Beitrag "Re: Wie sprunghafte Bereitstellung der Betriebsspannung für MC realisieren?" Der Ruhestrom dieser eFuse liegt um die 200µA. Man sollte aber beim Reset Controller auch die Gesamtschaltung mit Mosfet zu betrachten. Sonst hinkt der Vergleich. Sollte jedoch alles in der Gesamtbetrachtung des TOs mit Solarmodul absolut keine Rolle. Die paar µA hat man auch noch. Was mich an deiner pauschalen Aussage aber viel mehr interessiert ist, was an dieser eFuse ein unkontrolliertes Verhalten sein soll? Darauf hätte ich gern eine nachvollziehbare Antwort.
Veit D. schrieb: > Was mich an deiner pauschalen Aussage aber viel mehr interessiert ist, > was an dieser eFuse ein unkontrolliertes Verhalten sein soll? Darauf > hätte ich gern eine nachvollziehbare Antwort. Undefiniert, nicht unkontrolliert. Was sehr oft vorkommt, ist unerwartet hohe Stromaufnahme (weit über dem normalen angegebenen Stromverbrauch!) bei Unterspannung. Bei µC kann auch schon mal der Flashinhalt zerschossen werden. Einige Bauteile können sogar zerstört werden, wenn die Unterspannung zu lange dauert. Alles das hatte ich selber schon, auch den Rauch, wenn auch nicht bei E-Fuses. Haltet euch immer vor Augen: Alle Angaben im Datenblatt gelten nur für Randbedingungen, üblicherweise die "recommended operating Conditions". Außerhalb dieser tut das Bauteil irgendwas, und das steht so klipp und klar im Datenblatt. Zu den Randbedingungen gehört eben die Versorgung. Im Grenzfall (maximum operating Conditions ok, recommended nicht - also auch Unterspannung) gelten die Angaben im Datenblatt eben nicht. Die von dir genannte EFUSE hat einen BOR-Schaltkreis, was sehr gut ist, damit ist einigermaßen sichergestellt, dass das Verhalten der E-Fuse bei Unterspannung definiert ist (TI preist das eigens als Feature an - warum wohl!). Das sagt jedoch nichts über die Stromaufnahme bei Unterspannung aus. Die kann weit über den Angaben im Datenblatt liegen. Versuch macht hier klug.
Hallo, das hat mein Interesse geweckt. TPS259620. OVL offen. UVLO habe ich auf ca. 9V konfiguriert und den Strom direkt an Pin 4 gemessen. Zwischen 0,0V und 4,2V Ub sind es 0,0µA. Bis 6,5V geht es langsam hoch bis 10µA, dann kommt ein steiler Anstieg auf 72µA bis 7,3V um danach genauso steil auf 47µA abzufallen und zu bleiben. Erst wenn UVLO überschritten wird fließt dann der Laststrom. Umgekehrt fällt der Strom auf 47µA wenn UVLO unterschritten wird. Weiter runter bei 6,5V erneut der Peak auf 72µA um dann zügig weiter runter auf 0,0µA zu fallen. Es gibt bei überschreiten oder unterschreiten der Ub von 2,7V keine Stromspitzen o.ä.. Ab unter 4,2V praktisch 0,0µA. Auch der Ausgang bleibt abgeschalten. Alles mit Multimeter gemessen und beobachtet. Sollte bei Unterspannung des µC und eingestellter BOD sich der µC nicht selbst abschalten/anhalten. Ich kann nicht nachvollziehen warum sich der Flashinhalt zerstören sollte. Bei Überspannung ja, bei Unterspannung fehlt mir dafür die Logik.
:
Bearbeitet durch User
Veit D. schrieb: > Sollte bei Unterspannung des µC und eingestellter BOD sich der µC nicht > selbst abschalten/anhalten. Ich kann nicht nachvollziehen warum sich der > Flashinhalt zerstören sollte. Bei Überspannung ja, bei Unterspannung > fehlt mir dafür die Logik. Ja, geht mir auch so. Das ist doch auch sonst ein ganz normaler Vorgang: Die Versorgung wird abgeschaltet und je nach Größe der Netzteilkondensatoren sinkt die Versorgungsspannung mehr oder weniger langsam. Wenn allerdings gerade ein Schreibvorgang ins Flash erfolgen sollte und der BOD schlägt zu, ja, da könnten schon mal Daten korrupt werden.
Hallo, genau und deswegen stell ich mir die nächste Frage. Wann beschreibt man beim µC den Flash? Beim programmieren dessen. Hat man während des Programmiervorgang ein Spannungsproblem, hat man generell ein Problem, würde ich sagen. Ansonsten im laufenden Betrieb sollte das alles für den Flash keine Rolle spielen. Wie du schon sagst, die Entladung der Pufferkondensatoren ist ein normaler Vorgang. Und falls jemand auf externen Flash (SD-Karte) anspricht oder den µC internen EEprom, ja da muss man sowieso andere Maßnahmen wie ständige Spannungsüberwachung vorsehen und einprogrammieren.
Veit D. schrieb: > Wann beschreibt man beim µC den Flash? Kommt auf den µC an. Es gibt viele, da kann man auch während des Betriebs Daten im Flash speichern.
:
Bearbeitet durch Moderator
Hallo, okay, dann hätte man die gleiche Aufgabe vor sich die Ub zu überwachen. Beim nichts tun, also wenn nichts zur Laufzeit ins Flash geschrieben wird, kann auch nicht durch Absinken der Ub der Flashinhalt zerstört werden. Das widerspricht jeder Logik. Was man dabei nicht machen kann ist, die Schuld auf das Absinken der Ub schieben, wenn Daten korrupt sind, weil im falschen Moment noch geschrieben wurde, wenn man keine Vorkehrungen getroffen hat. Weil das betrifft alle Schreibvorgänge egal womit. Das ist meine Herangehensweise.
Veit D. schrieb: > dann hätte man die gleiche Aufgabe vor sich die Ub zu überwachen. > Beim nichts tun, also wenn nichts zur Laufzeit ins Flash geschrieben > wird, kann auch nicht durch Absinken der Ub der Flashinhalt zerstört > werden. Das widerspricht jeder Logik. Selbst wenn man Ub nicht überwacht und genau im passenden Moment der Strom ausfällt, sollte nur das eine Byte/Wort falsch geschrieben werden. Na gut, beim Programmspeicher mag es auch eine ganze Page betreffen. Aber das wären trotzdem "nur" Daten. Bei "Flashinhalt zerstört" denke ich, dass das Programm anschließend nicht mehr läuft. Ohne BOR ist theoretisch alles möglich, aber wenn es mit BOR passiert, müsste die Flash-Logik extrem primitiv sein und keinen Reset-Eingang haben. Mal angenommen, der gesamte Schreibvorgang muss per Software gesteuert werden, inkl. Timing. Also Ladungspumpe einschalten, warten, Daten und Adresse laden, warten, Write Enable setzen, Stromausfall. Selbst dann betrifft das doch maximal eine Page? Dass einzelne Adressbits umkippen während die Hochspannung noch hoch genug ist, kann doch auch nicht sein. Stromausfall bevor das Write Enable gesetzt wird, das Programm fängt an zu spinnen und stattdessen wird ein Erase Bit gesetzt? Faszinierend.
Veit D. schrieb: > Und falls jemand auf externen Flash (SD-Karte) anspricht oder den µC > internen EEprom, ja da muss man sowieso andere Maßnahmen wie ständige > Spannungsüberwachung vorsehen und einprogrammieren. Genau, und am besten schon vor dem Netzteilkondensator, so dass man es früh erkennt. Und wenn der richtig dimensioniert ist, dann reicht seine Ladung aus, um den Vorgang abzuschließen oder zumindest sauber vorzeitig zu beenden.
Veit D. schrieb: > Ich kann nicht nachvollziehen warum sich der > Flashinhalt zerstören sollte. Bei Überspannung ja, bei Unterspannung > fehlt mir dafür die Logik. Veit D. schrieb: > wenn nichts zur Laufzeit ins Flash geschrieben > wird, kann auch nicht durch Absinken der Ub der Flashinhalt zerstört > werden Ich hatte dazu mal nachgeforscht, nachdem es mir mit einem fertig gekauften Board wiederholt passierte. Dazu fand ich diese Erklärung: Beim Lesen aus Flash Zellen geht deren Inhalt zum Teil verloren, daher müssen sie dabei aufgefrischt werden. Das wiederum erfordert eine Stabile Versorgungsspannung. Ob das so stimmt, weiß ich nicht. In meinem Fall war die das USB Kabel zum Netzteil zu dünn, was kurz nach dem Start ein Absacken der Spannung bewirkte. Auf dem Oszilloskop war es deutlich zu sehen. Ein BOD hätte geholfen, ich wollte aber die eigentliche Problemursache beheben. Mit einem dickeren Kabel und einen größeren Abblock-Kondensator war mein Problem für immer gelöst.
Wie wäre es mit sowas? https://www.amazon.de/USBC-Solar-LiIon-Charger-Boost/dp/B0CLT783V7 Solarfähig, nutzt eine LiIon Zelle zur Pufferung und der Ausgang ist immer an mit 3.3 oder 5V. Sofern dein WEMOS nicht permanent 200mA zieht sondern auch mal schläft sollte man damit auch gut über die Nacht kommen und er wäre allzeit bereit. Abgriffe für die Zellspannung sind auch drauf, dann kann er sich bei dir melden wenn die Akku-Spannung schwach wird. Alternativ der angesprochene Reset Baustein.
Steve van de Grens schrieb: > Dazu fand ich diese Erklärung: > Beim Lesen aus Flash Zellen geht deren Inhalt zum Teil verloren Wo hast du das gefunden? Auf welche Flash-Art bezieht es sich? Üblicherweise ist es so: beim Löschen irgendeines Blocks bzw. einer Page werden die räumlich benachbarten "Randzellen" der räumlich benachbarten Pages/Blocks ein wenig "mitgelöscht". Und ja: langfristig verlieren die Flashzellen ihre Ladung. Umso schneller, je öfter sie zuvor schon gelöscht und beschrieben worden sind und dadurch abgenutzt wurden. Bei Speicherkarten und USB-Sticks schaut deshalb der Controller gleich nach dem Powerup (und laufend im Betrieb) nach seinen Referenzzellen und bestimmt anhand deren Zustand, welche Bereiche "aufgefrischt", sprich umkopiert werden müssen.
Lothar M. schrieb: > Wo hast du das gefunden? Daran kann ich mich nicht erinnern. Es war irgendwo im Internet.
Nicht nur irgendwo im Internet, auch bei berühmten Instituen, z.B. (Vorsicht, 12 Seiten Kleingedrucktes) https://users.ece.cmu.edu/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf Da geht es aber nur um NAND-Flash. NOR-Flash ist nicht so stark betroffen (suche: nor-flash read disturb). Das ist auch dringend nötig. Programm-Flash auf dem Chip wird doch etwas öfter gelesen, und immer die gleiche Stelle.
Bauform B. schrieb: > Selbst wenn man Ub nicht überwacht und genau im passenden Moment der > Strom ausfällt, sollte nur das eine Byte/Wort falsch geschrieben werden. Niemand weiß, welche Befehle ein Rechenwerk ausführt, wenn die Spannung nicht mehr reicht. Es kann ein Löschvorgang angestoßen werden, der nur teilweise ausgeführt wird. Ein ehemaliger Arbeitgeber hatte so einen Fall - beim Powercycle hat es in extrem seltenen Fällen den Flashinhalt eines µC zerschossen. Blöderweise eben oft auch den Bootloader, und schlimmeres. Wie Bits, die den µC sperren. Der Hersteller schweigt zu allen Details, verweist aber auf die Spezifikation der Spannungsanstiegsgeschwindigkeiten, und dass das unbedingt einzuhalten wäre. Die Lösung den Spannungsregler zu tauschen (gegen einen schnelleren) und eine Entladung in die Versorgung zu bauen, hat funktioniert. Wenn man viele Kunden hat, finden die jeden Fehler, auch solche, die man bei Prototypen oder Basteleien niemals sieht. Fragt euch einfach, warum es Spannungsregler mit Entladung, kontrollierten Spannungsanstiegszeiten und Resetbausteine gibt, wenn das doch alles eh kein Problem sein soll ;-)
Atmel hatte an der AVR-Serie jahrelang rumgebastelt, ehe die einigermaßen stabil liefen. Die glaubten doch allen Ernstes noch 1997, daß ein simples Zeitglied ausreichen würde, ohne jede Spannungsschwelle. Ich war 1998 kurz davor einen AVR einzusetzen, nach dem 10. mal Einschalten streikte er und ich untersuchte es näher. Das Ergebnis war, Projekt einstampfen. IMHO erst ab dem ATmega8 liefen die AVRs brauchbar für den industriellen Einsatz. Ältere Konsumergeräte hatten typisch nur ein einfaches RC-Glied (10µF+8,2k) als Reset und einen EPROM/OTP (VPP = 13V) als Programmspeicher.
ich hatte mit den AT90Sxxxx Typen angefangen und hatte in der Hinsicht keine Probleme. Aber wieso auch wenn man sich drum kümmert stabile Verhältnisse auf der 5V Schiene zu haben und etwas Entstörung, brachte die nichts so leicht aus dem Tritt eine 5cm Funkenstrecke direkt daneben war problemlos möglich nur die Aldi-Digital-Kamera hat es aus einem Meter Abstand gehimmelt.
Thomas schrieb: > ich hatte mit den AT90Sxxxx Typen angefangen und hatte in der Hinsicht > keine Probleme. Das Hauptproblem bei industriellen Anwendungen ist ein absolut zuverlässiges Neustarten nach beliebig langen Spannungseinbrüchen. Da kann nicht jedes Mal ein Techniker in die Pampa fahren und den Hauptschalter betätigen. Und genau das war bei den ersten AVRs problematisch (Start an falscher Adresse, Fuses falsch eingelesen, EEPROM oder Flash geändert). Im AVR-GCC wurde sogar die EEPROM-Adresse 0x0000 nicht vergeben, weil die bevorzugt kaputt ging. Die alten AVRs ohne Brownout sind auch gerne bei Unterspannung schon losgelaufen und haben dann Mumpitz ausgeführt. Das mag natürlich auf dem privaten Bastlertisch keine Rolle spielen.
Frank E. schrieb: > Das Problem: Wenn (zB. wegen Dunkelheit) das Goldcap leer ist und am > nächsten Tag erst nach und nach wieder Spannungswerte erreicht, bei > denen der Wemos funktioniert, "verschluckt" sich dieser aufgrund des > langsamen Spannungs-Anstieges. Vergiss den Goldcap und nimm einen richtigen Akku. LiFePo4 hat gleich die richtige Spannung von etwa 3,3V und liefert auch genug Strom. Das Laden auf 3,4V begrenzen, da hat er schon über 90% Kapazität.
ArnoNym schrieb: > Bauform B. schrieb: >> Selbst wenn man Ub nicht überwacht und genau im passenden Moment der >> Strom ausfällt, sollte nur das eine Byte/Wort falsch geschrieben werden. > > Niemand weiß, welche Befehle ein Rechenwerk ausführt, wenn die Spannung > nicht mehr reicht. Es kann ein Löschvorgang angestoßen werden, der nur > teilweise ausgeführt wird. Es muss doch dafür irgendeine Art Vorkehrung geben dem Controller zu sagen das er jetzt seinen aktuellen Schreibvorgang beenden soll und keinen neuen mehr starten darf. Ansonsten gebe es ja immer und immer wieder völlig unkontrollierte Situationen. Ich kann mir das einfach nicht vorstellen das es keine Schutzmaßnahmen geben soll die man nutzen kann, wenn der Controller das schon selbst nicht können sollte. Er könnte auch selbst die Ub überwachen und hat genügend Pufferkapazität um seinen aktuellen Schreibvorgang sauber beenden zu können. > Ein ehemaliger Arbeitgeber hatte so einen Fall - beim Powercycle hat es > in extrem seltenen Fällen den Flashinhalt eines µC zerschossen. > Blöderweise eben oft auch den Bootloader, und schlimmeres. Wie Bits, die > den µC sperren. Sind das aktuelle Erfahrungen? Welcher Controller? Klingt eher wie aus vergangenen Zeiten. Peter schreibt ja auch das es früher Probleme gab die schon lange behoben sind.
Angehängte Dateien:
-
errata.png
69 KB
Übrigens gibt es auch Chips, bei denen die Stromversorgung nicht zu schnell kommen darf...
Hallo, was es nicht alles gibt. :-)
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.