mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik attiny2313 schläft und lässt sich nicht mehr programmieren


Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SLEEP hat nichts mit der Programmierbarkeit zu tun, da bei RESET kein 
Programmcode ausgeführt wird.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Heinz Buchegger schrieb:
> Und nein: dagegen kann er
> sich auch nicht wehren.

doch, Reset Disable (gut das geht nicht per Software)

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kannnix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig deine Beschaltung und ein Bild vom Aufbau. Code und Fehlermeldungen 
braucht man auch nicht als Bild anzuhängen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
noch ein screenshot

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
noch einer

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Code und Fehlermeldungen
> braucht man auch nicht als Bild anzuhängen.


!!!!!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

>noch ein screenshot

>noch einer

Das ist keine Salami, die man scheibchenweise serviert. Ist es so 
schwer, dein Programm anzuhängen?

MfG Spess

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

...

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

Nimm einfach deine 'Sleep_Test.bas' als Anhang.

MfG spess

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus-Peter schrieb:
> Ich versuchs mal in WORD.

Bitte nicht!

...

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und jetzt noch mit dem Editor

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Mody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> ... Code und Fehlermeldungen braucht man auch nicht als Bild anzuhängen.

gelesen ?

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gimsk = &B01100000 'Bit6_ext.INT0 enable;Bit5_Pinchange Enable                                        '
Pcmsk = &B00000001 'Bit0_PCINT0 (PB0) ausgewählt als Aufwecksignal

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.

Das hat aber alles nichts mit dem ISP-Problem zu tun.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Stacks und Frame fehlt immer noch.

Nimmt dann nicht der Compiler die voreingestellten Werte?

...

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
---
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> Danke, ist ersetzt... - Aber etwas dreist ist das schon, oder?

Macht das Programmieren interessanter und abwechslungsreicher ;D

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter S. (avatar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-lokfahrtr...

> 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

...

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche es mal mit:
$ASM
 Sleep
$End ASM

Print "MfG Paul"
;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Könntest du mal den Text oder Ausschnitt zeigen, auf den du dich
> beziehst?

Das wollte ich auch gerade fragen...

...

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
        Mcucr = &B00100000   ' timer läuft
'        Mcucr = &B00110000   ' timer läuft nicht
'        Mcucr = &B01100000   ' timer läuft nicht
'        Mcucr = &B01110000   ' timer läuft nicht
        !Sleep
        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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
'----------------------------------------------------------
'Da mit Timer1 längere Schlafzeiten,aber nur externe Interupts mögich sind wird PORTB.0 als Eingang benutzt
'und mit Timer1 gesetzt.Das hat so schon funktioniert.
Mcucr = &B01100000                                          'Bit6_Standbymodus;Bit5_Sleepenable;Bits1-0
                                                            '=00_Lowlevel für INT0
Gimsk = &B01100000                                          'Bit6_ext.INT0 enable;Bit5_Pinchange enable                                        '
Pcmsk = &B00000001                                          'Bit0_PCINT0 (PB0) ausgewählt als Aufwecksignal
Timer1 = C                                                   'TCNT1H+TCNT1L;Überlauf nach ca 4,5sec?
'----------------------------------------------------------

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

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  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 programmers 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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus-Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: *-_-* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.