2010-03-27 10 views

Antwort

3

Sie müssten ein separates Ablaufdiagramm für die Interrupt-Verarbeitung haben. Flussdiagramme sind dazu gedacht, den Fluss der Kontrolle zu zeigen, und Interrupts sind aufgrund ihrer Natur eine Unterbrechung des Kontrollflusses.

+2

Ok, die Interrupt-Verarbeitung ist ein separater Prozess. Aber wie kann ich es zum Beispiel im Hauptprozess darstellen? –

+0

Nun, das ist die Sache - wenn der Hauptprozess frei läuft, wissen Sie nicht, wo es sein wird, wenn der Interrupt auftritt. Bei einigen eingebetteten Echtzeitanwendungen sehen Sie manchmal, dass 'Hauptverarbeitung' mit einem Interrupt synchronisiert ist. In diesem Fall könnte Ihr Flussdiagramm einen 'Warte auf Interrupt'-Block haben, aber umgekehrt könnte man argumentieren, dass das System in solchen Systemen nur ein ausgeklügeltes System ist Unterbrechungshandler. – JustJeff

0

Ich würde ein endliches Zustandsdiagramm einrichten, das die normalen Zustände der Kontrolle und der Unterbrechungszustände darstellt; Jeder Zustand wäre ein Block-Level-Element, das eine Flussdiagramm-Art von Diagramm enthält.

0

In der Regel markieren die Interrupts ohne ein Betriebssystem oder eine Bibliothek nur eine Variable, die dann den Fluss beeinflusst. Ich denke @JustJeff hat es richtig gemacht.

1

Je nach Flussdiagrammstruktur ist es wahrscheinlich am sinnvollsten, dass der Interrupt von einem Knoten/einer Box stammt, die nicht von einem anderen abgeleitet ist, da per Definition ein Interrupt nicht aus dem normalen Software-Fluss hervorgeht es ist ein softwaregesteuerter Interrupt). Es kann sinnvoll sein, sie in einem separaten Ablaufdiagramm zu speichern oder zusammen mit dem Rest des Ablaufdiagramms anzuzeigen, je nachdem, ob das Verhalten im Hauptfluss des Diagramms ausgelöst wird.

2

In der Regel kommunizieren Interrupts mit Ihrer "Haupt" -Funktion (oder anderen Interrupts) durch die Verwendung von "shared" globalen Variablen in C-basierten eingebetteten Systemen. Ich denke, eine sinnvolle Möglichkeit, dies in einem Flussdiagramm darzustellen, ist die Verwendung einer gestrichelten Linie zwischen Verarbeitungsblöcken, in denen solche "Kommunikationen" den Programmfluss beeinflussen.