mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bei welchen Variablen sollte man volatile verwenden


Autor: Philipp Mayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Hab eine kleine Anfängerfrage.
Bei welcher Art von Variablen muss man volatile als Zusatz verwenden?

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Typqualifizierer volatile verwendet man, wenn eine globale Variable
auch in Interrupt-Handlern geändert werden soll.

Autor: Philipp Mayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke sehr

Autor: Dante (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessante Frage!


Was passiert wenn 'volatile' nicht angegeben wird.

Autor: Wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann kann es sein, dass der Compiler auf der Variablen Optimierungen
durchführt, sie z.B. in einem Register für mehrfache Verwendung
zwischenspeichert. Daher ist der Code dann schneller und oft auch
kleiner.

Aber: Wenn die Variable z.B. in einer Timer-Interruptroutine geändert
wird, dann bekommt das Huptprogramm nicht von der Änderung mit, weil es
ja nicht die RAM-Zelle sondern das Zwischenspeicherregister liest, das
sich aber nicht ändert.

Folgender Code in main produziert dann eine Endlosschleife, wenn ticks
nicht volatile ist:

while(ticks < 50)
   ;

(Vorausgesetzt, dass ticks von einem Timer-ISR inkrementiert wird.)


    Wiesi

Autor: Dante (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, Danke!

Dann muss ich schnell noch einige 'volatils' nachtragen.




Schönen Gruß   Dante

Autor: M&M's (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch mal kurz zum Durchüberlegen:

Man muss also bei jeder Variable die in einer ISR vorkommt ein volatile
davor setzen.

Also z.B.

unsigned char xx=0;


Timer ISR:
xx=5;

void main (void)
{
bb=xx;
}

kommt dann 0 für bb heraus, da ich ja kein volatile verwendet hab.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es muss gar nichts passieren. Es hängt davon ab, wie viele Variablen im
Programm verwendet werden und was der Compiler daraus macht. Ein
durchschnittlicher Compiler versucht, so viele Variablen wie möglich im
Registersatz abzulegen, um die Geschwindigkeit zu optimieren. Da aber
beim Einsprung in einen Interrupt Handler (ISR) die verwendeten
Register gesichert und hinterher wieder neu geladen werden, kann ein
Zugriffsversuch aus einer ISR ohne Ergebnis bleiben. 'volatile' tut
eigentlich nicht viel anderes als dem Compiler mitzuteilen, dass er die
entsprechende Variable nicht im Registersatz sondern im SRAM ablegen
soll, was natürlich auf Kosten der Geschwindigkeit geht, was aber bei
den paar Zugriffen in einem durchschnittlichen Programm zu verschmerzen
ist.

Autor: M&M\'s (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn eine Variable nur in ISR's vorkommt.
Also z.B: in ADC-ISR und in Timer-ISR, aber nicht in Main
Muss man dann auch volatile machen?

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man braucht volatile immer dann, wenn die Variable außerhalb der
aktuellen Funktion zwischendurch geändert werden kann. Also wenn eine
Variable im Hauptprogramm von einem Interrupt unterbrochen wird, beim
Multitasking/Multithreading bzw. bei mehreren CPUs, usw. Aber auch bei
RAM das nicht nur vom Programm geändert wird, also z.B. einem
DMA-Buffer oder bei Memory-Mapped I/O.

Verwendet man eine Variable nur in einer Interruptfunktion, dann
braucht sie nicht volatile sind. Verwendet man sie in zwei
Interruptroutinen, die sich gegenseitig unterbrechen können, dann
schon.

Markus

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte heißen:
Verwendet man eine Variable nur in einer Interruptfunktion, dann
braucht man sie nicht volatile machen.

Autor: M&M's (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachteile gibts aber keine wenn ich zu viele volatiles mache, oder?
Abgesehn von der Geschwindigkeit.

Autor: struberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und wenn eine Variable nur in ISR's vorkommt.
> Muss man dann auch volatile machen?
Nein, natürlich nicht

volatile bringt es nur, wenn die Variable in einm 'multithreaded'
environment verwendet wird um zwischen den einzelnen prozessen Daten
auszutauschen/sharen.

Alle übrigen Variablen brauchen nicht volatile zu sein.

Aber ACHTUNG: volatile ist nur der erste Schritt! Um für eine IPC
(inter process communication) ein stabile data interaction zu bekommen
braucht man eventuell eine Art semaphore handling!
Auf diese kann nur dann verzichtet werden, wenn die Dateneinheit in
einem atomic step geschrieben und gelesen werden kann.

Beispiel:

In einem Programm eines AVR (bekanntlich ein 8-bitter) wir eine 4-Byte
langer Zähler ausgelesen.
Aktueller Stand: 0x 00 ff ff ff
Das Lesen beginnt mit dem LSB (least significant bit/byte).

Vor dem Lesen des letzen (höchsten) Bytes wird der Zählerinterrupt
ausgelöst. (aktueller Stand im Programm: 0x .. ff ff ff

Die ISR (interrupt service routine) inkrementiert den 4-Byte langen
Zähler auf den neuen Wert 0x 01 00 00 00
Danach wird die ISR mit iret beendet.

Das Programm macht also genau an der Stelle weiter wo es aufgehört:
Beim Lesen des höchsten Byte, wo nun aber nicht mehr 0x00 sondern 0x01
drinnen steht.

Das Programm liest also in Summe den Wert 0x 01 ff ff ff ( die 3
niederen Bytes waren ja schon eingelesen)!

Dss ist ein Fehlbetrag von 16,777.215
Wären das die Sekunden einer Uhr, würden wir uns um 4660 Stunden also
um ganze 194 Tage verrechnet haben ^^

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, die Geschwindigkeit ist der einzige Nachteil.

Aber das Problem sollte doch sowieso nur bei globalen Variablen
auftreten, d.h. es bringt nichts, wenn Du jetzt einfach alle Variablen
volatile machst.

Autor: Mark Struberg (struberg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ad zu meinem obigen Posting:

Vermeiden kann man das ganze am einfachsten, indem man das Lesen des
Zählers 'atomic' macht, also die Interrupts in dieser Zeit disabled.

Das sollte jedoch immer nur sehr kurze Zeit gemacht werden, da man
sonst Zeitverzerrungen in der ISR bekommen kann.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe dazu auch noch eine Frage.
Sollte man dieses Volatile auch dann benutzen, wenn es sich um globale
Varaiblen handelt und diese in verschiedenen Funktionen verändert
werden oder ist die volatile-Angabe nur dann notwendig wenn die
Variable in der IRQ-Routine und im Hauptprogramm verändert wird?
Danke.

Gruß, Mario

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja

Autor: Daniel M. (usul27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Antwort hätte auch 42 sein können ;)

Mario fragt: A oder B und die Antwort lautet ja ;)

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Globale Variabeln, welche NICHT in IRQ's verwendet werden, benötigen
kein Volatile.

Volatile ist auch nötig, wenn man von einem IO Port was einliest. Der
Compiler weiss ja nicht, dass sich der Portzustant von Aussen her
ändern kann. Darum muss man das per Volatile bekannt geben. Ansonsten
kann es vorkommen, dass diese Variable ganz wegoptimiert wird vom
Compiler.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Beispiel:
unsigned long timerticks; // Interrupt zählt diese hoch

void test(void)
{
  while( timerticks <= 123456L); // Warte bis Zeit vergangen
}

geht schief aus 2 Gründen:

1. Lesen nicht atomar

2. Variable nicht volatile


Aber so gehts einwandfrei:
unsigned long timerticks; // Interrupt zählt diese hoch

unsigned long get_ticks( void )
{
  unsigned long ticks;
  cli();
  ticks = timerticks;
  sei();
  return ticks;
}

void test(void)
{
  while( get_ticks() <= 123456L); // Warte bis Zeit vergangen
}

Nun die Preisfrage:

Warum geht das ohne volatile ?


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na gut, wenn keiner den Preis haben will:

Es geht deshalb ohne volatile, weil der erste Zugriff innerhalb einer
Funktion immer erfolgen muß.

Und die Auslesefunktion greift ja nur einmal zu, d.h. da gibt es
nichts, was der Compiler wegoptimieren kann.

Und einen Funktionsaufruf darf der Compiler nicht aus der
while-Schleife rausziehen.
Funktionsaufrufe sind per se immer volatile.


Peter

Autor: Roland Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was passiert, wenn der Compiler entscheidet die
kurze Funktion get_ticks() als Optimierung zu inlinen?

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich weiss dass es Probleme mit einer Variabeln geben kann,
dann schreib ich lieber mal ein volatile zuviel hin als zu wenig...

Die Suche nach solchen Fehlern kann ziemlich lange dauern. Und schnell
ist mal was am Code geändert und dann funktioniert dieser plötzlich
nicht mehr ohne ersichtlichen Grund.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Roland

"Was passiert, wenn der Compiler entscheidet die kurze Funktion
get_ticks() als Optimierung zu inlinen?"


Dann ist natürlich alles forn Arsch.

Deshalb schalte ich diese Optimierung nie ein.

Inlining hat ja noch viele andere unerwünschte Seiteneffekte.


Es verwundert mich immer wieder, warum die Compilerbauer
Inlinefunktionen nicht genau so behandeln können, wie echte Funktionen.
Man braucht doch nur das CALL+RET weglassen.


Peter

Autor: Bodo Borland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<i>Es verwundert mich immer wieder, warum die Compilerbauer
Inlinefunktionen nicht genau so behandeln können, wie echte
Funktionen.
Man braucht doch nur das CALL+RET weglassen.</i>

So einfach ists nicht. Veneers waeren z.B. überflüssig und evtl. sogar
gefährlich. Mag ein, dass diese sehr vereinfachte Betrachtungsweise auf
einem Primitiv-Prozessor wie dem AVR sogar funktioniert. Aber es gibt
genug Fälle, da ist eine Funktion mehr als ein bisschen Assembly mit
Call und Return. Alleine die Registernutzung ist beim Inlining meist
dramtisch anders.

Funktionsaufrufe sind ausserdem nicht grundsätzlich volatile.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "Was passiert, wenn der Compiler entscheidet die kurze Funktion
> get_ticks() als Optimierung zu inlinen?"
>
>
> Dann ist natürlich alles forn Arsch.

Naja, es ist eher so, daß das fälschliche Fehlen von volatile nun einen
Effekt zeigt.

> Deshalb schalte ich diese Optimierung nie ein.

Seltsame Denkweise. Außerdem könntest du die Funktion auch in einer
anderen Übersetzungseinheit definieren. Damit unterbindest du das
Inlining auch.

> Inlining hat ja noch viele andere unerwünschte Seiteneffekte.

Ja? Es hat meines Erachtens jede Menge erwünschter Effekte.

> Es verwundert mich immer wieder, warum die Compilerbauer
> Inlinefunktionen nicht genau so behandeln können, wie echte
> Funktionen. Man braucht doch nur das CALL+RET weglassen.

Dann kann man sich das inlining fast schenken. Richtig effektiv wird
das erst dadurch, daß noch jede Menge mehr optimiert werden kann.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es geht deshalb ohne volatile, weil der erste Zugriff innerhalb
> einer Funktion immer erfolgen muß.

Nein. Das ist natürlich falsch. Ein Beispiel wurde schon genannt,
Inlining.

Gerne lasse ich mich vom Gegenteil überzeugen. Dazu bitte die
entsprechende Stelle aus dem C99-Iso-Standard zitieren.


> Es verwundert mich immer wieder, warum die Compilerbauer
> Inlinefunktionen nicht genau so behandeln können, wie echte
> Funktionen.

Nun, Compilerbauer implementieren den Standard. Wenn der C-Compiler vom
Standard abweicht, ist er defekt.

Wenn der Programmierer den Standard nicht liest bzw. versteht, und z.B.
"volatile" an entsprechenden Stellen weglässt, dann ist produziert der
Programmierer defekten Code.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Es verwundert mich immer wieder, warum die Compilerbauer
Inlinefunktionen nicht genau so behandeln können, wie echte
Funktionen."

C wurde zwar anfangs sehr hardwarenah definiert und benutzt, und die
Compiler dieser Ära waren dementsprechend einfach. Aber heute ist es
eine allgemeine Programmiersprache für recht hoch angesiedelte
Anwendungen (mag man das nun gut oder schlecht finden).

Nur: Das war nie offiziell so definiert. K&R-C konnte einzig deshalb
auf "volatile" verzichten, weil die Compiler dieser Ära kaum über
Statement-Grenzen hinaus optimierten. Manche heutigen Compiler
betrachten das gesamte Programm als Einheit und sind in den Grenzen der
jeweiligen C-Definition frei, alles nach belieben umzuordnen und auch
wegzulassen. Wobei C hier immer noch weit weniger Freiheitsgrade hat
als beispielsweise Fortran (z.B. Aliasing).

In Controller-Anwendungen hingegen sind globale Optimierungen weniger
wichtig, allein schon weil es keinen entsprechenden Benchmark gibt. Die
einzig wirklich wichtige funktionsübergreifende Optimierung analysiert
statische Variablen um RAM zu sparen, bei Maschinen die sich mit
Variablen auf dem Stack schwer tun. Im Gegenteil, Transparenz von
Quellcode zu Objektcode ist durchaus hilfreich, und wenn man den
eigenen Code im Assembler-Listung noch wiedererkennt, ist das kein
Nachteil.

Wird nun aber ein Compiler für SPECmark-optimierte Standardsysteme auf
Controller-Anwendungen losgelassen, kann es für den Anwender schon mal
einen kleiner Kulturschock geben, weil die gewohnte Transparenz beim
Teufel ist. Und nun vieles zum Problem wird, das bei einfacher
gehaltenen Compilern wunderbar funktioniert.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.