Programmablaufplan mit Interrupt

Für jeden Interrupt zeichnet man ein eigenes Flussdiagramm. In den 
Hauptfluss kann man das nicht integrieren, da Interrupts ja asynchron 
dazu auftreten werden.

Vielleicht möchtest du ja Datenflussdiagramme zeichnen...

Tja,
da so ein Interrupt "immer" stattfinden kann, kann man den Code in der 
Interrupt-Service-Routine und als eigenständigen/ nebenläufigen Ablauf 
darstellen.

Nur Taster lösen keinen Interrupt aus, denn sie Prellen und man benötigt 
ja nur ein Tastenereignis : Taster wurde gedrückt und Taster wurde 
losgelassen.

Warum ? denke darüber man nach.

Tja,
da so ein Interrupt "immer" stattfinden kann, kann man den Code in der 
Interrupt-Service-Routine und als eigenständigen/ nebenläufigen Ablauf 
darstellen.

Nur Taster lösen keinen Interrupt aus, denn sie Prellen und man benötigt 
ja nur ein Tastenereignis : Taster wurde gedrückt und Taster wurde 
losgelassen.

Warum ? denke darüber mal nach.

Die meisten gut funktionierenden Programme erfassen und
entprellen Tastenbetätigungen in einem Interrupt und melden
eindeutige Ereignisse durch ändern eines Registers, oder einer
Speicherstelle.

In den PAP des Hauptprogramms fügt man dann die Abfrage dieses
Registers, oder der Speicherstelle ein.

Per Schalter einen Interrupt auslösen? Na hoffentlich ist dann auch an 
die Entprellung gedacht.

Nop schrieb:
> Per Schalter einen Interrupt auslösen?
Vielleicht meint er ja einen Timer Interrupt?

Wird doch auch nicht besser, weil der Schalter eben prellt. Dann löst 
man einen Timer-Interrupt mehrfach aus.

Normalerweise kenne ich das so, daß man prellende Eingänge im ohnehin 
eingerichteten Timerinterrupt einliest, weil man da eine vernünftige 
Zeitbasis hat. Dann zählt man den Eingang rauf/runter (begrenzt auf 0 
und MAX_COUNTER) und wertet mit ner Hysterese den Status aus.

Das Ergebnis schiebt man dann entweder in eine Queue, wenn man auf 
Flankensteuerung aus ist und kein Ereignis verpassen will, oder in eine 
Variable, wenn nur der momentane konsolidierte Level interessiert.

Oder natürlich man entprellt in Hardware, dann kann man auch direkt 
einen IO-getrigggerten Interrupt verwenden. Habe ich aber in der Praxis 
so gut wie nie gesehen, weil es zusätzliche oder aufwendigere Bauteile 
kostet.

Nop schrieb:
> Wird doch auch nicht besser, weil der Schalter eben prellt. Dann löst
> man einen Timer-Interrupt mehrfach aus.
Du hast mich nicht verstanden.

Nop schrieb:
> Normalerweise kenne ich das so, daß man prellende Eingänge im ohnehin
> eingerichteten Timerinterrupt einliest, weil man da eine vernünftige
> Zeitbasis hat.
Ja, so wird da ein Schuh draus.

Karl M. schrieb:
> kann man den Code in der
> Interrupt-Service-Routine und als eigenständigen/ nebenläufigen Ablauf
> darstellen.

In meinem Interrupt wird nur ein Flag gesetzt, also würde das bei mir 
wahrscheinlich eher keinen Sinn machen.

Ich habe zwar nur einen Code von 1000 Zeilen, allerdings fällt es mir 
schwierig alles in ein PAP zu packen (würde wahrscheinlich viel zu groß 
werden). Ist es eine geläufige Alternative anstatt eines PAP einen 
Zustandsautomaten zu zeichnen, um den Programmablauf zu erklären?

Dann hätte ich nämlich die Zustände: Initialisieren, Menü, Programm 1 
und Programm 2. Mit den Tastern wechsel ich dann zwischen dem Menü und 
den Programmen. Durch die Taster (entprellt) werden dann Interrupts 
ausgelöst in denen ein Flag gesetzt wird und danach ausgewertet wird. 
Daher würde ich "einfach Pfeile" zwischen den einzelnen Zuständen 
zeichnen.
Und in die einzelnen Zustände schreibe ich dann die Aktivitäten die 
durchgeführt werden (z.B. LED anschalten, etwas auf Display schreiben, 
usw.).

Kann es sein, dass ämpl gar keinen alternativen Vorschlag haben möchte 
und vielmehr nur die Zustimmung zu seinem aufgezeigten Weg haben möchte?

mfg GroberKlotz