ATtiny13 und Studio4 in Assembler

[MagicWSmoke]

..., aber könnte es sein, daß das grüne push fehlt oder das rote pop zuviel ist?

Nein, nur vertauscht, richtig wär's so:

TIM0_OVF:
push    r16
in      r16,SREG
dec     r17
out     SREG,r16
pop     r16
reti

Der Originalcode:

pop    r16
out    SREG,r16

stellt dagegen SREG mit einem Wert wieder her, den R16 beim Aufruf des Interrupts hatte, was für kreatives Verhalten des Codes sorgt.

[hegewald]

Hallo Macig,
den Cod
TIM0_OVF:
push r16
in r16,SREG
dec r17
out SREG,r16
pop r16
reti
hatten mir die Provis vom www.mikrocontroller.net vorgegeben, und daran habe ich mich dann gehalten.
SREG ist doch ein Register (Bit7=I) =sei, wenn gesetzt, läuft der Overflow ständig.
Was mich nun beschäftigt, die Zeiten von 20 | 30 | 40 Minuten zu realisieren...das wird noch an Zeit kosten.
Toleranzen sehe ich mit +/- 5%

Grüße

Rolf

[MagicWSmoke]

Hallo Hegewald,

TIM0_OVF:
push r16
in r16,SREG
dec r17
out SREG,r16
pop r16
reti
hatten mir die Provis vom www.mikrocontroller.net vorgegeben, und daran habe ich mich dann gehalten.

Dieser Code jetzt entspricht dem von mir berichtigten.

Vergleich' dazu Dein Post Nr. 6 dieses Threads:

;Interrupt-ISR
TIM0_OVF:    push    r16
            in        r16,SREG
            dec        r17
            pop        r16
            out        SREG,r16
            reti

Nur darum ging's, das ist falsch.
Betrachte genau wo R16 gepoppt wird und wo in's SREG heschrieben wird.

[hegewald]

Hallo Macig,
hast Recht, hier war ein Dreher, in meinen Quelltext habe ich es nochmal kontrolliert.
Habe mich mit den PUSH / POP nochmal über Bücher informiert.
Danach würde doch der Ablauf so aussehen:
push r16 ; push kopiert den Inhalt von r16 auf die durch den Stapelzeiger SP adressierte SRAM Speicherstelle
; und vermindert den SP um 1
Nun steht hier weiter für den Mega8:
Der Stapelzeiger (das ist doch eine Adresse im SRAM-Bereich,oder?) wird sofort nach dem Start des Programms
auf die höchste SRAM Adresse gesetzt. In der Deklarationsdatei m8def.inc vordefiniert auf Adresse RAMEND=$045F.
Wie das beim Tiny13 aussieht, kann ich nicht erkennen, oder Datenblatt ranholen.

pop r16 ; pop erhöht erst den Stapelzeiger SP um 1 und lädt dann r16 mit dem adressierten SRAM-Byte

Interessant ist auch, daß die Befehle rcall / icall / call und Inter. die aus 2 Bytes besteh. Rücksprungadresse
auf den Stapel legen, und automatisch durch ret bzw. iret wieder entfernt werden.
Wie gesagt, man schreibt im Quelltext notorisch so viele Befehlsabläufe und wies eigentlich garnicht, was da so
richtig passiert. Alles ist natürlich auch eine Zeitfrage um sich mit der Materie zu beschäftigen.
Ich als Rentner habe die Zeit, und der Geist bleibt dadurch in Bewegung.

Das wars erst mal, hoffentlich langweilt Dich dieses Thema nicht.

Grüße

Rolf

[MagicWSmoke]

das ist doch eine Adresse im SRAM-Bereich,oder?

Ja. Variablen wachsen von niedriger Adresse nach hoher Adresse, der Stack von hoher nach niedriger Adresse.
Wenn der Stackverbrauch zu groß wird, z.B. durch rekursiven Code, dann wächst er in die Variablen hinein und es gibt Datensalat.

Wie das beim Tiny13 aussieht, kann ich nicht erkennen, oder Datenblatt ranholen.

RAMEND ist je nach Prozessortyp und dessen SRam-Größe an anderer Adresse, das Prinzip bleibt zumindest bei den hier besprochenen Prozessoren immer gleich.

Interessant ist auch, daß die Befehle rcall / icall / call und Inter. die aus 2 Bytes besteh. Rücksprungadresse
auf den Stapel legen, und automatisch durch ret bzw. iret wieder entfernt werden.

Der Stack arbeitet nach dem LiFo-Prinzip, last in, first out.

Das wars erst mal, hoffentlich langweilt Dich dieses Thema nicht.

Nein, sonst hätte ich ja nicht geantwortet. Wobei Du mir zur Funktion aber sicher nix Neues sagen kannst