Mehrere gleichnamige Interrups AtMega328P

Dhaza schrieb:
> Mittels Funktionszeigern und einem kleinen Schalter auf meiner PCB
> möchte ich zwischen zwei unterschiedlichen Modi der PCB umschalten
> können.
Was hindert dich?

Dhaza schrieb:
> Kann ich die ISR(TIMER0_OVF_vect){ ... } in funk0 und funk1 jeweils
> unterschiedlich anlegen, auch wenn sie dann erst beim Funktionsaufruf
> angelegt werden?
Das ist wirr!

Arduino Fanboy D. schrieb:
> Was hindert dich?

Dass ich je Modus eine andere ISR(TIMER0_OVF_vect) brauche und ich nicht 
weiß wie ich das formal mache

Arduino Fanboy D. schrieb:
> Das ist wirr!

Ja, tut mir leid.

Dhaza schrieb:
> Dass ich je Modus eine andere ISR(TIMER0_OVF_vect) brauche und ich nicht
> weiß wie ich das formal mache

Es gibt keine zwei ISR(TIMER0_OVF_vect) auf AVR.
Denn diese liegt unveränderbar im Flash.
Kann nicht ausgetauscht werden.


Du kennst doch schon FunctionPointer ...
Nutze sie!

Cyblord -. schrieb:
> ir ist immer noch die klar, warum nicht die offensichtliche Lösung
> gewählt wurde: In der ISR wird eine Funktion über einen Funktionszeiger
> aufgerufen.
> Da braucht es keine Unterscheidungen an dieser Stelle.

Das kam etwas durch die Herangehensweise (was nicht sonderlich klug war, 
zugegeben, die Umschaltung war recht kurz entschlossen nachträglich 
hinzugefügt.

Aber so wie im zweiten Teil deiner Antwort werde ich es machen. Ich 
nutze die ISR nur um zum Funktionsaufruf und nehme die Funktionen da 
raus.

Hier ein Beispiel aus meiner Wühlkiste:
(marginal für deine Zwecke modifiziert)

1

#include <util/atomic.h>

2

#define AtomicSection ATOMIC_BLOCK(ATOMIC_RESTORESTATE)

3

4

5

using FuncPtr = void(*)();

6

7

volatile FuncPtr funcptr = nullptr;

8

9

void funcA()

10

{

11

  // tuwas  

12

}

13

14

void funcB()

15

{

16

  // tuwas  

17

}

18

19

ISR(TIMER0_OVF_vect)

20

{

21

  if(funcptr) funcptr();

22

}

23

24

25

int main() 

26

{

27

  for(;;)

28

  {

29

    AtomicSection funcptr = funcA;

30

    // tuwas

31

    AtomicSection funcptr = funcB;

32

    // tuwas

33

    AtomicSection funcptr = nullptr;

34

    // tuwas

35

  }

36

}

Ist zwar C++, aber der Umbau auf C sollte trivial sein.
Ob das volatile nötig ist, überlasse ich deiner Entscheidung.

Peter D. schrieb:
> Der Compiler sichert dann
> erstmal sämtliche Scratchpad-Register.
Ja, das tut er.

Das tut er immer, wenn das inlineing der, in der  ISR aufgerufenen, 
Funktion nicht möglich ist.

Das "Flag setzen und in der ISR auswerten" scheint dem TE ja nicht zu 
schmecken.
Dann hat er halt diese Kröte zu schlucken.
Ganz so viele Alternativen scheints ja nicht zu geben.

Cyblord -. schrieb:

> Das erfordert auch keinen Unsinn mit der ISR selber. Es kommt halt ein
> Funktionsaufruf hinzu.

Der kann recht teuer kommen. Schon der Funktionsaufruf selber ist nicht 
ganz billig, insbesondere auf den größeren AVR8 mit mehr als 128kB 
Flash.

Das Sichern und Wiederherstellen etlicher Register kommt dann noch dazu.

Selbst in Asm vermeide ich es, wo immer möglich, indirekte calls zu 
verwenden. Insbesondere natürlich in ISRs.

c-hater schrieb:
> Der kann recht teuer kommen. Schon der Funktionsaufruf selber ist nicht
> ganz billig,

Ich kann mich immer nur wundern, warum die Leute glauben, das Zeug sei 
langsam. Ich haette vor 40 Jahren nie Text auf den Z80/8085 usw. 
schreiben koennen ;-) Auch die kleinen Tinys sind schon vielfach 
schneller.

leo

leo schrieb:

> Ich kann mich immer nur wundern, warum die Leute glauben, das Zeug sei
> langsam.

Es ist langsam!

> Ich haette vor 40 Jahren nie Text auf den Z80/8085 usw.
> schreiben koennen ;-)

Du scheinst nicht verstanden zu haben, dass es auch viele Anwendungen 
für µC gibt, die vielfach schneller auf äußere Ereignisse reagieren 
können müssen, als die, welche menschliche Eingaben auszulösen in der 
Lage sind...

c-hater schrieb:
>> Ich kann mich immer nur wundern, warum die Leute glauben, das Zeug sei
>> langsam.
>
> Es ist langsam!

Ich lese oben "LED", "Schalter", ...

wie du meinst...

leo

Dhaza schrieb:
> Dass ich je Modus eine andere ISR(TIMER0_OVF_vect) brauche

Brauchst du nicht. Deine ISR kann je nach Modus eine andere Funktion 
aufrufen. Alternativ zu Funktionszeigern geht es auch so:

1

switch (modus)

2

{

3

  case 1: isr_modus1(); break;

4

  case 2: isr_modus2(); break;

5

  case 3: isr_modus3(); break;

6

  case 4: isr_modus4(); break;

7

}

Das kann effizienter sein, wenn der Compiler die Funktionen inline 
einbaut.
Ansonsten halt auch nicht.

leo schrieb:

> Ich lese oben "LED", "Schalter", ...

So what? Selbst in wirklich richtig kritischen Anwendungen kommen fast 
immer irgendwelche Schalter/Taster und LEDs vor. Das eine ist die 
eigentliche Aufgabe des µC, das andere das "GUI" zu seiner 
Konfiguration/Parametrierung.

Insofern: Die Existenz eines GUI ist ja wohl kein sicheres 
Ausschlußkriterium für eine zeitkritische Aufgabe des µC...

Aber die obersten Glaskugel-Besitzer haben wohl tiefergehende 
Informationen zur Intention des TO...

Johann L. schrieb:
>> Ich hoffe es gibt in der Hölle eine ganz spezielle Ecke für Leute die
>> Quellcode als Bild posten.
> Ok, also doch besser als Video.

Meinst du so: https://www.youtube.com/watch?v=IYlOQU6euZs ?

Der Typ fordert seine Follower auf, das Video auszudrucken.

Cyblord -. schrieb:

> Ich hoffe es gibt in der Hölle eine ganz spezielle Ecke für Leute die
> Quellcode als Bild posten.

Ja gibt es, ist aber noch nicht richtig durchdacht.

Die gegenwärtige Imlementierung ist: Alle Bits von geposteteten Anhängen 
werden als Matrix repräsentiert, wobei jedes gesetzte Bit durch einen 
10"-Nagel repräsentiert wird. Der Sünder wird nun über alle 
Kombinationen dieser Bits gezogen.

Der Implementierungsfehler ist: verglichen mit der Ewigkeit ist die 
Strafe viel zu schnell abgeritten...

Der Teufel verflucht die Endlichkeit binärer Mathematik!