Hallo,
habe das u.a. Beispiel aus dem Tutorial um eine Schleife erweitert, um
ca. 1 Sekunde Blinkdauer zu erreichen. Im AVR Studio funktioniert die
Simulation einwandfrei. Wenn ich das Programm auf den attiny13 flashe,
blinkt bzw. flackert die LED mehr zufällig und unregelmäßig.
Ist das ein Problem im Programm, oder evtl. meinem Steckbrettaufbau?
Da ich mich erst seit ein paar Tagen mit der Materie beschäftige, bin
ich für Hinweise dankbar.
Gruß
Thomas
PS. beim Statement ".org OVF0addr" habe ich auch nirgends einen Hinweis
gefunden was OVF0addr heißt ...
1 | .include "tn13def.inc"
| 2 |
| 3 | .def tmp = r16
| 4 | .def leds = r17
| 5 | .def count = r18
| 6 |
| 7 | .org 0x0000
| 8 | rjmp main ; Reset Handler
| 9 | .org OVF0addr
| 10 | rjmp timer0_overflow ; Timer Overflow Handler
| 11 |
| 12 | main:
| 13 | ldi tmp, LOW(RAMEND) ; Stackpointer initialisieren
| 14 | out SPL, tmp
| 15 |
| 16 | ldi tmp, 0xFF ; Port B auf Ausgang
| 17 | out DDRB, tmp
| 18 |
| 19 | ldi leds, 0x00
| 20 |
| 21 | ldi tmp, 0b00000101 ; CS00 und CS02 setzen: Teiler 1024
| 22 | out TCCR0B, tmp
| 23 |
| 24 | ldi tmp, 0b00000010 ; TOIE0: Interrupt bei Timer Overflow
| 25 | out TIMSK0, tmp
| 26 |
| 27 |
| 28 |
| 29 | loop:
| 30 | cpi count, 0x00
| 31 | sei ; Interrupt erlauben
| 32 | breq led
| 33 | rjmp loop
| 34 |
| 35 | timer0_overflow: ; Timer 0 Overflow Handler
| 36 | dec count ; Zähler - 1
| 37 | ret
| 38 |
| 39 | led:
| 40 | out PORTB, leds
| 41 | com leds ; LED's umschalten
| 42 | ldi count, 7 ; Zähler setzen
| 43 | rjmp loop
|
Sichere mal in der ISR das SREG.
Dein SEI ist auch nicht im LOOP nötig, es reicht am Ende von MAIN, das
ist aber nicht das primäre Problem. Dann solltest Du die ISR aber auch
mit RETI abschließen, so wie sich das gehört.
Mehr habe ich auf die Schnelle nicht gefunden.
MfG, Bärli, blauer
> PS. beim Statement ".org OVF0addr" habe ich auch nirgends einen Hinweis
> gefunden was OVF0addr heißt ...
Den Hinweis findest Du, wenn Du Dir die entsprechende Include-Datei
anschaust.
> out PORTB, leds
> com leds ; LED's umschalten
Das ist zwar unlogisch (andersrum wär's logischer, erst invertieren,
dann ausgeben), funktioniert aber trotzdem.
MfG, Heidel-Bär
> Sichere mal in der ISR das SREG.
> Dein SEI ist auch nicht im LOOP nötig, es reicht am Ende von MAIN, das
> ist aber nicht das primäre Problem. Dann solltest Du die ISR aber auch
> mit RETI abschließen, so wie sich das gehört.
SREG in ISR sichern ???
... da muß ich erst nochmal Doku lesen ...
Thomas
Sollte jetzt vielleicht so aussehen?
1 | timer0_overflow: ; Timer 0 Overflow Handler
| 2 | in srsk,sreg
| 3 | dec count ; Zähler - 1
| 4 | out sreg,srsk
| 5 | reti
|
Funktioniert in der Simulation jedenfalls immer noch, aber Register srsk
bleibt dabei immer auf 0x00
Thomas M. wrote:
> SREG in ISR sichern ???
Jou, Dein Decrement beeinflusst die Flags im SREG. In der LOOP gibt's
'nen bedingten Sprung (wenn Zero-Flag gesetzt ist), wenn Dein Int exakt
zwischen CPI und BREQ zuschlägt, dann reagiert BREQ nicht mehr auf das
Flagsetzen, von CPI sindern auf das der ISR (DEC). Dass Du auch noch SEI
dazwischen gesetzt hast begünstigt dieses Verhalten noch (geringfügig).
> ... da muß ich erst nochmal Doku lesen ...
Gute Idee...
>
> Thomas
MfG, Heidelbär, blauer
Thomas M. wrote:
> Sollte jetzt vielleicht so aussehen?
>
> 1 | > timer0_overflow: ; Timer 0 Overflow Handler
| 2 | > in srsk,sreg
| 3 | > dec count ; Zähler - 1
| 4 | > out sreg,srsk
| 5 | > reti
| 6 | >
|
Jou, genau so. Oder so ähnlich.
>
> Funktioniert in der Simulation jedenfalls immer noch, aber Register srsk
> bleibt dabei immer auf 0x00
Nö, wenn aud 0 decrementiert wird, dann nicht.
Tip: Setze im Simulator einen Haltepunkt (F9) in die Routine LED, starte
die Simulation mit F5 und achte im I/O-Workspace auf die Zeiten.
Oder den Haltepunkt in die ISR. Dann kannst Du mit F5 durchsteppen und
kommst schneller zu der gewünschten Konstellation.
MfG, Bär, blauer
>>
>> Funktioniert in der Simulation jedenfalls immer noch, aber Register srsk
>> bleibt dabei immer auf 0x00
>
> Nö, wenn aud 0 decrementiert wird, dann nicht.
Der Wert für SREG ändert sich schon, aber das müßte ich nach "in
srsk,sreg" doch auch in sreg (habe ich auf r19 gesetzt) sehen, oder ?
Simulator mit F9 und F5 betätigen war ein guter Tip!
Leider blinkt die LED mit dem geänderten Programm immer noch nicht :-(
Thomas M. wrote:
> Der Wert für SREG ändert sich schon, aber das müßte ich nach "in
> srsk,sreg" doch auch in sreg (habe ich auf r19 gesetzt) sehen, oder ?
Ich verstehe nicht wie Du das meinst.
"in srsk,sreg" kopiert den Augenblickswert des SREG nach SRSK.
Danach darf die ISR das SREG verändern, die Kopie in SRSK bleibt
erhalten.
Am Ende der ISR stellt "out sreg,srsk" den alten Zustand (außer i-Flag,
das macht reti) wieder her, damit sich das Hauptprogramm nicht
veralbert, weil ihm die ISR das SREG (ein Flag davon) unterm Hintern
verstellt hat, falls der Interrupt genau zwischen Flagbeeinflussung
(CPI) und Flagabfrage (BREQ) zugeschlagen hat. Dieser Fall tritt selten
auf, man muss schon lange simulieren, um das zu bemerken, aber er tritt
auf und macht Unsinn. Also immer schön das SREG sichern, wenn ISR und
Hauptprogramm es verändern bzw. auswerten.
Achja, Dein AVR hat auch "untere Register". Die können zwar nicht mit
Konstanten operieren, sind aber trotzdem ganz brauchbar. R19 für die
SREG-Sicherung ist daher Ressourcenverschwendung.
>
> Simulator mit F9 und F5 betätigen war ein guter Tip!
>
> Leider blinkt die LED mit dem geänderten Programm immer noch nicht :-(
Ich habe es etwas umgestellt und halbwegs lesbar formatiert, im
Simulator läuft es. Einen Tiny13 habe ich dafür aber nicht geopfert.
Tip: Stelle mal unter Tools/Options/Editor die Tab-Schrittweite auf 4
ein und lass die Tabs durch Spaces ersetzen. Dann stimmt die
Formatierung auch bei der Darstellung durch Fremdprogramme (Browser).
MfG, BlauBär, trolliger
>> Der Wert für SREG ändert sich schon, aber das müßte ich nach "in
>> srsk,sreg" doch auch in sreg (habe ich auf r19 gesetzt) sehen, oder ?
>
> Ich verstehe nicht wie Du das meinst.
>
Im I/O View beim Simulieren bleibt r2 (srsk) immer auf 0 !?
Danke für die Programmrevision, sieht jetzt doch etwas professioneller
aus, obwohl ich prinzipiell doch gar nicht so falsch lag ...
...aber blinken tut's nicht. LED bleibt bei Deiner Version auf
Dauerlicht.
Wenn das program und verify vom attiny funktioniert kann er doch nicht
kaputt oder falsch angeschlossen sein?
Irgendwie brauch ich jetzt bald mal ein Erfolgserlebnis ...
Gruß Thomas
Thomas M. wrote:
> Danke für die Programmrevision, sieht jetzt doch etwas professioneller
> aus, obwohl ich prinzipiell doch gar nicht so falsch lag ...
Das ist noch lange nicht professionell. Aber immer langsam mit den
jungen Pferden... Ich hatte bewusst darauf verzichtet, darauf
hinzuweisen, dass man die Bits im I/O-Bereich besser mit ihrem Namen
anspricht.
> ...aber blinken tut's nicht. LED bleibt bei Deiner Version auf
> Dauerlicht.
Dann ist da was Anderes falsch.
Ich habe jetzt mal einen Tiny13 in mein STK500 gesteckt und das Programm
draufgeschossen, das geht wunderbar (Anhang). Die Blinkdauer beträgt
(wie im Simulator) etwa 1,5 Sekunden, die Pause auch. Es sollte also
auch bei Dir funktionieren.
> Wenn das program und verify vom attiny funktioniert kann er doch nicht
> kaputt oder falsch angeschlossen sein?
An welchem Pin ist Deine LED? ich habe an PB0 und PB1 LEDs dran, die
blinken wie gewünscht. Die anderen Portpins sind derzeit durch die
ISP-Anschlüsse blockiert.
>
> Irgendwie brauch ich jetzt bald mal ein Erfolgserlebnis ...
Dann checke Deine Hardware. Der Teufel (nicht der Robert) steckt meist
im Detail.
>
> Gruß Thomas
MfG, Troll, blaubäriger
>
> An welchem Pin ist Deine LED? ich habe an PB0 und PB1 LEDs dran, die
> blinken wie gewünscht. Die anderen Portpins sind derzeit durch die
> ISP-Anschlüsse blockiert.
>
LED ist an PB0
>
> Dann checke Deine Hardware. Der Teufel (nicht der Robert) steckt meist
> im Detail.
>
Habe den Aufbau nochmal mit einem M8 auf dem Steckbrett aufgebaut und
das Programm dafür umgestrickt. Das hat im Prinzip funktioniert, aber
sehr unzuverlässig je nachdem an welchem Kabel ich gewackelt habe...
Ich denke, ich werde die paar Teile besser zusammenlöten. Das STK500 hat
schon seine Vorteile!
Ich verstehe aber immer noch nicht, warum im I/O View beim Simulieren
der r2 (srsk) immer auf 0 bleibt, er sollte doch den Wert von SREG
annehmen?
Gruß
Thomas
Thomas M. wrote:
> Habe den Aufbau nochmal mit einem M8 auf dem Steckbrett aufgebaut und
> das Programm dafür umgestrickt. Das hat im Prinzip funktioniert, aber
> sehr unzuverlässig je nachdem an welchem Kabel ich gewackelt habe...
Nunja, solche Wackelkonstruktionen macht man nicht. Den Chip steckt man
in eine Präzisionsfassung, dann mit Fassung in das Steckbrett. Dann
achtet man darauf, dass man das Steckbrett nicht durch zu dicke Drähte
(Dioden) ausgrackelt.
Hast Du wenigstens Keramik-Kondensatoren (100nF) an der Betriebsspannung
(ganz dicht am AVR)?
> Ich denke, ich werde die paar Teile besser zusammenlöten.
Steckbrett ist schon ok, wenn man es ordentlich benutzt. Ich habe auch
einige Steckbretter im Einsatz.
> Das STK500 hat
> schon seine Vorteile!
Gutes Werkzeug hat aber auch seinen Preis.
>
> Ich verstehe aber immer noch nicht, warum im I/O View beim Simulieren
> der r2 (srsk) immer auf 0 bleibt, er sollte doch den Wert von SREG
> annehmen?
R2 nimmt den Wert von SREG an, den SREG exakt im Moment der Zuweisung
hatte. Zwischendurch und von alleine ändert sich der Inhalt von r2
nicht. Da Dein Programm noch sehr klein ist und wenige bedingte Sprünge
hat, ist das im Moment in der ISR (i-Flag gelöscht) der Wert 0.
Warum arbeitest Du mit I/O-View? Schau Dir mal das Watch-Fenster an
(Anhang).
>
> Gruß
> Thomas
Mfg, Troll, bärisch Blauer
>
> R2 nimmt den Wert von SREG an, den SREG exakt im Moment der Zuweisung
> hatte. Zwischendurch und von alleine ändert sich der Inhalt von r2
> nicht. Da Dein Programm noch sehr klein ist und wenige bedingte Sprünge
> hat, ist das im Moment in der ISR (i-Flag gelöscht) der Wert 0.
>
Jetzt hab ich's kapiert, ich hatte den Breakpoint immer bei den LED's
gesetzt, da war sreg natürlich nicht 0, wurde aber auch nicht auf srsk
gesichert.
Ich werde mich dann mal mit der Hardware beschäftigen ...
Vielen Dank für die Hilfe!
Gruß
Thomas
Thomas M. wrote:
> Jetzt hab ich's kapiert, ich hatte den Breakpoint immer bei den LED's
> gesetzt, da war sreg natürlich nicht 0, wurde aber auch nicht auf srsk
> gesichert.
Schau Dir auch mal im Menü Debug/New Breakpoint/Data Breakpoint an.
Damit kannst Du anhalten, wenn ein von Dir vorbestimmtes Ereignis
eintritt (Variablenänderung, I/O-Konstellation usw.).
>
> Ich werde mich dann mal mit der Hardware beschäftigen ...
Mach das, Wackelkontakte taugen nix.
MfG, Bb.
>
> Mach das, Wackelkontakte taugen nix.
>
Mit dem neuen Steckbrett läuft alles wie geschmiert! Das alte lag wohl
doch zu lange im Keller rum ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|
Thread beobachten
Seitenaufteilung abschalten