Zitat Zitat von Holomino Beitrag anzeigen
löst das schon während der laufenden ISR den nächsten Interrupt aus - nicht sofort, da beim Betreten einer ISR implizit das "global interrupt enabled"-Flag zurückgesetzt wird. Das gesetzte Statusflag wirkt aber sofort nach Verlassen der ISR (hier wird implizit auch wieder das "global interrupt enabled" gesetzt) und Dein Programm springt direkt wieder in die gleiche ISR. Das merkst Du z.B., wenn Du in Deiner ISR einen Zähler inkrementierst. Der springt dann mal zwei oder mehr Schritte pro Tastendruck, je nachdem, wie lange das Prellen dauert und wie schnell Dein ISR-Code abläuft.
Interessanter Aspekt, da ich davon ausging, dass erst nach dem Verlassen der ISR der nächste Interrupt durchgelassen wird. Das "speichern" des Flag innerhalb eines ISR ist mir neu und macht einiges unübersichtlicher...
Daher wollte ich auch innerhalb des ISR die Tastenentpreller (später teils Tasten, Türkontakte, Bewegungsmelder, etc) einsetzen. Nach deiner Beschreibung, aber vollkommen unsinnig.

Zitat Zitat von Holomino Beitrag anzeigen
Wenn Du im ms-Bereich über einen Timer einfach nur den Port abfragst, hast Du dieses Problem nicht. Das Abtasten der Pin-Zustände im zeitlichen Raster wirkt wie ein digitaler Tiefpass, der das Prellen oberhalb der halben Abtastfrequenz (siehe Nyquist- oder Shannon-Theorem) herausfiltert.
Hier habe ich immer noch "Bauchgrummeln", da auch ohne minuten-/stundenlange Kontaktbetätigung, im ms-Interval ISR-Routiniert wird - unnötige Energie und Rechenleistung!?

Wie sieht es mit einem Kompromiss als Königsweg aus?
Bsp:
PortChange-Interrupt löst den Timer-Interrupt aus, der diesen wiederum ablöst und eine Tastenentpreller einleitet. Erst danach DARF der "global interrupt enabled" des PortChange wieder gesetzt werden.