Hallo! Vor fast 2 Jahren habe ich eine Zutritt-Anlage gebaut. Sie besteht aus 3 Einheiten: Codeeingabe-Einheit - Ist auf der Straße Türeinheit - Ist am Tor montiert (da ist ein Motor drin, der die Gartentür freigibt bei erfolgreicher Codeeingabe) Zentrale - ist im Wintergarten montiert. In allen 3 Einheiten werkelt ein ATmega8 Mikrocontroller. Die Anlage läuft 24/7 und eigentlich sehr gut. Allerdings gab es einige Vorfälle, die ich mir nicht erklären kann. Zuerst lief die Anlage von September 2016 (Inbetriebnahme) bis Juli 2017 fehlerfrei. In einer Nacht kam es dann zwei Mal hintereinander (ca Viertelstunde Abstand) zu einer Fehlfunktion. Es schien, als würden die Port D Pins falsch eingelesen bzw ausgegeben werden. (Beide Male) Zwei Wochen lang lief dann die Anlage wieder fehlerfrei, ich tauschte dann aber trotzdem den Mikrocontroller aus. Heuer, wieder im Juli, wieder in der Nacht, kam es auch mit dem neuen Mikrocontroller zu der selben Fehlfunktion. Ich dachte, ok, anscheinend macht der uC ein Mal Jährlich einen Fehler, sei‘s drum, es gibt jetzt wieder ein Jahr Ruhe. Es kam anders. Nach einer Woche (sogar am selben Wochentag) kam es wieder zu der Fehlfunktion. Wieder in der Nacht. Jetzt stell ich mir die Frage, wie das denn sein kann!? Ist das normal, dass ein ATmega8 seine Eingänge plötzlich falsch liest!? Es ist aber auch komisch, dass es immer nur die Einheit im Wintergarten betrifft. Einen Programmierfehler würde ich weitgehend ausschließen, da es keine Unterschiede in der Bedienung an den Fehlertagen gab. Es gab auch keine Gewitter. In der Nacht dürfte es auch nicht so heiß gewesen sein. (Tagsüber wird es dort schon sehr heiß, da gab‘s aber nie Fehlfunktionen) Was meint ihr zu dem Ganzen!?
Wie weit sind die Stationen voneinander entfernt? Welche Schutzmaßnahmen wurden bzgl. EMV unternommen?
Hallo, dann stelle bitte mal Bilder, Schaltplan und das Programm ein. Ich denke an EMV, bzw. EMVU Probleme! Test: Man halte ein 2m Sender mit 5 Watt Ausgangsleisung direkt an die Einheit!
UC schrieb: > Einen Programmierfehler würde ich weitgehend ausschließen Die Erfahrung sagt: das solltest du nicht. Vermutlich ist es so, dass da von aussen was herein kommt, womit dein Programm nicht rechnet. > Es schien, als würden die Port D Pins falsch eingelesen bzw ausgegeben > werden. (Beide Male) Was ist denn am Port D angeschlossen? Ein Schaltplan wäre da hilfreich, vom Programm will ich gar nicht reden...
UC schrieb: > Ist das normal, dass ein ATmega8 seine Eingänge plötzlich falsch liest!? Was bedeutet "Normal", an dieser Stelle? Denn, normalerweise funktionieren ATMegas! Egal welcher. Karl M. schrieb: > dann stelle bitte mal Bilder, Schaltplan und das Programm ein. Ja, dürfte hilfreich sein, falls du wirklich möchtest, dass wir eine Chance haben, dich mit der Nase auf den Fehler zu stoßen. UC schrieb: > Einen Programmierfehler würde ich weitgehend ausschließen, Der Weg in die Hölle ist mit ungenügend geprüften Annahmen gepflastert.
Wie wäre es mit kalten Lötstellen? Oder Wackelkontakt, vielleicht rüttelt ja ein Fuchs am Wintergarten? Also im Controller selbst würde ich den Fehler erst sehr spät suchen.
Flugobjekte die Gravitationswellen aussenden, könnten Deine Schaltung beeinflußt haben. MfG
Tom schrieb: > Wie weit sind die Stationen voneinander entfernt? 5-15m Kabelweg Tom schrieb: > Welche Schutzmaßnahmen wurden bzgl. EMV unternommen? Signalleitungen zwischen den Einheiten sind verdrillt und geschirmt. Innerhalb der Zentrale zwischen den Platinen verdrillt. Alle Leitungen, die ein Signal liefern sollen, müssen einen nennenswerten Strom führen, damit am Pull-Down-Widerstand eine Spannung abfällt, die dann als 1 gewertet wird. (mA-Bereich) In Software werden die Eingänge alle 50ms abgetastet. Erst wenn 8 mal (bzw. bei manchen Tasten sogar 32 mal) hintereindander ohne Lücke ein 1-er detektiert wurde, wird eine Flanke erkannt. Lothar M. schrieb: > Was ist denn am Port D angeschlossen? PD0: Signaleingang von der Codeeingabe-Einheit (mittels UART und RS232 über MAX232) PD1: Signal an die Türeinheit (langsames Signal, kein UART oder so) PD2: Signal von der Türeinheit (zur Meldung von Fehlern) (langsames Signal, kein UART oder so) PD3: Geht dieser Eingang für 8 Abtastungen auf 0, gibt es Alarm. Es gibt einen externen Pulldown-Widerstand (10k, wenn ich mich richtig erinnere). Dieser Eingang ist permanent auf 5V gebrückt, da die Alarmfunktion nicht verwendet wird. PD4: Hier ist die Glockentaste angeschlossen. Bei 8 Abtastungen auf 1 gibt es ein Läuten. Ebenfalls mit Pulldown (auch hier 10k, glaub ich). PD5 & PD6: Hier ist ein Schieberegister angeschlossen, an den LEDs angeschlossen sind. PD7: Hier ist ebenfalls eine LED angeschlossen. Beim Fehler wurde die Alarm-Melodie gespielt. Bei den LEDs am Schieberegister haben (fast?) alle geleuchtet. Wahrscheinlich wurde auch die Glocken-Melodie gespielt. (Ich war leider nicht anwesend und man konnte mir nicht alles wiedergeben) Lothar M. schrieb: > UC schrieb: >> Einen Programmierfehler würde ich weitgehend ausschließen > Die Erfahrung sagt: das solltest du nicht. > > Vermutlich ist es so, dass da von aussen was herein kommt, womit dein > Programm nicht rechnet. Ich schließe sowas normalerweise eher nicht aus. Aber hierbei handelt es sich um eine Anlage, die 99% der Zeit in Bereitschaft ist. Es gab nie Fehlfunktionen, während man mit dem System interagiert hat. (Wo ein Fehler doch wahrscheinlicher sein sollte.) Als der Fehler auftrat, war die Anlage einfach in Bereitschaft. Es gab dabei keinerlei Interaktion. Dieser Zustand unterschied sich also nicht von dem Zustand, in dem das Gerät zu 99% der Zeit ist und ein Jahr lang keinen Fehler produzierte. Deshalb kann ich mir nicht erklären, woher so ein Fehler plötzlich herkam. An EMV denke ich normalerweise auch zuerst, wenn etwas unerwartetes passiert und der Code nicht Schuld ist. Aber es hat auch nie Probleme während eines Gewitters gegeben. Auch auf ein Handy spricht er nicht an. WLAN stört ihn auch nicht. DECT auch nicht. Ich kann mir einfach nicht vorstellen, woher ausgerechnet in einer Nacht mit klarem Himmel in einem kleinen Dorf eine EMV-Störung herkommen soll... Ein Amateurfunker vielleicht? Aber der müsste ja dann öfter stören, oder nicht!? Ich dachte auch an die Stromversorgung. Die kommt aus einem Tischnetzteil. Dieser Liefert bei 15V Nennspannung ca. 14,7V. Daraus macht dann ein kleiner 780x-Pin-kompatibler RECOM DC/DC-Wandler 5V. Der selbe sitzt auch in der Türeinheit. (In der Codeeingabe-Einheit ist ein 7805) Wenn ich die Spannung messe, passt die. Ich kann auch keine Spitzen feststellen (zumindest nicht mit der MAX/MIN-Funktion meines Multimeters). Auch nicht während einer Interaktion. Trotzdem bin ich da skeptisch. Ist aber im Moment nicht mein Hauptverdächtiger. Vl ein Fehler? S. Landolt schrieb: > Wie wäre es mit kalten Lötstellen? Oder Wackelkontakt, vielleicht > rüttelt ja ein Fuchs am Wintergarten? > Also im Controller selbst würde ich den Fehler erst sehr spät suchen. Auf mechanische Einwirkung reagiert er auch nicht. Habe an den Kabeln gewackelt - nichts. Zudem müssten da viele Kontakte auf einmal kaputt sein. Und der Fehler dürfte nicht durch ein kurzes Stromlos-Schalten weg sein. (Einen Fuchs würde unser Hund schneller fortjagen als der Fuchs schauen kann :D) Vielleicht hab ich ja ein (oder mehrere) Denkfehler drin...
Beitrag #5478583 wurde vom Autor gelöscht.
UC schrieb: > Tom schrieb: >> Wie weit sind die Stationen voneinander entfernt? > > 5-15m Kabelweg Ok. Und Du hast direkt Portpins mit den Kabel verbunden oder sind da noch diverse Leitungstreiber vorgesehen?
Tom schrieb: > UC schrieb: >> Tom schrieb: >>> Wie weit sind die Stationen voneinander entfernt? >> 5-15m Kabelweg > Ok. Und Du hast direkt Portpins mit den Kabel verbunden oder sind da > noch diverse Leitungstreiber vorgesehen? Bei den Ausgängen gibt es Transistoren. Bei den Eingängen die Pull-Down-Widerstände.
UC schrieb: > Bei den Eingängen die Pull-Down-Widerstände. Die Eingänge gehen ganz ohne jegliche Schutzbeschaltung (Serienwiderstände, Kondensatoren, Schutzdioden...) vom uC Pin auf das Kabel?
:
Bearbeitet durch Moderator
Hoer auf mit dem Prosa und zeig endlich einen Schaltplan! Alles andere ist unsinn
Kaj schrieb: > Hoer auf mit dem Prosa und zeig endlich einen Schaltplan! Aber der böse Atmel hat ihm doch einfach Schund geliefert, oder? :-((( Das ist ein fetter Design Fehler und sonst nichts.
Design Fehler in seinem Projekt. Der Atmel macht bestimmt das, was er soll. Von den Dingern gibt es zuviel und zu lange am Markt, als dass solche Kinderkram hoch kocht.
Lothar M. schrieb: > Die Eingänge gehen ganz ohne jegliche Schutzbeschaltung > (Serienwiderstände, Kondensatoren, Schutzdioden...) vom uC Pin auf das > Kabel? Kondensatoren gibt es. 1uF bei der Glockentaste und beim Alarm. Schutzdioden und Serienwiderstände gibt es nicht. Würden die Schutzdioden gegen EMV Störungen helfen? Wie würde man die Schalten? Von Masse zu Pin und von Pin zu 5V? Macht man das generell? Ich dachte, es macht nur Sinn, um Schäden durch falsche Beschaltung zu verhindern... Was genau würden die Serienwiderstände bewirken? Wie groß müssten diese sein? Das Problem mit dem Schaltplan ist, dass der nicht alles zeigt. Ich habe z.B. eine externe kleine Lochrasterplatine gebaut, wo Pulldown und die Kondensatoren drauf sind. Außerdem auch ne Erweiterung, etc.
Dann nimm dir einen Vormittag und zeichne den Schaltplan einfach. Das wäre das Mindeste.
> Einen Programmierfehler würde ich weitgehend ausschließen, da es keine > Unterschiede in der Bedienung an den Fehlertagen gab. Man glaubt gar nicht, wieviele Fehler man pro Code-Zeile unterbringen kann.
UC schrieb: > Würden die Schutzdioden gegen EMV Störungen helfen? Zusammen mit den anderen Maßnahmen... > Wie würde man die > Schalten? Von Masse zu Pin und von Pin zu 5V? Ja. > Ich dachte, es macht nur Sinn, um Schäden durch falsche Beschaltung zu > verhindern... Nein, die sorgen dafür, dass überschüssige Energie nicht 8n den uC kommt > Was genau würden die Serienwiderstände bewirken? Wie groß müssten diese > sein? Zusammen mit dem Kondensator bilden die einen Tiefpass, der hochfrequente Störungen draußen hält. UC schrieb: > Beim Fehler wurde die Alarm-Melodie gespielt. Bei den LEDs am > Schieberegister haben (fast?) alle geleuchtet. Wahrscheinlich wurde auch > die Glocken-Melodie gespielt. (Ich war leider nicht anwesend und man > konnte mir nicht alles wiedergeben) Wer "spielt" diese Melodien? Werden die laufend nacheinander gespielt? Gleichzeitig? Hast du irgendwelche Testroutinen, die so etwas auslösen können? Was muss passieren, damit alle LEDs am Schieberegister leuchten? Reicht es aus, wenn die einmalig beschrieben werden?
UC schrieb: > Ein Amateurfunker vielleicht? Aber der müsste ja dann öfter stören, oder > nicht!? Der müsste vielleicht seine Richtantenne (zufällig) mal in deine Richtung drehen und zufällig tut er das nicht so oft. Das sollte sich aber durch einen Blick in die Nachbarschaft (drehbare Richtantenne auf dem Dach/Gittermast) näher eingrenzen lassen. An welchem Wochentag und zu welchen Uhrzeiten kam es denn zu den Störungen? Amateurfunker führen ein Logbuch, mit dem das dann korrelieren müsste.
UC schrieb: > Die Anlage läuft 24/7 und eigentlich sehr gut. So ein "eigentlich" kann einem den ganzen Tag versauen. Die Space Shuttle liefen auch eigentlich sehr gut, bis ...
"(Einen Fuchs würde unser Hund schneller fortjagen als der Fuchs schauen kann :" Dein Hund macht Experimente mit Tesla-Transformatoren und den ersten Prototypen holt er immer nur nachts hervor. Der Fuchs ist dagegen ein Längstwellenspezialist. Also doch ein EMV-Problem. "Zuerst lief die Anlage von September 2016 (Inbetriebnahme) bis Juli 2017 fehlerfrei. In einer Nacht kam es dann zwei Mal hintereinander (ca Viertelstunde Abstand) zu einer Fehlfunktion" Der Hund brauchte natürlich eine Weile, um sich die Grundlagen anzueignen und den ersten Aufbau zu erschaffen, dann aber klappte es in der besagten Nacht zum ersten Mal ganz gut. Du hast nicht zufällig unverschlossen abgestellte Bücher im Haus? MfG
:
Bearbeitet durch User
hatte ein ähnliches Phänomen. Lag an zu klein dimensionierten arrays. ging wochenlang richtig. irgendwann wurde unplanmäßig über das array hinaus in den Programmcode geschrieben.
grundschüler schrieb: > irgendwann wurde unplanmäßig über das array > hinaus in den Programmcode geschrieben. Das kann bei der Architektur der ATmegas nicht passieren. Aber andere Variablen überschreiben geht
> Ich kann mir einfach nicht vorstellen, woher ausgerechnet in einer > Nacht mit klarem Himmel in einem kleinen Dorf eine EMV-Störung > herkommen soll... Du hast mit bestimmten Geräten getestet, die nur ganz bestimmte Frequenzen abstrahlen und das auch noch mit relativ wenig Energie. Ich halte den Test für Sinnvoll (da einfach), aber er ist eben nicht vollständig. Du hast nichts von analogen Schutzschaltungen (z.B. Filter) geschrieben. Bedenke, dass ungeschützte IC Eingänge durchaus auch langsam mit der Zeit geschädigt werden können, so dass sie im laufe der Zeit immer schlechter funktionieren. Früher, als man Drucker noch mit kurzen Parallelen Kabel angeschlossen hatte, waren Filter an beiden Enden des Kabel üblich. Und das, obwohl die Geräte direkt nebeneinander standen und das Kabel verdrillt und doppelt abgeschirmt war. So einen Aufwand treibt man nicht nur Spaß. Wesentlich einfach als der ganze EMV Kram ist eine Messung der Signalqualität (Stichwort Augendiagramm) mit einem Oszilloskop. Eventuell hat deine Schaltung schon immer nur mit Glück funktioniert, weil die Signale ungültige Pegel, zu flache oder sonst wie verzerrte Flanken haben. Ich möchte nochmal wiederholen, dass du deinen Schaltplan zeigen solltest. Schaltpläne sind die Sprache der Elektronik und die Ausgangslage für jede Diskussion, sobald es um mehr als ein einzelnes Bauteil geht. Du hast Fragen zu diversen Schutzschaltungen gestellt. Dieses Thema ist zu umfangreich, um Die hier im Rahmen der Diskussion zu helfen. Du hast die nötigen Stichworte genannt bekommen, jetzt solltest du Abhandlungen darüber im Internet oder in der Bücherei suchen. Das Thema ist nicht neu, so dass durchaus auch alte Bücher aus den 80er Jahren hilfreich sein können. In der Artikelsammlung (https://www.mikrocontroller.net/articles/Hauptseite) wirst du auch was finden.
Stefanus F. schrieb: > Du hast nichts von analogen Schutzschaltungen (z.B. Filter) geschrieben. So siehts aus. Die Pins vom Mikrocontroller sind dafür gedacht Signale auf der Leiterplatte zu treiben. Sobald es von der Platine runtergeht, sollte man über geeignete Leitungstreiber nachdenken. > Bedenke, dass ungeschützte IC Eingänge durchaus auch langsam mit der > Zeit geschädigt werden können, so dass sie im laufe der Zeit immer > schlechter funktionieren. Elektromigration ist bekannt, aber bisher nicht in dem obigen Szenario. Hast Du da irgendwelche Belege/Quellen/Hintergünde? > Wesentlich einfach als der ganze EMV Kram ist eine Messung der > Signalqualität (Stichwort Augendiagramm) mit einem Oszilloskop. Nanana. Oszilloskop ja gerne, aber nicht gleich mit Augendiagramm. Das würde ja einen kontinuierlichen Datenstrom voraussetzen. > Eventuell hat deine Schaltung schon immer nur mit Glück funktioniert, > weil die Signale ungültige Pegel, zu flache oder sonst wie verzerrte > Flanken haben. Genau. Und jetzt gibt es in der Nachbarschaft ein neues Spielzeug aus China...
UC schrieb: > Es schien, als würden die Port D Pins > falsch eingelesen bzw ausgegeben werden. (Beide Male) Schaltplan posten und Quellcode anfügen! Lade am besten die Leiterplattenfiles hier hoch!
>> Bedenke, dass ungeschützte IC Eingänge durchaus auch langsam mit der >> Zeit geschädigt werden können, so dass sie im laufe der Zeit immer >> schlechter funktionieren. > Hast Du da irgendwelche Belege/Quellen/Hintergünde? Das habe ich so in meiner Ausbildung gelernt und im Laufe vieler Jahre auch mehrmals am laufendem Gerät erlebt. > Oszilloskop ja gerne, aber nicht gleich mit Augendiagramm. > Das würde ja einen kontinuierlichen Datenstrom voraussetzen. Jein. Einige Speicheroszilloskope bekommen das auch mit nicht kontinuierlichen Signalen hin. Zur Überprüfung von Signalen auf Leitungen kann es aber durchaus erforderlich sein, ein spezielle Testprogramm zu schrieben, dass die ungünstigsten Fälle absichtlich provoziert und die Signale so erzeugt, dass man sie gut darstellen kann. Früher hat man dazu oft Signalgeneratoren verwendet, heute werden sie teilweise und zunehmend durch Software abgelöst. Flash Speicher und ISP bzw Bootloader unterstützen dies.
Habe nun den Schaltplan ergänzt und in den Anhang gegeben. Bitte nicht so streng sein, was die Form betrifft. Ich zeichne mittlerweile wesentlich sauberer. Diese Anlage war eben mein erstes größeres Projekt, das ich selbst durchgeführt habe. Ich habe damals schon viel dabei gelernt und lerne jetzt weiter dazu. Danke daher schon mal für alle bisherigen Tipps und auch für jene, die im Anschluss kommen werden im Voraus!! Lothar M. schrieb: > UC schrieb: >> Beim Fehler wurde die Alarm-Melodie gespielt. Bei den LEDs am >> Schieberegister haben (fast?) alle geleuchtet. Wahrscheinlich wurde auch >> die Glocken-Melodie gespielt. (Ich war leider nicht anwesend und man >> konnte mir nicht alles wiedergeben) > Wer "spielt" diese Melodien? Werden die laufend nacheinander gespielt? > Gleichzeitig? Hast du irgendwelche Testroutinen, die so etwas auslösen > können? Was muss passieren, damit alle LEDs am Schieberegister leuchten? > Reicht es aus, wenn die einmalig beschrieben werden? Die Melodien werden durch das Programm über PWM erzeugt, verstärkt und an zwei Lautsprechern ausgegeben. Werden im Programm mehrere Melodien gleichzeitig angefordert, werden diese nacheinander abgespielt. Die verschiedenen Melodien haben eine bestimmte Priorisierungsliste. Ich denke, dass das Programm beim Fehler zumindest Glocke und Alarm gleichzeitig angefordert bekam.
UC schrieb: > Habe nun den Schaltplan ergänzt und in den Anhang gegeben. Das ist ein Eagle-File! Also bitte noch .brd und .sch posten, damit diejenigen die Eagle haben, sich leichter tun!
Für den Anfang würde ich in die Leitungen zwischen Taster und ATmega jeweils 1 kOhm in Reihe machen und zwei Dioden: eine zu GND und eine zu Vcc. Damit werden Spannungsspitzen die unter GND oder über Vcc sind abgeleitet. Außerdem mit einem Oszilloskop mal auf die Betriebsspannung schauen. Durch das ständige schalten des DC/DC-Wandlers werden die (internen) Kondensatoren recht strapaziert und können schon mal nachlassen.
kleiner Tipp: Man könnte im Programm regelmäßig die Aus- bzw. und Eingänge prüfen, ob sie wirklich noch Aus- bzw. Eingänge sind. Gern überprüfe ich Registerinhalte, ein "NULL-Register", z.B. R11=0x00, sollte immer Null sein. Der SRAM darf nicht den STACK überschreiben. Ein Überwachungsbyte im SRAM permanent abfragen (zw.Stack und SRAM-Daten). WDR Überwachung. Sollte sich in dieser Beziehung etwas ändern ---> Fehlermeldung bzw. Neustart Sind die Eingänge softwaremäßig genügend entprellt?
:
Bearbeitet durch User
Marc Horby schrieb: > UC schrieb: >> Habe nun den Schaltplan ergänzt und in den Anhang gegeben. > > Das ist ein Eagle-File! Also bitte noch .brd und .sch posten, damit > diejenigen die Eagle haben, sich leichter tun! Ich habe allerdings im Schaltplan eben einiges mit GIMP verändert, was ich nachträglich dazugebaut habe. Tom schrieb: > Für den Anfang würde ich in die Leitungen zwischen Taster und ATmega > jeweils 1 kOhm in Reihe machen und zwei Dioden: eine zu GND und eine zu > Vcc. Damit werden Spannungsspitzen die unter GND oder über Vcc sind > abgeleitet. Ok, verstehe. Würde man das nur bei den Tastern machen, die über längere Leitungen zum uC führen? Oder auch bei den Tastern am Frontpanel der Zentrale, wo die Leitungen nur ca. 20cm lang (und verdrillt) sind?? Nur zum Verständnis: Ohne Kondensator nutzt ein Serienwiderstand nichts, oder? Nur mit dem Kondensator gemeinsam bildet es einen Tiefpass? Tom schrieb: > Außerdem mit einem Oszilloskop mal auf die Betriebsspannung schauen. > Durch das ständige schalten des DC/DC-Wandlers werden die (internen) > Kondensatoren recht strapaziert und können schon mal nachlassen. Heißt das, man sollte gar keinen DCDC-Wandler nehmen, wenn man einen uC benutzt? Würdest du das gegen einen 7805 tauschen? Bernhard S. schrieb: > Man könnte im Programm regelmäßig die Aus- bzw. und Eingänge prüfen, ob > sie wirklich noch Aus- bzw. Eingänge sind. Das habe ich mir auch schon gedacht. Ist es allerdings nicht so, dass der Compiler soetwas herausoptimieren würde? Schließlich wird das ja im Programm nach der Initialisierung nicht mehr verändert...
UC schrieb: > zentrale.png An PB2 und PB3 hast die ziemliche Antennen dran hängen. Die bieten, danke ihres relativ hochohmigen Abschluss (int. Pull-Up?), bei langen Leitungen zu den Tastern IMHO genügend Spielraum für Störungen. Würde Fehlinterpretation des Signalpegels an diesen Pins zu den von dir beobachteten Betriebsstörungen passen?
Wolfgang schrieb: > UC schrieb: >> zentrale.png > > An PB2 und PB3 hast die ziemliche Antennen dran hängen. Die bieten, > danke ihres relativ hochohmigen Abschluss (int. Pull-Up?), bei langen > Leitungen zu den Tastern IMHO genügend Spielraum für Störungen. > > Würde Fehlinterpretation des Signalpegels an diesen Pins zu den von dir > beobachteten Betriebsstörungen passen? Eigentlich überhaupt nicht: An PB2 hängt ein Knopf, womit man Ereignisse (u.a. auch den Alarm) quittieren kann. Da müsste die Störung eher abgefangen werden. An PB3 hängt die Taste zum Öffnen der Tür, das löst auch keine Melodien oder Alarme aus. Die Taste an PB2 ist außerdem direkt an der Frontplatte der Zentrale, wenige cm von der Platine entfernt...
Ganz vergessen: Bernhard S. schrieb: > Sind die Eingänge softwaremäßig genügend entprellt? Ja. Mehr als das. Die Eingänge werden alle 50ms abgetastet. Bei einigen Tasten muss der jew. Pin 8 mal hintereinander(!), beim Rest sogar 32 mal, als 1 gelesen werden, damit reagiert wird...
Wäre so eine Schutzschaltung ok? (Nicht nur hier, sondern generell, wenn man an Mikrocontrollern etwas EMV-kritisches anschließt)
Ich würde den Serienwiderstand wohl vor den Dioden platzieren. Und evtl etwas kleiner machen. Und den PullDown evtl. auch, bei 15m Kabeln. Je höher der Strom+Spannungsdifferenz, desto größer der Störabstand. In der Industrie/SPS sind 24V und 20mA weit verbreitet. Da muss schon ordentlich was an Störung kommen, um sich durchzusetzen.
UC schrieb: > Wäre so eine Schutzschaltung ok? Ja, im Prinzip schon. Ich würde die Dioden direkt an den Pin machen oder zumindest davor noch einen R. Auch ist das 1μF etwas groß, 100n sollten gut reichen. Sonst könnte die Reaktion ggf. zu langsam sein. Das hängt aber vom Einzelfall ab.
Die Dioden auf die andere Seite des Laengswiderstands und der Pulldown darf intern sein. Und glaub nicht den Scheiss von den langsam schimmelden Ausgängen. Das Märchen von Stefan meine ich.
In der Nacht von warmen Tagen gibt es Probleme? Kann es vielleicht ein Problem mit Kondenswasser sein? Vorallem, da die Zentrale im Wintergarten untergebracht ist wo evtl. auch Pflanzen stehen?
mr. mo schrieb: > Vorallem, da die Zentrale im Wintergarten untergebracht ist wo evtl. > auch Pflanzen stehen? Man kann sich auch gut vorstellen, daß es da Pflanzen gibt, die zu Streichen aufgelegt sind: https://ixquick-proxy.com/do/spg/show_picture.pl?l=deutsch&rais=1&oiu=http%3A%2F%2Fview.stern.de%2Fde%2Fpicture%2F3040808%2Fnatur-pflanzen-busch-busch-gesicht-940.jpg&sp=92b4226d8544960052f224ec54b367d2 MfG Paul
Design vs Basteln schrieb: > Die Dioden auf die andere Seite des Laengswiderstands und der > Pulldown > darf intern sein. Der Atmel hat keinen internen Pulldown. Nur einen Pullup. > > Und glaub nicht den Scheiss von den langsam schimmelden Ausgängen. Das > Märchen von Stefan meine ich. Das "Märchen", wie du es bezeichnest, ist keinesfalls nur "Scheiß", sondern hat sich schon mehrmals durch Erfahrung bestätigt.
Ich habe gar nicht von Ausgängen geschrieben. Die meinte ich schon, aber auch Eingänge.
Immer schön dran denken: Jede Leitung (egal wie lang) ist zugleich eine Antenne. Antennen lassen Ströme fließen, die nicht von deiner bewussten Stromversorgung her kommen. Sie können daher sehr leicht zu positiver und negativer Überspannung führen, und sie können auch leicht zu überhöhten Strömen führen. Gegen zu hohe Ströme sollte man jeden Eingang und Ausgang mindestens durch einen Serienwiderstand schützen. Meistens kommen dann noch Kondensatoren dazu, um HF abzublocken, sowie Dioden, um Überspannung vom IC fern zu halten. Freilich haben all diese Bauteile einen Einfluss auf die Signale, die man übertragen möchte. Deswegen gibt es nicht "die eine" optimale Schutz-Schaltung. Neben der Antennenwirkung ist jede Leitung auch mit induktiven und kapazitiven Wirkungen behaftet. Wenn du einen annähernd Rechteckigen Impuls los sendest, regt er die Leitung zu Schwingungen an. Was hinten raus kommt, kann daher völlig anders aussehen. Auch dagegen gibt es Mittel (Terminierung entsprechend dem Wellenwiderstand, und Tiefpässe).
>In einer Nacht kam es dann zwei Mal hintereinander (ca Viertelstunde >Abstand) zu einer Fehlfunktion. Wie äußerte sich die Fehlfunktion? Durch Alarmauslösung PD3 ? Glockentaster "betätigt" PD4 ?
UC schrieb: > Nur zum Verständnis: Ohne Kondensator nutzt ein Serienwiderstand nichts, > oder? Oh doch, der 1k wirkt oft schon Wunder. Durch die Strombegrenzung können die internen Portdioden Spannungsspitzen kappen, indem sie den Störstrom in die Versorgung ableiten. Die nächste Stufe wäre wohl ein 10nF Kerko zwischen Port und Masse. Das sieht man öfter. Externe 4148 können auch nicht sooo viel mehr ableiten als die schon im Mega steckenden. Wenn dann würde ich stärkere nehmen.
Stefanus F. schrieb: > Wenn du einen annähernd Rechteckigen > Impuls los sendest, regt er die Leitung zu Schwingungen an. Was hinten > raus kommt, kann daher völlig anders aussehen. Auch dagegen gibt es > Mittel (Terminierung entsprechend dem Wellenwiderstand, und Tiefpässe). Und den Tiefpass hängt man dann vor die Leitung (damit die höherfrequentigen Anteile erst gar nicht in den "Schwingkreis"(=Leitung mit seinen parasitären Induktivitäten und Kapazitäten) kommen, oder doch eher nachher? Bernhard S. schrieb: >>In einer Nacht kam es dann zwei Mal hintereinander (ca Viertelstunde >>Abstand) zu einer Fehlfunktion. > > Wie äußerte sich die Fehlfunktion? > > Durch Alarmauslösung PD3 ? > > Glockentaster "betätigt" PD4 ? Beides. Deshalb dachte ich, dass der PORTD falsch interpretiert wird... batman schrieb: > Externe 4148 können auch nicht sooo viel mehr ableiten als die schon im > Mega steckenden. Wenn dann würde ich stärkere nehmen. Welche würde man nehmen? Ich dachte die 1N4148 sind sehr schnell... HildeK schrieb: > UC schrieb: >> Wäre so eine Schutzschaltung ok? > > Ja, im Prinzip schon. > Ich würde die Dioden direkt an den Pin machen oder zumindest davor noch > einen R. > Auch ist das 1μF etwas groß, 100n sollten gut reichen. Sonst könnte die > Reaktion ggf. zu langsam sein. Das hängt aber vom Einzelfall ab. Ok, also wie im jetzt angehängten Schaltplan? Wieso ist 1µF zu groß? Für langsame Signale müsste es reichen, nicht? Gibt es andere Nachteile, als dass es keine schnellen Signale erlaubt?
Noch eine Frage: Ab welcher Leitungslänge würdet ihr eine Schutzschaltung überhaupt am µC bauen? Oder würdet ihr das sogar schon bei reinen Platinen-Leiterbahnen machen? (Also wenn der Taster direkt an der Platine wäre)
UC schrieb: > Wieso ist 1µF zu groß? Üblicherweise sollte die Anstiegsgeschwindigkeit der Eingängssignale nicht zu langsam sein. HF-Einstreuungen weden auch mit 10nF schon sehr vut unterdrückt. UC schrieb: > Ab welcher Leitungslänge würdet ihr eine > Schutzschaltung überhaupt am µC bauen? Oder würdet ihr das sogar schon > bei reinen Platinen-Leiterbahnen machen? (Also wenn der Taster direkt an > der Platine wäre) Auf der Platine im geschützten Gehäuse gar nicht. Sobald eine Leitung den 'geschützten' Raum verlässt, dann schon. Je länger die Leitung ist und je schmutziger das Umfeld, desto mehr muss man die Maßnahmen ausweiten. Filter, Schirmung etc. Manchmal ist hier auch ein Optokoppler ganz hilfreich, weil man den so dimensionieren kann, dass es erst ab einigen mA LED-Strom zur Umschaltung kommt, selbst wenn die galvanische Trennung nicht notwendig ist.
HildeK schrieb: > UC schrieb: >> Ab welcher Leitungslänge würdet ihr eine >> Schutzschaltung überhaupt am µC bauen? Oder würdet ihr das sogar schon >> bei reinen Platinen-Leiterbahnen machen? (Also wenn der Taster direkt an >> der Platine wäre) > > Auf der Platine im geschützten Gehäuse gar nicht. Muss es ein Metallgehäuse sein, damit es ein "geschütztes Gehäuse" ist? Oder ist es einfach die Faustregel für die maximale Länge? Im zweiten Fall wäre bei mir also PB3, PD2, (PD3 falls mal die Alarmfunktion genutzt wird) und PD4 zu schützen, richtig? Muss man auch beim MAX232 irgendwelche Maßnahmen ergreifen? Müssen auch Ausgänge, die eine lange Leitung treiben, vor Überspannung geschützt werden? Oder reichen da die Treiber-Transistoren, wie ich sie auch habe? HildeK schrieb: > Manchmal ist hier auch ein Optokoppler ganz hilfreich, weil man den so > dimensionieren kann, dass es erst ab einigen mA LED-Strom zur > Umschaltung kommt, selbst wenn die galvanische Trennung nicht notwendig > ist. Müsste man da die LED irgendwie schützen? Oder könnte man da die lange Leitung direkt anhängen?
HildeK schrieb: > Ja, im Prinzip schon. > Ich würde die Dioden direkt an den Pin machen Da sind schon welche, sagt das Datenblatt vom ATmega8.
UC schrieb: > Muss es ein Metallgehäuse sein Die Leitungen sind auf der Platine kurz und damit erst mal deutlich schlechter Empfänger. Nein, muss also nicht, ist aber besser. Zumindest sollte man nichts berühren können: ESD. Eine maximale Leitungslänge kann dir keiner sagen, selbst auf der Platine gibt es bei den Ausführungen große Unterschiede (z.B. GND-Fläche oder nicht, Wert der Pullups, Entprellung usw.). UC schrieb: > Muss man auch beim MAX232 irgendwelche Maßnahmen ergreifen? Normalerweise nicht, aber ein Berührschutz ist immer sinnvoll, wieder: ESD. UC schrieb: > Müsste man da die LED irgendwie schützen? Oder könnte man da die lange > Leitung direkt anhängen? Die ist erst mal nicht so schnell, dann benötigt sie einige mA Strom, der durch eine Einstreuung kaum zustande kommt. Die LED ist durch den Vorwiderstand schon gut geschützt, Einflüsse auf die Prozessorschaltung sind deutlich geringer. Ein offener Anschluss an einer LED bringt die üblicherweise nicht zum leuchten und die Schaltung kann man recht niederohmig auslegen. Aber mit den o.g. Filter direkt am Pin solltest du auf jeden Fall schon weit in die sichere Zone kommen. Bisher gehst du mit der schlechtest möglichen Variante auf den Pin und es stört 'nur' gelegentlich, jede Maßnahme wird eine Verbesserung bringen. Gegen eine beliebig energiereiche Störung kann letztlich nichts helfen - man hat das schon zur Kriegsführung vorgeschlagen ... UC schrieb: > Müssen auch Ausgänge, die eine lange Leitung treiben, vor Überspannung > geschützt werden? Oder reichen da die Treiber-Transistoren, wie ich sie > auch habe? Ausgänge sind weit unkritischer und die Transistoren trennen die Leitung schon sehr gut vom Prozessor ab. Aber gänzlich unempfindlich gegen externe Einflüsse sind die auch nicht - wieder: ESD, aber auch eine Überlast.
mr. mo schrieb: > In der Nacht von warmen Tagen gibt es Probleme? Kann es vielleicht > ein > Problem mit Kondenswasser sein? > > Vorallem, da die Zentrale im Wintergarten untergebracht ist wo evtl. > auch Pflanzen stehen? Das ist mir vor 10 Jahren Jahren tatsächlich in einem Industrieprojekt in der Firma passiert. Entwickelte eine Prototyp uC Steuer Schaltung die dann in einem Geschlossen Elektronik Schutzgehäuse bei einem Kunden zum Testen installiert wurde. Der Kasten war nicht hermetisch abgeschlossen und Frischluft hatte tatsächlich Zugang wegen der Batteriebelüftung. Die Anlage war Solar gespeist. Nach einigen Wochen Betrieb fiel das Gerät ab März im Frühjahr regelmäßig zwei bis drei Mal per Woche einmal pro Nacht in den frühen Morgenstunden ein paar Stunden aus um dann später wenn die Sonne aufging wieder zu funktionieren. Es stellte sich heraus, daß die PIC Quarzschaltung durch Feuchtigkeit zum Schwingen aufhörte. Da ich in der FW keinen Gebrauch von der möglichen automatischen Clock Fail-Safe Umschaltung machte, stoppte der uC bis die Temperatur durch die Sonne die Kondensation wieder beseitigte und der Quarzoszillator von alleine wieder ansprang. Ich beschützte dann die Schaltung mit einem Silkon Schicht Überzug und das Problem kam nie wieder und es funktioniert wahrscheinlich heute noch. Ist also kein Jägerlatein:-)
:
Bearbeitet durch User
Wolfgang schrieb: > HildeK schrieb: >> Ja, im Prinzip schon. >> Ich würde die Dioden direkt an den Pin machen > > Da sind schon welche, sagt das Datenblatt vom ATmega8. Ja, deren Maximalstrom ist aber selten spezifiziert. Die waren übrigens in der alten Schaltung auch schon im Einsatz :-).
Danke für all eure Antworten! Ihr habt echt geholfen, habe viel gelernt. Zwei Fragen hätte ich noch: 1. Welche Diode nimmt man am besten als Schutzdiode? 2. Ist es eurer Meinung nach ausgeschlossen, dass es doch auch am Mikrocontroller lag? Ich hab damals ein paar beim örtlichen Conrad gekauft. Einer war dabei, der hat erst beim zweiten Mal das Programm übernommen... (Hab dann einen anderen genommen)
HildeK schrieb: > Aber mit den o.g. Filter direkt am Pin solltest du auf jeden Fall schon > weit in die sichere Zone kommen. Die vorgeschlagenen Filter filtern im Mikro- bis unteren Millisekundenbereich. Wenn die Software tatsächlich, wie angegeben, sauber auf 0,4s bzw. 1,6s lange Steuerpulse filtert, hätten kurze Störpulse keine Chance. Folglich muss es sich um ein ziemlich "böses Event" (Latch-up o.ä.) handeln, dass deutlich länger als das SW-Filter zum falschen Lesen des Eingangspegels führt. UC schrieb: > In Software werden die Eingänge alle 50ms abgetastet. Erst wenn 8 mal > (bzw. bei manchen Tasten sogar 32 mal) hintereindander ohne Lücke ein > 1-er detektiert wurde, wird eine Flanke erkannt. HildeK schrieb: > Wolfgang schrieb: >> HildeK schrieb: >>> Ja, im Prinzip schon. >>> Ich würde die Dioden direkt an den Pin machen >> >> Da sind schon welche, sagt das Datenblatt vom ATmega8. > > Ja, deren Maximalstrom ist aber selten spezifiziert. Dann dürfen die zusätzlichen Ableitdioden aber nicht direkt an den Pins sitzen, sondern es müssen zumindest Schottky-Dioden sein und/oder besser ein weiterer Widerstand Richtung Pin eingeschleift sein. Sonst weiss der Strom nicht, dass er durch die externen Dioden fließen soll. Außerdem muss über der Versorgungsspannung, da wo der Störstrom hingeleitet wird, ein Kondensator sitzen, der die Ladung aufnehmen kann.
Alles konzentriert sich auf die Hardware und es könnte doch ein Softwarefehler sein. Typisch wäre ein Timerinterrupt der irgendwo eine Non-Atomic Zuweisung verfälscht. Das kann dann zu sehr seltenen, schwer zu findenden Fehlern führen.
chris schrieb: > Alles konzentriert sich auf die Hardware ... Nein ;-) Wolfgang schrieb: > Wenn die Software tatsächlich, wie angegeben, ...
Wolfgang schrieb: > Dann dürfen die zusätzlichen Ableitdioden aber nicht direkt an den Pins > sitzen, sondern es müssen zumindest Schottky-Dioden sein und/oder besser > ein weiterer Widerstand Richtung Pin eingeschleift sein. Ja, völlig korrekt. Am besten noch einen zusätzlichen 1k zwischen den Dioden und dem Pin reinbauen. Im letzten geposteten Bild von "UC" zwischen Pin 6 und dem 4k7 PullDown.
npn schrieb:
In einem Thread bitte nur mit einem Nick posten, Stefan.
Mit deiner "Erfahrung" verwechselst du was. Der schleichende
Halbleitertod hat was mit "Betrieb ausserhalb der Spezifikation" zu tun.
Und muss man die Schaltung anpassen.
> Viele viele Fragen von Dir Lies dich erst einmal zu dem Thema ein. Wie gesagt ist das Thema zu umfangreich, um es im Rahmen dieses Diskussionsforums zu unterrichten. Wir haben Dir die richtigen Stichwörter genannt, damit du die passende Literatur finden kannst. Es macht keinen Sinn, wenn du aus deiner ursprünglichen Frage 20 weitere Fragen machst, die wiederum 100 neue Fragen aufwerfen werden. > Ist es eurer Meinung nach ausgeschlossen, dass es doch > auch am Mikrocontroller lag? Die Frage wurde längst beantwortet. Normalerweise funktionieren sie richtig, es gibt aber auch defekte, und sie können nach und nach kaputt gehen.
> In einem Thread bitte nur mit einem Nick posten, Stefan. Was siehst du, was ich nicht sehe? Ich habe nur einen Account, und diesen seit vielen Wochen nicht geändert. Ich sehe hier auch keinen anderen Stefan. > Mit deiner "Erfahrung" verwechselst du was. Nein > Der schleichende Halbleitertod hat was mit "Betrieb > ausserhalb der Spezifikation" zu tun. Ganz genau, und dieser Betrieb findet statt, wenn man Leitungen ohne Schutzschaltung heraus führt. Elektromagentische Feder induzieren zum Beispiel Spannungen, welche die 5V Signale überhöhen oder 0V Signal in den negativen Bereich bringen. Zum Beispiel 7V und -2V. Und jetzt schau nochmal in die Absolute maximum ratings...
Wie vergällt sich Deine Schaltung, wenn kurzzeitig, für ein paar ms, die Netzspsnnung ausfällt? Überwacht der AVR die 5V Versorgungsspannung? Ich gehe davon aus, daß die Fuse-Bits auf 4.5V gesetzt sind? Ein WDR Reset bei Programmstart ist empfehlenswert. Damit der uC definiert booten kann.
Ein AVR speichert auch die Ursache eines Resets z.B. ext Reset, Spannungsausfall usw. Könnte bei der Fehlersuche hilfreich sein. Nach meiner und anderer Meinung ist es momentan unklar, ob es ein Hard- und/oder ein Softwareproblem ist.
:
Bearbeitet durch User
Bernhard S. schrieb: > Wie vergällt sich Deine Schaltung, wenn kurzzeitig, für ein paar ms, die > Netzspsnnung ausfällt? > > Überwacht der AVR die 5V Versorgungsspannung? > > Ich gehe davon aus, daß die Fuse-Bits auf 4.5V gesetzt sind? > > Ein WDR Reset bei Programmstart ist empfehlenswert. Damit der uC > definiert booten kann. Brown-Out-Detection auf 4,5V läuft. Der Watchdog überwacht die Endlosschleife. Was genau bringt der Software-Reset am Programmanfang? Da wird ja eh initialisiert, also alles so gesetzt, wie man‘s braucht....
UC schrieb: > Was genau bringt der Software-Reset am Programmanfang? Sowas wurde vorgeschlagen? Glaube ich nicht.
Arbeitest Du mit Interrupts? Wenn ja.... Wie reagiert Dein Programm, wenn ein falscher Interrupt aufgerufen wird?
Bernhard S. schrieb: > Arbeitest Du mit Interrupts? > Wenn ja.... ...kann es dabei irgendwelche Probleme mit Semaphoren geben? Das Stichwort "Atomic" wurde ja schon genannt: gibt es aus dem Interrupt heraus (schreibende) Zugriffe auf 16 oder 32 Bit Variablen?
Arduino Fanboy D. schrieb: > UC schrieb: >> Was genau bringt der Software-Reset am Programmanfang? > Sowas wurde vorgeschlagen? > Glaube ich nicht. Bernhard S. schrieb: > Ein WDR Reset bei Programmstart ist empfehlenswert. Damit der uC > definiert booten kann.
Er meint damit, dass du beim Programmstart ein "ich lebe noch" Signal an den Watchdog senden sollst, damit er nicht zu früh einen unerwünschten Reset während der Initialisierungsphase auslöst.
Carl D. schrieb: > Nein, das war ZDF, nicht WDR. Stefanus F. schrieb: > Er meint damit, dass du beim Programmstart ein "ich lebe noch" Signal an > den Watchdog senden sollst, Carl mag das so meinen :-) - für mich ist die "Faktenlage" schlicht nicht ausreichend. Ich lese immer wieder mal mit und die Informationen des TO sind für mich schlicht zu spärlich. Ist aber wahrscheinlich nur mein Problem ... :-(
Dieter F. schrieb: > Carl D. schrieb: >> Nein, das war ZDF, nicht WDR. > > Stefanus F. schrieb: >> Er meint damit, dass du beim Programmstart ein "ich lebe noch" Signal an >> den Watchdog senden sollst, > > Carl mag das so meinen :-) - für mich ist die "Faktenlage" schlicht > nicht ausreichend. Ich lese immer wieder mal mit und die Informationen > des TO sind für mich schlicht zu spärlich. Ist aber wahrscheinlich nur > mein Problem ... :-( Ich hatte schon am 7.7. kurz nach Mitternacht angemerkt, daß > Einen Programmierfehler würde ich weitgehend ausschließen, > da es keine Unterschiede in der Bedienung an den Fehlertagen gab. etwas zu viel Optimismus beinhaltet.
UC schrieb: > Schutzdioden und Serienwiderstände gibt es nicht. Da liegt der Hund begraben. 15m Kabel ohne Serienwiderstand auf nen Porteingang ist fishing for problems.
OK, es wurde also doch vorgeschlagen... Aber der Sinn, sich mir nicht erschließt. Reset Quelle überwachen, ok. Bernhard S. schrieb: > Ein WDR Reset bei Programmstart ist empfehlenswert. Warum reicht der PowerOn Reset nicht?
> Da liegt der Hund begraben. > 15m Kabel ohne Serienwiderstand auf nen Porteingang ist fishing for > problems. Sagte ich oben bereits. Es liegt am Hund! mfG
>> Ein WDR Reset bei Programmstart ist empfehlenswert. > Warum reicht der PowerOn Reset nicht? Natürlich reicht ein Power-On Reset. Es soll NICHT ein zusätzlicher Reset durch den Watchdog ausgelöst werden, sondern der Watchdog Timeout-Counter soll beim Programmstart zurückgesetzt werden. Warum?: Normalerweise läuft ein µC Programm in einer endlosen Hauptschleife (bei Arduino: loop()), bei der jeder Durchlauf nur eine maximale Zeit dauern darf. Der Watchdog überwacht diese maximale Zeit mit seinem Counter, der in regelmäßigen Intervallen hochgezählt wird. Bei jedem Durchlauf der Hauptschleife wird dieser Counter per Software auf 0 zurück gesetzt, das ist der "WDR Reset". Wenn dieses Zurücksetzen für eine zu lange Zeitspanne ausbleibt, läuft der Watchdog Timer über und löst einen System Reset aus. Da beim Programmstart zusätzlich zur normalen Hauptschleife noch diverse Initialisierungen durchgeführt werden, kann der erste Watchdog Reset später stattfinden, als normal. Um zu Verhindern, dass der Watchdog dadurch ungewollt auslöst, kann man ihn zwischendurch nochmal extra zurück setzen. Zu dieser Initialisierung gehört zum Beispiel auch das Einschwingen des Quarz Oszillators, wofür (per Fuse) typischerweise einige zig Millisekunden reserviert sind. Deswegen macht es Sinn, schon gleich an Anfang des Programm den ersten Watchdog Reset durchzuführen. Zusammenfassung: - Watchdog Counter Reset != System Reset durch den Watchdog - Einschwingzeit des Quarz-Oszillator nicht vergessen - Zeit für weitere Initialisierungen nicht vegressen PS: In besonderen Situationen mag es anders sein. Wer mag, darf das dann gerne im Off-Topic Bereich durchkauen.
Stefanus F. schrieb: > Watchdog Counter Reset != System Reset durch den Watchdog Das war scheinbar das Mißverständnis. Einige (ich auch) dachten, du wolltest mit dem WDT einen Reset des µC auslösen. Aber so (Reset des Counters) macht das natürlich Sinn :-)
UC schrieb: > Ab welcher Leitungslänge würdet ihr eine > Schutzschaltung überhaupt am µC bauen? Sobald das Signal das Gerät verläßt. Den besten Schutz geben Optokoppler. Daher werden sie in der Industrie oft verwendet.
Stefanus F. schrieb: > Sie können daher sehr leicht zu positiver und negativer Überspannung > führen, und sie können auch leicht zu überhöhten Strömen führen. Dafür müssen erstmal ausreichende Feldstärken erreicht werden. Dank verdrillter und geschirmer Leitungen reicht da bestimmt nicht jeder Ping vom Smart-Phone. UC schrieb: > 1. Welche Diode nimmt man am besten als Schutzdiode? 1N4148, die können immerhin schon mal 400mA. Ohne die Störungen zu kennen, halten die zusammen mit zwei Widerständen und einem Kondensator etliches fern.
Eine Schutzdiode muß einen hohen Strompeak abkönnen, zumindest sollte es deutlich mehr sein als die (unbekannten) internen Portdioden vermutlich schon abkönnen. Die alte 1N4001 kann 30A peaken, das klingt für mich ok.
mr. mo schrieb: > In der Nacht von warmen Tagen gibt es Probleme? Kann es vielleicht ein > Problem mit Kondenswasser sein? Wenn tatsächlich Kondenswasser (mit gelöstem Dreck) ganz zwanglos den Taster überbrückt, würde das natürlich erklären, wieso die Störung durch das Softwarefilter ungeschoren durchkommt. Erste Maßnahmen wären: - höherer Betätigungsstrom - IP67-Taster - feuchte Luft darf nicht durch den Taster strömen (Kabeldurchführung dichten)
Hallo! Möchte euch nochmals für eure Hilfe danken und euch ein kleines Update geben: Habe die Schutzschaltung, die hier empfohlen wurde in die Leitungen zum -Glockentaster -Öffner und -Alarmkreis (nach wie vor überbrückt, nicht angeschlossen) eingebaut. ======================================================================== == Auch habe ich den Mikrocontroller ausgetauscht. Habe beim alten Mikrocontroller danach mit dem AVR8-Burn-O-Mat die Fuse-Bits ausgelesen: hfuse=C9 lfuse=3F Ich weiß nicht, wie ich damals auf diese Konfiguration gekommen bin... Der uC wird schließlich mit einem 3,6864MHz-Quarz betrieben, das definitiv nicht bei 8-16MHz liegt. Außerdem war bei "Start-up-time" "slowly rising power" angewählt und nicht "brown-out-detection enabled", obwohl die Brown-Out-Detection ja auf 4V eingeschaltet war. Könnte das so eine Fehlfunktion erklären? ======================================================================== == Bernhard S. schrieb: > Arbeitest Du mit Interrupts? > > Wenn ja.... > > Wie reagiert Dein Programm, wenn ein falscher Interrupt aufgerufen wird? Es wird ein Timer- und ein UART-Interrupt verwendet. Was meinst du mit falschem Interrupt? Ich habe sonst keine Interrupts programmiert... Stefanus F. schrieb: > Er meint damit, dass du beim Programmstart ein "ich lebe noch" Signal an > den Watchdog senden sollst, damit er nicht zu früh einen unerwünschten > Reset während der Initialisierungsphase auslöst. Der Watchdog wird erst unmittelbar vor der Endlosschleife aktiviert. Peter D. schrieb: > UC schrieb: >> Ab welcher Leitungslänge würdet ihr eine >> Schutzschaltung überhaupt am µC bauen? > > Sobald das Signal das Gerät verläßt. > Den besten Schutz geben Optokoppler. Daher werden sie in der Industrie > oft verwendet. Alles klar! Danke! batman schrieb: > Eine Schutzdiode muß einen hohen Strompeak abkönnen, zumindest sollte es > deutlich mehr sein als die (unbekannten) internen Portdioden vermutlich > schon abkönnen. Die alte 1N4001 kann 30A peaken, das klingt für mich ok. Habe 1N4007 genommen. Die hatte ich noch zu Hause. Zum uC Pin gibt es dann auch nochmal einen Serienwiderstand, somit sollte der Strom hauptsächlich durch die äußeren Dioden fließen. Wolfgang schrieb: > Wenn tatsächlich Kondenswasser (mit gelöstem Dreck) ganz zwanglos den > Taster überbrückt, würde das natürlich erklären, wieso die Störung durch > das Softwarefilter ungeschoren durchkommt. Allerdings passt nicht dazu, dass auch der Alarm losging. Denn dazu müsste der Kontakt aufgehen. Gleichzeitig gab es auch ein läuten. Dazu muss der Kontakt der Glockentaste allerdings schließen.
> Außerdem war bei "Start-up-time" "slowly rising power" angewählt > und nicht "brown-out-detection enabled", obwohl die > Brown-Out-Detection ja auf 4V eingeschaltet war. Das ist so gemeint: Wenn die minimale Start-up-time gewählt wird, muss zusätzlich ein Brown-Out Detektor verwendet werden. Bei allen anderen Start-up-times ist der Brown-Out-Detektor optional. Wobei ich auch schon die minimale Zeit ohne Brown-Ozt verwendet habe (mit 3 Akkuzellen und Ein-Schalter). Aber das ist halt vom Hersteller so nicht empfohlen. > Der Watchdog wird erst unmittelbar vor der Endlosschleife aktiviert. Ok gut gemeint, aber jetzt kommt der Haken: Wenn der Watchdog erstmal aktiviert ist, kann man ihn IMHO nicht mehr deaktivieren. Wenn du nun einen Reset machst, könnte während der Initialisierung schon das nächste "ich lebe noch Signal" überfällig werden, und dann bekommst du eine Reset-Schleife.
In einem 15ms-Watchdog-Intervall führt ein Mega meist über 100000 Instructions aus. Damit sollte man einen winzigen 8-Bitter normalerweise doch recht bequem initialisieren können.
batman schrieb: > In einem 15ms-Watchdog-Intervall führt ein Mega meist über 100000 > Instructions aus. Des wäre der erste 8-Bitter, der fast 2 Instruktionen pro Takt ausführt ;-) UC schrieb: > Der uC wird schließlich mit einem 3,6864MHz-Quarz betrieben
Mein Tipp: Protokollierung im EEPROM des µC, also mit Zeitstemel, wann welcher Alarm bzw. Aktion, ausgelöst wird, sonst sucht man(n) ewig nach der eigentlichen Ursache ^^
:
Bearbeitet durch User
> Damit sollte man einen winzigen 8-Bitter normalerweise > doch recht bequem initialisieren können. Je nach Fuses dauert alleine schon das Einschwingen des Quarzes (Start-up-time) länger als 15ms. Sobald die Initialisierung externe Kommunikation einschließt, zum Beispiel die Initialisierung eines Displays oder angetriebene Komponenten in eine Ausgangslage zu fahren, kommt man schnell auf mehre hundert Millisekunden.
Der AVR-Watchdog ist auch nicht wirklich dazu da, einen externen Gerätepark auf Fehler zu überwachen.
Danke für die Tipps. Ich denke allerdings nicht, dass der Wathdog für den Fehler zuständig ist. Es werden ja Melodien abgespielt. Würde das Programm bei der Initialisierung hängen, wäre das nicht möglich. Auch kann das Programm nicht in einer Schleife oder sowas festhängen... Bleibt noch die Frage, was dann passiert, wenn man die Fusebits für einen schnelleren Quarz setzt, als man verwendet...
UC schrieb: > Bleibt noch die Frage, was dann passiert, wenn man die Fusebits für > einen schnelleren Quarz setzt, als man verwendet... Man darf mit Fehlfunktionen rechnen. Das ist z.B. auch so, wenn man eine zöllige Mutter auf einen metrischen Bolzen dreht. Das kann ein bisschen halten, aber zuverlässig, ist was anderes. Auch die üblichen Festigkeitstabellen helfen da nicht weiter, da die Kombination außerhalb der Spezifikation ist.
>Bleibt noch die Frage, was dann passiert, wenn man die Fusebits für >einen schnelleren Quarz setzt, als man verwendet... Durch die Fuse-Bits werden intern u.a. die Rückkopplungseigenschaften der Quarz-Schwingschaltung geändert z.B. die Verstärkung. Nach meiner Meinung könnte es passieren, daß der Quarz nicht oder instabil schwingt. instabil: aussetzer oder sogar ein mehrfaches des Grundtones, konnte ich aber in der Praxis bei den ATmegas noch nicht nachweisen. Tipp: Solle durch ein versehentliches "verfusen" der Quarz nicht schwingen, dann einfach einen externen Generator z.B. 1Mhz an die Pins des XTAL anlegen und schon ist der µC mit etwas Glück wieder "ansprechbar" ^^
:
Bearbeitet durch User
Ich denke, die Schwingungen haben gepasst, denn die Programmierten Verzögerungen hatten die richtige Länge. Aber die Fehlfunktion könnte also möglicherweise dadurch verursacht gewesen sein?
************************************************************************ ************************************************************************ ************************************************************************ *************************** *************** U P D A T E ***************************************************** ************************************************************************ ************************************************************************ ****************** ************************************************************************ ********* BITTE DAS ERSTE POSTING LESEN.... Habe die neue Schutzschaltung (Kondensator, Schutzdioden nach + und GND, Serienwiderstand vor und nach der Schutzschaltung, Pulldown-Widerstand) im Juli eingebaut. Gleichzeitig tauschte ich auch den ATmega8 aus (frisch gekauft, gleich das richtige Programm aufgespielt und verifiziert). Vergangenen Donnerstag gab es wieder die gleiche Prozedur. (siehe Post 1) Ich weiß nicht, wie das sein kann. Es ist jetzt mindestens das dritte Mal Donnerstag spät am Abend. (Beim ersten Vorkommnis in 2017 weiß ich den Tag nicht mehr...) Das kann doch kein Programmierfehler sein!? Der ATmega8 hat keinerlei Zeitinformation. Kein RTC, keine Datums- oder Zeiteinstellung, nichts. Habe mit einer herkömmlichen Klingel versucht, die Inneneinheit zu stören. Es hat nicht reagiert. Auch bei Gewittern gab es nach wie vor nie Fehlfunktionen. Bin für alle Ideen dankbar!
Hallo, Dein Hund führt neue Experimente mit Skalarwellen durch und kann erste Erfolge verzeichnen. Wirklich ein schlaues Kerlchen! Mfg
So. Jetzt stellst Du die Frage einfach mal vernünftig und unter Angabe aller Fakten in hinreichend detaillierter Form. Nicht diese, von "kann doch nicht sein" unterbrochenen Salamischeibchen. Programm, Schaltung, Aufbau etc., Fotos, Entfernungsangaben, Geländeskizze, verwendete Kabel, Umgebungsbedingungen, Maschinen, insbesondere vorhanden Geräte mit hoher Leistung, Netztyp, etcpp. Sonst lesen wir das noch die nächsten 5 Jahre und soviel Unterhaltungswert hat das auch nicht.
SCNR Dann finde und bestrafe den Kerl, der jeden Donnerstag dort sehr feste auf den Klingelknopf draufdrückt! Siehe Bildanhang: Ich gehe mal davon aus das die rote "5V Versorgung" eine lange Leitung ist. Nicht wirklich niederohmig, ausserdem induktiv. Womöglich verrotten auch so langsam deren Klemmstellen, also noch etwas hochohmiger. Jetzt betätigt jemand (der böse Hund?) die "Glockentaste", während des Aufladens des rechten Kondensators reißt es die 5V brutal herunter, auch abhängig von der Kapazität des linken Kondensators...und schon folgt auch eine Alarmauslösung... Die Schaltung ist Käse. HTH
>Gleichzeitig tauschte ich auch den ATmega8 aus (frisch gekauft, gleich das
richtige Programm aufgespielt und verifiziert).
Nach dreimaligem Austauschen des Mikrocontrollers sollte es dir endlich
bewusst werden, dass dieser korrekt arbeitet und du ihm nicht einfach
die Schuld in die Schuhe schieben kannst.
2 Cent schrieb: > Jetzt betätigt jemand (der böse Hund?) die "Glockentaste", während des > Aufladens des rechten Kondensators reißt es die 5V brutal herunter, auch > abhängig von der Kapazität des linken Kondensators...und schon folgt > auch eine Alarmauslösung... Die Schaltung ist Käse. Auch sattsam bekannt als Pollin-Board Effekt. Beitrag "Pollin AVR Board Fehler beim drücken der Taster / Qualität der Bauteile"
Bitte 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.