Kurze Frage zum Interrupt

Sauger schrieb:
> nein, wenn er (der Interrupt) freigegeben ist schlägt er zu.

theoretisch könnte aber die

> "Empfangspuffer-Warten-Schleife"

ja auch in einem Interrupt sein...

Ob Dein Interrupt zubeißt oder nicht, ist nicht davon abhängig, wo im 
Programm sich die CPU gerade rumtreibt.  Ausschlaggebend dafür ist 
ausschließlich das I-Flag im Statusregister.

Klaus Dietz schrieb:
> wird das I-Flag nicht über den Befehl sei() gesetzt?

Ja.  Ab dann sind Interrupts erlaubt.  Und das bleiben sie, solange kein 
cli() kommt und solange nichts sonst am Statusregister manipuliert (beim 
Interrupt wird das Flag übrigens gelöscht, aber beim Beenden des 
Interrupts wieder auf den alten Wert gesetzt).

Wenn diese Bedingungen erfüllt sind und wenn Dein Programm also auf ein 
Flag vom Interrupt ewig wartet, aber keines kommt, würde ich davon 
ausgehen, dass es vom Interrupt nicht gesetzt wird (und nicht, dass kein 
Interrupt ausgeführt wird).

Klaus Dietz schrieb:
> ich hab den Prägnanten teil des Programms mal zusammengefasst.
>
> so sieht das dann ungefähr aus.

Du hast deine Lektion von gestern immer noch nicht gelernt.
Poste ein komplettes, getestetes Program.

Das Programm muss sich hier bei uns kompilieren lassen und wenn du uns 
sagst, das und das muss auf den Eingängen gemacht werden, damit man das 
Problem sieht (vorher bei dir ausprobieren ob das zurechtgestutzte 
Programm bei dir auch wirklich dieses Verhalten zeigt), dann kann man 
auf dieser Seite des Montiors auf Fehlersuche gehen.

Klaus Dietz schrieb:
> Lektion von gestern?
> ich glaub du verwechselst mich mit jemandem...

Mag sein. In dem Fall entschuldige ich mich.
Mir ist nur der Anfang von main sehr bekannt vorgekommen, und da ging es 
auch um einen INT0

Die Variable 'Interrupt' (übrigens ein selten dämlicher Name für eine 
Variable), ... ist die volatile?

(Und im Grunde gilt es trotzdem: mach ein komplettes Beispiel fertig)

Sag vorher noch ganz schnell ob 'Interrupt' volatile ist oder nicht. 
Wenn nicht, dann hast du dein Problem identifiziert.

Klaus Dietz schrieb:
> und die variable interrupt ist mit uint8_t definiert.

und hast du dir mal angeschaut, was für ein Assembler-Code aus deinem 
C-Code ensteht?

Klaus Dietz schrieb:
> nein wie soll den das gehen?

indem man die lss-Datei öffnet...

Peter schrieb:
> Klaus Dietz schrieb:
>> was meinst du mit volatile?
>>
>> und die variable interrupt ist mit uint8_t definiert.
>
> dann lies mal hier
> 
http://www.mikrocontroller.net/articles/Interrupt#Steuersignale_zwischen_ISR_und_Hauptprogramm

Oder hier
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Datenaustausch_mit_Interrupt-Routinen

Justus Skorps schrieb:
> Klaus Dietz schrieb:
>> und die variable interrupt ist mit uint8_t definiert.
>
> und hast du dir mal angeschaut, was für ein Assembler-Code aus deinem
> C-Code ensteht?

Im Prinzip keine schlechte Idee, aber wenn die Variable nicht volatile 
ist, brauchen wir erst mal gar nicht weiter suchen :-)

(Zumal ja auch gar nicht gesagt ist, dass er mit dem Assembler-Output 
was anfangen kann)

Karl heinz Buchegger schrieb:
> Im Prinzip keine schlechte Idee, aber wenn die Variable nicht volatile
> ist, brauchen wir erst mal gar nicht weiter suchen :-)

jo, das hätte man vorher mal machen sollen

> (Zumal ja auch gar nicht gesagt ist, dass er mit dem Assembler-Output
> was anfangen kann)

na ja, aber wenn da ein kompletter Abschnitt fehlt, dann sollte das 
einem schon irgendwie auffallen denke ich mir

Nein.

Sie heißt "I_Flag"
Und sie ist vom Datentyp "volatile uint8_t"

(und I_Flag ist immer noch ein selten dämlicher Name. Er sagt so rein 
gar nichts darüber aus, welche Aufgabe diese Variable hat, was es 
anzeigt, wenn sie 0 oder 1 ist.

Benenne Variablen weder nach ihrem Datentyp noch wer sie setzt. Benenne 
sie nach ihrer Funktion. Die Variable zeigt an, dass eine Taste gedrückt 
wurde (das rate ich jetz, weil ich nicht weiß woher der INterrupt 
bedient wird). Also könnte sie einen Namen bekommen, der das ausdrückt. 
Wenn dieser Interrupt ausschliesslich dafür zuständig ist, dass dein 
Benutzer sich beim System bemerkbar macht um mmitzuteile "Was immer du 
momentan tust, hör auf damit", dann könnte man auch das als Name nehmen, 
irgendwas mit den Worten Cancel und Operation. Mglw. auch noch ein 
Request da mit drinnen

dann liest sich die Schleife plötzlich

  while( irgendwas    &&
         ! OperationCanceled )


oder
  while( irgendwas    &&
         ! CancelRequested )

oder
  while( irgendwas    &&
         ! KeyPressed )

und das ist dann schon fast Klartext.

Lass dich bei deiner Namenswahl von der Verwendung der Variablen leiten! 
Sieh dir an, wie und wo sie abgefragt wird und dann denk über einen 
Namen nach, der in diesem Abfragezusammenhang maximalen Sinn ergibt.

Lies mal was zum Thema Interrupt. Das erspart die 1001 philosopische 
Diskussion über das ewig gleiche Thema.

MfG
Falk

Klaus Dietz schrieb:
> warum den nicht? Aber wenns mehr werden dann bevorzuge ich schon das was
> Karl Heinz gesagt hat. Spricht ja auch irgendwie dafür das man einen
> Code selbsterklärend schreibt.


Nicht: 'spricht ja irgendwie dafür'

Es spricht alles dafür!

Unter anderem auch die Erfahrung, dass diejenigen mit den 
fehleranfälligsten und unwartbarsten Programmen auch meistens die sind, 
die sich einen feuchten Kehrricht um formale Dinge, wie Codeformatierung 
oder Funktions- und Variablennamen, Konsistenz etc. kümmern.

Seltsamerweise haben die Programmierer, die auf solche Dinge achten, 
meistens auf lange Sicht deutlich weniger Probleme :-)