Interrupt-Routine beenden

1

if

2

...

3

else if

4

...

5

else if...

6

...

7

return;

Oliver

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ö.

1

void bla(void)

2

{

3

  if (test_whatever())

4

    return;

5

  do_something();

6

  if (test_whatelse())

7

    return;

8

  do_something_else();

9

}

Das ist völlig legitim.

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

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

Stimmt, ist es nicht.

Oliver

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.

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

1

   if (taste == 1)

2

   if (taste == 2)

3

   if (taste == 3)

4

   if (taste == 4)

5

   if (taste == 5)

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

1

   if (taste == 1)

2

   else if (taste == 2)

3

   else if (taste == 3)

4

   else if (taste == 4)

5

   else if (taste == 5)

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

Dasselbe gilt für die switch-Alternative.

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

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

Dann reicht sogar kein "return".

mfg.

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.

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

1

    if (taste == 1)

2

>    if (taste == 2)

3

>    if (taste == 3)

4

>    if (taste == 4)

5

>    if (taste == 5)

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

1

    if (taste == 1)

2

>    else if (taste == 2)

3

>    else if (taste == 3)

4

>    else if (taste == 4)

5

>    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. 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.

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.

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.

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.

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."

:-)