Werte Kollegen Kleiner Code im Anhang. Ich habe 8 LED's am PORTA beim ATTiny24v-10PU, dort sollen wechselweise 2 Bytewerte ausgegeben werden. LSB ist auf A0, MSB ist auf A7. Das funktioniert grundsätzlich tip top. Erfolgt aber ein Wechsel vom Wert 31 (0b00011111) auf den Wert 32 (0b00100000), resettet sich der uC automatisch. Das soll nicht sein. Umgekehrt, beim Wechsel von 32 auf 31, läuft es wiederum plangemäss ok. Auch z.B. von 31 auf 33 funktioniert es tip top, und eigentlich bei allen beliebigen Bytepaarwechsel ok, ausser die Paare in der Wechselfolge 31>32, 63>64, 95>96, und wohl noch bei weiteren höheren Byte-Paaren. Die "unteren" Paare 15>16 und 7>8 und 3>4 und 1>2 können dem uC nichts anhaben. What the hell happens here...?! Ich komme nicht drauf. Danke und Gruss, Wigi
Wigi schrieb: > Kleiner Code im Anhang. ??? *.doc ist kein Code, da wird der Compiler nur Fehlermeldungen spucken, wenn Du ihm das vorsetzt. Code heißt z.B. *.c oder *.asm. Peter
Hat der Assembler keinen Fehler ausgeben bei dieser Zeile? cpi r17, 0 ==> breq OFF t rjmp Stage1
Programm ist soweit von der Logik her in Ordnung (bis auf den einen Tippfehler) Wie sieht die Hardware aus?
Rüge betreffend DOC zu Recht, aber der Code ist drin. Tippfehler JA habe ich gesehen, das ist eben der DOC Umstand, da habt ihr Recht. Die Hardware ist auf dem Steckbrett, Speisung 16VAC über 4-Weg Brücke, 5VDC mit Stabi, 2x 220u geglättet und 2x 100n entstört (Standard). ISP ist frei, habe im Betrieb kein Progger dran. Habe auch schon andere Versorgungen dran gehabt > dasselbe Problem.
Steht die Resetursache im MCUSR Register? Hast du die Brownout Detection über die AVR Fuses aktiviert?
Brownout Detection Fuse ist disabled. By the Way: das CKDIV8 Fuse ist gesetzt, weil die Bytewechsel sonst zu schnell laufen. Die anderen Fuses habe ich aber nicht angerührt. Das MCUSR Reg werde ich noch einsehen und melde mich wieder.
> 5VDC mit Stabi, 2x 220u geglättet und 2x 100n entstört (Standard). Du schaltest die LEDs active high Pin o------####---->|-----GND Das Phänomen tritt bei hoher Last (31, 95) nach niedriger Last (32, 96) auf. Hast du zusätzlich direkt am Attiny24V einen 100nF Kondensator zwischen Vcc und GND? Kommt der Reset auch bei active low Schaltung Pin o------####----|<-----Vcc dann mit LDI r16, ~(31) LDI r16, ~(32)
Genau, die LED's sind gegen GND (active High). Hohe Last vs. niedrige Last, das ist korrekt, und ein guter Gedanke von dir. Ob das am Ende reinspielt? Meine LED's haben Rv = 330, von da her sollte die Last Pin-verträglich sein, auch wenn alle 8 an sind. Aber wer weiss...Spannungszusammenriss oder so....? Nein, beim uC habe ich dann keinen C mehr. Werde es noch einbauen und zurück melden. Bei activ Low passiert dasselbe > Reset (Code umgeschrieben und HW umverdrahtet). Ich melde mich wegen C und MCUSR.
Also: MCUSR Auswertung gibt immer 0b00101100 zurück, egal wo ich das einbaue und den Prozess anhalte. Das irritiert mich deshalb, weil das obere Nibble nicht 0 ist (muss immer 0 sein, weil nicht belegt). also etwa so: ldi r16, MCUSR out PORTA, r16 loop123: nop rjmp loop123 Hingegen hat das C über dem uC etwas gebracht! Offenbar habe ich ein Versorgungsproblem, wenn z.B. 5 LED's an sind (31) und dann bis auf 1 LED abgeschalten werden (32). Das erklärt allerdings nicht, warum der Wechsel von 31 auf 64 funktioninert, wo ich Strommässig exakt dieselbe Situation antreffe. Deshalb wär's schon noch interessant zu sehen, was WIRKLICH im MCUSR steht. Wie kann ich das MCUSR korrekt einbauen? Danke!
kleine Korrektur: MCUSR Auswertung gibt immer 0b00110100 zurück.... ich hab's oben verkehrt herum angegeben (LSB <> MSB). Das korrekte Auslesen des MCUSR bleibt weiterhin eine Frage. Danke euch, Gruss Wigi
> ldi r16, MCUSR
LDI lädt eine Konstante, hier die Adresse des MCUSR Registers also 0x34,
und nicht den Inhalt, der dich eigentlich interessiert
Du brauchst die IN Anweisung
1 | IN r16, MCUSR |
2 | OUT PORTA, r16 ; letzte Resetursache aus MCUSR lesen |
3 | LDI r17, 0 |
4 | OUT MCUSR, r17 ; frisches MCUSR = 0 für die nächste Runde |
Wigi schrieb: > Hohe Last vs. niedrige Last, das ist korrekt, und ein guter Gedanke von > dir. Ob das am Ende reinspielt? Meine LED's haben Rv = 330, von da her > sollte die Last Pin-verträglich sein, auch wenn alle 8 an sind. Ich hab ehrlich gesagt weniger an den statischen Zustand gedacht sondern mehr an den Zeitpunkt des Umschaltens, wenn µC-intern Strompfade sich schlagartig öffnen oder sperren. Du kannst ja auch problemlos eine 1l Wasserflasche mit einer ausgestreckten Hand halten. Nur wenn ich dir die Flasche auf die ausgestreckte Hand druafstelle, wird deine Hand kurz runtergehen. Kannst du nicht verhindern. > Nein, beim uC habe ich dann keinen C mehr. .... > Hingegen hat das C über dem uC etwas gebracht! Jetzt weißt du auch, das man den nicht einfach weglässt.
Merci an alle für die konstruktive Lösung, besonders an Karl und Stefan. Die Lösung lautet: 100nF direkt über den uC Versorgungspins, in diesem Fall nützlich zur Betriebsstabilität bei mittelgrossen und grösseren Schaltstromentlastungen beim ATtiny24 (z.B. 50mA > 10mA). Danke auch für den Tip des MCUSR Handlings, habe ich in der Tat falsch implementiert (shame on me). Ich werde die Korrektur noch nachholen und die Auswertung neu beurteilen. Bei weiteren Fragezeichen gibt es genügend Threads dazu, wie ich gesehen habe. Das soll hier nicht abgehandelt werden. Hiermit schliesse ich diesen Task. Danke und Gruss, Wigi
> Die Lösung lautet: 100nF direkt über den uC Versorgungspins, in diesem > Fall nützlich zur Betriebsstabilität Nicht "nützlich", sondern "selbstverständlich". Man betreibt grundsätzlich keinen AVR (oder anderen Mikrocontroller) ohne diesen Abblock-Kondensator. Und wenn er mehrere Anschlusspaare für Versorgungsspannung hat, dann bekommt er auch mehrere Kerkos. Weglassen ist Pfusch! ...
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.