Forum: Compiler & IDEs In Interrupt herausfinden, welche Funktion interruptet wurde


von uint8_t (Gast)


Lesenswert?

Hallo,

kann man in C (avr-gcc) irgendwie einigermaßen sauber herausfinden, aus 
welcher Funktion in einen Interrupt hinein gesprungen wurde?
Die Rücksprungadresse liegt ja auf dem Stack.
Zum Debuggen wäre das manchmal eine sehr große Hilfe.

Danke schonmal

von 2ter Gast (Gast)


Lesenswert?

Ad hoc Möglichkeit 1:

Mit einem Debugger arbeiten.

Ad hoc Möglichkeit 2:

Rücksprungadresse rausschreiben und mit Assembler-Listing vergleichen

von gdb (Gast)


Lesenswert?

Debugger zeigen den Callstack ja normalerweise an. Wenn man diese 
Möglichkeit nicht hat, dann geht das prinzipbedingt nicht direkt, denn 
das lauffähige Programm weiss nichts von Funktionen. Man kommt also 
nicht darum herum, in ein Assemblerlisting zu schauen, wo die 
Information, welcher Bereich zu welcher Funktion gehört, noch vorhanden 
ist.

von gdb (Gast)


Lesenswert?

Alternativ, wenn es um eher wenige fragliche Funktionen geht, so könnte 
man in den fraglichen Funktionen auch einfach ein kleines Makro 
einbauen, das unmittelbar nach dem Aufruf eine Identifikationsnummer auf 
den Stack legt.

von 2ter Gast (Gast)


Lesenswert?

50€ für AVR Dragon investieren. Ist zwar Geld, aber die Zeit die man 
damit spart kann man durch Jobben wieder das Geld reinholen

von Peter D. (peda)


Lesenswert?

2ter Gast schrieb:
> 50€ für AVR Dragon investieren. Ist zwar Geld, aber die Zeit die man
> damit spart kann man durch Jobben wieder das Geld reinholen

Glaub ich nicht.

Ein Interrupt hat bei richtiger Programmierung keine Seiteneffekte.
Und wenn er die hat, dann liegt es in der Natur, daß die extrem selten 
auftreten, d.h. man kann sich dumm und dämlich debuggen. Trial und Error 
führt da nicht weiter.

Besser ist es daher, im Vorfeld alle Variablen, die das Main und 
Interrupts benutzen, daraufhin zu überprüfen und gegebenenfalls atomar 
zuzugreifen.
Zu beachten ist, das diese Variablen auch IO-Register sein können.
Ein Beispiel ist die berüchtigte (und völlig unnötige) Funktion 
sleep_mode().
"As the sleep_mode() macro might cause race conditions ..." ist ernst zu 
nehmen.


Peter

von 2ter Gast (Gast)


Lesenswert?

@Peter Dannegger

Es war hier die Frage, wie er herausbekommt, aus welcher Routine in den 
Interrupt gesprungen ist. Nicht mehr und nicht weniger. Von 
Seiteneffekten seinerseits war nicht die Rede. Natürlich gibt es Fälle, 
wo einem ein Debugger nicht helfen kann.

Mal Unabhängig davon: IHMO ein Debugger zu besitzen und zu benutzen ist 
vorteilhaft. Es erspart eine Menge Zeit. Aber jedem das seine.

von Matthias L. (Gast)


Lesenswert?

>Es war hier die Frage, wie er herausbekommt, aus welcher Routine in den
>Interrupt gesprungen ist.

Er solle uns mal erklären, warum er das in der ISR wissen muss? Eine ISR 
ist normalerweise autark von der entsprechend unterbrochenen Funktion.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Ich vermute, daß die ISR irgendwohin zu Debugzwecken ihren Aufrufer 
vermerken soll, so daß bei einem Absturz des Gesamtsystems dies mit 
einem Speicherdump herausgefunden werden kann.

2ter Gast schrieb:
> @Peter Dannegger
>
> Es war hier die Frage,

Es wäre schon schön, wenn Du gnädigerweise den Mitforisten das Mitdenken 
nicht untersagen würdest. Es zeigt sich nämlich gerade erfahreneren 
Zeitgenossen (zu denen ich Peter eindeutig zählen würde) häufig schon 
an der Fragestellung, daß der Fragende ein Problem hat, bei dessen 
Lösung er sich vollkommen verrannt hat. Würden Fragen ausschließlich in 
"Deinem" Sinne beantwortet, dann würde den Fragestellern letztlich gar 
nicht geholfen, sie würden sich nur mit ihren kaputten 
Problemlösungsansätzen noch weiter verrennen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.