Interrupt-Abfrage >>> Routine vereinfachen

[Holomino]

Hier habe ich immer noch "Bauchgrummeln", da auch ohne minuten-/stundenlange Kontaktbetätigung, im ms-Interval ISR-Routiniert wird - unnötige Energie und Rechenleistung!?

Löse Dich von dieser Vorstellung. Ohne Sleep-Modi (die eigentlich nur im Batteriebetrieb interessant sind) läuft der Controller in der main-Loop immer in der Runde. Da spart man nix. Die Verluste von Netzteil und Regler bewegen sich üblicherweise weit oberhalb der vom Controller aufgenommenen Leistung.

Der von mir gepostete ISR-Rahmen dürfte incl. Stack-Push/-Pop nicht mehr als 10..20µs bei 8MHz dauern. Im Zyklus von 1..8ms aufgerufen (so schnell muss man erst mal tippen können) und bezogen auf die Gesamtleistung des Controllers reden wir also über 0,125 .. 2% Rechenlast für die Timerroutine.

[frabe]

Hallo - nochmal.

Die Methoden die ihr mir mit dem Timer-ISR aufgezeigt habt ist toll und funktioniert. Soweit kann ich auch als Anfänger jede Code-Zeile nachvollziehen.
Hier ist es so, das alle Kontakte des Register A kontinuierlich abgefragt werden. Sobald eine Veränderung statt findet, wird dieser Kontakt auf Prellung überprüft.
Zum Entprellen wird einfach eine Variable hoch gezählt. Sollte 30ms keine Veränderung statt finden, ist dieser Kontakt entprellt!
Danach kommt der Befehl "tu was".

Aber ... eigentlich brauche ich eine Kontaktabfrage aus dem main() heraus.
Innerhalb des Prg-ablauf gibt es verschiedene Bereiche. Mal ist es wichtig Kontakt PA4 dauernd zu überwachen, wärend dessen mir Eingang PA5 vollkommen egal ist.
Erst wenn ich PA4 benötige, würde ich auf Veränderung und Entprellung abfragen.


Oder ich sehe vor lauter Bäumen den Wald nicht mehr...

[Holomino]

Ich denke mal, es ist kein Problem, den Code so zu erweitern, dass Du auch aus der main() auf die Tasten reagieren kannst. Tatsächlich hatte ich die Änderungen hier schon reingeschrieben, dann allerdings wieder gelöscht - ganz einfach weil es jetzt gänzlich unterschiedliche Konzepte für unterschiedliche Anwendungen gibt (nix für Ungut, aber bei "ich bräuchte" von nem Youngster lohnt es sich manchmal zu hinterfragen, ob er es denn wirklich braucht).

Eine tastengesteuertes Displaymenü z.B. würde ich mit Funktionspointern zu erschlagen suchen. Andere logische Zusammenhänge eher mit einer einfachen StateMachine. Ob das dann allerdings immer in der main() liegt oder ebenfalls in der Timer-ISR, hängt alleine davon ab, wie lange der Ablauf der Aktionen ist. Eigentlich präferiere ich die Timer-ISR, weil sie sich ideal für mehrere "asynchone" Aufgaben eignet (Das ist zwar nicht wirklich asynchron, aber mit Prescalern kann man fabelhaft passende Abfragezyklen bauen und so die Rechenleistung optimal aufteilen). Die main() hebe ich mir dann gerne für niederpriorisierte Aufgaben auf.

Wir müssten jetzt also erst einmal darüber sprechen, was genau Du vor hast.

[frabe]

Ein Reaktionsspiel; erst wenn Teil A erfolgt ist, läuft Teil B ab - usw.
Zwichendurch werden immer wieder Reaktionszeiten ermittelt, die unterschiedliche Wege vorgeben.
Bsp: Teil A, Reaktion langsam, spring in Teil B.
Teil A, Reaktion schnell, spring in Teil C.

Natürlich eine StateMachine!

Innerhalb der einzelnen Teile (A, B) würde ich die jeweiligen Tastenabfrage über Interrupts erledigen.
Somit kann mir der jeweilige Kontakt nicht mehr "durchrutschen" oder das Programm verlangsamen.
Bsp: in Teil A wird die Taste PA4 und in Teil B wird die Taste PA5 auf Veränderung überwacht.

Innerhalb der jeweiligen Blöche A, B etc. werden bestimmte elektro-mechanischen Kontakte (Tasten, Türkontakte, Bewegungsmelder etc) benötigt - daher Entprellung notwendig!
Wenn das Prinzip einmal läuft, braucht man das Prinzip nur noch kaskadieren und/oder verschachteln.
Zur Zeit baue ich einfach nur eine Versuchsplattform mit 2 Tastern und 2 Ausgängen (LED, Summer) auf.

Der ATtiny84 hat nur 2 Timer-Interrupts. Einen lasse ich im 1ms-Takt als Zeitmesser laufen.
Den habe ich auch als Eingangsabfrage nutzen wollen - ala "EierlegendeWollmilchSau" - bis ich jetzt nur noch "Bäume, aber keinen Wald" sehe...

- - - Aktualisiert - - -

Somit müsste nach meinem Verständnis eine Eingangsabfrage blockweise mit einem Timer-Interrupt erfolgen.
Bsp:
Teil A wird gestartet, PA4 wird dauerhaft überwacht, wären dessen laufen sonstige (niederpriorisierte) Dinge.
Teil A wird beendet, PA4-Abfrage gestoppt.
Teil B startet, PA5 und PB1 überwacht,
bis PB1 nicht mehr gebraucht wird, aber PA5 weiter überwacht wird.
usw.

D.h. die einzelnen Eingangsüberwachungen (PA4, PA5, PB1) werden nach Bedarf ein- und ausgeschaltet.
Königslösung?!

[Holomino]

Ein schönes Beispiel, klingt sehr einfach, hat es aber in sich. Mal so grob geplant mit 2 LEDs und 2 Tastern.

Statusaufteilung:
- Idle: Warte auf Key1Up, um das Spiel zu starten
- Started: Blinke 3x mit LED1, wobei das Erlöschen des 3. Blinkzyklus den Spielstart signalisiert (das 3. Blinken kann man fieserweise noch mit einem leichten Random verzögern)
- Measure: Messe die Zeit bis zum Key2Down und entscheide anhand der Reaktionszeit zwischen Success oder Fail
- Success: Gebe Erfolgsmeldung LED1/2 blinken 10 mal im Wechseltakt.
- Fail: Nur einmal blinken
Success und Fail wechseln zurück zu Idle.
Obacht bei "Started". Wer hier schon vor dem Startsignal wild auf Key2 herumtippt, wird mit Spielabbruch "bestraft".
Ein Timeoverflow in "Measure" sollte das System nach 10s in den "Idle" zurücksetzen

spinnerte Erweiterungsmöglichkeiten:
- Highscore in EEPROM speichern
- Tendenzen besser/schlechter erfassen (also mit vorhergehendem Ergebnis vergleichen)
- Schwierigeres Startverhalten bei guten Ergebnissen (Startblinken wird schneller oder wilder mit mehr Random)

Was uns in den einzelnen States interessiert:
- KeyUp/KeyDown
- Timerzyklus für statusinternen Zähler
Diese Funktionen würde ich jedem Status optional zur Verfügung stellen, egal, ob sie gebraucht werden oder nicht. Zusätzlich bekommt jeder Status eine Init-Funktion, in der er sich entsprechend (erst einmal ganz abstrakt ausgedrückt) am System anmeldet und seine internen Variablen initialisiert.


Aktoren:
- LEDs
- optionale statische Variablen für vorhergehende Ergebnisse
- optional EEPROM für Highscore
Diese "Aktoren" kommen in separate Module, quasi als "globale Funktionen".

Aber bevor ich jetzt codemäßig anfange loszuwirbeln, erst einmal Dein Kommentar. Weiter geht es also nach der nächsten Maus.

[frabe]

Moin.
Bin gerade auf dem Sprung - konzentriert komme ich esrt zu Mittag dazu.

Ein schönes Beispiel, klingt sehr einfach, hat es aber in sich. Mal so grob geplant mit 2 LEDs und 2 Tastern.

Mein Testaufbau sieht erst mal genau so aus. Das Spiel wird wesentlich komplexer. Mit Analog-Eingangs-Auswertungen, etc.
Die Struktur steht auch soweit. Nur wollte ich endlich mal mit Interrupts arbeiten - NEULAND für mich - DAS macht es jetzt gerade etwas komplizierter, wird, wenn ich´s begreife und kontrolliere wesentlich schneller, flexibler und modularer!

(das 3. Blinken kann man fieserweise noch mit einem leichten Random verzögern)

...ohhhhh, welch B Ö S E R Gedanke ...

[frabe]

se
Aber bevor ich jetzt codemäßig anfange loszuwirbeln, erst einmal Dein Kommentar. Weiter geht es also nach der nächsten Maus.

Danke für deine Gedanken und Mühe!

Bis auf deine "spinnerte Erweiterungsmöglichkeiten:" ähneld deine Auflistung meinem Projekt.
ABER, ich brauche keinen fertigen Code als Kopiervorlage. Viel mehr geht es mir ums Verstehen, Funktionen in universelle/autonome Module packen, um diese später in weitere Projekte mit gutem Gewissen einsetzen zu können.

JETZT geht es mir um eine Interrupt-Eingangsabfrage, die ich nach Bedarf ein/ausschalten kann.
Aber nicht generell, sondern jeder Eingang autonom.

Bsp:
Interrupt-Überwachung/Auslösung, inkl. (einfacher) Tastenentprellung
# PA4, PA5 ein
# PA4 aus
# PB2 ein
# PB2 aus
# PA4 ein
# PA4, PA5 aus