Frage zur Verwendung von "volatile"

Hannes schrieb:
> 1) Wenn ich eine Variable global deklariere, sie aber nur innerhalb
> einer einzigen Interrupt-Funktion verwende, muss ich diese dann auch mit
> "volatile" deklarieren ?
Nein.
Volatile sagt dem Compiler, dass sich die Variable im Programmverlauf 
"von aussen" ändern kann. Volatile müssen nur die Variablen sein, die 
sich "unvohergesehen" ändern können.

> 2) Wenn ich eine Variable global deklariere und diese in
> unterschiedlichen Interrupts verwende (nicht jedoch in der Mainloop!),
> muss ich diese dann auch mit "volatile" deklarieren? Wir gehen davon
> aus, dass eine ISR nicht durch eine andere ISR unterbrochen werden kann.
Nein, weil sie sich nicht "von aussen unvorhergesehen" ändern kann. 
Somit darf der Compiler diese Variable auch in der ISR lokal optimieren.

1) Nein
2) Ja (der Compiler weiß ja nicht, wann ein Zugriff in einer ISR war)

Sicherheitshalber noch der Hinweis, dass "volatile" kein Allheilmittel 
ist. Bei Variablen mit mehr als 1 Byte Grösse, die in main() und im 
Interrupt verwendet werden, empfiehlt es sich, den Zugriff mit "atomic 
block" zu schützen.

Peter II schrieb:
> Teo D. schrieb:
>> 2) Ja (der Compiler weiß ja nicht, wann ein Zugriff in einer ISR war)
> nein, muss er auch nicht, weil beim Start einer isr immer die Daten aus
> Ram laden muss. (und am ende wieder wegschreiben)

Jo, wenn man genauer drüber nachdenkt....

Peter II schrieb:
> nur Variablen die in er Main verwendet werden und in einer ISR geändert
> werden müssen volatile sein.

Immer diese falsche Einschränkung, die man immer wieder ließt.
Es spielt keine Rolle, wo geändert und wo nur gelesen wird.
Es kommt zwar deutlich seltener vor, dass eine Variable in Main geändert 
und in der ISR nur gelesen wird, aber auch dann muss sie volatile sein.

Hannes schrieb:
> Was macht der Compiler genau, wenn ich eine Variable im
> Interrupt als 'static' deklariere? Wo ist der Unterschied zu einer ganz
> normalen Deklaration innerhalb der ISR?

Eine normale Variablendeklaration innerhalb einer Funktion (also auch 
innerhalb einer ISR) wird automatisch genannt. Die Variable landet auf 
dem Stack, d.h. sie verliert beim Beenden der Funktion ihren Wert und 
ist beim Aufruf der Funktion auch nicht initialisiert (d.h. es kann 
beliebiger Unfug drinstehen).

Wird eine Variable innerhalb einer Funktion als static deklariert, 
entspricht das einer globalen Variablen, d.h. sie landet nicht auf dem 
Stack, sondern ist dem Linker bekannt (und Du erhältst Deine 
Informationen über den RAM-Verbrauch). Die Variable behält auch über 
mehrere Funktionsaufrufe hinweg ihren Wert, verhält sich also genau so 
wie eine globale Variable.
Die Variable ist aber außerhalb der Funktion nicht "sichtbar", d.h. auf 
sie kann nicht von anderen Orten über ihren Namen zugegriffen werden.

Zu guter letzt: Eine Variable, die außerhalb einer Funktion als static 
deklariert wird, ist nur innerhalb der zugehörigen C-Übersetzungseinheit 
sichtbar, d.h. aus anderen C-Übersetzungseinheiten kann nicht auf sie 
über ihren Namen zugegriffen werden. Davon abgesehen verhalten sich auch 
diese Variablen wie globale Variablen.

Hallo Hannes,
Georg hat mit seinem Kommentar recht:
Georg G. schrieb:
> Sicherheitshalber noch der Hinweis, dass "volatile" kein Allheilmittel
> ist. Bei Variablen mit mehr als 1 Byte Grösse, die in main() und im
> Interrupt verwendet werden, empfiehlt es sich, den Zugriff mit "atomic
> block" zu schützen.
auch wenn jemand meinte, ihn negativ zu bewerten zu müssen.

Aus der AVRlibc Doku:

1

#include <inttypes.h>

2

#include <avr/interrupt.h>

3

#include <avr/io.h>

4

#include <util/atomic.h>

5

volatile uint16_t ctr;

6

ISR(TIMER1_OVF_vect)

7

{

8

  ctr--;

9

}

10

...

11

int

12

main(void)

13

{

14

   ...

15

   ctr = 0x200;

16

   start_timer();

17

   sei();

18

   uint16_t ctr_copy;

19

   do

20

   {

21

     ATOMIC_BLOCK(ATOMIC_FORCEON)

22

     {

23

       ctr_copy = ctr;

24

     }

25

   }

26

   while (ctr_copy != 0);

27

   ...

28

}

ATOMIC_BLOCK(..) sperrt Int's für die Dauer des Blocks.

ATOMIC_FORCEON
ist für den Fall daß Int's hinterher freigegeben sein sollen, 1 Register 
und 2..3 Befehle kürzer als
ATOMIC_RESTORESTATE,
was der SREG-Zustand sicher und am Ende wieder den alten SREG-Zustand 
herstellt.

W.S. schrieb:
> Carl D. schrieb:
>> ATOMIC_BLOCK(..) sperrt Int's für die Dauer des Blocks.
>
> Ähemm.. nun, die AVR-Leute machen das eben so, allerdings halte ich es
> für einen doch eher unüberlegten Programmierstil, mit dem Aus- und
> Einschalten der Interrupts um sich zu werfen. Auf größeren Systemen
> macht man sowas nicht und dort, wo es irgend ein OS gibt, erst recht
> nicht.

Ja, auf Mainframes hab ich das auch nie gemacht, aber es geht hier um 
einen AVR, der zwischen jedem Lesen eines Bytes einer Mehrbyte-Variable 
aus dem RAM durch einen Interrupt unterbrochen werden kann. Und dann hat 
man ein "geht meistens"-Programm. Also besser verstehen, was passieren 
kann und gleich richtig machen.
BTW, ein AVR-Leut bin ich dann, wenn ich es mit dem AVR zu tun habe. Ich 
kann aber auch ARM-Leut, x86/x64-Leut, /370-Leut, ... Und in jedem Fall 
muß man die Besonderheiten der HW beachten.
Aber was red ich, das weißt du sicher selbst.

Und Lock-Free macht eigentlich nur Sinn, wenn man mehrere Cores hat, die 
auch wirklich parallel zugreifen. AVR!