Hallo zusammen, bis ich gemerkt hatte, dass ich einen Programmierfehler gemacht habe, dacht ich, dass mein Programmiergerät defekt ist. Dann baute ich mir ein Testgerät für den 2313 mit seriellem Anschluss. Mit einigen Printbefehlen im Programm stellte ich fest, dass die falsch programmierten 2313 nach dem !Sleep-Befehl einschlafen und nicht wieder aufwachen. Gibt es eine Möglichkeit, sie wieder programmieren zu können? Vielen Dank Klaus-Peter
SLEEP hat nichts mit der Programmierbarkeit zu tun, da bei RESET kein Programmcode ausgeführt wird.
das hat bestimmt nichts mit deine Programmierung zu tun. Dann wenn der µC Programmiert wird ist er im Reset status - da läuft kein Programm.
Ich hatte schon mal das Programm mit !Sleep am laufen. Es ist auch gelaufen und wieder aufgewacht. Was ich daran geändert habe weis ich dummerweise nicht mehr. Seither kann ich einen neuen 2313 programmieren. Ich habe viele der Befehle getestet und er lies sich immer wieder programmieren. Erst als ich den Befehl !Sleep einfügte war es anschliesend aus. Das Programm läuft bis zu diesem Bfehl, bleibt stehen und nichts geht mehr.
Nochmal: Das alles hat nichts mit der Programmierung über ISP zu tun! Wenn der Programmer auf den µC zugreift, dann resettet er als erstes den µC. Der arbeitet dann nicht dein Programm ab. Und nein: dagegen kann er sich auch nicht wehren.
Karl Heinz Buchegger schrieb: > Und nein: dagegen kann er > sich auch nicht wehren. doch, Reset Disable (gut das geht nicht per Software)
Karl Heinz Buchegger schrieb: > Nochmal: Das alles hat nichts mit der Programmierung über ISP zu tun! Alles schön und gut, aber was kann ich tun um die 2313 wieder programmieren zu könne? Sie sind ja nicht kaputt, das Programm läuft ja nach einem Reset wider bis zum !Sleep
Peter II schrieb: > Karl Heinz Buchegger schrieb: >> Und nein: dagegen kann er >> sich auch nicht wehren. > > doch, Reset Disable (gut das geht nicht per Software) Ja, und wenn die Taktquelle verfust ist, geht auch nichts mehr. Aber davon gehe ich bei der Beschreibung im Eröffnungsposting nicht aus.
Klaus-Peter schrieb: > Karl Heinz Buchegger schrieb: >> Nochmal: Das alles hat nichts mit der Programmierung über ISP zu tun! > > Alles schön und gut, aber was kann ich tun um die 2313 wieder > programmieren zu könne? Nun mal langsam. Erst mal ist deine Fehlerbeschreibung mehrdeutig. Kannst du ein neues Programm in deine 2313 brennen oder kannst du das nicht? Du musst die beiden Dinge trennen: Das eine ist das Brennen eines neuen Programmes in den 2313. Das hat nichts damit zu tun, welches Programm gerade auf dem 2313 läuft oder welches Programm du in den 2313 brennen willst. Das andere ist, was dann dieses Programm macht. Da kommt dann dein Sleep ins Spiel. Wenn das dein Problem ist, dann hast du einfach nur einen Programmfehler, den du beheben musst. Dieser Fall hat aber wiederrum nichts mit deinem Programmiergerät zu tun.
Also Karl-Heinz, ich bewundere Deinen Umgang mit bornierten Fragestellern. Hätte der TO seinen Code eingestellt, hätte ihm längst jemand sagen können, wo's hakt. Denn genau das wird's sein, solange er nicht an den Fuses rumpfuscht und den µC damit himmelt, ist einfach nur der Quellcode fehlerhaft.
Karl Heinz Buchegger schrieb: > Das andere ist, was dann dieses Programm macht. Da kommt dann dein Sleep > ins Spiel. Wenn das dein Problem ist, dann hast du einfach nur einen > Programmfehler, den du beheben musst. > Dieser Fall hat aber wiederrum nichts mit deinem Programmiergerät zu > tun. Mein Programmiergerät ist in Ordnung, ich kann damit ein neues IC programmieren. Wenn ein Programm ohne diesen Befehl geladen ist, lasst es sich auch wieder neu programmieren. Nur wenn dieser !Sleep-Befehl drin ist, geht nichts mehr. Ich habe nichts mit den Fsebits gemacht. Aber bei all den Versuchen "schlafen" jetzt schon 6 ATTiny2313 bis ich heraus gefunden habe wann sie das machen.
Zeig doch einfach mal dein Programm was ist den ein "!Sleep" Befehl? Versuchsweise kannst du den ResetPin mal dauerhaft auf GND legen und schauen ob dann der Programmer wieder darauf zugreifen kann.
Wenn du mit dem Programmer nicht mehr zugreifen kannst, solltest du dich mit dem Gedanken vertraut machen, dass beim Programmiervorgang selbst irgendetwas schief gegangen ist. Du suchst an der falschen Stelle. Selbst mit dem größten Unsinn kannst du deinen 2313 nicht so programmieren, dass du mit dem Programmer nicht mehr rann kannst. (Du benutzt aber schon einen richtigen ISP Programmer und nicht zb einen Bootloader?)
Läubi .. schrieb: > Versuchsweise kannst du den ResetPin mal dauerhaft auf GND legen und > schauen ob dann der Programmer wieder darauf zugreifen kann. Das mit dem Dauerreset kann ich mal probieren. Vielen Dank für Eure Anteilname. Ich muss jetzt weg, arbeiten. Bin morgen Abend wieder im Netz.
Kontaktprobleme oder zu hohe ISP-Geschwindigkeit kann die Fuses so
verstellen, dass Du Dich aussperrst. Versuchsweise kannst Du einen Takt
>1Mhz an XTAL1 anschließen und gucken, ob Du dann wieder an den
Controller kommst.
Karl Heinz Buchegger schrieb: > Du suchst an der falschen Stelle. Selbst mit dem größten Unsinn kannst > du deinen 2313 nicht so programmieren, dass du mit dem Programmer nicht > mehr rann kannst. Es tät' noch die Möglichkeit des Setzens der Fuses über ein .elf-File geben, und damit sozusagen die Himmelung bei jedem Programmiervorgang. Nur statt mit Info's rauszurücken, Typ und SW des Programmierers, Umgebung, Board usw., muss man wieder alles aus der Nase des geschätzten Fragenden ziehen.
Angehängte Dateien:
-
Sleep_Test.jpg
180 KB
MWS schrieb: > Nur statt mit Info's rauszurücken, Typ und SW des Programmierers, > Umgebung, Board usw., muss man wieder alles aus der Nase des geschätzten > Fragenden ziehen. Infos: Programmiergerät:BASCOM USB ISP Programmer, mit dem ich schon die unterschiedlichsten ATMEL ohne Probleme geladen habe. Sowohl auf dem Testboard von Roland Walter als auch auf meinem Eigenbau. Testboard:Eigenbau, auf dem ich schon verschiedene ATiny2313 programmiert habe und die alle ohne Probleme laufen und sich auch wieder neu laden lassen. Programm:Im Anhang
Angehängte Dateien:
-
avr.JPG
64 KB
Welcher fehler wird den angezeigt ???? wenn der fehler angezeigt wird dann haste warscheinlich einen von den ISP pinnen an deinen attiny2313 falsch beschaltet oder noch was angschlossen was zu niederohming ist. Mfg Kannnix
Neueste Erkenntnisse: Die Nummer mit dem Dauaerreset beim Starten hat funktioniert, aber nur einmal. Nachdem ich ein weiteres Mal das Sleep-Programm geladen hatte kam die Meldung:Difference at000003. Ein weiterer Versuch brachte die Meldung: could not identify chip with ID:ffffff. Es lies sich nicht mehr löschen. Jetzt geht mit diesem "2313 gar nichts mehr. Ich etwas vorsichtiger geworden, ich hab es nur noch mit zwei IC's versucht, mit dem gleichen Ergebnis.
Kannnix schrieb: > wenn der fehler angezeigt wird dann haste warscheinlich einen von den > ISP pinnen an deinen attiny2313 falsch beschaltet oder noch was > angschlossen was zu niederohming ist. Außer dem Ziel-IC ist nichts angeschlossen. Und alle anderen Programme die ich lade laufen wie auch das gepostete ohne !Sleep. Wenn ich das lade, läuft es bis zum Befehl !Sleep und bleibt stehen. Wenn ich mit INT0 "Stellen" auslöse kommen erst einige Hiroglyphen und dann läuft das Programm weiter bis zum nächsten !Sleep. Aber neu laden lässt es sich dann nicht mehr. Noch was zu den Printbefehlen: Damit kann ich im Terminalprogramm von Bascom verfolgen was passiert, oder wo er hängen bleibt. Die fallen dann im Original weg. Für die mangelhafte Information am Anfang bitte ich um Verzeihung, ich bin nicht sehr erfahren im Umgang mit Foren. Bis jetzt haben mir einschlägige Literatur und die Datenblätter weiter geholfen.
Zeig deine Beschaltung und ein Bild vom Aufbau. Code und Fehlermeldungen braucht man auch nicht als Bild anzuhängen.
Klaus-Peter schrieb: > Außer dem Ziel-IC ist nichts angeschlossen. Und alle anderen Programme > die ich lade laufen wie auch das gepostete ohne !Sleep. Wenn ich das > lade, läuft es bis zum Befehl !Sleep und bleibt stehen. Du hast, jedenfalls was vom Screenshot zu sehen ist, keine Stackwerte definiert. Das ist einer der Fehler-Klassiker. Es ist auf dem Bild auch kein Sleep zu sehen, deshalb wie schon geraten, als Datei anhängen. Nur - das Programm kann so falsch sein wie es nur will, deswegen funktioniert die Programmierung immer wieder, außer: - Kontaktprobleme - störende Bauteile an den Programmierpins - falsches Setzen der Fuses - in extremen Fällen Verfusen des µCs wegen Punkt 1 oder 2
Angehängte Dateien:
-
Sleep_test2.jpg
130 KB
MWS schrieb: > Du hast, jedenfalls was vom Screenshot zu sehen ist, keine Stackwerte > definiert. Das ist einer der Fehler-Klassiker. Es ist auf dem Bild auch > kein Sleep zu sehen, deshalb wie schon geraten, als Datei anhängen. Sorry, ich hab gar nicht gemerkt, dass da noch einiges fehlt. So wie es dargestellt ist, läuft das Programm einwandfrei und das IC lässt sich auch immer wieder neu laden. Nur wenn der !Sleep-Befehl freigeschaltet ist kann ich das Programm laden und es läuft bis zum !Sleep. Mit einem Hardwarerest startet das Programm auch wieder. Mit dem INT0 zeigt das Terminalprogramm etwa 10 Hiroglyphen und dann wider "schlafen". ImScreenshot Sleep_test4 ist der Terminalausdruck des Programms mit !Sleep, gestartet mit INT0.
HI >noch ein screenshot >noch einer Das ist keine Salami, die man scheibchenweise serviert. Ist es so schwer, dein Programm anzuhängen? MfG Spess
Klaus-Peter schrieb: > noch ein screenshot Will hier keiner... - Denn wie soll man damit das Programm in Bascom laden und debuggen? Du sollst den Quelltext als Textdatei anhängen. ...
spess53 schrieb: > Das ist keine Salami, die man scheibchenweise serviert. Ist es so > schwer, dein Programm anzuhängen? Leute ich bin 70 und froh, dass ich da überhaupt durchblicke. Meine Versuche, alle auf einmal anzuhängen haben nichts gebracht. Wahrscheinlich habe ich nicht lange genug gewartet bis das Bild angehängt war und ein Wartesignal habe ich auch nicht entdeckt, sorry!
Peter, bitte hänge die Datei mit dem Namen "Sleep_Test.bas" an, die sich im Ordner "C:\Users\Peter\1-Minutentakt" befindet. Ähhh, ich bin auch schon lange keine 60 mehr... ...
Hannes Lux schrieb: > Will hier keiner... - Denn wie soll man damit das Programm in Bascom > laden und debuggen? Du sollst den Quelltext als Textdatei anhängen. Ich versuchs mal in WORD.
HI Nimm einfach deine 'Sleep_Test.bas' als Anhang. MfG spess
Klaus-Peter schrieb: > Nur wenn der !Sleep-Befehl freigeschaltet > ist kann ich das Programm laden und es läuft bis zum !Sleep. Mit einem > Hardwarerest startet das Programm auch wieder. Das ist aber jetzt was anderes als "schläft und lässt sich nicht mehr programmieren" Dein Programm ist einfach falsch, nix weiter. Nur wenn Du weiter die ignorierst, die Dir helfen sollen, dann wirst Du das wohl selbst austüfteln dürfen. Kein Mensch will Screenshots, wenn's eine Textdatei verfügbar ist.
Hannes Lux schrieb: > Peter, bitte hänge die Datei mit dem Namen "Sleep_Test.bas" an, die sich > im Ordner "C:\Users\Peter\1-Minutentakt" befindet. ok, das war mal ein guter Rat,danke
MWS schrieb: > Das ist aber jetzt was anderes als "schläft und lässt sich nicht mehr > programmieren" > Dein Programm ist einfach falsch, nix weiter. Nur wenn Du weiter die > ignorierst, die Dir helfen sollen, dann wirst Du das wohl selbst > austüfteln dürfen. Toll!
Simon K. schrieb: > ... Code und Fehlermeldungen braucht man auch nicht als Bild anzuhängen. gelesen ?
Klaus-Peter schrieb: > Toll! War nur 'n Hinweis, wie's hier so läuft. Aber wie ich seh' gab's ja jetzt endlich 'ne positive Reaktion :D
1 | Gimsk = &B01100000 'Bit6_ext.INT0 enable;Bit5_Pinchange Enable ' |
2 | Pcmsk = &B00000001 'Bit0_PCINT0 (PB0) ausgewählt als Aufwecksignal |
Du hast Int0 und PCI aktiviert, aber nur für Int0 einen Int-Handler
1 | On Timer1 Ontimer1 'Timer1-Overflow-Interrupt-Routine |
2 | On Int0 Stellen 'Zum Überbrücken der Zeitschleife |
Deine Warteschleifen gefallen mir auch nicht. Das hat aber alles nichts mit dem ISP-Problem zu tun. ...
Du hast das Datenblatt gelesen ? "Standby mode is only recommended for use with external crystals or resonators." Und wenn Du PCInts nutzen willst, musst Du das PCMSK-Register setzen. Ohne wacht da nix auf. Wenn's denn über den PCInt aufwachen soll. Ansonsten etwas durcheinander das Ganze.
Hannes Lux schrieb: > Du hast Int0 und PCI aktiviert, aber nur für Int0 einen Int-Handler > On Timer1 Ontimer1 'Timer1-Overflow-Interrupt-Routine > On Int0 Stellen 'Zum Überbrücken der Zeitschleife > > Deine Warteschleifen gefallen mir auch nicht. Die Warteschleifen und die Printbefehle sind nur zum beobachten. Wen alles richtig läuft fallen die alle raus. Das mit dem Timer1 zum Aufwecken hab ich so gemacht, weil der länger zählt bis er überläuft. Ob und wie das funktioniert wollte ich ja testen. Dazu aber muss ich ihn ja erst mal Schlafen legen. Und das ist die Krux, weil danach nichts mehr geht.
MWS schrieb: > Du hast das Datenblatt gelesen ? > "Standby mode is only recommended for use with external crystals or > resonators." ich hab den Idlemode gewählt.Mcucr = &B01100000
Klaus-Peter schrieb: > ich hab den Idlemode gewählt.Mcucr = &B01100000 Nein, das ist Standby und beiläufig ist die Binär-Schreibweise ein Graus. Das geht besser.
MWS schrieb: > Nein, das ist Standby und beiläufig ist die Binär-Schreibweise ein > Graus. > Das geht besser. ok,Dum hast recht, aber das ändert nichts an der Tatsache, dass egal wie ich MCUCR einstelle, nach dem Laden mit !Sleep keine weiteren Ladungen möglich sind. Für mich ist der Binärcode übersichtlicher.
MWS schrieb: > Und wenn Du PCInts nutzen willst, musst Du das PCMSK-Register setzen. Ich dachte, wenn ich Pcmsk = &B00000001 setze, dann wird PB0 (PCINT0)angesprochen. Was fehlt da noch?
Klaus-Peter schrieb: > Für mich ist der Binärcode übersichtlicher. Wäre es das, hättest Du den Fehler nicht gemacht. Es gibt für Deinen Zweck den Befehl: POWER IDLE
MWS schrieb: > Klaus-Peter schrieb: >> ich hab den Idlemode gewählt.Mcucr = &B01100000 > > Nein, das ist Standby Weder noch, das ist der zweite Power-Down-Mode... ;-) >und beiläufig ist die Binär-Schreibweise ein > Graus. > Das geht besser. Stimmt: Mcucr = Bits(sm1,se) 'Sleep im Mode Power-Down voreinstellen ...
Klaus-Peter schrieb: > Was fehlt da noch? Eigentlich gar nix, es ist was zuviel... Pinchange-Int und Ext-Int (im Level-Mode) sind Zweierlei. Du brauchst (wenn überhaupt) nur einen von Beiden. Aber auch Dein ganzes Konzept ist sehr diffus. So richtig verstehe ich nicht, was das werden soll. ...
Klaus-Peter schrieb: > Ich dachte, wenn ich Pcmsk = &B00000001 setze, dann wird PB0 > (PCINT0)angesprochen. Was fehlt da noch? Ja, musst es aber auch in Deinen Code reinschreiben. Stacks und Frame fehlt immer noch.
MWS schrieb: > Stacks und Frame fehlt immer noch. Nimmt dann nicht der Compiler die voreingestellten Werte? ...
Hannes Lux schrieb: >>und beiläufig ist die Binär-Schreibweise ein >> Graus. >> Das geht besser. > > Stimmt: > > Mcucr = Bits(sm1,se) 'Sleep im Mode Power-Down voreinstellen Ich seh schon, da muss ich noch einiges dazu lernen. Allerdings habe ich für meine Brennwertterme von Herrmann (vielleicht kennt die ja einer und auch den Murks) eine neue Steuerung gebaut mit einem ATMEGA8 und einen Tempomat für meinen VW Bus auch mit dem MEGA8. Beide funktioniren einwandfrei. Auch das leidige Sleepprogramm läuft auf einem MEGA88 anstandslos. Erst als ich versuchte es auf den 2313 umzuschreiben klemmte es.
Hannes Lux schrieb: > Aber auch Dein ganzes Konzept ist sehr diffus. So richtig verstehe ich > nicht, was das werden soll. Ich hab eine Slaveuhr oder wie man das nennt. Die braucht alle Minute einen Impuls von 12V, allerdings jedesmal mit anderer Polung. Sie soll mit Batterie laufen und das tut sie auch. Aber ich wollte Strom sparen. Die Ausgänge PB2,PB3 schalten die Polung um umd dann bringt PB4 die Spannung, alles über Relais. Die Zeiten sind freilich viel zu lang. Sie sind es nur zum besseren Beobachten.
Hannes Lux schrieb: > MWS schrieb: > Nimmt dann nicht der Compiler die voreingestellten Werte? Ja, aber die Voreinstellung ist recht klein, wenn ISRs drin sind, dann ist das zuwenig
MWS schrieb: > Es gibt für Deinen Zweck den Befehl: POWER IDLE In meinem ersten Bascomprogramm (Demo) hatte ich eine komplette Liste aller Befehle.Um nicht durcheinander zu kommen habe ich es entfernt, als ich mir die Vollversion gekauft hatte. Abgesehen davon, dass ich mich erst wieder darin zurecht finden musste fand ich diese Liste nicht mehr.
MWS schrieb: > wenn ISRs drin sind, dann > ist das zuwenig Jaaaa, stimmt ja, diese riesigen Push/Pop-Orgien... Also geht's jetzt nicht nur um die Einträge, sondern vor allem auch um die richtige Anpassung der Einträge (viel HW-Stack wegen der Registersicherung, wenig SW-Stack wegen geringer Parameterübergabe und wenig Framesize, da keine Funktionen rechnen müssen...). Nunja, ich werkele meist in ASM, in Bascom nur ganz selten. ...
Hannes Lux schrieb: > Stimmt: > > Mcucr = Bits(sm1,se) 'Sleep im Mode Power-Down voreinstellen Also bei meinem Tiny2313 Datenblatt entspricht SM1=1 SM0=0 dem Standby Mode, was verwendest Du für ein DB ?
MWS schrieb: > Ja, aber die Voreinstellung ist recht klein, wenn ISRs drin sind, dann > ist das zuwenig HW Stack = 40; Softstack = 16; Framesize = 32. Wie erkenne ich wie groß die Werte mindestens sein müssen?
Hannes Lux schrieb: > Jaaaa, stimmt ja, diese riesigen Push/Pop-Orgien... > > Also geht's jetzt nicht nur um die Einträge, sondern vor allem auch um > die richtige Anpassung der Einträge (viel HW-Stack wegen der > Registersicherung, wenig SW-Stack wegen geringer Parameterübergabe und > wenig Framesize, da keine Funktionen rechnen müssen...). Und das alles nur wegen des !Sleep? Denn ohne läuft das Programm ja. Übrigens, der Interupt, der jetzt noch mit dem TIMER1 ausgelöst werden soll wird nachher von einem DTF-Modul gesendet. Das ist dann das nächste Problem.
Klaus-Peter schrieb: > Ich hab eine Slaveuhr Kenne ich als Nebenuhr, das ist aber über 40 Jahre her... ;-) > oder wie man das nennt. Die braucht alle Minute > einen Impuls von 12V, allerdings jedesmal mit anderer Polung. Richtig. > Sie soll > mit Batterie laufen und das tut sie auch. Aber ich wollte Strom sparen. Die Uhr (die im AVR) braucht Quarz und Timer. Da ist nix mit Stromsparen. Da geht nur der Idle-Mode und der spart kaum Strom. Power-Down schaltet den Takt ab und damit auch den Timer... > Die Ausgänge PB2,PB3 schalten die Polung um umd dann bringt PB4 die > Spannung, alles über Relais. Etwas umständlich, eine H-Brücke (auch mit 2 Relais mit je 1 Wechsler möglich) hätte da gereicht. Also ein Pin für sorum und einer für rosum. Diese werden abwechselnd alle 60 Sekunden eingeschaltet und ein paar Zehntelsekunden später wieder aus. Ich würde mittels Timer im CTC-Mode eine Zeitbasis von 1 ms generieren. In dessen ISR würde ich einen Countdown (Word-Variable) von 60000 herunterzählen. Bei 0 wird der Startwert gesetzt und eine Bitvariable getoggelt. Dann wird anhand des Bitzustandes der eine oder andere Relaisausgang eingeschaltet und ein weiterer Countdown (Bytevariable) auf Startwert (Anzahl der Millisekunden, die das Relais eingeschaltet bleiben soll) gesetzt. Zusätzlich wird in der Timer-ISR dieser Count-Down geprüft (ob er >0 ist) und wenn aktiv (also >0) heruntergezählt. Erreicht er 0, dann werden beide Relaisausgänge ausgeschaltet (ist billiger als wenn man erst prüfen müsste, welcher gerade aktiv ist). > Die Zeiten sind freilich viel zu lang. Sie > sind es nur zum besseren Beobachten. Ja klar, aber Warteschleifen im Sekundenbereich in einer ISR, da bekomme ich Magenkrämpfe... ...
Klaus-Peter schrieb: > HW Stack = 40; Softstack = 16; Framesize = 32. Wie erkenne ich wie groß > die Werte mindestens sein müssen? Sollte reichen. Wie erkennen ? Teils Erfahrung, gibt auch ANs dazu im MCS- Forum. Eine ISR benötigt 26 der 40 Bytes HW-Stack. Wie weit ist denn das Problem der Nichtmehrneuprogrammierbarkeit gediehen ?
Angehängte Dateien:
-
SM_tn2313.gif
14 KB
MWS schrieb: > was verwendest Du für ein DB ? 2543I–AVR–04/06 Ist zwar nicht ganz taufrisch der Tiny2313 aber auch nicht. Warum sollte sich da inzwischen etwas geändert haben? Mir sind bei meinen Tiny2313-Basteleien noch keine Unstimmigkeiten gegenüber diesem DB aufgefallen. Da ich fast immer einen Timer verwende, nutze ich natürlich keinen Tiefschlaf-Modus. ...
Hannes Lux schrieb: > Warum sollte sich da inzwischen etwas geändert haben? Weis auch nicht... Aber schau das hier an: http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf
--- Changes from Rev. 2543H-02/05 to Rev. 2543I-04/06 Updated “Power Management and Sleep Modes” on page 30 --- Hmmm! "Updated" ist aber dann nett ausgedrückt.
Klaus-Peter schrieb: > Und das alles nur wegen des !Sleep? Denn ohne läuft das Programm ja. Das halte ich für einen Irrtum... > Übrigens, der Interupt, der jetzt noch mit dem TIMER1 ausgelöst werden > soll wird nachher von einem DTF-Modul gesendet. Das würde ich nicht so machen, dazu ist der DCF77-Empfang zu störanfällig. Ich würde also erstmal eine freilaufende Quarzuhr programmieren, die dann gelegentlich das "DCF77-Radio" einschaltet, die Signale liest, decodiert und auf Plausiblität prüft (mehrere Datensätze lang) und dann "die Uhr trimmt", indem der Startwert für den Minuten-Countdown leicht korrigiert wird. Dazu muss die "Quarzuhr" natürlich nicht nur die Minutenimpulse generieren, sondern auch die Zeit mitzählen, damit sie weiß, wie spät es ist und die Korrektur sauber berechnen kann. > Das ist dann das nächste > Problem. Dazu kommt noch, dass einige DCF77-Module keinen sauberen 100ms/900ms-Impuls abgeben, sondern einschwingen und ausschwingen. Dann verarscht sich der Interrupt und zählt die Sekunde mehrfach. Ich würde deshalb den DCF-Eingang wie einen Taster entprellen, allerdings etwas schneller. Auch dies würde ich den Timer-Interrupt nebenbei mit erledigen lassen. Aber, ich muss das Ding nicht bauen und werde Dir nicht vorscheiben, wie Du es realisieren sollst. Es reicht, wenn Du mal über Alternativen nachdenkst. Viel Erfolg... ...
MWS schrieb: > Aber schau das hier an: Danke, ist ersetzt... - Aber etwas dreist ist das schon, oder? Tut aber nix zur Sache, Timer laufen weder im Power-Down noch im Standby. Das wäre mir also auch zukünftig nicht aufgefallen. ...
Hannes Lux schrieb: > Danke, ist ersetzt... - Aber etwas dreist ist das schon, oder? Macht das Programmieren interessanter und abwechslungsreicher ;D
MWS schrieb: > Wie weit ist denn das Problem der Nichtmehrneuprogrammierbarkeit > gediehen ? Genau und nur um das geht es mir eigentlich. Auch wenn Ihr es nicht glaubt, meine Programme laufen, alle. Nur jetzt komme ich nicht weiter, weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt. Ob das Programm nun der Norm von Profis entspricht weis ich nicht. BASCOM hab ich zufällig gefunden und ich war neugierig ob ich damit was anfangen kann. Und da die Atmels wirklich preiswert sind fing ich vor etwa 2 Jahren an, es auszuprobieren. Sicher könnte ich das Problem auch anders lösen und werde es wohl auch tun müssen. Nur wenn etwas nicht so funktioniert wie es soll, lässt es mir keine Ruhe, und daher meine Anfrage. Es hätte ja sein können, dass einer von Euch da schon mal was ähnliches erlebt hat. Oder vielleicht, dass jemand weis, wie man so einen verriegelten 2313 wieder ansprechen kann. Trotzdem vielen Dank für Eure Mithilfe. Ich habe doch einige gute Ratschläge bekommen.
Klaus-Peter schrieb: > Genau und nur um das geht es mir eigentlich. Auch wenn Ihr es nicht > glaubt, meine Programme laufen, alle. Nur jetzt komme ich nicht weiter, > weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt. Also ist das ein "Ja, Problem existiert noch" ? Oder ein "Hab's noch nicht wieder probiert" > Ob das > Programm nun der Norm von Profis entspricht weis ich nicht. BASCOM hab > ich zufällig gefunden und ich war neugierig ob ich damit was anfangen > kann. Und da die Atmels wirklich preiswert sind fing ich vor etwa 2 > Jahren an, es auszuprobieren. Sicher könnte ich das Problem auch anders > lösen und werde es wohl auch tun müssen. Niemand stört wie Du das für Dich hältst. Es gibt da die Regel, dass Du jederzeit so programmieren kannst, wie Du möchtest, und der µC kann dann jederzeit die Mitarbeit verweigern, so wie er möchte :D > Oder vielleicht, dass jemand weis, wie man so > einen verriegelten 2313 wieder ansprechen kann. High Voltage Programmierung wäre hier das Stichwort, das kann Dein Programmer aber nicht, da bräuchtest Du 'nen STK500. Klaus-Peter schrieb: > Nur jetzt komme ich nicht weiter, > weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt. Wie schon erwähnt, das ist eher unwahrscheinlich. Bevor ich wirklich so etwas annehmen würde, würd' ich eher den Fehler beim Programmer und beim Benutzer suchen. Wir wollten Deinen Programmcode sehen, um einschätzen zu können, ob da etwas drinsteht, was Du für den Fehler interpretieren könntest. Nach meiner Einschätzung hast Du Anfängerlevel, was jetzt nicht abwertend gemeint ist. Bei Anfängern werden manche Ursachen für gänzlich andere gehalten und ab und zu lösen sich die bei weiterer Beschäftigung mit der Materie von selbst. Klaus-Peter schrieb: > Außer dem Ziel-IC ist nichts angeschlossen. Hast Du denn wenigstens den 100nF Abblockkondensator dran ? Der kann den Unterschied ausmachen. Wie ist der genaue Aufbau beim Programmieren ? Mein Rat wäre, je nach Budget und Verfügbarkeit einer seriellen Schnittstelle an Deinem PC, einen STK500 zu besorgen und AVR-Studio 4 zu installieren. Oder auch das 5er-Studio, wobei mir das zu aufgeblasen ist.
Nachtrag: Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ?
Wenn Dein Programmer STK500 kompatibel ist, solltest Du das AVRStudio installieren und den Programmer starten. Da kannst Du dann in aller Ruhe Diagnostik betreiben, warum er sich nicht programmieren lassen soll. Also Signatur lesen, bei Bedarf SPI-Takt runter setzen, Erase machen usw. Peter
Klaus-Peter schrieb: > Oder vielleicht, dass jemand weis, wie man so > einen verriegelten 2313 wieder ansprechen kann. Wie bereits genannt, geht das im HV-Modus mit einem STK500 oder Dragon. Beides steht mir zur Verfügung, wenn es Dir das Porto und Rückporto (nach Sachsen-Anhalt) wert ist, dann überprüfe und rette ich die Dinger gern mal. Bei Bedarf Kontaktaufnahme über PM: http://www.mikrocontroller.net/user/show/hannes ...
Hast Du überhaupt eine ordentliche, d.h. stabile Stromversorgung für den AVR? Es kann gut sein, daß Du den Power-Down-Modus setzt, der AVR zieht keinen Strom mehr, die VCC läuft hoch und es macht Peng. Dann ist der AVR nicht durch das Sleep gestorben, sondern durch Überspannung. Tip: Kauf Dir ne Stange Suppressordioden für 5V und baue die in jede Schaltung ein. Die begrenzen im Fehlerfall auf ~6,8V und bei nem starken Netzteil opfern sie sich (Kurzschluß) und schützen damit die Schaltung. Peter
MWS schrieb: > Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ? An Alle, danke für die vielen guten Ratschläge. Ich war bisher Einzelkämpfer und Seiteneinsteiger, daher ist mein Fachjargon wahrscheinlich sehr mangelhaft. Was aber nicht darüber hinwegtäuschen soll, dass ich mehrere auch kompliziertere Programme zum Laufen gebracht habe. Auch mag vielleicht die Kontrolle des Progammverlaufs mit Printbefehlen und dem Terminalprogramm sehr Laienhaft sein, aber ich kann Euch versichern, dass ich sehe ob meine Programme laufen oder nicht. Also nochmal, das gepostete Programm läuft ohne "!Sleep" genau wie es soll. Ich habe es nur um es zu beweisen 10 Mal gelöscht und neu geladen, immer im gleichen IC. Also kann es weder am Programm, noch am Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A) auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem "!Sleep" Befehl liegen. Das wars. Auch wenn es so aussieht als würde ich die guten Ratschläge von Euch ignorieren. Ich werde diesen Befehl aus meinem Befehssatz für den Tiny 2313 (ohne A!) streichen, denn sonst sehe ich ihn, weil kleiner als der Mega8, als für mich brauchbare Ergänzung zu Letzterem. Der Tiny hat 2,35€ gekostet. Ich hab damals 10 Stück gekauft und werde mir noch mal welche besorgen. Bis jetzt lohnt es sich also nicht, sie zur Überprüfung (danke Hannes) wegzuschicken, noch dafür einen HV-Programmer zu kaufen (danke MWS). Klaus-Peter
Klaus-Peter schrieb: > Also kann es weder am Programm, noch am > Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A) > auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem > "!Sleep" Befehl liegen. Das wars. Auch wenn es so aussieht als würde ich > die guten Ratschläge von Euch ignorieren. wenn du das sagst muss es ja stimmen, wieder Mal ist Atmel schuld
Klaus-Peter schrieb: > MWS schrieb: >> Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ? > > An Alle, > danke für die vielen guten Ratschläge. Ich war bisher Einzelkämpfer und > Seiteneinsteiger, Bin und war ich auch. > daher ist mein Fachjargon wahrscheinlich sehr > mangelhaft. Was aber nicht darüber hinwegtäuschen soll, dass ich mehrere > auch kompliziertere Programme zum Laufen gebracht habe. Das dachte ich von meinen ersten Programmen auch mal. Heute sehe ich das differenzierter, da würde ich Vieles anders machen. > Auch mag > vielleicht die Kontrolle des Progammverlaufs mit Printbefehlen und dem > Terminalprogramm sehr Laienhaft sein, aber ich kann Euch versichern, > dass ich sehe ob meine Programme laufen oder nicht. Das schon, man kann's aber auch unnötig kompliziert machen bzw. unnötige Fehlerquellen einbauen und das Programm läuft trotzdem und es sieht auch so aus, als ob es das tut was es soll. > Also nochmal, das gepostete Programm läuft ohne "!Sleep" genau wie es > soll. Ich habe es nur um es zu beweisen 10 Mal gelöscht und neu geladen, > immer im gleichen IC. Also kann es weder am Programm, noch am > Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A) > auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem > "!Sleep" Befehl liegen. So sieht es aus, so muss es aber nicht sein. Du benutzt einen "Tiefschlaf-Modus", in dem der CPU-Takt abgeschaltet wird und daher keine Timer mehr laufen. Da kommst Du nur wieder raus mit externem Interrupt im Low-Level-Mode, dem Pinchange-Interrupt oder TWI-Interrupt (hierzu irrelevant). Fast alle meine Programme benutzen Sleep, und zwar konsequent am Ende der Mainloop. Einerseits damit (z.B. bei impulserzeugenden Programmen) die Interrupt-Response-Time konstant bleibt, aber auch weil es schön bequem ist. Da ich meist einen Timer brauche, bleibt mir dabei nur der Idle-Mode. Will ich "Tiefschlaf" mit Wecken per Taster und brauche in den Ruhepausen keinen Timer, dann arbeite ich mit wechselnden Sleep-Modi. Solange das Ding aktiv ist (und Timer braucht), wird nach jeder Runde der Mainloop im Idle-Mode gepennt, bis der Timer wieder weckt. Sind die Bedingungen zum Deaktivieren erfüllt, so wird der Sleep-Mode auf "Tiefschlaf" umgeschaltet und der externe Interrupt freigeschaltet. Beim nächsten Erreichen des Sleep-Befehls am Ende der Mainloop wird dann der Takt abgeschaltet. Nun kann den Controller nur noch der externe L-Pegel-Interrupt aufwecken. Der zugehörige Interrupt schaltet nur den Sleep-Mode auf Idle um und deaktiviert den externen Interrupt. Beim nächsten Sleep ist dann der Idle-Mode aktiv, die Timer laufen und das Programm kann Tasten entprellen und darauf reagieren. Hier mal ein Beispiel dazu: http://www.hanneslux.de/avr/divers/melody/melody04.html http://www.hanneslux.de/avr/divers/melody/melody04.asm > Das wars. Auch wenn es so aussieht als würde ich > die guten Ratschläge von Euch ignorieren. Ich werde diesen Befehl aus > meinem Befehssatz für den Tiny 2313 (ohne A!) streichen, Das ist nicht nötig, man muss ihn nur richtig anwenden. Dazu gehört auch, dass man sich mit der Architektur des Controllers vertraut macht, also versucht, die interne Logik zu verstehen. > denn sonst sehe > ich ihn, weil kleiner als der Mega8, als für mich brauchbare Ergänzung > zu Letzterem. Ich benutze den Tiny2313 sehr gerne. Das umfangreichste Tiny2313-Programm ist in einem Lokfahrtregler für akkubetriebene Gartenbahn mit 2,4GHz-RC-Steuerung. Da laufen 5 Interrupts und einige Tasks der Mainloop. Und nach jedem abgearbeiteten Schritt gehts in den Sleep (Idle). Der Tiny2313 liest und decodiert 5 RC-Kanalimpulse, verwaltet ein/ausloggen der Fahrzeuge und steuert Motor, 3 Schaltfunktionen, 3 Soundsteuerfunktionen und in 4 Modi umschaltbare Frontbeleuchtung. http://www.hanneslux.de/planet5b/index.html http://www.hanneslux.de/planet5b/planet5-lokfahrtregler_v02.html > Der Tiny hat 2,35€ gekostet. Ich hab damals 10 Stück gekauft und werde > mir noch mal welche besorgen. Bis jetzt lohnt es sich also nicht, sie > zur Überprüfung (danke Hannes) wegzuschicken, Ich will nix dran verdienen, Porto und Rückporto sind zweimal 1,45€. Also zusammen mit einem frankierten Rückumschlag in einen Umschlag und ab die Post. Du wärst da nicht der Erste. > noch dafür einen > HV-Programmer zu kaufen (danke MWS). Den habe ich bisher nur für Andere gebraucht. ;-))) Hoffentlich bleibt das auch so... > Klaus-Peter ...
Hallo Klaus - Peter, ich habe denthread erst heute entdeckt. mir gefällt dein !Sleep befehl nicht und zwar wie du ihn setzt. und ich halte ihn tatschlich für die ursache deines Proplems! du setzt dort nicht nur dir SM1 SE und SM0 sondern auch das Komplette Register! imho enthält dieses aber auch die Pinchange bits und damit schießt du dir den Resetpin ab! er wird ungewollt zu PA2 und bleibt es! deshalb kannst du nicht neu brennen siehe Seite 53 im datasheet hier hilft nur HV Programmierung zurück will mann nur einzelne Bits verändern sollte man Bit-set-befehle in ASM benutzen wenn mann kein ASM verwenden will oder mit AND und OR die bits setzen und löschen (Maskierung) z.b MCUCR=MCUCR or 0b0110000; Rem setzen MCUCR=MCUCR and 0b1000111; rem löschen so werden nur die maskierten bits verändert mfg Winne
Versuche es mal mit: $ASM Sleep $End ASM Print "MfG Paul" ;-)
Um die Reset-Funktion des Pins abzuschalten muss man schon m.E. schon das entsprechende Fuse-Bit bemühen. Nichts in MCUCR schaltet die ab.
A. K. schrieb: > Um die Reset-Funktion des Pins abzuschalten muss man schon m.E. schon > das entsprechende Fuse-Bit bemühen. Nichts in MCUCR schaltet die ab. dann schau dir mal seite 53 an MCUCR register das bietet so dumme sachen auch zur laufzeit.
Winfried J. schrieb: > dann schau dir mal seite 53 an MCUCR register > das bietet so dumme sachen auch zur laufzeit. Die Seite 53 in meiner Version vom Datasheet (08/10) fängt an mit der Beschreibung des PUD Bits und erwähnt sonst nur die alternativen Pinzuordnungen, aber nichts zu Laufzeit und auch nichts über Reset. Dass der Pin eine optionale zweite Funktion hat ist klar, wird aber über die Fuse umgeschaltet. Könntest du mal den Text oder Ausschnitt zeigen, auf den du dich beziehst?
A. K. schrieb: > Könntest du mal den Text oder Ausschnitt zeigen, auf den du dich > beziehst? Das wollte ich auch gerade fragen... ...
Im Register MCUCR ist doch das oberste Bit PUD mit drin. (Pull up Disable) Wenn das gesetzt wird, dann werden die internen Ziehwiderstände abgeschaltet, auch wenn sie vorher eingeschaltet hatte. Ich denke, daß man dann mit dem ISP-Programmiergerät nicht mehr dran kommt, weil der Reset-Eingang keinen H-Pegel mehr bekommt. MfG Paul
Winfried J. schrieb im Beitrag #2452815: > enthält dieses aber auch die Pinchange bits und damit schießt du dir > den Resetpin ab! er wird ungewollt zu PA2 und bleibt es! > deshalb kannst du nicht neu brennen Das ist doch jetzt wirklich der komplette Blödsinn. MCUCR kann die internen Pullups abschalten, Sleep-Modi konfigurieren und die Modi für ext. Int0/1 einstellen. Aber keinen Reset disablen. Hoffen wir mal, dass nicht Deine Aufzüge nach diesem System funktionieren. Paul Baumann schrieb: > Ich denke, daß man dann mit dem ISP-Programmiergerät nicht mehr dran > kommt, weil der Reset-Eingang keinen H-Pegel mehr bekommt. Sobald der Programmer auf Low zieht, egal ob mit oder ohne Pullup, ist kein Programm mehr aktiv und die Default-Einstellungen des µC sind gültig. Per Default ist PUD ausgeschaltet, selbst wenn die Pullups für den Resetpin überhaupt gelten sollten. Klaus-Peter schrieb: > An Alle, > danke für die vielen guten Ratschläge. Ich war bisher Einzelkämpfer und > Seiteneinsteiger, Statt dessen Du mir die gewünschte Antwort gibst, wird's um den Brei rumreden und das Thema "Beleidigte Leberwurst". Ganz deutlich: es ist uns absolut egal, wie Du programmierst, wie Du das gelernt hast, wofür's sein soll, usw. Aber 1) fragst Du um Hilfe und stellst Dich dabei eher als verständnisresistent dar und 2) sagst Du "Sleep im ATTiny2313 ist kaputt" Klaus-Peter schrieb: > Also kann es weder am Programm, noch am > Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A) > auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem > "!Sleep" Befehl liegen. Das wars. Und das ist entweder ein Schmarrn oder es gibt bei diesem µC tatsächlich einen Defekt. Wenn Letzteres der Fall ist, dann interessiert es alle hier. Um das Leiden abzukürzen hab' ich Dein Programm hier auf einen ATTiny2313-20PU geflasht. Steckbrettaufbau Bascom Version 2.0.7.3, aktuell Programmer Diamex ISP STK500 Nachbau Programmeroberfläche Bascom, STK500 native driver µC-Versorgung 5V über VTG des Programmers mC ATTiny2313-20PU, 8MHz CKDIV8 Fuse ein, Takt 1MHz Ich kann Dein Programm egal mit oder ohne !Sleep so oft flashen wie ich will, da gibt's überhaupt kein Problem, und das war auch anzunehmen. Mit Sleep funktioniert Dein Programm selbst allerdings nicht, was daran liegt: Klaus-Peter schrieb: > MWS schrieb: >> Du hast das Datenblatt gelesen ? >> "Standby mode is only recommended for use with external crystals or >> resonators." Damit fällt der Standby-Mode für Dich aus. Auch der Power-Down geht nicht, denn da läuft der Timer nicht mehr. Was funktioniert ist der Idle-Mode, da läuft Dein Programm auch und die Leds blinken. Hier hab' ich alle Modi getestet:
1 | Mcucr = &B00100000 ' timer läuft |
2 | ' Mcucr = &B00110000 ' timer läuft nicht |
3 | ' Mcucr = &B01100000 ' timer läuft nicht |
4 | ' Mcucr = &B01110000 ' timer läuft nicht |
5 | !Sleep |
6 | Mcucr = &B00000000 |
Entweder Dein Programmer arbeitet nicht zuverlässig, die Stromversorgung ist nicht ok, Dein Aufbau passt nicht, oder was auch immer. Der ATTiny2313 kann jedoch immer wieder neu geflasht werden, also nix mit toten Käfer.
Paul Baumann schrieb: > Ich denke, daß man dann mit dem ISP-Programmiergerät nicht mehr dran > kommt, weil der Reset-Eingang keinen H-Pegel mehr bekommt. Vorausgesetzt die PUD Fuse hat überhaupt etwas mit dem Reset-Pullup zu tun. Was ich für unwahrscheinlich halte. Einerseits aus der Logik der Sache her, andererseits, weil sich der Reset-Pullup von den Pin-Pullups technisch unterscheidet, wie das Datasheet hinten anhand der Widerstandswerte deutlich macht. Ausserdem setzt er das Bit auf 0, schaltet die Pullups also nicht ab.
Hi Dein Link funktioniert nicht. Aber abgesehen davon sind, wie andere schon gesagt haben, Reset-PullUp und IO-PullUp zwei paar Schuhe. Der Reset-PullUp lässt sich über PUD nicht abschalten. MfG Spess
o.k. insofern habt ihr recht ich habe mich von der seitengestaltung auf seite 53 des schon weiteroben aufgeführten und dort funktionierenden links in die irre führen lassen. Beim 32er vergessen Anfänger gern den jtag abzuschalten und das geht definitv per MCUCR zur Laufzeit durch 2maliges setzen des betreffenden bits während 4 Takten durch die unmittelbardaurunter aufgeführten Alternativen portfunktionen schloss ich darauf das das hier mit dem MCUCR unmittelbar zu tun hat, aber ich schrieb auch zunächst imho weil ich nicht ganz sicher war und fort musste. Sorry wenn ich damit für zusätzliche Verwirrung sorgte ich war halt derartige MCUCR Aktivitäten gewohnt. Aber folgendes mißfällt mir trotzdem
1 | '---------------------------------------------------------- |
2 | 'Da mit Timer1 längere Schlafzeiten,aber nur externe Interupts mögich sind wird PORTB.0 als Eingang benutzt |
3 | 'und mit Timer1 gesetzt.Das hat so schon funktioniert. |
4 | Mcucr = &B01100000 'Bit6_Standbymodus;Bit5_Sleepenable;Bits1-0 |
5 | '=00_Lowlevel für INT0 |
6 | Gimsk = &B01100000 'Bit6_ext.INT0 enable;Bit5_Pinchange enable ' |
7 | Pcmsk = &B00000001 'Bit0_PCINT0 (PB0) ausgewählt als Aufwecksignal |
8 | Timer1 = C 'TCNT1H+TCNT1L;Überlauf nach ca 4,5sec? |
9 | '---------------------------------------------------------- |
hier wird die MCU schlafen geschickt bevor der externe interrupt erlaubt wird! Das heist der externe IRQ ist noch gar nicht erlaubt aber der Prozessor schläft schon Deshalb Bits in MCUCR einzeln und in der richtigen Reihenfolge auch mit anderen Registern setzen! Aber der Reset sollte dann eigentlich funktionieren. Ob er das auch im Schlaf tut? Sollte er eigentlich wenn er ordentlich arbeitet, ich werde das mal probieren. obwohl will ich dafür einen2313 opfern? ich sehe lieber erst mal zu das ich ihn normal geweckt bekomme ;-) MfG
Winfried J. schrieb: > Schlaf tut? Sollte er eigentlich wenn er ordentlich arbeitet, ich werde > das mal probieren. > obwohl will ich dafür einen2313 opfern? Hättest Du meinen Beitrag gelesen, der zwei Beiträge vor Deinem lag, dann würde sich Dir diese Frage nicht mehr stellen. Was ist los ? Zu tief in's Glas geschaut ? :-) Winfried J. schrieb: > Mcucr = &B01100000 > hier wird die MCU schlafen geschickt bevor der externe interrupt erlaubt > wird! Nein, das geschieht nicht. Das MCUCR zu setzen ist nur die Vorbereitung auf den Sleep-Befehl. Ohne Sleep schläft da noch gar nix. Der TE hat nur das Setzen des MCUCR an die falsche Stelle geschrieben, üblicherweise kommt's unmittelbar vor dem Sleep-Befehl.
A.K schrob:
>Ausserdem setzt er das Bit auf 0, schaltet die Pullups also nicht ab.
Au weh, das habe ich jetzt im Quelltext gesehen...
Ich glaube, ich bin noch im Sleep-Modus...
MfG Paul
MWS schrieb: > Der TE hat nur das Setzen des MCUCR an > die falsche Stelle geschrieben, üblicherweise kommt's unmittelbar vor > dem Sleep-Befehl. Das würde ich nicht so eng sehen. Bei festem Sleepmode stelle ich den Sleepmode bereits in der Init (also beim Reset) ein und rufe Sleep in der Mainloop auf. Bei wechselndem Sleepmode stelle ich den Modus dort um, wo es im Programm sinnvoll erscheint. Der Aufruf von Sleep erfolgt dann aber auch am Ende der Mainloop. Damit bin ich bisher immer ganz gut gefahren. ...
Hannes Lux schrieb: > Das würde ich nicht so eng sehen. Bei festem Sleepmode stelle ich den > Sleepmode bereits in der Init (also beim Reset) ein und rufe Sleep in > der Mainloop auf. Ich find's günstig Ursache und Wirkung beieinander zu haben. Für Übersichtlichkeit kann man mit Konstanten arbeiten.
Hannes Lux schrieb: > Bei wechselndem Sleepmode stelle ich den Modus dort um, wo es im > Programm sinnvoll erscheint. Der Aufruf von Sleep erfolgt dann aber auch > am Ende der Mainloop. Ich zitier mal kurz Seite 30 aus dem ATTiny2313 Datenblatt:
1 | • Bit 5 – SE: Sleep Enable |
2 | The SE bit must be written to logic one to make the MCU enter the sleep mode when the SLEEP instruction is executed. |
3 | To avoid the MCU entering the sleep mode unless it is the programmer’s purpose, it is recommended to write the Sleep Enable (SE) bit to one just |
4 | before the execution of the SLEEP instruction and to clear it immediately |
5 | after waking up. |
Ich hab die Erfahrung gemacht, das Atmel so was nicht ohne Grund schreibt.
Matthias Sch. schrieb: > Hannes Lux schrieb: >> Bei wechselndem Sleepmode stelle ich den Modus dort um, wo es im >> Programm sinnvoll erscheint. Der Aufruf von Sleep erfolgt dann aber auch >> am Ende der Mainloop. Matthias Sch. schrieb: > • Bit 5 – SE: Sleep Enable > The SE bit must be written to logic one to make the MCU enter the sleep mode when the SLEEP instruction is executed. > To avoid the MCU entering the sleep mode unless it is the programmer’s purpose, it is recommended to write the Sleep Enable (SE) bit to one just > before the execution of the SLEEP instruction and to clear it immediately > after waking up. Beides schließt sich nicht aus. Es ist durchaus möglich, den Sleep-Mode umzustellen, aber das SE-Bit erst direkt vot dem 'sleep'-Befehl zu setzen und direkt danach wieder zu löschen. Per Bitmanipulation kann man das in ASM wunderbar machen. In C braucht´s halt worst case ein paar Befehle mehr.
Matthias Sch. schrieb: > Ich zitier mal kurz Seite 30 aus dem ATTiny2313 Datenblatt:• Bit 5 – SE: Sleep Enable > The SE bit must be written to logic one to make the MCU enter the sleep mode when the SLEEP instruction is executed. > To avoid the MCU entering the sleep mode unless it is the programmer’s purpose, it is recommended to write the Sleep Enable (SE) bit to one just > before the execution of the SLEEP instruction and to clear it immediately > after waking up.Ich hab die Erfahrung gemacht, das Atmel so was nicht ohne Grund > schreibt. In diesem Fall doch. Rein logisch gesehen ist es Schwachsinn, das SE nach dem Sleep zu löschen, wenn man es eh wieder vor dem Sleep setzt. Und es ist völlig egal, ob man es einen Zyklus oder 10 Jahre vor dem Sleep setzt. Sein Zustand beim Sleep ist exakt derselbe. Hier mal die Antwort von Atmel dazu: "FYI, there is no other way except sleep instruction to make the device enter into sleep mode. The statement given in the data sheet is just a recommendation to avoid some software bugs. There may be a chance that one has enabled the sleep instruction at some part of the huge code(buried) and some sleep instruction that pops up from ISR which is not in the normal program flow. There is a chance for the programmer to think it as an unintentional event. Hence to avoid such software bugs it is recommended in such a way described in the data sheet and it is not mandatory to enable the SE bit immediately prior to SLEEP instruction." Es sollte also nur Fehlern des Softwareentwicklers vorbeugen, aber das tut es nicht. Es müßte dann ja noch an anderer Stelle ein Sleep ohne vorherige SE setzen stehen. Das widerspräche aber der "Empfehlung", also ist sie sinnlos. Peter
Ich vermute ja immer noch, er hat die Dinger spannungsmäßig gekillt. Aber dazu sagt er ja nichts und hat es wohl nichtmal nachgemessen. Ich hatte schonmal ne Charge 7815, die im Leerlauf auf 30V geklettert sind. Peter
Peter Dannegger schrieb: > Aber dazu sagt er ja nichts und hat es wohl nichtmal nachgemessen. Richtig, ich war seit Freitag ausser Gefecht. Man hat mir mein Auto geschrottet und ich war nach mehreren Arztbesuchen und dam ganzen Hickhack mit ADAC, Anwalt und Werkstatt (Gutachter) voll beschäftigt und hatte keinen Kopf mich momentan mit diesem Problem zu befassen. Peter Dannegger schrieb: > Ich vermute ja immer noch, er hat die Dinger spannungsmäßig gekillt. Dann müssten ja alle IC's sterben und nicht nur wenn der !Sleep-Befehl mit drin steht. MWS schrieb: > Was funktioniert ist der Idle-Mode, da läuft Dein Programm auch und die > Leds blinken. Hier bestätigt mir ein Fachmann, dass dieses Programm läuft, mal abgesehen davon, dass es besser gemacht werden könnte. Alles was ich wissen wollte war, warum die 2313 sich nicht mehr programmieren lasen und was ich dagegen tun kann. Denn sie sind ja nicht gekillt, das geladene Programm läuft ja. Es war das erste Mal, dass ich mit einem ATiny2313 arbeitete. Mit dem ATMEGA-8 und -88 hatte ich bisher null Probleme. Da ist mir auch noch keiner ausgestiegen oder gestorben. Wenn es mir wieder besser geht nehme ich die Versuche wieder auf und teste es mit dem Vorschlag: Mcucr = &B00100000 ' timer läuft Danke einstweilen Klaus Peter
Klaus-Peter schrieb: > Dann müssten ja alle IC's sterben und nicht nur wenn der !Sleep-Befehl > mit drin steht. Der Sleep-Mode Power-Down bewirkt, daß der AVR keinen Strom mehr zieht. Wenn dann das Netzteil nicht leerlauffest ist, kann die Spannung steigen. Zieh mal den AVR aus dem Sockel und miß die Spannung nach. Peter
Peter, Du wiederholst Dich ;-) Beitrag "Re: attiny2313 schläft und lässt sich nicht mehr programmieren"
Knut Ballhause schrieb: > Peter, Du wiederholst Dich ;-) Na und? Wenn es keine Antwort dazu gibt muss man die Jungs immer wieder in Erinnerung rufen. Peter Dannegger schrieb: > Der Sleep-Mode Power-Down bewirkt, daß der AVR keinen Strom mehr zieht. Peter, der Klaus schreibt das doch die Dinger funktionieren bis sie in den sleep Mode gehen. Also das Programm läuft in dem µC bis zu einer bestimmten Stelle. Warum soll er jetzt gestorben sein? Das soll jetzt kein Klugscheisser Spiel sein, sondern einfach nur für mein Verständnis.
Thread beobachten
Seitenaufteilung abschalten
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.