uC im Dauerbetrieb?

[M@tes]

Gibt es irgendwas zu beachten, wenn man einen uC (in meinem Fall ein AtMega168) im Dauerbetrieb nutzen will?
Wäre z.B. ein Kühlkörper sinnvoll?
Oder wie lang ist die Lebensdauer in Stunden?
Habt ihr da schon ein paar Erfahrungen diesbezüglich?

[UlrichC]

Ich habe einen Mega32 seit mehreren Monat im Dauerbetrieb.
Der Mega selbst ist vermutlich weniger das Problem dabei.
Dann eher die Schaltung und Programmierung.

Kühlen ist nicht wirklich sinnvoll. Da der Mega auch ein beschäftigter Mega mit 16 Mhz im Normalfall nicht warm wird.

Für einen sicheren Dauerbetrieb würde ich den Mega aber abschirmen.
Also in ein Gehäuse setzen das Störstrahlungen usw. dämpft.
Denn solche Megas flippen in der nähe von Handys oder anderen hochfrequenten Strahlungen förmlich aus ;-)

[M@tes]

In der nähe von Handys? Scho?
Bei Trafos auch?

[UlrichC]

In der nähe von Handys? Scho?
Bei Trafos auch?

Einfach mal probieren... das mindert die "?"

Die Impedanz beim Einschalten von Trafos oder Spulen wie in Motoren usw. allgemein. wirken vermutlich ähnlich.
EMP ist kein SF sondern Physik ;-)

[M@tes]

Hehe - Ja werd ich machen. Bisher gabs damit aber noch keine Probleme.
Werds aber im Hinterkopf behalten. Danke
Wie so die Lebenserwartung ist, weisst du aber nicht zufällig oder?

[Ringo]

Hat der Speicher nicht eine bestimme Lese/Schreib "Abnutzung"? War da nicht was mit 100.000 Zyklen oder so?

MfG
Ringo

[oberallgeier]

RTFM:
Seite 1, Zeile 13 und 14 des doc2545:
– Write/Erase cyles: 10,000 Flash/100,000 EEPROM
– Data retention: 20 years at 85°C/100 years at 25°C(1)

[M@tes]

Ja sry,...
Daraus werd ich insofern nicht ganz schlau, ob das für ein festes Programm auch gilt. Es schreib ja im Prinzip nicht?!
Trotzdem danke

[askazo]

Das einzige, worüber sich Atmel in den Datenblättern auslässt, ist
1) Anzahl der Schreib-/Löschzyklen des Flashs: 10.000 (Mega168) gilt für ein laufendes Programm nicht, da es nicht in den Flash schreibt, es sei denn, Du benutzt dauernd einen Bootloader. Höchstens der EEPROM könnte während der Laufzeit beschrieben werden.
2) Data retention failure rate (Fehlerrate der gespeicherten Daten im Bezug zur Betriebsdauer): << 1 ppm nach 100 Jahren bei 25°C bzw. nach 20 Jahren bei 85°C (Mega168)

Das Ding wird Dich also unter normalen Umständen wahrscheinlich überleben, selbst wenn's im Dauerbetrieb ist.

Gruß,
askazo

da war der Oberallergeiler schneller..

[Besserwessi]

Es wäre schlimm wenn die uC nicht im Dauerbetrieb laufen könnten. Gerade für Regelaufgaben wird ein zuverlässiger Dauerbetreib gefordert. Fall durch äußere Störungen mal Probleme Auftreten sollten, gibt es das Watchdog Modul, um ein eventuell hängendes Programm zuverlässig neu zu starten.

Für einen Zuverlässigen Dauerbetrieb sollte den Watchdog und den Browout detektor in betracht ziehen. Gerade im Dauerbetrieb sollte der Controller ohnehin relativ lange in einem Standby Modus sein. Über Kühlung sollte man sich beim Spannungsregler und ggf. Trafo gedanken machen.

[M@tes]

Habs mir etwa denkt, die 10'000 Schreibzyklen haben mich nur einwenig stutzig gemacht.
Watchdog ok, Browout ist mir aber neu. Schau ich mal gleich was das ist.
Danke

[oberallgeier]

Vielleicht lädst Du Dir von Atmel´s Dokumentationsseite (http://www.atmel.com/dyn/products/datasheets.asp?family_id=607#760) das ganze Atmel doc für den 168er (http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf) herunter? Und liest mindestens die erste Seite = Inhaltsverzeichnis. Und schaust mal, welche Dinge Dir wichtig erscheinen oder welche Du noch nicht kennst. Und liest die entsprechenden, egal ob Du das nun willst oder nicht :).

[M@tes]

Hab doch nünt gesagt? Das mit den 10'000 Schreibzyklen ist für einen Anfänger halt nicht vielsagend.. Das hab ich scho gelesen gehabt.
Mitm Browout hab ich ja gesagt das ICH nachgucke..
Du unterstellst mir, die Sachen nicht zu lesen, aber wenn man halt noch nie damit gearbeitet hat, ists halt bez schwierig.

[oberallgeier]

Ach je, ich unterstelle nicht. Den Link hatte ich extra für Dich rausgesucht um Dir zu helfen. Mag sein, dass es ätzend klingt, weil ich Dich zum Lesen dränge.

Viel Erfolg

[M@tes]

Ehrlichgesagt hatte es mich gewundert.
Einerseits hilfst mir, andererseits...
Egal, trotzdem danke.

[oberallgeier]

Das mit den Schreib-/Lesezyklen ist schon etwas missverständlich. Diese Zyklen betreffen (in unserem Fall der Lebensdauerfrage) nur den Flash-Speicher (10 000) und die EEproms. Beide sind eher für statische Daten bestimmt.

Der Flash-Speicher ist ja eigentlich für das (ausführbare) Programm vorgesehen. Er kann bei den Atmel µControllern aber beispielsweise auch vom Bootloader beschrieben werden. Hier im Forum standen schon Berichte, dass jemand mehrmals täglich neu geflasht hätte, und das über Jahre, ohne dass der Controller Fehler gemeldet hätte. Klar - 10 000 ist ja nicht sooo wenig - 10xtäglich über drei Jahre . . . .

Das EEprom ist für eher konstate oder sich selten ändernde Daten im Programm vorgesehen - diese können aber auch im Flash stehen.

Übrig bleibt das SRAM (http://de.wikipedia.org/wiki/Static_Random_Access_Memory#Statisches_RAM_.28SRAM .29) für die Aufnahme der Rechenvariablen - es ist im Wesentlichen frei adressierbar und zugreifbar; siehe Seite 20 im doc. Die Daten im SRAM können sich "ständig" ändern. Das SRAM kann seine Arbeit nur befriedigend erledigen, wenn es "beliebig viele" Schreib-Lese-Zyklen durchsteht. Eine Beschränkung über die Anzahl der Schreib-Lesezugriffe beim SRAM habe ich nirgendwo in der Dokumentation gefunden.

Der watchdog ist im Tutorial im microcontroller.net (http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_Watchdog) gut beschrieben.

Der brown out ist so eine Art abgeschwächter Black Out. Eine recht verständliche Erklärung (http://de.wikipedia.org/wiki/Brownout) ist im Wikipedia. Ansonsten eben S 43 und 48 im mega168-doc.

Watch Dog (wie schon der Name sagt: ein Wachhund) und Brown Out Detection dienen also für Überwachungen und erlauben einen sinnvollen Wiedereinstieg ins Programm, wenn das mal abstürzt. Beide müssen dann aber auch programmiert werden und dem Programm bzw. der Hardware entsprechende, sinnvolle Reaktionen auf den Pannenfall einleiten oder durchführen.

[M@tes]

Wow danke, das nen ich mal eine super Antwort :D Damit kann man was anfangen!
Mehr als ich eigentlich wollte :)

(So nebenbei bemerkt: Hab selbst noch keinen uC, hab nur einmal einen beim Kolleg getestet und hoffe, das die Woche meine endlich kommen.
Drum mögen meine Fragen imo vllt einwenig blöd klingen.)