To już się robi tak zagmatwane że tylko .lss całości może rozwiązać wszelkie wątpliwości. 🙂
Z wrzuconego kodu Bit_send, bez wglądu w całość, ciężko również wywnioskować co właściwie ma robić lub jaki ma efekt wrzucanie rejestrów na stos bez żadnego kodu do ich zdejowania:
$asm
Bit_send:
ldi r17, Ile_ledow
clr R18
clr r19
;****************************************
LDI XL , LOW(LABEL3)
LDI XH , HIGH(LABEL3)
PUSH XL <-------------------
Push XH <------------------
LDI XL , LOW(LABEL2)
LDI XH , HIGH(LABEL2)
PUSH XL <-------------------
Push XH <------------------
LDI XL , LOW(LABEL1)
LDI XH , HIGH(LABEL1)
PUSH XL <-----------------
Push XH <-----------------
IN R23, SPL <--- SP jest ładowany już po wrzuceniu danych na stos
in R24, sph
Led_loop_:
...
A wracając do tematu dyskusji; to jeśli przerwanie wywołuje podprogram który czeka w pętli nieskończonej na kolejne przerwanie, to nie tylko musisz zdejmować ze stosu adresy powrotu zarówno w przerwaniu jak i w podprogramie czy tablice alokowane na stosie(SP), ale również zrzucone rejestry na wejściu do przerwania.
Coś takiego to tylko w assemblerze się widuje gdzie ma się pełną kontrolę nad stosem a nie w BASCOM'ie.
Oczywiście pomijam możliwość zastosowania "chińskich jednostek", przez alternatywnego producenta, gdzie 2kB to w rzeczywistości 1 kB i objawia się to właśnie nachodzeniem stosu na zmienne. 😉