mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Interrupt mit Bascom wird doppelt ausgeführt


Autor: Bark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ähnlich wie hier:
Beitrag "mega32 interrupt zählt doppelt"

habe ich das Problem, dass ein prellender Taster unter bascom eine 
doppelte Ausführung meiner ISR verursacht. Wie kann ich in Bascom am 
Ende der ISR es so einstellen, dass alle noch wartenden Interrupts 
gelöscht werden? Hier mal mein quick&dirty sourcecode:

$regfile = "m48def.dat"                                     'compile for 
mega48
$crystal = 10000000                                         'make sure 
it uses the external 10 MHz crystal oscillator
                                                             'dont 
forget to set fusebits


Config Portc = Output
Config Portd = Input
Config Portb = Input

Portc = 0                                                   'no signal 
at output

Portb = 255
Portd = 255                                                 'Pullups

Declare Sub Inter

On Int0 Inter
On Int1 Inter


Enable Int0                                                 'enables the 
TIMER1 interrupt
Enable Int1
Config Int0 = Falling                                       'trigger on 
falling edge
Config Int1 = Falling

Enable Interrupts                                           'allow 
interrupts to be set

Dim C As Byte                                               'set counter 
variable


Do                                                          'main loop 
is empty

Loop

End


Inter:                                                      'interrupt 
routine
Disable Int0                                                'prevent 
double triggering
For C = 1 To 10                                             '100 images
  Portc.0 = 1                                               'set camera 
pin high
  Waitms 49                                                 'wait a 
moment
  Portc.0 = 0                                               'set low
  Waitus 1000                                               'allow 
readout
Next C

Enable Int0                                                 're-enable 
trigger

Return

Autor: Bark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
$regfile = "m48def.dat"       'compile for mega48
$crystal = 10000000

Config Portc = Output
Config Portd = Input
Config Portb = Input

Portc = 0

Portb = 255
Portd = 255  'Pullups

Declare Sub Inter

On Int0 Inter
On Int1 Inter


Enable Int0      'enables the TIMER1 interrupt
Enable Int1
Config Int0 = Falling   'trigger on falling edge
Config Int1 = Falling

Enable Interrupts    'allow interrupts to be set

Dim C As Byte   'set counter variable


Do       'main loop is empty

Loop

End


Inter:   'interrupt routine
Disable Int0       'prevent double triggering
For C = 1 To 10    '100 images
  Portc.0 = 1        'set camera pin high
  Waitms 49 'wait a moment
  Portc.0 = 0    'set low
  Waitus 1000 'allow readout
Next C

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bark schrieb:
> habe ich das Problem, dass ein prellender Taster unter bascom eine
> doppelte Ausführung meiner ISR verursacht.

Das ist völlig normal, wenn man nen externen Interrupt nimmt, d.h. 
Bascom ist daran unschuldig.

Die beste Methode ist, keinen externen Interrupt zu nehmen.

Die quick& wirklich sehr sehr dirty Methode ist, im Interrupt erstmal 
elendig lange kostbare CPU-Zeit zu verwarten und am Ende das 
Interrupt-Pending-Flag zu löschen, indem man es setzt.


Peter

Autor: Bark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort, aber ich brauche unbedingt einen externen 
Interrupt, und der darf auf keinen Fall doppelt getriggert werden. Zeit 
verwarten ist gar kein Problem, solange das reproduzierbar ist, ist es 
egal. Kannst Du mir sagen, wie ich das Interrupt Pending Flag setzen 
kann?

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo bark,

ich habe das in bascom bisher so gelöst:

int auf falling,
interner pullup am int-eingang einschalten
100nF vom inteingang nach masse


in der isr frage ich dann nochmal den portpin direkt ab, ob er auf null 
liegt.
wenn das so ist, setze ich das flag  "taste gedrückt", welches dann in 
der hauptschleife verarbeitet wird.

hat bisher ganz gut geklappt.

natürlich gibt es auch die verschiedenen qualitäten von tastern zu 
bedenken.

wenn das alles nicht hilft, müsstest du vielleicht zusätzliche hardware 
bemühen, um den taster  zu entprellen.

siehe z.b. http://www.labbookpages.co.uk/electronics/debounce.html

gruss  klaus

Autor: Joachim R. (bastelbaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi nehm deine Routine aus dem Interrupt raus und mach es so wie Klaus 
schrieb. Also einfach in der Art:

Interrupt auf Falling mit internem Pull-Up und Taster gegen Masse

Do       'main loop is empty
  if Tasterflag=1 Then
    For C = 1 To 10    '100 images
      Portc.0 = 1        'set camera pin high
      Waitms 49 'wait a moment
      Portc.0 = 0    'set low
      Waitus 1000 'allow readout
    Next C
    Tasterflag=0
  end if
Loop

End


Inter:   'interrupt routine
  Tasterflag=1
Return

Dann ist es egal wie oft dein Interrupt kommt. Solange das Tasterflag 
nicht zurückgesetzt wird, hat das keine Auswirkung auf den Ablauf des 
Programmes.
Und wenn die Taster entprellen willst, dann einfach per Software und 
ohne INT0/1-Interrupt sondern mit Timerinterrupt. Aber dann hast du xx 
Millisekunden, bis du definiert sagen kannst ob der Taster wirklich 
gedrückt ist oder nur ein Störimpuls die Eingabe triggert.

Autor: Wah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, das wäre eine Möglichkeit, ich habe auch das hier probiert:

GIFR.INTF0 = 1

Nur dann meckert Bacom "falscher Datentyp".Wieso? Kann ich das GIFR 
Register nicht beschreiben oder was?

Set Intf0

Hingegen geht, scheint aber keinerlei Auswirkungen auf den 
versehentlichen doppelten Interrupt zu haben.

Autor: frag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch am den anfang der ISR das Prellen abwarten:

Inter:
   waitms 20
   if int0=1 then reti 'weg hier falls es nur eine Nadel war

   ...
return

Autor: hmm.... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach die Tasten mit einem timer. In einem vom timertick ausgeloesten 
Prozess schau ich ob eine Taste gedrueckt wurde. Eine Taste wir erst als 
gedrueckt/losgelassen akzeptiert wenn der Zustand zwei mal gleich ist.

Autor: Joachim R. (bastelbaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interruptroutinen die zuviel innerhalb der eigenen Routine machen, 
sollte man vermeiden, da sonst u.U. die Routine mehrfach aufgerufen 
werden kann was zu einem Stacküberlauf führen kann. Wenn z.B. in der 
Routine von "frag" während der Wartezeit von 20ms Interrupts kommen, 
wird die Routine mehrfach aufgerufen und Overflow ist da. Besser in den 
ISR-Routinen nur "Kleinkram" machen und die Zeitschleifen die du z.B. 
hast ins normale Hauptprogramm auslagern.

Hier mal was zum Entprellen von bis zu acht Tastern an einem Port in 
BASCOM. Ist eine Portierung eines C-Quelltextes der hier im Forum 
gepostet wurde.

Die Variable io_press zeigt bitweise dass ein Eingang ein Signal 
hat/hatte. Das liest man aus und löscht dann die Variable. Die Variable 
io_state gibt den aktuellen Zustand der Eingänge an. Die Variablen 
io_ct0 und io_ct1 bilden einen Zähler bis drei für jedes Bit des 
Eingangsport. Die Entprell-ISR-Routine ist wirklich tricky gemacht und 
funzt einwandfrei.
Der Timerwert von hier 100 gibt an wie oft die Routine die Eingänge 
checkt.
'Variablen für die Entprell-Routine
Io_port Alias Porta
Io_pins Alias Pina
Config Io_port = Input
Io_port = 255 ' Pull-Ups setzen
Dim Iwr0 As Byte
Dim Io_ct0 As Byte
Dim Io_ct1 As Byte
Dim Io_state As Byte
Dim Io_press As Byte

' Init Eingänge
Io_ct0 = 0
Io_ct1 = 0
Decr Io_ct0
Io_ct1 = Io_ct0
Io_state = 0
Io_press = 0

'Timer2-Interrupt konfigurieren (Timer2 = 8bit)
Config Timer2 = Timer , Prescale = 1024
On Timer2 Timer2_isr              'Interrupt Service Routine anspringen
Timer2 = 100
Enable Timer2

' Interrupts freigeben
Enable Interrupts

'### MAINLOOP
Do

  ' Zum Keyboardcheck den Timer anhalten
  Disable Timer2
  If io_press<>0 Then
    if io_press.0=1 Then 'tu was
    if io_press.1=1 Then 'tu was andres
    io_press=0
  End If
  Enable Timer2 ' und wieder starten
Loop
END

'### Interrupt Routine für Timer2 (Eingänge pollen + entprellen)
Timer2_isr:
  Timer2 = 100
  Iwr0 = Io_pins
  Iwr0 = Not Iwr0
  Iwr0 = Iwr0 Xor Io_state
  Io_ct0 = Io_ct0 And Iwr0
  Io_ct1 = Io_ct1 And Iwr0
  Io_ct0 = Not Io_ct0
  Io_ct1 = Io_ct1 Xor Io_ct0
  Iwr0 = Iwr0 And Io_ct0
  Iwr0 = Iwr0 And Io_ct1
  Io_state = Io_state Xor Iwr0
  Iwr0 = Iwr0 And Io_state
  Io_press = Io_press Or Iwr0

Return

Autor: Bark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jepp, ok, jetzt läuft die Aufgabe in der Hauptroutine und es 
funktioniert super und ohne jedes Problem. Dankeschön!

Autor: krümeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es nicht auch möglich am Anfang der ISR die Interrupts komplett zu 
deaktivieren oder nur den einen Interrupt und dann am Ende wieder 
einzuschalten?

Ich habe vor kurzem beim Kennenlernen der 8051er einen Counter mit dem 
Timer gebastelt, der das Ergebnis dann noch bearbeitet und auf 7 Segment 
Anzeigen ausgibt. Das ist relativ zeitaufwendig und es hat auch 
rumgesponnen wenn der Impuls zu oft kam. Ich habe dann einfach die Ints 
ausgemacht am Anfang der ISR und am Ende wieder an. So können zwar 
Ereignisse unterschlagen werden, aber wenn es darauf nicht ankommt, 
passt das auch.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
krümeltee schrieb:
> Wäre es nicht auch möglich am Anfang der ISR die Interrupts komplett zu
> deaktivieren oder nur den einen Interrupt und dann am Ende wieder
> einzuschalten?

Du vertraust der Hardware wohl nicht?
Da muß ich Dich enttäuschen, sie macht das automatisch, genau dem 
Datenblatt entsprechend.



> Ich habe vor kurzem beim Kennenlernen der 8051er einen Counter mit dem
> Timer gebastelt, der das Ergebnis dann noch bearbeitet und auf 7 Segment
> Anzeigen ausgibt. Das ist relativ zeitaufwendig und es hat auch
> rumgesponnen wenn der Impuls zu oft kam. Ich habe dann einfach die Ints
> ausgemacht am Anfang der ISR und am Ende wieder an.

Das ist Quatsch mit Soße.

Die einzige Möglichkeit, daß beim 8051 ein Interrupt sich selber 
unterbricht, ist die, daß Du im Interrupthandler die eigene Priorität 
hochsetzt.
Ansonsten kannst Du Dich auf den Kopf stellen, erst nach dem RETI kann 
der nächste Interrupt zuschlagen.
Man sollte ruhig mal das Datenblatt lesen, bevor man völlig sinnlosen 
und wirkungslosen Code in den Interrupt packt.


Wenn Du aber nem anderen Interrupt ne höhere Priorität zugewiesen hast 
und der stört, dann kann man die Interrupts global sperren.
Dann fragt sich allerdings, warum man diesen überhaupt erst die höhere 
Priorität gegeben hat, um sie dann doch wieder auszuhebeln.

Machs also lieber gleich richtig, d.h. nutze die Prioritäten erst dann, 
wenn Du Dir dabei auch was gedacht hast.


Peter

Autor: Alex (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ja, der Beitrag ist schon sehr alt. Ich stand jetzt aber vor dem 
gleichem Problem einen weiteren Interrupt innerhalb der ISR zu sperren 
oder eine doppelte Auslösung zu verhindern. Vielleicht hilft es ja 
jemandem.

User "Wah" hat eigentlich schon die richtige Lösung gepostet:

"GIFR.INTF0 = 1"

Keine Ahnung warum bei ihm eine Fehlermeldung kam...

GIFR ist das "general interrupt flag register", sowas wie ein 
Zwischenspeicher der weitere Interrupts auch innerhalb der ISR 
speichert.
Ist die ISR am Ende bei Return angekommen, wird zwar wieder in das 
Hauptprogramm gesprungen, aber der zwischengespeicherte Interrupt 
wieder sofort ausgelöst.

Ein DISABLE der Interrupts innerhalb der ISR funktioniert leider nicht 
und scheint auch nicht nötig zu sein, da der AVR zwar weitere Interrupts 
sperrt, aber eben das FLAG für einen Interrupt im GIFR speichert. Ein 
weiteres Interrupt wird dann eben nur zeitversetzt ausgelöst, sobald man 
z.B. im Hauptprogramm wieder die Interrupts auf ENABLE setzt.

Man muss also innerhalb der ISR den Interrupt Flag im GIFR Register 
löschen und zwar ganz am Ende vor Return.

Das GIFR hat 8 Bits, relevant für INT0 & INT1 sind Bit6 und Bit7.
Man setzt nun einfach das entsprechende Bit des Registers auf 1.

Möchte man den Interrupt Flag für INT0 löschen:
GIFR = 64

Möchte man den Interrupt Flag für INT1 löschen:
GIFR = 128

Natürlich geht das auch mit binärer Schreibweise.
Für INT0:
GIFR = &b10000000

Für INT1:
GIFR = &b01000000

So könnte das in Bascom aussehen:

On_int:
Portd = &B00000000
Sound Portd.7 , 200 , 1000
Wait 5
Gifr.int1 = 1
Return

Alex

Autor: Fred Red (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alex,

eine sehr, sehr hilfreiche Erklärung.
Mit Interrupt’s hatte ich auch immer wieder Probleme. Seit dem ich am 
Anfang der Hauptschleife das GIFR- Register komplett lösche nicht mehr. 
War oft ein Problem für Stacküberlauf.
Eins ist für mich noch unklar warum Interrupt in eine Art 
„Schieberegister“  sich die „Klicks" merken müssen.
Ist es nicht so, INTx  spring aus der Do in ISR. Nun eine Entscheidung 
treffen und wieder ab zu Do.
Warum diesen „Klick“ merken und dummer Weise den letzten „Klick“ wieder 
an Anfang des Register stellen, wenn Überlauf?


Mit freundlichen Grüßen

Autor: pfeife (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred R. schrieb:
> Eins ist für mich noch unklar warum Interrupt in eine Art
> „Schieberegister“  sich die „Klicks" merken müssen.

Nicht nur das ist mir auch unklar.


> Ist es nicht so, INTx  spring aus der Do in ISR. Nun eine Entscheidung
> treffen und wieder ab zu Do.
> Warum diesen „Klick“ merken und dummer Weise den letzten „Klick“ wieder
> an Anfang des Register stellen, wenn Überlauf?

Jau. Entscheidung und ab ... Aber was sind die „Klicks" vom 
„Schieberegister“

Autor: Staubfänger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn ich Dich recht verstehe, dann fragst Du Dich warum der uC so 
funktioniert, daß ein Interrupt mehrfach ausgelöst werden kann; 
insbesondere warum er noch einmal ausgelöst werden kann, wenn der erste 
doch gerade behandelt wird bzw. eben behandelt wurde.

Zu dem folgenden schaue Dir bitte mal parallel die Bilder und die 
Beschreibung im Datenblatt an:

Das Verhalten ergibt sich zunächst einmal ganz natürlich, wenn man eine 
ganz einfache Schaltung dafür entwirft:
Das externe Signal löst einen Interrupt dadurch aus, das ein Bit in 
einem Register gesetzt wird.
Bei jedem Übergang von einem Befehl zum nächsten, beeinflusst diese Bit, 
wenn es gesetzt wurde, welcher Befehl als nächstes ausgeführt wird; 
effektiv in dem der Programmzähler auf einen, von dem Interrupt 
abhängigen Wert gesetzt wird. Das ist bei den AVRs eine Adresse in der 
Interrupt-Vektor-Tabelle.
Gleichzeitig wird das oben erwähnte Bit, das anzeigt, dass ein Interrupt 
ausgelöst wurde, wieder zurückgesetzt. (Das könnte man auch zu einem 
anderen Zeitpunkt machen, aber das hängt von dem Hersteller ab, wie er 
sich da entscheidet).
Tritt also das Ereignis, das diesen Interrupt auslöst, nach diesem 
Zeitpunkt noch einmal ein, so wird das Bit wieder gesetzt.
Der Mechanismus, der nach jedem Befehl, das Interrupt-Bit berücksichtig, 
ist allerdings zu diesem Zeitpunkt ausser Kraft gesetzt, sonst würde 
eine gerade laufender ISR unterbrochen. (Bei manchen CPUs wird das auch 
nicht getan oder nur für den zuletzt ausgelösten Interrupt. Hängt wieder 
vom Hersteller ab und diese Varianten bieten auch gewisse Vorteile).
Jedenfalls, da der Mechanismus ausser Kraft ist, wird die ISR nicht 
unterbrochen.
Erst wenn man mit IRET die ISR verlässt, wird er wieder wirksam. Falls 
inzwischen wirklich der Interrupt erneut aufgetreten ist, so wird gleich 
wieder die entsprechende ISR ausgeführt.

Wie gesagt, das Verhalten ergibt sich zwangsläufig aus einer ganz 
einfachen, man könnte sagen Straight-Forward oder As-Simple-As-Possible 
Implementierung dieses Ablaufs. Das ist insofern keine "Absicht".
Diese, wie auch die anderen oben in Klammern erwähnten Varianten sind 
sinnvoll nutzbar.

Man muss aber doch wissen, was bei einem gewissen Prozessor tatsächlich 
geschieht und das berücksichtigen.

Bei Tastern nun, ist es so, dass die, wie Du schon weißt, prellen. Das 
aber bedeutet, dass ein Interrupt wahrscheinlich mehrfach ausgelöst 
wird.
Es gibt nun zwei Auswege aus dieser Situation:

A) Man betreibt prellende Taster gar nicht an einem Interrupt. Da spart 
man sich zusätzlichen Code um diesen Fall zu behandeln.

B) Man fügt zusätzlichen Code hinzu, um den Fall zu behandeln - d.h. 
kurz hintereinander auftretende gleiche Interrupts als einen zu 
behandeln. Das führt aber das Problem ein, dass man ziemlich genau 
wissen muss, welche Interrupts durch die selbe Ursache (den einen und 
einzigen Tastendruck) ausgelöst wurden und welche nicht. Das ist nicht 
ganz einfach, denn die Taster verhalten sich verschieden, andererseits, 
kann ein Benutzer kaum in kürzeren Abständen, als etwa ein paar 100ms 
eine Taste drücken.

Deswegen vermeidet man, und rät insbesondere Anfängern, Taster nicht mit 
Interrupts zu behandeln.

Andererseits gibt es durchaus Interruptquellen, die so kurz 
hintereinander Interrupts auslösen, das die ISR noch nicht fertig werden 
konnte. Auch dafür gibt es einige Wege zu Behandlung, von denen eine 
ist, den oben beschriebenen Ablauf nicht als Problem, sondern als Lösung 
zu betrachten:
Wenn nämlich ein weiterer Interrupt wiederum das Flag setzt, und man 
weiß, dass das so sein soll, dann kann man das nutzen. Da aber nur noch 
ein zusätzlicher Interrupt gespeichert werden kann, geht das nur mit 
Quellen, die während der Laufzeit der ISR höchstens einen weiteren 
Interrupt auslösen. Geht also auch nicht für alle Fälle.

Da guckt man dann, danach die ISR zu verkürzen, damit man im Code auch 
alle Interrupts mitbekommt.

Das ist ein komplexes Thema. Daher wird Anfängern zuerst dazu geraten:
1. ISR so kurz wie möglich zu halten.
2. Keine Quellen an Interrupts zu betreiben die unnötige weitere 
Interrupts auslösen - wie es eben bei Tastern der Fall ist.

Ich hoffe das hilft Dir.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Staubfänger schrieb:
> Wie gesagt, das Verhalten ergibt sich zwangsläufig aus einer ganz
> einfachen, man könnte sagen Straight-Forward oder As-Simple-As-Possible
> Implementierung dieses Ablaufs. Das ist insofern keine "Absicht".

Das Verhalten ist sehr wohl volle Absicht!
Jeder Interrupt ist zwangsläufig wichtig, sonst würde man ja keinen 
Interrupt verwenden.
Oberste Prämisse ist daher, es darf kein Interrupt verloren gehen, auch 
wenn er gerade nicht behandelt werden kann.
Z.B. ein Ethernet-Controller kann mehrere Interruptquellen haben und 
jede muß behandelt werden, sonst gehen Nachrichten verloren.

Daß man Interrupts auch für schneckenlahme menschliche Eingaben mit 
prellenden Tastern verwendet, ist zwar prinzipiell erlaubt, aber nicht 
die Regel (sollte es nicht sein).

Autor: Staubfänger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Staubfänger schrieb:
>> Wie gesagt, das Verhalten ergibt sich zwangsläufig aus einer ganz
>> einfachen, man könnte sagen Straight-Forward oder As-Simple-As-Possible
>> Implementierung dieses Ablaufs. Das ist insofern keine "Absicht".
>
> Das Verhalten ist sehr wohl volle Absicht!

Da das von Dir, meinem Zitat folgende, beschriebene ohne Zweifel 
plausibel ist, hätte ich wohl besser gar keine Vermutung darüber äussern 
sollen, die sich wie eine definitive Aussage liest. Ich ziehe sie daher 
zurück. Was da wer und wann gedacht hat, bleibt vermutlich ohnehin auf 
immer im Dunklen.

Es scheint mir im übrigen durchaus nicht unwahrscheinlich, dass 
derjenige, der das zum ersten Mal implementiert hat, dies auf die von 
mir beschriebene Weise getan hat und beim Testen erfreut festgestellt 
hat, dass er alleine durch das löschen des Interrupt-Flags, einen (nur 
einen) weiteren Interrupt erfassen kann, obwohl die ISR schon läuft. 
Aber ich will nicht darauf bestehen, das wäre albern.

Andererseits ist der von Dir beschriebenen Maxime auch nicht vollständig 
entsprochen worden, denn spätestens der dritte Interrupt geht ja - in 
der beschriebenen Implementierung - fallweise doch verloren. Ist das 
nun, für sich genommen, ein Zeichen, dass er das gewollt hat? Oder hat 
er es hingenommen? Wenn ja, warum nicht auch die erste Eigenschaft?
Er konnte allenfalls annehmen, das in der Praxis ein weiterer Interrupt 
reichen sollte. Das das oft nicht der Fall ist, zeigen aber meiner 
Meinung nach Mechanismen die mehrfach ausgelöst Interrupts zulassen 
(z.B. im Verein mit reentranten ISRs.

Ich habe ja keinesfalls verneint, dass potentiell jeder Interrupt 
wichtig ist. Auch liest sich mein Text, meiner Meinung nach, keinesfalls 
so, als wenn ich mit der Beschreibung des Ablaufs sagen wollte, das dies 
der einzig sinnvolle ist, oder der, der alle denkbaren Anforderungen 
erfüllt.
Sie zielte vielmehr auf den Fokus der Frage. Der war nicht, warum alle 
Interrupts erfasst werden (was ohnehin nicht der Fall ist; jedenfalls 
nicht unter gewissen weiteren Nebenbedingungen) sondern vielmehr, warum 
denn mehr als einer erfasst wird, in dem Kontext von Tastern, wo doch 
die nachfolgenden Interrupts (durch das prellen) so störend sind.

Naja. Ich bemühe mich hier, klarzustellen, dass ich nicht völligen 
Unsinn erzählt habe. Ich weiß; Du bist in der Regel keiner der unbedingt 
Recht haben will. Ich bin da sensibler als Du. Aber was soll's? Es 
sollte dem TO helfen ein Verständnis zu entwickeln.

Autor: Staubfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter D.

Wenn ich mir das recht überlege, dann wäre es besser gewesen, als 
primäres Ziel zunächst das zu nennen, was Du, Peter, genannt hast: 
Nämlich das, möglichst viele, wenn nicht alle Interrupts erfasst werden 
sollen. Und dass das eben auch zur Folge hat, dass gerade bei Tastern 
unnötig viele Interrupts erfasst werden. Und dass das wiederum zu dem 
Ratschlag führt, Taster nicht mittels Interrupts zu erfassen.

Also gut: Bark, bitte fasse meinen Beitrag in diesem Lichte auf. Ich 
hoffe ich habe Dich nicht allzusehr in die Irre geführt.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fred,

freut mich, dass Dir meine Erklärung gefällt. Ich suche selbst immer 
wieder nach möglichst einfachen Erklärungen mit expliten Anleitungen und 
kleinen Beispielen. Oft reichen MIR pauschale Aussagen wie "Flag 
löschen" nicht aus.Besonders immer dann, wenn ich ungeduldig mal etwas 
Neues ausprobieren möchte, und das Datenblatt irgendwie wieder viel zu 
lang und kryptisch ist. Diesmal habe ich mich eben durchgebissen und der 
kleine Artikel ist halt 7 Jahre nach Fragestellung entstanden :-)

"Eins ist für mich noch unklar warum Interrupt in eine Art
„Schieberegister“  sich die „Klicks" merken müssen."

Eine Ausführliche Antwort hast Du ja mittlerweile erhalten :-) Hatte mir 
darüber noch keine Gedanken gemacht, aber war ein interessanter Ausflug 
noch ein Stück tiefer in die Hardware hinein.

Mich als reinen Anwender der nur ganz simplen Code mit Bascom und ganz 
wenig in Assembler schreibt, hat dieses Verhalten des AVR`s eigentlich 
auch immer eher gestört. Aber: "it`s a feature, not a bug" Also klasse, 
dass Du mit Deiner Frage die Diskussion darüber ausgelöst hast. Vielen 
Dank auch an die nachfolgenden User für die interessanten Erklärungen.

Alex

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Staubfänger schrieb:
> Andererseits ist der von Dir beschriebenen Maxime auch nicht vollständig
> entsprochen worden, denn spätestens der dritte Interrupt geht ja - in
> der beschriebenen Implementierung - fallweise doch verloren.

Bei einem externen Peripheribaustein bleibt die Interruptleitung solange 
aktiv, bis alle Ereignisse abgearbeitet sind. Es geht also nichts 
verloren.
Es kann aber passieren, daß keine neue Flanke erzeugt wird, da schon 
beim Eintritt in den Handler mehrere Ereignisse vorliegen. In dem Fall 
sollte man vor Verlassen des Handlers prüfen, ob die Leitung noch aktiv 
ist oder den zustandsgetriggerten Interrupt verwenden.

Es gab allerdings auch MCs, die Interrupts ohne eigenes Pending-Flag 
hatten, z.B. der Scenix SX18. Da konnte dann nicht festgestellt werden, 
ob bei einem externen Interrupt auch gleichzeitig ein Timerinterrupt 
vorlag. Es konnten also Timerinterrupts verloren gehen.
Ich hab dann beim Lesen des Datenblattes nur mit dem Kopf geschüttelt 
und die Eval-Samples samt Datenblatt in den Papierkorb befördert.

Autor: Fred Red (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nun auch noch mein Dank an Peter Dannegger und Staubfänger.

Diese sachlichen Kommentare sind lesenswert. Nun weiß ich ein externer 
Interrupt ist nicht nur ein „Klick“ ,wie ich es lustigerweise 
bezeichne,um die Hauptschleife zu verlassen. Habe es immer nur als Art 
Aufruf eines Unterprogramm verstanden.
Wichtiger Lerneffekt:
Um Interrupt zu nutzen, sollten die Vor- Nachteile schon bei der 
Projektentwicklung hinterfragt werden.

Mit freundlichen Grüßen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.