while + return = böse?

[Joachim .. (joachim_01)]

Hab hier nen ATMega 1284P als PID-Regler mit nem selbstgestrickten 
Frontend mit Menüführung. Die Steuerung der Menüführung (Bilderaufruf 
und weiterschalten) findet durch globale Schaltbits statt die je nach 
Notwendigkeit zT. auch in der ISR gesetzt und weggenommen werden. Um aus 
nem Menü herauszukommen stelle ich aber plötzlich fest, daß mir das nur 
gelingt wenn ich ein bedeutungsloses und nur zu Kompatibilitätszwecken 
eingefügtes

int encode_read2( void )         // read two step encoders
{
/*
  ...
  */
 return enc_delta2;
}

benutze. Andernfalls hängt das Programm.
1. Kann es sein, daß mir irgendwo der Stapel überläuft und der 
return-Befehl den Stapelzeiger wieder 'richtig' positioniert?
2. Ist es fatal wenn ich aus einer switch-case Abfrage mit return 
einfach abhaue (ich muß einen Programmteil überspringen) anstatt wie 
üblich mit break?

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

Joachim ... schrieb:
> und der return-Befehl den Stapelzeiger wieder 'richtig' positioniert?

Ein eingefügter Aufruf kann den Optimizer beeinflussen. Siehe volatile.

> 2. Ist es fatal wenn ich aus einer switch-case Abfrage mit return
> einfach abhaue (ich muß einen Programmteil überspringen) anstatt wie
> üblich mit break?

Nein.

[Mark B. (markbrandis)]

Irgendwie versteh ich die Frage nicht. Du hast die Funktion so 
deklariert, dass es einen Rückgabewert gibt (nämlich int), also gehört 
logischerweise auch ein return dazu.
Es hindert dich aber auch niemand daran, die Funktion als "void" zu 
deklarieren, falls sie gar nicht unbedingt einen Rückgabewert braucht.

Ach so, oder ist das so gemeint dass ohne diese "Dummy-Funktion" dein 
Programm gar nicht mehr funktioniert? Dann hast du Mist gebaut. Ohne 
deinen Code zu sehen, dürfte es aber reichlich schwer sein zu sagen 
woran es liegt.

> 2. Ist es fatal wenn ich aus einer switch-case Abfrage mit return
> einfach abhaue (ich muß einen Programmteil überspringen) anstatt wie
> üblich mit break?

Was hindert Dich daran, direkt nach dem switch-case ein "return retval;" 
zu haben und in den verschiedenen cases den Rückgabewert für jeden Fall 
entsprechend zu setzen?

[Joachim .. (joachim_01)]

>Ach so, oder ist das so gemeint dass ohne diese "Dummy-Funktion" dein
>Programm gar nicht mehr funktioniert? Dann hast du Mist gebaut.
Das ist der Punkt. Der Code wird durch die vielen Verschachtelungen 
allmählich immer mehr zum Matt-in-sieben-Zügen Problem... ich überlege 
ob ich das Probleme konzeptionell nicht irgendwie anders angehen kann...

[Peter II (Gast)]

Joachim ... schrieb:
> Das ist der Punkt. Der Code wird durch die vielen Verschachtelungen
> allmählich immer mehr zum Matt-in-sieben-Zügen Problem... ich überlege
> ob ich das Probleme konzeptionell nicht irgendwie anders angehen kann...

dann zeige doch mal her was du hast. Es werden dann bestimmt auch 
hilfreiche kommentare zur verbesserung kommen.

[Peter D. (peda)]

Das ist ein volatile Problem.
Durch Einbau von Funktionen kann es kaschiert werden, aber dann in 
anderem Kontext wieder auftreten.

Zugriff auf Interruptvariablen muß im Main-Kontext volatile erfolgen.
Z.B.:

#define IVAR(x)         (*(volatile typeof(x)*)&(x))

uint8_t intvar;

int main()
{
  while( IVAR(intvar)); // wait until false

}

Peter

[Pako (Gast)]

Ja, ein "volatile" und/oder "atomic" Problem.

siehe
http://www.mikrocontroller.net/articles/Interrupt

Wenn Hauptprogramm und ISR read-modify-write auf die gleiche Variable 
machen, muß man im Hauptprogrammen die Zugriff unter Interruptsperre 
machen, ansonsten kann die Variable unerwartete Zustände annehmen.