Sleep Mode und Uart beim ATmega

Nein, so ist das nicht. Du kannst jeden Sleep-Mode verwenden, die UART ist nur nicht in der Lage, das Gerät aus den tieferen Schlaf-Modi aufzuwecken.

Diese Einschränkung kann man sehr leicht umgehen, indem man beim Einschlafen die UART deaktiviert und statt dessen den PinChange-Interrupt für den RxD-Pin aktiviert.

1) Warten bis auch das letzte Bit den Sendepuffer verlassen hat (das kann bis zu zwei Wortlängen dauern!). 2) UART deaktivieren. 3) PinChange-Interrupt aktivieren 4) einschlafen.

Nach dem Aufwachen PinChange-Int ausknipsen und UART neu initialisieren.

Das erste Datenwort (dessen Startbit effektiv zum Aufwachen geführt hat) wird sie allerdings nicht oder zumindest nicht fehlerfrei empfangen können, allenfalls bei sehr niedrigen Bitraten kann das gelingen. Das verwendete Kommunikationsprotokoll muß auf diesen Sachverhalt Rücksicht nehmen.

Ok, das ist eh nicht mein Probem. Der Prozessor wird über ein anderes Signal geweckt und soll dann eine Kommunikation aufbauen.

Ist klar, aber hier sowieso nicht nötig.

Ist auch klar...

ist klar

ist sowieso aktiv, aber auf nem anderen Pin

klar

Uart wird neu initialisiert

Wie schon geschrieben: ich will gar nicht auf ein empfangenes Datenwort reagieren. Mein Problem ist, dass der Uart nach dem Auswecken nicht mehr sendet.

Gruß

Stefan

Dann hast du wahrscheinlich irgendeinen der Punkte 1) bis 4) nicht korrekt umgesetzt.

Denkbar wäre aber natürlich auch ein Fehler an ganz anderer Stelle, von dem das Nicht-Senden-Können nach dem Aufwachen nur ein Nebeneffekt ist. Z.B. weil das ganze System deswegen abgekackt ist. Sowas in der Art vermute ich ganz stark...

Konkreteres kann man dazu nur sagen, wenn du Code sehen läßt. Ich kann dir jedenfalls garantieren, daß die UART sehr wohl auch nach dem Aufwachen aus jeglichem Schlafmodus einschließlich des tiefsten "PowerDown" senden kann. Das mach' ich nämlich in fast jedem zweiten Projekt. (Debugausgabe via UART und irgendeinen der Schlafmodi verwenden)

Am 16.10.2012 18:07, schrieb Heiko Nocon:

Ok, gut zu wissen. Ich hab das Projekt nicht selbst bearbeitet sondern einem Mitarbeiter übergeben, der schon am Verzweifeln war und dem nur hin und wieder über die Schulter geguckt und kluge Ratschläge von mir gegeben ;-)

Wir haben das jetzt gelöst, indem wir den Prozessor über den Watchdog in den Reset fahren. Eine Lösung, die mir momentan auch noch aus anderen Gründen gefällt, d.h. auch wenn wir es anders hinbekommen würden, würden wir den Reset drin lassen.

Gruß

Stefan

Ähm...

Das ist wohl ein mehr als deutliches Zeichen, daß es da an anderer Stelle ganz gewaltig knirscht, wie ich es schon vermutet hatte...

Ich habe noch nie die Notwendigkeit gesehen, den Watchdog überhaupt zu verwenden.

OK, eine einzige Ausnahme: Ein extrem zeitkritisches Ding ganz am Rande der Möglichkeiten der AVRs. Da waren einfach nicht mehr genug Taktzyklen für einen Timeout-Zähler frei, der war aber unbedingt nötig, weil die entsprechende Situation von vornherein zur Spezifikation gehörte.

Diesen Zähler habe ich dann durch den Watchdog ersetzt. Die einzig sinnvolle Anwendung für das Teil. Zum Beheben von Programmfehlern sollte man hingegen lieber seinen Kopf benutzen, nicht den Watchdog...

Das ist klar. Ich will den Watchdog auch nicht benutzen, um Programmabstürze abzufangen, sondern um gezielt einen Reset auszulösen wenn ein bestimmtes Ereignis eintritt.

Dadurch startet der Rechner neu durch und führt nach der Initialisierung einmalig die gewünschte serielle Kommunikation aus.

Danach geht er in eine Endlosschleife die mit einem Sleep abgeschlossen wird. Aus dem Sleep wird der Prozessor durch einen PCINT und durch Timer2 mit 32 kHz Quarz geweckt, aber er muss dann nicht die oben genannte serielle Kommunikation ausführen.

Gruß

Stefan

Full ACK, aber sowas von...

...hab noch niemals nie nich in >40a und Hunderten von Projekten einen Watchdog benutzt. Watchdogs sind für Dummies um ein verkacktes Proggi zu sanieren. Kenner und Könner brauchen das nicht. Nie nich!

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! 
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf 

Wolfgang Allinger schrieb:

Du redest mal wieder einen gequirlten Mist! Wahrscheinlich weisst du nicht mal um was es geht.

Wann wirst du es selber mal?

Am 17.10.2012 09:00, schrieb Jens Fittig:

Nein er hat völlig recht. Wenn hier einer gequirlten Mist schreibt, dann du. Und ich bin mir sicher, dass Wolfgang in einer ganz anderen Liga spielt als du.

Einen Watchdog setzt man ein, wenn das Programm 100% zuverlässig läuft und man dann eine zusätzlich Sicherheit gegen unvorhergesehene Ereignisse einbauen will / soll. Man darf niemals den Watchdog verwenden, um vermurkste Programme zu retten.

In meinem Anwendungsfall geht es aber um etwas anderes. Ich will unter bestimmten Bedingungen einen Reset auslösen und missbrauche dazu den Watchdog. Wenn es statt dessen einen Befehl "reset" gäbe, würde ich den verwenden.

Gruß

Stefan

Am 16.10.2012 19:46, schrieb Heiko Nocon:

Stimmt schon.

Ich habe einige zig 8031 Systeme als Produktionsdatenerfassungssysteme in verschiedenen Firmen laufen. Die Dinger müssen 365 Tage im Jahr zuverlässig laufen. Da habe ich zusätzlich einen Max1232 (?) als Watchdog und Burn-Out Detektor eingebaut.

Die Software läuft aber auch ohne den Watchdog einwandfrei. Ist nur eine zusätzliche Sicherheit. Die Dinger laufen teiweise seit mehr als 15 Jahren einwandfrei und ohne Ausfall im Dauerbetrieb in Industrieumgebung.

Gruß

Stefan

Am 17.10.2012 12:19, schrieb Stefan:

Müsste man nicht über Assembler zum Reset- Vektor springen können?

Ja, den 1232 gibt es aber auch mit diversen anderen Praefixen von x Herstellern.

Micha

Am 17.10.2012 13:20, schrieb Heiko Lechner:

Der Watchdog-Reset setzt üblicherweise auch die Peripherie in einen definierten Zustand, ein Sprung zum Reset-Vektor tut dies nicht.

Stefan schrieb:

^^^^^^^^^^^^^^^^

um diesn idiotischen Absatz ging es in meiner Meinung dazu!

Eben nicht! Wer lesen kann, ist im Vorteil. Und wer es dann noch versteht, hat gewonnen. Du hast verloren!

Du und der Allinger!

Das kannst du nicht beurteilen.

Also doch Watchdog. Was der Wolfgang aber vehement mit aller Kraft ausschliesst! Sowas ist nur was für Dummies ....

Das hat auch niemand behauptet!

Lerne lesen und vertshen bevor du konterst!

Kann man, verwende ich in einem Bootloader. Da wird aber vorher immer ein Reset gemacht und der Bootloader ausschliesslich via BOOTRST-Fuse angesprungen.

Kann man prinzipiell auch mit der Hand am Arm alles per Software initialisieren. Ist halt recht aufwaendig, weil man ziemlich viel anfassen muss. Zu verifizieren, dass man nichts uebersehen hat und dass das so mit jedem moeglichen Ausgangszustand funktionieren wird ist quasi auch unmoeglich.

Micha

Natürlich kann man das, nur wird es am Zustand der Hardware nichts ändern.

Am 17.10.2012 13:37, schrieb Michael Baeuerle:

Ja, hab ich schon mal schmerzlich feststellen müssen. Bei dem von Maxim musste ich keinen zusätzlichen 100nF spendieren ;-)

Na wenn Du das sagst, wirds wohl stimmen.

Gerber als Hohlkörper. Was hast Du an meiner Sig nicht verstanden?

Setzen, SECHS, Hundertmal auswendig lernen:

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! 
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf 

Aber es ist (m)ein guter Stil, bei einem Reset per SW alles in den gewünschten Zustand incl. Register und IR System zu setzen. Egal was das Datenblatt (nicht) erzählt. Es gibt häufig Register oder einzelne Bits, die undefiniert oder zufällig sind. Besonders beliebt sind undefinierte UART Register Zustände. Wenn da was quer läuft, landest Du manchmal in der Rue de Kack! Aber so ein Fehler ist umgekehrt proportionl zum Abstand des eigenen Labors und dem Kunden.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! 
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf