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?
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.
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?
>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...
Gast
#2757054
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.
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.:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Peter
Gast
#2757234
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.