Hallo ich habe so eine Frage: Wie lange kann ein µC (mega8) dauerhaft Arbeiten, ohne ab zu stürtzen? Natürlich hängt alles (sehr vieles) von der Software und Stromversorgung ab. In meinem Programm wird immer wieder in der Hauptschleife Debounce ausgeführt. Erst wenn die Taste gedrückt ist, geht das Programm in das Unterprogramm. Nach dem Unterprogramm geht er wieder in die Hauptschleife und Debounced immer wieder einen Pin. Die Taste wird ziemlich selten gedrückt. Im Durchschnitt 6x / Woche. Die restliche Zeit ist der µC wie gesagt nur am Debouncen. Habe irgendwie so ein Gefühl, dass nach 1-2 Monaten, das ganze sich irgendwie, warum auch immer verhacken kann, und dann ist erst mal Schluss. Wie kann man solche Situationen vermeiden, wie kann man einen µC für den absoluten Dauereinsatz vorbereiten? Und wie ist dann die Lebensdauer des µ von der Hardware her? Wie gesagt, die Software wurde schon so angepasst, dass ausser Debounce NICHTS mehr ausgeführt wird. Danke Gruss Alex
Über Lebensdauer kann ich leider nichts sagen. Würd mir aber nicht all zu große Sorgen machen solange nichts kompliziertes drauf läuft. Aber Stichwort Watchdog. <-- Bin mir aber auch nicht sicher ob der Mega8 einen hat.
@ Alex (Gast) >Wie lange kann ein µC (mega8) dauerhaft Arbeiten, ohne ab zu stürtzen? Wenn das Programm OK ist, praktisch endlos. >In meinem Programm wird immer wieder in der Hauptschleife Debounce >ausgeführt. Was die meisten Leute anders machen, mämlich per Timer. Siehe Entprellung. >Die Taste wird ziemlich selten gedrückt. Im Durchschnitt 6x / Woche. >Die restliche Zeit ist der µC wie gesagt nur am Debouncen. Was erst recht sinnlos ist. Das macht man per Sleep Mode. >Habe irgendwie so ein Gefühl, dass nach 1-2 Monaten, das ganze sich >irgendwie, warum auch immer verhacken kann, und dann ist erst mal >Schluss. Programmierfehler. >Wie kann man solche Situationen vermeiden, wie kann man einen µC für den >absoluten Dauereinsatz vorbereiten? Solide programmieren. >Und wie ist dann die Lebensdauer des µ von der Hardware her? Praktisch endlos. Naja, nicht ganz, der Flash wird irgendwann einzelene Bits verlieren. Laut Atmel bei 85°C nach 20 Jahren, bei 25°C nach über 100 Jahren. >Wie gesagt, die Software wurde schon so angepasst, dass ausser Debounce >NICHTS mehr ausgeführt wird. Was Programmierfehler nicht ausschließt ;-) MfG Falk
In so einem Fall würde ich den Watch-Dog aktivieren. Vorher natürlich alle anderen Störungsmöglichkeiten ausschließen.
Im Grunde sollte das "ewig" laufen, wenn es keine Soft- oder Hardware Fehler gibt :-) Wie wird das "debounce" gemacht? Polling oder Interrupt? Am besten wäre es die Taste an einen externen Interrupt zu hängen, den µC schlafen zu schicken und erst bei Tastendruck zu wecken. Um einen Absturz zu erkennen könnntest Du auch den "Watchdog"-Timer benutzen. Das ist ein Timer, der in der Hauptschleife immer gelöscht wird. Bleibt das aus (Timer läuft über) wird ein Hardware-Reset durchgeführt. Welche Programmiersprache nutzt Du? Für C findest Du jede Menge Beispiele in der Code- und Artikel-Sammlung!
Beschreibe mal genauer was dein Programm machen soll. Vom Prinzip her ist es egal ob der Prozessor lange in einer Hauptschleife läuft ---> Do -- loop, oder ne halbe Ewigkeit auf eine Taste wartet und der Rest dann in Millisekunden erledigt.
Hmm, 6 mal pro Woche wird die Taste gedrückt, und nach 4 - 8 Wochen ist Feierabend. Könnte das ein Stackproblem sein? Der Stack wächst durch einen Fehler jedes mal beim Drücken der Taste und ein oder ein paar Byte und nach 20 bis 50 mal läuft er über. Könnte man schnell testen indem der Taster mal öfter gedrückt wird.
Das Ganze soll meinen Schuppen überwachen. Es ist ein Mikroschalter eingebaut, der betätigt wird, wenn man die Tür auf macht. Soll nachts von den Dieben schützen. Wenn der Schalter betätigt wird, geht das Programm ins Unterprogramm, und der Alarm wird per Can-Bus nach Hause übertragen. Das Unterprogramm ist also etwas komplizierter, funktioniert aber tadellos. Ich will also auf keinen Fall, dass sich das Programm abstürzt und ich desswegen wichtigen Alarm verpasse. Kann man sich auf den Watchdog verlassen? Gruss Alex
>Hmm, 6 mal pro Woche wird die Taste gedrückt, und nach 4 - 8 Wochen ist >Feierabend. Nein, ist nicht :) Die Schaltung ist noch nicht in Betrieb. Ich will nur diesen möglichen Feierabend vermeiden. Gruss Alex
Wie wärs, wenn du in der Hauptschleife nur ein while(1); hast und deine kompletten Routinen in Interrupts verfrachtest? Das erscheint mir bei der Anwendung deutlich sinnvoller.
es würde dann so in Bascom aussehen: xxxxxxxxxxxxxx xxxxxxxxxxxxxx Config watchdog = 2048 xxxxxxxxxxxxxx xxxxxxxxxxxxxx do Start watchdog Debounce Pind.0 , 0 , Alarm , Sub reset watchdog loop Alarm: xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx waitms xx xxxxxxxxxxxxxxx ... return richtig? muss ich immer wieder den Watchdog starten, oder kann ich das nur ein mal vor der Hauptschleife machen und dann nur noch resetten? z.b. so: Start watchdog do Debounce Pind.0 , 0 , Alarm , Sub reset watchdog loop Danke Gruss Alex
Alex schrieb: > Kann man sich auf den Watchdog verlassen? Der Watchdog ist ein Stück Silizium, welches sich per Software entsprechend konfigurieren lässt. Wenn die Errata-Sheets des µC's nichts Dementsprechendes hergeben, ist die einzig mögliche Unsicherheit die Konfiguration per SW, d. h. auch hier sitzt das Hauptproblem ca. 50cm vor dem Monitor.
Benutz Assembler und, oder analysiere den generierten Assembler code KOMPLETT. Benutze den Watchdog. Lass zwei AVRs das Programm ausführen in unterschiedlichen Programmiersprachen programmiert und "veroder" den Alarmausgang.
Dann kann er auch gleich zwei unterschiedliche Controller nehmen, also zusätzlich nen PIC oder 8051 dazuschalten ;)
@ uwe (Gast) >Benutz Assembler Man kann ein Problem auch vergrößern. >und, oder analysiere den generierten Assembler code >KOMPLETT. Naja, weder sonderlich lustig noch zielführend. > Benutze den Watchdog. Als Rettungsanker. > Lass zwei AVRs das Programm ausführen in >unterschiedlichen Programmiersprachen programmiert und "veroder" den >Alarmausgang. Für einen Schuppen mit bissel Zeug drin? Das ist nicht Fort Knox. Es wird einer der vielen beliebten Fehler sein, den viele Anfänger machen. Wenn der OP vollständigen Code als Anhang posten würde, könnte man im ggf. helfen. MfG Falk
Alex schrieb: >>Hmm, 6 mal pro Woche wird die Taste gedrückt, und nach 4 - 8 Wochen ist >>Feierabend. > Nein, ist nicht :) > Die Schaltung ist noch nicht in Betrieb. Ich will nur diesen möglichen > Feierabend vermeiden. Hääh, erst redest du davon daß der Fehler alle 4 - 8 Wochen auftritt und jetzt daß er gar nicht auftritt sondern du Angst davor hast daß er auftreten könnte. Von Basic hast du vorher auch nichts gesagt. Das ist mir zu wirr, ich bin raus, von Basic hab ich eh keine Ahnung.
Wieso will er seinen Feierabend vermeiden ??? > "Die Schaltung ist noch nicht in Betrieb. Ich will nur diesen möglichen > Feierabend vermeiden." Komisch
Dann kehr doch das Prinzip um: Der Controller sendet alle 5 Sekunden über den CAN-Bus einen "Alles-OK-Alarm". Sobald dieses Zeichen ausbleibt, dann wird Alarm ausgelöst. So hast du in jedem Störfall eine Meldung und kannst sofort eingreifen. Umgekehrt hingegen kriegst du keinen Alarm, wenn der Einbrecher z.B. den Controller oder das Kabel zerstört. Oder wenn Stromversorgung oder Bus schon tagelang kaputt sind. Oder wenn eben die Software abstürzt. Ganz nebenbei: Ein vorsichtig programmiertes, einfaches C-Programm mit keinen Interrupts bis auf einen einzigen Timerinterrupt, ohne Rekursion, ohne dynamische Speicherallokation und hinreichend getestet, wird deine geringste Fehlerquelle im ganzen System sein. Da sind andere Fehlerwahrscheinlichkeiten um Grössenordnungen grösser, so dass deine Sorge um Softwarefehler im statistischen Rauschen untergehen.
Es ist sehr unwahrscheinlich, dass in deiner Hauptschleife ein Fehler steckt, der vor dem Einbau in den Schuppen nicht auffällt. Dein AVR hat keine Gigabytes an RAM. Wenn da ein Fehler den Stack auffrisst, hängt das Programm nach wenigen Millisekunden. Wenn es Tage funktioniert, dann funktioniert es auch Wochen oder Monate. Solche Fehler wie "hängt sich nach drei Wochen auf" haben andere Ursachen. Zum Beispiel wird ein Code-Pfad, in dem sich der Fehler versteckt, nur unter sehr selten zutreffenden Bedingungen aufgerufen. Oder du liest externe Daten ein und hast bei selten vorkommenden Werten irgendwo einen Überlauf. Da gibt es viele Möglichkeiten, aber das lässt sich alles gut testen. Ursachen für aussteigende AVRs sind eher starke EMV-Probleme oder ein schlechtes Netzteil. Die erste Generation AVRs war da sehr empfindlich, bei späteren hat sich das verbessert. Nimm mal einen uralten, vergammelten Lichtschalter und schalte ein paar Mal Mamas Staubsauger damit ein und aus. In direkter Nähe zur Schaltung. Wenn dein Programm weiterläuft, bist du auf der sicheren Seite :)
>Hääh, erst redest du davon daß der Fehler alle 4 - 8 Wochen auftritt und >jetzt daß er gar nicht auftritt sondern du Angst davor hast daß er >auftreten könnte. das habe ich geschrieben: >Habe irgendwie so ein Gefühl, dass nach 1-2 Monaten, das ganze sich >irgendwie, warum auch immer verhacken
1 | kann |
, und dann ist >erst mal Schluss. Sorry, wenn das nicht klar genug rübergekommen ist. Gruss Alex Also werde ich zum Programm noch den WDT einbauen, und fertig. Gruss Alex
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.