Zmienne globalne wykorzystywane przez przerwania i inne.

Cześć.
Na stronie o przerwaniach zewnętrznych http://akademia.nettigo.pl/arduino_przerwania/
jest napisane coś takiego
"Zwróć uwagę na problem komunikacji w drugą stronę. Jeżeli program w loop miałby zmieniać wartość zmiennych używanych przez funkcję obsługującą przerwania, to warto zapewnić by przerwanie nie zaskoczyło programu w momencie modyfikacji zmiennej. Jeżeli jest to operacja złożona z więcej niż jednej komendy kodu maszynowego procesora, może się zdarzyć, że przerwanie zostanie wywołane "pośrodku" i jako rezultat stan zmiennej będzie błędny."

Ale z operacjami atomowymi już z czymś podobnym się spotkałem w javie
https://www.samouczekprogramisty.pl/watki-w-jezyku-java/

tu piszą
"Tutaj należy Ci się kolejne wyjaśnienie. Operacja atomowa to taka operacja, która jest niepodzielna. Operacja atomowa realizowana jest przy pomocy jednej instrukcji w bytecode (w skompilowanej klasie). Operacja value += 1 nie jest operacją atomową, jest ona równoważna z value = value + 1. Wykonanie tej operacji składa się z kilku kroków:
a)pobrania aktualnej wartości value do zmiennej tymczasowej (niewidocznej w kodzie źródłowym)5,
b)dodania 1 do zmiennej tymczasowej,
c)przypisanie powiększonej wartości do value."

Zastanawiam czy czy ta zmienna w przerwaniu będzie błędna w sensie, że np zamiast 1 będzie 99992323 czy w takim sensie błędna że nie aktualna(volatile nie pomoże w tym przypadku).(w przerwaniu tylko odczyta się zmienną globalną).

Celowo podaję że zmienna w przerwaniu nie jest modyfikowana bo jak by chyba wystąpi chyba to samo zjawisko opisane na stronie o javie.?

Np w trakcie aktualizacji int >=16 bitów na AVR, pomiędzy jednym a drugim bajtem wskoczy przerwanie.
Przerwanie zobaczy zmienną pól słowa starszego, pól nowego. Obie polówki <w jakimś sensie> sensowne, tzn dające się uzasadnić - nie jest to wartośc randomowa - ale realnie bezsensowna

Przyjmijmy, ze aktualizacja jest z 0x1234 na 0x789A.
Przerwanie zobaczy 0x129A (ewentualnie 0x7834)

Dodano po 5 [minuty]:

prawdziwa tragedia się zaczyna, jak procedura przerwania też chce aktualizować

Błędy są tym bardziej bolesne, bo rzadkie. One nie wyjdą na przypadkowych, nawet dość obszernych testach, tylko na "produkcji"

JacekCz napisał:

Np w trakcie aktualizacji int >=16 bitów na AVR, pomiędzy jednym a drugim bajtem wskoczy przerwanie.
Przerwanie zobaczy zmienną pól słowa starszego, pól nowego. Obie polówki <w jakimś sensie> sensowne, tzn dające się uzasadnić - nie jest to wartośc randomowa - ale realnie bezsensowna

A w przypadku kiedy używam zmiennej byte 8 bitowej jak procesor 8 bitowy AVR ? to tu nie zajdzie to co powyżej napisałeś?

A nie lepiej na czas modyfikacji zmiennej wyłączyć na moment odpowiednie przerwanie ?

kamil3211 napisał:

A w przypadku kiedy używam zmiennej byte 8 bitowej jak procesor 8 bitowy AVR ? to tu nie zajdzie to co powyżej napisałeś?

jednosttronna aktualizcja takiej zmiennej jest bezpieczna *) - przerwanie widzi stary lub nowy stan, ale spójny.
Dwustronna nadal nie.


*) jakbyś dłużej romansował z ekosystemem Javy, zauważysz, że programiści bardzo cenią klasy niezmiennicze, immutable. Bezpieczeństwo przy wątkach, to jeden z istotnych powodów.

krzysiek_krm napisał:

A nie lepiej na czas modyfikacji zmiennej wyłączyć na moment odpowiednie przerwanie ?

Faktycznie.
Ale jeśli będzie jak ze zmienną 8 bitową na 8 bit procesorze to będę wiedział, że nie trzeba. i trochę mniej mocy zmarnuję.

krzysiek_krm napisał:

A nie lepiej na czas modyfikacji zmiennej wyłączyć na moment odpowiednie przerwanie ?

Tak.
To jest węższy sposób z szerszej grupy "synchronizacja".

W bardziej złożonym systemie ciężko będzie wskazać to jedno przerwanie, o które chodzi

Zamiast analizować skutki lepiej jest po prostu zadbać, aby taka operacja nie została zaburzona przerwaniem. W AVRach masz do tego celu udostępnioną całą bibliotekę - atomic.h:
https://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html

Nie zastanawiać się i zawsze wstawiać atomic block? Etam...
Można sobie wyobrazić funkcję zabezpieczoną blokiem z atrybutem RESTORE, która jest wyoływana zarówno w mainie jak i przerwaniu. I co? Można sobie zrobić kuku, nieprawdaż?

ex-or napisał:

Można sobie wyobrazić funkcję zabezpieczoną blokiem z atrybutem RESTORE

I co ma się niby stać? Bo jakoś nie widzę tutaj żadnego "kuku".

khoam napisał:

Może wystąpić problem, jeżeli zmienna 8-bitowa będzie tymczasowo przechowywana w rejestrze MCU, a nie w pamięci. W tym wypadku akurat pomaga specyfikator volatile na taką okoliczność.

Czy mógłbyś ten problem bardziej opisać bo ja myślę że jedyny to taki że jest większa szansa że zmienna będzie nie aktualna.

excray napisał:

I co ma się niby stać?

Przedwczesne odblokowanie przerwań.

Tu kiedy zmienna globalna jest NIE volatile to tylko nie aktualna zmienna może się zdarzyć ? kiedy akurat trafi się pomiędzy operacje atomowe przypisania w pętli loop ? Wcześniej złe wysłałem.
te liczba++; widzę tak:

1. pobranie liczba do zmiennej tymczasowej.
2. w zmiennej tymczasowej dodanie 1
3. przypisanie do liczba;
a przerwanie wykona się pomiędzy 2 i 3

oczywiście celowo zrobiłem nie volatile ale zawsze z przerwaniami ją daję . Może te kroki wyglądają inaczej ?

ex-or napisał:

Przedwczesne odblokowanie przerwań.

To najwyraźniej nie rozumiesz do końca tego, jak działa parametr ATOMIC_RESTORESTATE.

Chyba jak Pan pisał to ja zmodyfikowałem zdjęcie bo złe dałem. A Pan myślał o tym przypisaniu 0 lub 1 ze starego.

Skąd pan to wie ? a co by było gdyby +=2; ?

excray napisał:

jak działa parametr ATOMIC_RESTORESTATE

No dobra, niech będzie, ze palnąłem głupstwo. Odblokowanie nastąpi przy FORCEON.
Co nie zmienia faktu, że brak namysłu nad tym co się robi jest...zresztą nieważne.

Nie da się jakoś podglądnąć tego co wypluje kompilator??? ja podglądnąłem coś takiego z pliku z rozszerzeniem hex (to tylko część) ale to nie po ludzku
:100000000C9435000C9455020C942E020C945D0057
:100010000C945D000C945D000C945D000C945D00EC
:100020000C945D000C945D000C945D000C945D00DC
:100030000C945D000C945D000C945D000C945D00CC
:100040000C94E4010C945D000C94B2010C948C01AE
:100050000C945D000C945D000C945D000C945D00AC
:100060000C945D000C945D00070311241FBECFEFBC
:10007000D8E0DEBFCDBF11E0A0E0B1E0E8E7F6E0F8
:1000800002C005900D92A631B107D9F721E0A6E193
:10009000B1E001C01D92AD3BB207E1F710E0C5E34E
:1000A000D0E004C02197FE010E943403C433D1077D
:1000B000C9F70E947C020C943A030C940000089546
:1000C000AF92BF92CF92DF92EF92FF920F931F9366
:1000D000CF93DF936C017B018B01040F151FEB01A4
:1000E0005E01AE18BF08C017D10759F06991D6015B

kamil3211 napisał:

Nie da się jakoś podglądnąć tego co wypluje kompilator??? ja podglądnąłem coś takiego z pliku z rozszerzeniem hex (to tylko część) ale to nie po ludzku

Powinien być jakiś "asm".

Znalazłem było ale pod rozszerzeniem .lst jakiś NASM Listing
to fragment z loop ale więcej tego było
void loop()
{
liczba++;
1b8: 80 91 09 01 lds r24, 0x0109 ; 0x800109 <liczba>
1bc: 8f 5f subi r24, 0xFF ; 255
1be: 80 93 09 01 sts 0x0109, r24 ; 0x800109 <liczba>
delay():
#endif // 0
}

zrobiłem to dla programu takiego

byte liczba;
void setup()
{}
void loop()
{
liczba++;
delay(5000);
}

a kiedy byte zmieniłem na int(16bit) to coś takiego
void loop()
{
liczba++;
1b8: 80 91 09 01 lds r24, 0x0109 ; 0x800109 <liczba>
1bc: 90 91 0a 01 lds r25, 0x010A ; 0x80010a <liczba+0x1>
1c0: 01 96 adiw r24, 0x01 ; 1
1c2: 90 93 0a 01 sts 0x010A, r25 ; 0x80010a <liczba+0x1>
1c6: 80 93 09 01 sts 0x0109, r24 ; 0x800109 <liczba>
delay():
#endif // 0
}

No a gdzie przerwanie?

usunąłem chciałem zobaczyć ile operacji atomowych generuje inkrementacja.

khoam napisał:

Inkrementacja zmiennej 8-bitowej to też operacja atomowa.

Może i jest.
W moim własnym projekcie bałbym się korzystać. Szczegóły się zapomną, za długi czas kod będzie miał dalsze życie itd ... cho cby skoiowany do następnego projektu.
Jest w kodzie widoczna synchronizacja, to się inaczej to czyta (ja jestem z tych, co uznają kod PO PIERWSZE dla czytajacego, dopiero po drugie dla kompilatora)

moje zdanie