Bootloader Delay

Hallo,

wie lange dauert es eigentlich bis ein Sketch startet, wenn keine Daten kommen?
Der Bootloader wartet ja eine zeitlang auf Daten. Millis() und micros() beginnen erst nach dem Bootloader zu messen oder?

Ich möchte einen Watchdog einsetzen, den Bootloader behalten und verhindern, dass das Bootloader Delay zu lange für den Watchdog dauert.

Vor dem Aufspielen von einem neuen Sketch will ich den Watchdog dann mittels Taster deaktivieren, so dass die Zeit fürs neu programmieren keine Rolle spielt.

Vielen Dank.

Die Verzögerung hängt vom Bootloader ab, aber eigentlich sollte sie nicht wirklich relevant sein. Denn:

Fall 1: Du setzt die Fuses so, dass der Watchdog immer aktiv ist --> das geht nur wenn Du einen ISP hast --> dann lass den Bootloader weg und nimm immer den ISP zum flashen --> das Problem existiert nicht

Fall 2: Du aktivierst den Watchdog in Deinem Programm --> dann ist der WD nach einem Reset nicht mehr aktiv --> der Bootloader darf so lange brauchen wie er will --> das Problem existiert nicht

Fall 3: Du setzt die Fuses so, dass der Watchdog immer aktiv ist und verwendest einen Bootloader --> jetzt hast Du überhaupt erst das Problem --> ich würde empfehlen das einfach nicht zu tun :wink:

Hallo Udo,
DANKE. Ich habe Fall 2.

Ich bin davon ausgegangen, dass ein einmal gesetzter WD nach einem Reset sofort wieder aktiv ist. Schön das es nicht so ist. Danke!

Die eigentliche Frage ist wozu Du einen internen Watchdog einsetzen willst? Eigentlich sollte man ohne internen Watchdog auskommen.

Ich habe gerade eben nochmal nachgeschaut, leider ist die Sache wohl doch etwas vertrackter: http://www.mikrocontroller.net/articles/AVR-Tutorial:_Watchdog. Ich würde sagen: Versuch macht klug, einfach mal ausprobieren. Die Preisfrage ist aber trotzdem wozu Du den WD genau brauchst.

Falls schief geht:

Damit kannst Du blockierte ATmega's zurücksetzen.
Grüße Uwe

Hallo,

Danke für die Antworten.

Ich habe mich etwas gespielt, und mit einem Duemilanove328 einen ProMini168 eingeschaltet und dann gewartet bis dieser einen Ausgang schaltet. Den Ausgang schalten war die 2. Anweisung nach dem pinMode in setup()

Vom Einschalten bis zur Rückmeldung waren es 1460ms.
Wenn der ProMini den Duemilanove geschaltet hat waren es 1457ms.
Gemessen habe ich nur mit der millis() Funktion.

Werde morgen den Watchdog ausprobieren auf jeden Fall mit mehr als 1500ms. Hoffentlich beißt er nicht.

Wg. Grund für den Wachtdog
Ich habe immer wieder EMV Probleme. Es passiert immer wieder dass der µC hängenbleibt. Verfälschte Werte (z.B. Eingang ist kurz Low obwohl kein Taster gedrückt) fängt er auch immer wieder ein, aber die kann ich via Software handeln.

An allen Leitungen zum µC hängen mittlerweile Ferrite und Varistoren, 230V Leitungen haben mittlerweile Entstörkondensatoren, Spannungsversorgung habe ich mit Pufferbatterie und Kerkos zu stabilisieren versucht, und der µC ist in einem geerdeten PC Gehäuse.
Trotzdem passiert es immer wieder dass sich der µC aufhängt.
Z.B: 230V Aufzug letzte Woche: beim Ausschalten ist der µC hängengeblieben, obwohl er nur via Batterie versorgt war und ca 10m Entfernt. Das ist nicht nur 1x passiert sondern war super reproduzierbar. Was leider nicht häufig der Fall ist. Netzfilter zwischen den 230V Leitungen haben nicht geholfen. Mit einem RC Glied parallel zum Schalter war dieser Fehler nicht mehr provozierbar. Was jedoch nur Probleme--; bedeutet.

Der µC der den Watchdog bekommen soll, muss sich immer wieder via Funk bei einem anderen µC melden. Wenn er das nicht tut, gibt dieser Fehlermeldungen aus (Website und später auch Handy).

So das ist der lange Grund für den Watchdog.

Das klingt ja gruselig!

Wie ist denn die Hardware gebaut? Relais? Hast du entsprechende Schutzdioden? Passende Transistoren? Schonmal mit Optokopplern probiert?

Gruß,
Tobias

Was baust Du da?

Und vor allem: solange Du nicht die Wurzel des Übels beseitigt wird die Sache durch einen Watchdog nur kaschiert und nicht behoben. Es kann Dir auch passieren, dass Du trotz des Watchdogs einen Hänger bekommst und dann viel Spass beim Suchen. D.h. der interne Watchdog wird Dein Problem nicht zuverlässig lösen. Für sowas brauchst Du einen externen WD. Wenn Du aber EMV Probleme hast, dann musst Du die abstellen. Wenn Du das nicht kannst, dann ist die einzig sinnvolle Lösung eine fertige Lösung zu kaufen die damit fertig wird. Bei SPS Modulen haben normalerweise Ingineure die Ihr Handwerk verstehen sehr viel Zeit reingesteckt damit das nicht passiert. Daher der Preis und deshalb ist ein Arduino in solchen Umgebungen auch nicht sinnvoll einsetzbar.

Hallo,

Wg. SPS:
Ich will keine SPS einsetzen, sondern möchte meine EMV Probleme natürlich langfristig lösen und unbedingt mit µC´s und Arduino arbeiten, weil mir das Projekt irrsinnig taugt.
Das der Watchdog nicht perfekt ist, ist mir klar. Die Fehlersuche erschwert er mir jedoch mMn nicht, denn wenn der µC ohne Watchdog irgendwann hängenbleibt weiß ich auch nicht warum. Ein externer Watchdog ist aber ohne Frage die bessere Lösung, und macht viel mehr Sinn.

Wg. Hardware gebaut
Hallo Tobias,
Alle Eingänge laufen über Optokoppler. Die Ausgänge über mehrere ULN2803 also mit integrierten Schutzdioden. Es werden u.a. 4 Relais geschaltet. Die Relais haben zusätzliche Schutzdioden.
Probleme machen jedoch externe Geräte wie der oben genannte Taster vom elektr. Aufzug. Der Aufzug ist nicht mit dem µC verbunden. Es gibt aber auch Probleme mit Netzteilen von Ladegeräten beim Einstecken (mangels On/Off Knopf)…
Habe schon angefangen Leitungen zu verlegen um möglichst große Abstände zu erreichen usw. es ist besser geworden. Aber noch nicht befriedigend.

Zur Watchdog Lösung:
Wie im Link von Udo beschrieben war das Problem, dass nach einem WD-Reset, der WD-Timer auf eine sehr kurze Zeit gesetzt wurde (vermutl. 15ms). Also hat mein Programm gar keine Chance gehabt den WD wieder auszuschalten. Obwohl der WD zuvor auf 8 Sekunden eingestellt war.
Die Lösung war im Makefile '-DWATCHDOG_MODS' beim 328-er hinzuzufügen. Danach den Bootloader kompilieren und zu brennen.
Anleitung dazu:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1255016475/1
Jetzt lässt mir der Watchdog genug Zeit um mein Programm zu starten und um ihn zu deaktivieren.

Die Anlage selbst dient nur zu Überwachung von Eingängen bzw. einer Zufahrtstrasse, mit Geschwindigkeitsmessung, Temperatursensoren, Hundfütterung usw. also nichts großartig Gefährliches was jemanden verletzen könnte.

Alle Eingänge laufen über Optokoppler.

Das ist gut.

Die Ausgänge über mehrere ULN2803 also mit integrierten Schutzdioden.

Also gemeinsame Masse --> das könnte die Ursache sein. Ich würde auch an den Ausgängen Optokoppler einsetzen und damit die ULN2803 ansteuern. Damit kannst Du dann die Verbraucher (und damit auch die von Ihnen verursachten Störungen) abkoppeln.

Probleme machen jedoch externe Geräte wie der oben genannte Taster vom elektr. Aufzug.

Hmmm. Das versteh ich nicht. Taster = Eingang --> Optokoppler. Zumindest hatte ich das eben so verstanden.

Was also nur noch bleibt ist die Stromversorgung. Wie man die in "dreckigen" Umgebungen säubert schaut man am Besten bei der Autoelektrik ab:
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.23

Voralpenkreuz:
...
Alle Eingänge laufen über Optokoppler. Die Ausgänge über mehrere ULN2803 also mit integrierten Schutzdioden. Es werden u.a. 4 Relais geschaltet. Die Relais haben zusätzliche Schutzdioden.
Probleme machen jedoch externe Geräte wie der oben genannte Taster vom elektr. Aufzug. Der Aufzug ist nicht mit dem µC verbunden. ...

Welche Pullup-Widerstämde verwendest Du? Wie groß sind sie? Hast Du versucht einen kleineren Widerstandswert zu nehmen?
Grüße Uwe

Hallo,
ich hoffe ich verschreie es nicht, aber mittlerweile hat sich etwas getan. Aber der Reihe nach.

Wg. Seilwinde Taster:
Die elektr. Seilwinde(250W) wird nur händisch betätigt und ist nicht mit dem µC verbunden. Wenn ich auf den Taster für hinauf/hinunter drücke bzw. loslasse sind Fehler aufgetreten. Wie oben erwähnt 2 RC Glieder direkt beim Taster und das Problem war gelöst.
Der Betrieb der Verbraucher bei meiner Schaltung hat keine Probleme verursacht. Es war immer das Umfeld.

Wg. Gemeinsame Masse, Optokoppler
Aus Kostengründen wird die gesamte Schaltung über 1 kleines Netzteil (welches die Batterie speist) versorgt. Die eingesetzten Optokoppler sind eigentlich nur für die Pegelwandlung zuständig, bzw. zum Schutz der Inputpins vor Überspannung. Also nicht optimal.
Die längste Leitung ist ca 25m. Die Überlegung war dass ich den µC-Pin vor einer in die Leitung induzierten Überspannung schützen könnte wenn es über Optokoppler läuft. Trotz gemeinsamer Masse. Funktioniert das eigentlich?
Die eingesetzten Pullups sind die internen vom Mega. Tastvorgänge habe ich immer erkannt, sogar welche die nicht da sind.

Wg mögliche Lösung
Gestern habe ich viele Tests gemacht, um Abstürze des µCs zu provozieren. Leider habe ich erst recht spät erkannt dass oft nur die Laptop-Usb-µC Verbindung abbricht, obwohl der µC normal weiterarbeitet. Egal. Irgendwann habe ich mir die Kabelführung der bestehenden Installation angesehen. Die schaut ungefähr so aus:

Von unten kommt die Zuleitung. Der Untere Verteilerkasten(1) versorgt den oberen und geht nach rechts weiter zu anderen Geräten(4) (elektr. Seilwinde usw.)

Der obere Verteiler(2) geht zum Licht bzw. Bewegungsmelder, und zum Lichtschalter mit Steckdose (3).
Im Punkt wo sich die blauen Linien kreuzen sind die Leiter nicht verbunden. Alle eingezeichneten Leiter befinden sich in einer Wand

Nachdem was ich über EMV gelesen habe nicht wirklich optimal. Also das Kabel von 2-3 ausgezogen, Lichtschalter zwischen 1 und 2 geklemmt.
Danach wieder getestet. Der µC ist nicht mehr abgestürzt!
Hoffentlich bleibt das so, habe schon oft gehofft eine Lösung gefunden zu haben und 2 Tage später ist die Ernüchterung gekommen.

Der µC erkennt wenn ich störe immer noch ab und zu einen Input als Low, aber im Bereich von unter 50ms, also leicht zu erkennen.

Ich hoffe, dass es das war. Vielen Dank für eure Hilfe.

EMV Skizze.JPG

Der Arduino wird stöhrsicherer wenn Du externe, kleinere Pullupwiderstände nimmst ( zB 1kOhm)
Grüße Uwe

Nochmal zur Watchdog:

Da habe ich meine Infos her und die widersprechen ein bischen dem das die Zeit nur 1mal gilt. Funktioniert bei mir tadelos. Ich habe auch den Bootloader entfernt damit ist die Ardu schneller "da". Das heisst aber Programieren mit ISP. Ich habe mir diese einsteigermodell gegönnt:

Den halten hier einige für nicht so toll ;), aber ich habe in meinen AVR Projekten nur gute erfahrungen mit dem gemacht und Preis/Leistung stimmen voll. Er ist einfach in die IDE einzubinden.
Kann ich gerne weiterhelfen oder im FOrum suchen

Gruß

Daniel

Hallo volvodani,

du hast natürlich Recht. Mit der Option DWATCHDOG_MODS wird das Prescaler-Bit beim Start behandelt, und der Watchdog ausgeschaltet wenn ich das richtig verstanden habe. Auf jeden Fall ist der Watchdog nach einem Reset jetzt aus.
Aus ATmegaBOOT-168.c

#ifdef WATCHDOG_MODS
	ch = MCUSR;
	MCUSR = 0;

	WDTCSR |= _BV(WDCE) | _BV(WDE);
	WDTCSR = 0;
…

Übrigens: die oben beschriebene Änderung der Installation hat meine Abstürze nur verringert. Beim Einschalten von großen Geräten stürzt der µC immer wieder ab, ebenso bei Blitzen.

Ich will jetzt einen externen Watchdog einbauen. Dazu 1 Frage:
Wenn der µC sich aufgehängt hat, reicht es den Reset Pin auf Low zu ziehen damit er wieder arbeitet oder ist es besser gleich die Stromversorgung kurz zu trennen? Also wie „verlässlich“ ist der Reset Pin?