Interrupt-Routine beenden

[Peter Z. (Gast)]

Hallo Forum, ich habe da eine (Timer)-Interruptroutine die nach 
Möglichkeit schnell abgearbeitet werden soll.
In der Routine sind eine Reihe if-Abfragen,

   if(Tasten == 0x02){ // Code für Tasten 0x02

   }
   if(Tasten == 0x06){ // Code für Tasten 0x06

   }
   if(Tasten == 0x04){ // Code für Tasten 0x04

   }
   if(Tasten == 0x00){ // Code für Tasten 0x00

   }
   // usw.

wenn eine davon zutrifft soll der dazu gehörende Code abgearbeitet 
werden und die Interrupt-Routine sofort  beendet werden.
Klar, ich könnte das mit switch case break machen.
Aber gibt es noch eine andere Möglichkeit, die Interupt Routine sauber 
zu beenden ohne die anderen if-Abfragen zu durchlaufen?
Was nehme ich da am besten?

[Peter II (Gast)]

Peter Zz schrieb:
> Was nehme ich da am besten?

return - wie bei jeder anderen Funktion auch.

[Peter Z. (Gast)]

Peter II schrieb:
> return - wie bei jeder anderen Funktion auch.

Aber ich habe doch gar keinen Return-Wert!
Und man soll doch in einer Funktion nur einen einzigen Return haben? 
oder?

[Oliver S. (oliverso)]

if
...
else if
...
else if...
...
return;

Oliver

[Peter II (Gast)]

Peter Zz schrieb:
> Aber ich habe doch gar keinen Return-Wert!
spielt doch keine rolle.

> Und man soll doch in einer Funktion nur einen einzigen Return haben?
> oder?
man sollte auch keine gotos verwenden - aber es gibt auch gründe warum 
am es trotzdem macht.

[Rufus Τ. F. (rufus)]

Peter Zz schrieb:
> Aber ich habe doch gar keinen Return-Wert!

Dann schreibst Du halt keinen hin.

> Und man soll doch in einer Funktion nur einen einzigen Return haben?

Nö.

void bla(void)
{
  if (test_whatever())
    return;
  do_something();
  if (test_whatelse())
    return;
  do_something_else();
}

Das ist völlig legitim.

[Peter Z. (Gast)]

Oliver S. schrieb:
> return;

Ist dieser letzte Return überhaupt notwendig?
An dieser Stelle ist die Interrupt-Routine eh zuende abgearbeitet.

[Markus F. (mfro)]

... was hast Du gegen ein switch()-Statement?

[Oliver S. (oliverso)]

Peter Zz schrieb:
> Ist dieser letzte Return überhaupt notwendig?

Stimmt, ist es nicht.

Oliver

[Karl H. (kbuchegg)]

Peter Zz schrieb:

> Und man soll doch

Man soll vor allen Dingen bei allen 'Man soll' Regeln den Hintergrund 
dieser Regel kennen und auch wissen, wann es klüger ist, die Regel über 
Bord zu werfen.

In der Programmierung gibt es nur ganz wenige Regeln, die ausnahmslos 
einzuhalten sind. Auf Anhieb fällt mir allerdings keine ein.

[Frank M. (ukw) (Moderator)]

Markus F. schrieb:
> ... was hast Du gegen ein switch()-Statement?

Das ist neben Olivers Einwurf die zweite sinnvolle Möglichkeit.

Es muss einem doch direkt ins Auge stechen, dass

   if (taste == 1)
   if (taste == 2)
   if (taste == 3)
   if (taste == 4)
   if (taste == 5)

viel däml^H^H^H^H ineffizienter ist als ein

   if (taste == 1)
   else if (taste == 2)
   else if (taste == 3)
   else if (taste == 4)
   else if (taste == 5)

... wo direkt nach dem ersten Match keine weiteren Abfragen mehr 
vorgenommen werden.

Dasselbe gilt für die switch-Alternative.

[Oliver S. (oliverso)]

Vor allem hilft die "else if" -Variante, den Code bzw. das, was damit 
erreicht werden soll, besser zu verstehen.

Peter Zz schrieb:
> In der Routine sind eine Reihe if-Abfragen,
> ...
> wenn eine davon zutrifft soll der dazu gehörende Code abgearbeitet
> werden

Genau das wird durch "else if" ausgedrückt. Ist "selbstdokumentierend".

Oliver

[?!? (Gast)]

Oliver S. schrieb:
> Genau das wird durch "else if" ausgedrückt. Ist "selbstdokumentierend".
>
> Oliver

Richtig, und dann reicht auch ein "return" statt mehreren.

[Peter Z. (Gast)]

Markus F. schrieb:
> ... was hast Du eigentlich gegen ein switch()-Statement?

Du hast ja recht,
ich sollte das in der Tat mit einem switch case break machen!

[Thomas E. (thomase)]

?!? schrieb:
> Richtig, und dann reicht auch ein "return" statt mehreren.

Dann reicht sogar kein "return".

mfg.

[?!? (Gast)]

Thomas Eckmann schrieb:
> Dann reicht sogar kein "return".

Stimmt! :-)

[Karl H. (kbuchegg)]

Peter Zz schrieb:
> Markus F. schrieb:
>> ... was hast Du eigentlich gegen ein switch()-Statement?
>
> Du hast ja recht,
> ich sollte das in der Tat mit einem switch case break machen!

Das ist auch wieder so eine 'Regel'.

Ob ein switch-case besser ist, oder einfach ein paar if else-if hängt 
nicht zuletzt auch von den Abfragebedingungen bzw. den dort vorkommenden 
konkreten Werten ab.

[Johann L. (gjlayde)]

Frank M. schrieb:
> Es muss einem doch direkt ins Auge stechen, dass
>

    if (taste == 1)
>    if (taste == 2)
>    if (taste == 3)
>    if (taste == 4)
>    if (taste == 5)

>
> viel däml^H^H^H^H ineffizienter ist als ein
>

    if (taste == 1)
>    else if (taste == 2)
>    else if (taste == 3)
>    else if (taste == 4)
>    else if (taste == 5)

>
> ... wo direkt nach dem ersten Match keine weiteren Abfragen mehr
> vorgenommen werden.

Falls taste nicht verändert wird macht das keinen Unterschied. 
Ausprobieren!

> Dasselbe gilt für die switch-Alternative.

Die wird i.d.r anders (effizienter) übersetzt.

[m.n. (Gast)]

Johann L. schrieb:
>> Dasselbe gilt für die switch-Alternative.
>
> Die wird i.d.r anders (effizienter) übersetzt.

Wobei das aber auch bedeutet, die Reihenfolge kann beliebig verändert 
werden. Mit einem 'if' gibt man die Priorität der Vergleiche selber vor.

[Markus F. (mfro)]

m.n. schrieb:
> Johann L. schrieb:
>>> Dasselbe gilt für die switch-Alternative.
>>
>> Die wird i.d.r anders (effizienter) übersetzt.
>
> Wobei das aber auch bedeutet, die Reihenfolge kann beliebig verändert
> werden. Mit einem 'if' gibt man die Priorität der Vergleiche selber vor.

Bei einem "ausreichend großen" switch gibt's keine Priorität mehr (bzw. 
sie ist für jeden Wert gleich). Der Compiler macht dann eine 
Sprungtabelle draus. Wenn man unbedingt will, kann man die per 
Funktionspointer auch in C zimmern. Bei meinem ersten großen C-Projekt 
(vor 25 Jahren) hat das - gegenüber einem großen switch-Statement) mal 
ca. 30% Laufzeitverbesserung gebracht.
Moderne Compiler sollten das heutzutage - ohne daß man ihnen "auf die 
Sprünge" helfen muß - besser können.

[m.n. (Gast)]

Markus F. schrieb:
> Moderne Compiler sollten das heutzutage - ohne daß man ihnen "auf die
> Sprünge" helfen muß - besser können.

Das können sie aber nur, weil sie machen, wie sie es wollen!
Was Du willst spielt dann keine Rolle mehr ;-)

[(prx) A. K. (prx)]

Markus F. schrieb:
> Bei einem "ausreichend großen" switch gibt's keine Priorität mehr (bzw.
> sie ist für jeden Wert gleich).

Nur wenn die Werte ohne grössere Löcher liegen.

> Moderne Compiler sollten das heutzutage - ohne daß man ihnen "auf die
> Sprünge" helfen muß - besser können.

Es gibt diverse Varianten, switch Statements umzusetzen, und dazu wird 
anhand Anzahl und Verteilung der Werte abgeschätzt, welche besser ist. 
Dazu gehört auch eine Variante, die kein Programmierer zu Fuss 
hinbekommt, nämlich ein Baum aus Vergleichen. So arbeitete schon manch 
schwach optimierender Compiler vor 30 Jahren. Allerdings kann diese 
Abschätzung auch mal schief liegen. Damals wie heute.

[Johann L. (gjlayde)]

Wobei das alles nur ein Nebenschauplatz ist...

Das o.g. Porblem wird nämlich am besten dadurch gelöst, dass man die 
Abfrage — wie vieles andere auch — eben nicht in der ISR macht sondern 
den Code dahingehend umstrukturiert, dass die Tests und der ganze andere 
Tralala nicht mehr auf Interrupt-Ebene geschehen.

[Rolf M. (rmagnus)]

Was hier noch bei der if-Variante zu beachten ist: Da es um eine ISR 
geht, wird "Tasten" vermutlich volatile sein und damit bei jedem if 
nochmal neu aus dem RAM gelesen. Also besser erst in eine lokale 
Variable kopieren, die nicht volatile ist.

[Da D. (dieter)]

Karl Heinz schrieb:
> In der Programmierung gibt es nur ganz wenige Regeln, die ausnahmslos
> einzuhalten sind. Auf Anhieb fällt mir allerdings keine ein.

Ich fällt da eine ein :)

"Thou shalt not follow the NULL pointer, for chaos and madness await 
thee at its end."

:-)