Anbieter zum Thema
Damit wird es sehr einfach, die verschiedenen Stromsparmodi der MSP430-MCU innerhalb der Uhr zu steuern, denn die einzige Aufgabe der Hauptprogrammschleife ist eine Verarbeitung mit niedriger Priorität und die Rückkehr in den entsprechenden Low-Power-Modus.
Der einzige Nachteil kann sein, dass die Applikationslogik über verschiedene Module verteilt ist. Während einer Debug-Sitzung oder beim Hinzufügen neuer Funktionen kann sich somit eine Verfolgung der verschiedenen Funktionen und deren Interaktion erschweren.
Design mit Zustandsmaschine
Eine andere Möglichkeit, diese Art von Applikation aufzugliedern, ist die Organisation im Rahmen einer Hauptprogrammschleife, die den Großteil der High-Level-Logik mit einbindet. Hinzu kommt eine Vereinfachung der Interrupt-Routinen, um nur Events für die Anwendung zu erkennen und zu berichten. In einer zustands-/event-orientierten Anwendungen dient ein Design-Ansatz mit Zustandsmaschine dann zur Entwicklung und Implementierung der Logik.
Damit ist es möglich, eine klare Trennung zwischen Eingangsgerätetreibern, Applikationslogik und Ausgangsgerätetreibern zu erzielen. Der Code für die Eingangserkennung und das Ausgangshandling kann dann in verschiedenen Projekten auf der gleichen Hardware wiederverwendet werden, ohne dabei den Code um das applikationsspezifische Know-how bereinigen zu müssen.
Der Nachteil ist, dass sich die für eine zentralisierte Zustandsmaschine erforderliche Verwaltung erschwert, sobald die Anwendung komplexer wird – zumindest wenn sie mittels handgeschriebenem Code und ohne High-Level-Tool-Support implementiert wird. Ein tool-unterstützter Zustandsmaschinen-Ansatz hilft dabei. So unterstützen z.B. Tools wie visualSTATE von IAR Systems, eine ereignisgesteuerte, zustandsbasierte Applikation zu entwickeln und den Entwicklungsprozess zu vereinfachen.
Tool-Support für Zustandsmaschinen-Ansatz
- Höhere Produktivität. Es gibt natürlich eine Lernkurve mit neuen Erkenntnissen; die Endproduktivität erhöht sich aber, da weniger Zeit mit der Code-Verwaltung verbracht wird und sich mehr auf die Funktionalität konzentriert werden kann. visualSTATE generiert z.B. auch den Code für die Zustandsmaschine und sorgt so für einen schnellen Entwicklungserfolg.
- Höhere Qualität. Der Einsatz von Zustandsmaschinen gilt als semi-formelle Methode. Wird ein zustands-/event-orientiertes Problem während der Entwicklung als Zustandsmaschinenproblem behandelt, ist es vorteilhaft, in der formelleren Umgebung mit ihrer gut definierten Zustandsmaschinen-Semantik zu arbeiten. Eine Simulation der Applikation ist sofort möglich, um deren Verhalten zu überprüfen. Auch eine formale Verifikation ist möglich, um Dead-Locks oder Zustände auszuschließen, die nicht erreicht werden können etc.
- Eine klare Trennung zwischen dem Eingangs- und Ausgangsteil der Applikation (v.a. der Board-Support-Code) und der Applikationslogik vereinfacht die Applikationsarchitektur und hilft der Wiederverwendung über verschiedene Hardwareplattformen hinweg.
Tastenprellen verhindern

Als Beispiel dient ein kleines Modell für das ez430-Chronos-Kit, das Tastenprellung verhindert und entscheidet, ob eine Tasterbetätigung kurz oder lang interpretiert wird. Die dargestellte Zustandsmaschine sendet Signale an den Applikationsteil der Zustandsmaschine, um anzuzeigen, welche Art von Tasterbetätigung gerade dekodiert wurde (Bild 1).
Der Zustand „NoButton“ ist der Startzustand dieser Zustandsmaschine, dargestellt durch den kleinen Kreis (Anfangszustand) und den zugehörigen Zustandsübergang. In einer echten Applikation wäre die Realisation der Entprell-Logik innerhalb der Zustandsmaschine wahrscheinlich nicht die beste. Hier dient sie allerdings als Anschauungsobjekt für die Leistungsfähigkeit hierarchischer Zustandsmaschinen.
(ID:356663)