volatile Funktionspointer in ISR

http://www.embedded.com/electronics-blogs/beginner-s-corner/4023801/Introduction-to-the-Volatile-Keyword

Stellt sich die Frage, ob der volatile Funktionszeiger wirklich nötig 
und sinnvoll ist. Man kann ebenso die Steuervariable in der ISR 
auswerten und passend die Funktion aufrufen. Die paar Takte, die das 
kostet werden deine ISR nicht unbrauchbar machen.

Auch ganz ohne volatile wird das funktionieren.

Jörg W. schrieb:
> Auch ganz ohne volatile wird das funktionieren.

Warum? Was unterscheidet einen Funktionszeiger von einer Variablen? 
Werden Funktionszeiger prinzipiell nicht optimiert und lokal gepuffert?

Alexander H. schrieb:
> dem weise ich abhängig von der Bedingung am Anfang der main die Funktion
> zu:
> 1if(read1 == 1)
> 2   readSensor = readSensor1;
> 3else
> 4   readSensor = readSensor2;

Aber auch hier muss man aufpassen! Die Zuweisung muss ATOMAR erfolgen!

https://www.mikrocontroller.net/articles/Interrupt#Atomarer_Datenzugriff

Falk B. schrieb:
> Jörg W. schrieb:
>> Auch ganz ohne volatile wird das funktionieren.
>
> Warum? Was unterscheidet einen Funktionszeiger von einer Variablen?
> Werden Funktionszeiger prinzipiell nicht optimiert und lokal gepuffert?

Die Frage stelle ich mir auch gerade.

Falk B. schrieb:
>> Auch ganz ohne volatile wird das funktionieren.
>
> Warum?

Weil der Compiler in einer ISR gar keine Chance hat, da irgendwie 
irgendwas unpassendes zu cachen. Der kann nur auf den globalen 
Funktionszeiger zugreifen, um die entsprechende Funktion aufzurufen.

Anders wäre die Situation, wenn sich noch während der Laufzeit der ISR 
dieser Zeiger ("von außen") ändern könnte. Aber das wird ja wohl eher 
nicht der Fall sein.

https://stackoverflow.com/questions/40108010/how-to-use-function-pointer-inside-arduino-interrupt-service-routine-to-modify-t

In dem Post steht was anderes, allerdings geht aus den Kommentaren 
hervor, dass er auch noch eine anderes Problem mit seinem Code haben 
könnte.

Jörg W. schrieb:
> Auch ganz ohne volatile wird das funktionieren.

Eher nicht.
Der Compiler sieht im Mainkontext keinerlei Verwendung und schenkt sich 
die Zuweisung in die Variable.

Den Interrupt interessiert das volatile nicht. Er kennt keine vorherige 
Instanz, d.h. muß die Variable in jedem Fall neu einlesen.

Peter D. schrieb:
> Der Compiler sieht im Mainkontext keinerlei Verwendung und schenkt sich
> die Zuweisung in die Variable.

Darf er nicht. Die ist global, da muss er immer mit Seiteneffekten 
rechnen.

DAS ist doch mal eine Freitagsdiskussion, die nicht auf Anhieb nervt.

Jörg W. schrieb:
>> Der Compiler sieht im Mainkontext keinerlei Verwendung und schenkt sich
>> die Zuweisung in die Variable.
>
> Darf er nicht. Die ist global, da muss er immer mit Seiteneffekten
> rechnen.

Wenn das so ist, warum müssen dann Variablen volatile deklariert werden?

Falk B. schrieb:
> Jörg W. schrieb:
>>> Der Compiler sieht im Mainkontext keinerlei Verwendung und schenkt sich
>>> die Zuweisung in die Variable.
>>
>> Darf er nicht. Die ist global, da muss er immer mit Seiteneffekten
>> rechnen.
>
> Wenn das so ist, warum müssen dann Variablen volatile deklariert werden?

Hab ich mich auch gerade gefragt.

1

uint8_t myVar=0;

2

3

int main() {

4

while(1) {

5

if (myVar==24) doSomething();

6

}

7

}

8

9

ISR() {

10

myVar=24;

11

}

klappt nicht ohne volatile weil der compiler myVar nicht mehr aus dem 
speicher liest. es wird im prinzip der ganze schleifeninhalt 
wegrationalisiert.

Cyblord -. schrieb:
> klappt nicht ohne volatile weil der compiler myVar nicht mehr aus dem
> speicher liest. es wird im prinzip der ganze schleifeninhalt
> wegrationalisiert.

Das ist allerdings auch der gegenteilige Fall.

In der ISR gibt es keine Schleife, also muss der Wert aus dem globalen 
Kontext stammen.

Walter T. schrieb:
> Cyblord -. schrieb:
>> klappt nicht ohne volatile weil der compiler myVar nicht mehr aus dem
>> speicher liest. es wird im prinzip der ganze schleifeninhalt
>> wegrationalisiert.
>
> Das ist allerdings auch der gegenteilige Fall.

Bitte was?
Es geht nicht um den Fall, sondern um die Aussage globale Variablen 
bräuchten kein volatile.

Analog wäre:

1

uint8_t myVar=0;

2

3

int main() {

4

myVar = 0;

5

while(1) {

6

    myVar = !myVar;

7

}

8

9

}

10

11

ISR() {

12

   if (myVar) doSomething();

13

}

Cyblord -. schrieb:
> Es geht nicht um den Fall, sondern um die Aussage globale Variablen
> bräuchten kein volatile.

Die Aussage gab es nie. Es gab die Aussage, dass in diesem Fall eine 
globale Variable kein volatile benötigte.

Walter T. schrieb:
> Analog wäre:
>

1

> uint8_t myVar=0;

2

> 

3

> int main() {

4

> myVar = 0;

5

> while(1) {

6

>     myVar = !myVar;

7

> }

8

> 

9

> }

10

> 

11

> ISR() {

12

>    if (myVar) doSomething();

13

> }

14

>

Ja richtig. So rum gehts weil er beim Eintritt in die ISR myVar aus dem 
Speicher lesen muss.
Nur die Aussage von Jörg war an diese Stelle etwas zu allgemein.
Bezogen auf diesen Fall aber korrekt.

Walter T. schrieb:
> In der ISR gibt es keine Schleife, also muss der Wert aus dem globalen
> Kontext stammen.

s/Schleife/wiederholte Verwendung/

Nur in dem Zusammenhang ist das so relevant. Aber ja, in der Regel 
erfolgt diese wiederholte Verwendung natürlich innerhalb einer Schleife, 
insbesondere, wenn man dabei auf irgendeine Veränderung pollt, die durch 
einen Interrupt verursacht wird.

Einfaches Beispiel:

1

#include <avr/interrupt.h>

2

#include <avr/io.h>

3

#define F_CPU 1E6

4

#include <util/delay.h>

5

6

void (*fptr)(void);

7

8

ISR(USART_RX_vect)

9

{

10

        if (fptr)

11

                fptr();

12

}

13

14

void

15

set_led(void)

16

{

17

        PORTB &= ~_BV(1);

18

}

19

20

void

21

clear_led(void)

22

{

23

        PORTB |= _BV(1);

24

}

25

26

int

27

main(void)

28

{

29

        DDRB |= _BV(1);

30

31

        for (;;)

32

        {

33

                fptr = set_led;

34

                _delay_ms(100);

35

                fptr = clear_led;

36

                _delay_ms(100);

37

        }

38

}

Auch mit maximaler Optimierung wirft der Compiler die Zuweisung an 
"fptr" nicht weg, und die ISR holt sich selbstverfreilich den Wert von 
da. Was sollte sie auch sonst tun?

1

        .file   "example.c"

2

__SP_H__ = 0x3e

3

__SP_L__ = 0x3d

4

__SREG__ = 0x3f

5

__tmp_reg__ = 0

6

__zero_reg__ = 1

7

        .text

8

.global set_led

9

        .type   set_led, @function

10

set_led:

11

/* prologue: function */

12

/* frame size = 0 */

13

/* stack size = 0 */

14

.L__stack_usage = 0

15

        cbi 0x5,1

16

/* epilogue start */

17

        ret

18

        .size   set_led, .-set_led

19

.global clear_led

20

        .type   clear_led, @function

21

clear_led:

22

/* prologue: function */

23

/* frame size = 0 */

24

/* stack size = 0 */

25

.L__stack_usage = 0

26

        sbi 0x5,1

27

/* epilogue start */

28

        ret

29

        .size   clear_led, .-clear_led

30

.global __vector_18

31

        .type   __vector_18, @function

32

__vector_18:

33

        push r1

34

        push r0

35

        in r0,__SREG__

36

        push r0

37

        clr __zero_reg__

38

        push r18

39

        push r19

40

        push r20

41

        push r21

42

        push r22

43

        push r23

44

        push r24

45

        push r25

46

        push r26

47

        push r27

48

        push r30

49

        push r31

50

/* prologue: Signal */

51

/* frame size = 0 */

52

/* stack size = 15 */

53

.L__stack_usage = 15

54

        lds r30,fptr

55

        lds r31,fptr+1

56

        sbiw r30,0

57

        breq .L4

58

        icall

59

.L4:

60

/* epilogue start */

61

        pop r31

62

        pop r30

63

        pop r27

64

        pop r26

65

        pop r25

66

        pop r24

67

        pop r23

68

        pop r22

69

        pop r21

70

        pop r20

71

        pop r19

72

        pop r18

73

        pop r0

74

        out __SREG__,r0

75

        pop r0

76

        pop r1

77

        reti

78

        .size   __vector_18, .-__vector_18

79

        .section        .text.startup,"ax",@progbits

80

.global main

81

        .type   main, @function

82

main:

83

/* prologue: function */

84

/* frame size = 0 */

85

/* stack size = 0 */

86

.L__stack_usage = 0

87

        sbi 0x4,1

88

        ldi r18,lo8(gs(set_led))

89

        ldi r19,hi8(gs(set_led))

90

        ldi r24,lo8(gs(clear_led))

91

        ldi r25,hi8(gs(clear_led))

92

.L10:

93

        sts fptr+1,r19

94

        sts fptr,r18

95

        ldi r30,lo8(24999)

96

        ldi r31,hi8(24999)

97

1:      sbiw r30,1

98

        brne 1b

99

        rjmp .

100

        nop

101

        sts fptr+1,r25

102

        sts fptr,r24

103

        ldi r30,lo8(24999)

104

        ldi r31,hi8(24999)

105

1:      sbiw r30,1

106

        brne 1b

107

        rjmp .

108

        nop

109

        rjmp .L10

110

        .size   main, .-main

111

.global fptr

112

        .section .bss

113

        .type   fptr, @object

114

        .size   fptr, 2

115

fptr:

116

        .zero   2

117

        .ident  "GCC: (GNU) 10.2.0"

118

.global __do_clear_bss

(Dass Funktionszeiger in ISRs auf dem AVR keine sonderlich gute Idee 
sind, weil sie eine push/pop-Orgie nach sich ziehen, steht auf einem 
anderen Blatt.)

Nop schrieb:
> uatsch. Am Anfang der main() erfolgt die Zuweisung,

Sagt der OP.

> also bevor die
> Interrupts aufgesetzt werden.

Das weißt du nicht.

Jörg W. schrieb:
> (Dass Funktionszeiger in ISRs auf dem AVR keine sonderlich gute Idee
> sind, weil sie eine push/pop-Orgie nach sich ziehen, steht auf einem
> anderen Blatt.)

Die Aussage reicht mir schon, um die Bedingung in der ISR zu machen und 
auf den Pointer zu verzichten.

Danke für die hilfreichen Beiträge.

Grüße, Alex

Alexander H. schrieb:
> Die Aussage reicht mir schon, um die Bedingung in der ISR zu machen und
> auf den Pointer zu verzichten.

Naja wenn man in einer Hochsprache schreibt, sollte der Fokus erst mal 
auf gutem Code in dieser Hochsprache liegen. Erst wenn es sein muss 
sollte man diesen Code auf besseren ASM Code hin optimieren. z.B. wenn 
man wirklich Zeitkritische Dinge macht, welche den Controller sowieso 
schon an den Rand der Leistungsfähigkeit bringen.

A. S. schrieb:

> Main muss nach der Zuweisung noch eine weitere Zuweisung haben,
> dazwischen keinen Funktionsaufruf aber eine loop (mit volatile var als
> Bedingung).

Ja, korrekt, man muss natürlich irgendwas haben, was potenziell in der 
Lage sein könnte, den Wert zu verwenden. Wenn ich in meinem Beispiel die 
_delay_ms()-Aufrufe rausnehme, werden die wiederholten Zuweisungen an 
die Variable weg optimiert.

Aber wie du schon schriebst: in der Praxis normalerweise kein Problem.

Alexander H. schrieb:
>> (Dass Funktionszeiger in ISRs auf dem AVR keine sonderlich gute Idee
>> sind, weil sie eine push/pop-Orgie nach sich ziehen, steht auf einem
>> anderen Blatt.)
>
> Die Aussage reicht mir schon, um die Bedingung in der ISR zu machen und
> auf den Pointer zu verzichten.

Hast du das auch richtig verstanden? Es geht bei dem Problem nicht nur 
um Funktionszeiger, sondern auch um normale Funktionsaufrufe in einer 
ISR. Die sind beim avr gcc relativ "teuer" in bezug auf die push/pop 
Liste der Register.

Beitrag "Atmega ISR Prolog dauert zu lange - verschieben möglich?"

Ich dachte, Jörgs Aussage bezog sich jetzt konkret auf mein Problem mit 
dem Funktionszeiger. Mir ist bekannt, dass Funktionsaufrufe push/pop 
verursachen.
Bei mir ist es im wesentlichen das lesen einer uint16_t Variable über 
SPI. Die Lesefunktion ist in einer (eigenen) Bibliothek für den 
Sensor-Baustein, die ich mir geschrieben habe. Ich könnte das noch als 
inline deklarieren, wenn das was bringt. Es sind aber nicht viele 
ineinander verschachtelte Funktionen, nur Lesen und darin noch eine 
Funktion, die die Pins setzt und eine, die die SPI bedient. Das ist 
nicht ewig tief.

Alexander H. schrieb:
> Ich dachte, Jörgs Aussage bezog sich jetzt konkret auf mein Problem mit
> dem Funktionszeiger. Mir ist bekannt, dass Funktionsaufrufe push/pop
> verursachen.

Sie verursachen in einer ISR aber noch mehr push/pop.

> Ich könnte das noch als
> inline deklarieren, wenn das was bringt.

Das funktioniert nicht immer. Probier's aus.

> Es sind aber nicht viele
> ineinander verschachtelte Funktionen, nur Lesen und darin noch eine
> Funktion, die die Pins setzt und eine, die die SPI bedient. Das ist
> nicht ewig tief.

Klingt trotzdem nach einer arg akademischen Implementierung eines 
schnöden SPI-Zugriffs.

Falk B. schrieb:
> Klingt trotzdem nach einer arg akademischen Implementierung eines
> schnöden SPI-Zugriffs.

Falls ein SPI-Zugriff timergesteuert sehr exakt erfolgen soll, mag sowas 
Sinn haben.

Jörg W. schrieb:
>> Klingt trotzdem nach einer arg akademischen Implementierung eines
>> schnöden SPI-Zugriffs.
>
> Falls ein SPI-Zugriff timergesteuert sehr exakt erfolgen soll, mag sowas
> Sinn haben.

Das meinte ich nicht. Sondern die Verschachtelung von 2-3 Funktionen für 
bissel SPI, was mit einem Dutzend Zeilen in einer Funktion erledigen 
kann.

OSI layering? ;-)

Wir kennen seine Aufgabe nicht.

Jörg W. schrieb:
> Falls ein SPI-Zugriff timergesteuert sehr exakt erfolgen soll, mag sowas
> Sinn haben.

Das ist bei mir der Fall. Ich habe eine genaue Uhr auf dem Board und der 
Messwert muss zum Takt der Uhr (1kHz) genommen werden.

In der ISR passiert im Wesentlichen das:

1

uint16_t adis16003ReadValueY( void )

2

{

3

  int16_t tmp;

4

  adis16003SetCS(0);              

5

  tmp = adis16003SendReceiveByte(ADIS_Y_DIRECTION);

6

  tmp = (tmp << 8) | adis16003SendReceiveByte(ADIS_Y_DIRECTION);

7

  adis16003SetCS(1);

8

  return tmp;

9

}

Das ist während der Messung außer einem 100ms Timer, der noch paar LED 
setzt, auch das Einzige was an Interrupts passiert.

vonweiterweg schrieb:
> Das kann man in eine Funktionsaufruf zusammenfassen.
> Spart Zeit / Overhead.

Klar. Eine Eine Zeile Sourcecode statt zwei spart 50%. Wenn du dann noch 
die Funktionsnamen auf die halbe Länge kürzt, spart das nochmal 50%. 
Macht zusammen dann 100%.

Oliver

mh schrieb:
> Die Zuweisung von fptr müsste noch atomisiert werden oder?

Ja, im Prinzip schon, korrekt.

mh schrieb:
> Die Zuweisung von fptr müsste noch atomisiert werden oder?

Naja, du meinst eine atomare Zuweisung. Atomisieren bedeutet im 
Allgemeinen eher das Gegenteil ;-)

:-)

vonweiterweg schrieb:
> return ( (uint16_t)(byte0<<8) | byte1 );

Das funktioniert nur deshalb, weil die Integer Promotion vom Compiler 
sowieso VOR dem Schieben gemacht wird. Bei 32 Bit Zielgröße würde es 
NICHT funktionieren. Richtig ist es so. Erst der cast, dann schieben! 
Die Klammer um byte0 ist eine Angstmaßnahme, braucht man eigentlich 
nicht.

return ( (((uint16_t)byte0)<<8) | byte1 );

vonweiterweg schrieb:
> Soviel Abstraktionsfähigkeit des Lesers setze ich voraus ....

CS fehlt . . . naja

MaWin schrieb:

> Natürlich nicht. Du hast ein Fu..poi.. deklariert. Und da ist das
> volatile blödsinn. :-<<<

Blödsinn ist hier die Hälfte von dem, was du schreibst.

> Wenn volatile, gehört zur Definition der Variablen readSensor.

Genau da stand/steht es.

> Und den atomaren Zuweisungskrams erwarte ich vom Compiler. Wenn er das
> nicht kann, ist er Schrott. :-<<<

Schrott ist, was du da schreibst. Nur, weil du dir "MaWin" als Nick 
klaust, hilft das noch lange nichts.

Mittlerweile gibt es sogar ein <stdatomic.h>, welches in den nächsten 
C-Standard mit reinkommen wird, um sowas abzuhandeln. Das werden sie 
sich nicht aus Spaß so augedacht haben.

MaWin schrieb:
> mh schrieb:
>> wer auch
>> immer du bist.
>
> MaWin

Naja, jedenfalls nicht der MaWin. Der, den die, die ihn kennen, schon 
aus dem Usenet kennen.

Ist aber auch egal, deine Ahnungslosigkeit hinsichtlich C hast du uns ja 
nun ausreichend demonstriert.

MaWin schrieb:
> Jörg W. schrieb:
>> der MaWin
>
> Doch ich bin MaWin, der MaWin.

Du brauchst nicht zu lügen. Der MaWin bist du nicht, sondern 
irgendeiner. Wir kennen unsere Pappenheimer hier …