[c/AS6] Debugowanie kodu C dla AVR: problem z SPI i przerwaniami w symulatorze

Witam.
wcześniej w mikrokontrolerach avr korzystałem z assemblera (co pomogło mi dobrze poznać ukłądy "od środka"). Jednak nadszedł czas aby skorzystać z dobrodziejstw języka C (w tym języku pisałem wcześniej programy komputerowe). schody zaczęły się już na początku.
po napisaniu kolejnych fragmentów kodu uruchamiałem symulator żeby zobaczyć czy poprawnie działa, kolejność pisania:
przerwanie CTC timera co 1ms[działa]
next_sec()- działa
ledmux()- działa
dodałem SPI- przestało działać, po instrukcji sei() program skakał do instrukcji spi_buff[0]=0xaa;//enable>>8;
więc zajrzałem do okna disassembly:

jak widać kolejność instrukcji się zmieniła. pomogło na to jedynie ustawienie w opcjach braku optymalizacji. Ale wtedy po kilku wykonaniach pętli while kasowane jest zezwolenie na przerwania (bit I rejestru SREG).

Czy ktoś wie dlaczego tak się dzieje? błąd w kodzie czy to może błędne działanie symulatora?

dodam jeszcze że program miał pełnić funkcję zegara, multipleksowanie na 74hc595.
Korzystam z Atmel studio i wbudowane w niego narzędzia.
Atmel Studio 6 (Version: 6.1.2440 - beta)
Atmel AVR (8 bit) GNU Toolchain - 3.4.2.876

Jeszcze przy zmiennych występujących w przerwaniach dodaj modyfikator volatile.

Zastanów się jak działa ten program. Na początku status==0, więc to co masz po if nigdy się nie wykona. Dlaczego? Bo z logicznej analizy tego kodu wynika, że status zawsze będzie równy zero! W efekcie optymalizator wywala całą tą sekwencję. Kompilator nic nie wie o tym, że status zmieniasz w przerwaniu, bo mu o tym nie powiedziałeś. Magiczne zaklęcie: volatile.

pomogło dziękuję.

Dodano po 39 [minuty]:

jako że kasowanie zezwolenia na przerwania (bit I rejestru SREG) jest kasowany po wykonaniu instrukcji:
RJMP PC+0x0006
podejrzewam że jest to błąd symulatora, co o tym sądzicie? (w tej chwili nie mam dostępu do procka więc nie mam jak sprawdzić.)

Pokaż ten fragment kodu. Jeśli kasowanie jest po rjmp to i tak nigdy się nie wykona. Najpewniej jest to fragment kodu dodawany przez bibliotekę AVR-libc, odpowiedzialny za reakcję na wyjście z pętli głównej. Atrybut OS_main załatwia sprawę - skróci kod, ale tak czy siak, program działa poprawnie.

kod programu:

Wydruk z okna disassembly:



teraz skorzystałem zoptymalizacji dla rozmiaru -Os i zezwolenie jest kasowane w linii "0000015F LDS R24,0x0075", czyli na początku pętli while.
Po południu sprawdze na rzeczywistym procku bo wg mnie nie powinno byś takiej możliwości żeby tutaj się ta flaga kasowała.

Sprawdziłem w symulatorze wbudowanym w AVR Studio 4.18 i wszystko działa poprawnie. więc to wina symulatora.

Ale co ci się nie podoba? Ta instrukcja CLI? Ona się nigdy nie wykona, jest to wstawiane przez bibiotekę AVR-libc jako reakcja na wyjście z pętli głównej i w efekcie zakończenie wykonywania funkcji main, która nigdy nie powinna się kończyć. W efekcie te instrukcje cię nie interesują.

W tej chwili nie pasuje mi że w symulatorze AtmelStudio z niewiadomego powodu kasuje się flaga globalnego zezwolenia na przerwania, A gdy skorzystam z symulatora w AVR studio 4 to wszystko działa tak jak powinno.

edit:
w linni

pokazuje mi się ostrzeżenie:

co on oznacza?

Hmm, kiedyś Atmel Studio miało błąd związany z kasowaniem tej flagi, ale błąd ten naprawiono, być może powrócił w AS 6.1beta. Sprawdź czy w AS6 z SP też występuje.
Co do ostrzeżenia - tablica składa się z elementów o typie char, a SPDR pewnie ma typ uint8_t. Można to zignorować, zastosować jawne rzutowanie, lub zmienić typ elementów.

dla symulacji wstawiam sei() na końcu pętli i jakoś to jedzie.
zmiana typu zmiennych na uint8_t zlikwidowała warning.

Widzę dokładnie ten sam problem.
AS6 natychmiast po wykonaniu SEI kasuje SREG.I

Czyli wygląda to na stary bug w AS, któy odżył. W AS 6.1 też jest? Jeśli tak to warto by zgłosić regression na stronie Atmela.