Hat jemand das QP-State-Framework für Arduino portiert?

Bei der Überprüfung möglicher Ansätze für mein Datenprotokollierungsprojekt habe ich festgestellt, dass das Buch "Praktische UML-Zustandsdiagramme in C / C ++" für eine ernsthaftere Arbeit mit dem Arduino sehr interessant ist. QP ist eine Familie von ultra-light, Open Source, Zustandsmaschine-basierten Frameworks für eingebettete Systeme und verteilen sie Code und Häfen für ihre Frameworks (GNU GPL2) bei http://www.state-machine.com/ , wo sie eine haben Port für den AVR und AVR Mega mit dem WinAVR / Gnu C ++ Tool Set.

Obwohl die chipspezifischen Header angemessen sind, hat jemand eine Board-BSP-Datei erstellt oder Erfahrung mit diesen Frameworks? Ich fange gerade mit dem Buch an, daher sind Kommentare sehr willkommen.

Ich würde so etwas wie die Pest vermeiden.

Die "ernsthafteste" Low-Level-Software, auf die ich gestoßen bin, war eine Zustandsmaschine in dieser Form:

#include <stdio.h>

typedef enum
{
    STATE_INIT,     // Description
    STATE_RUNNING,  // Description
    STATE_COMPLETE  // Description
} state_t;

int main(void)
{
    state_t state = STATE_INIT; // setup the initial state

    while(1)
    {
        os_run(); // call the OS services (poll the UART, check buttons, etc.)

        switch(state)
        {
            case STATE_INIT:
                state = STATE_RUNNING;
                puts("init");
                break;
            case STATE_RUNNING:
                state = STATE_COMPLETE;
                puts("running");
                break;
            case STATE_COMPLETE:
                puts("complete");
                break;
        }
    }
    return 0;
}

Es gibt viele andere gute Ansätze in C / C ++, aber sie sind nicht meine Favoriten.

Das große Problem mit Tools wie QP ist, dass es oft sehr schwierig ist, Dinge zu tun, die Sie nicht wollen. Wenn Sie manuell mit Code fummeln, müssen Sie den Sonderfall für immer beibehalten.

Ich würde sagen, UML-Zustandsdiagramme sind ein fantastisches Werkzeug für Dokumentation, Lehre und Analyse. Aber nicht für die eigentliche Programmierung - dafür gibt es viel bessere Tools :)

Ich persönlich habe das QP-Framework / die QP-Bibliothek aufgrund der GPL-Lizenz nicht verwendet. Zu der Zeit glaubte ich nicht, dass mein Arbeitgeber bereit war, den Teig zu husten, damit ich mit HSMs (hierarchischen Zustandsautomaten) unter Verwendung von QP experimentieren konnte. Ich musste meine eigene implementieren, die der von QP ähnelte, als ich eine schreckliche Zustandsmaschine überarbeitete, die Hunderte von Codezeilen in Anspruch nahm, wie Jobys Beispiel, aber mal 1000. Das alte Design, das ausgeliehen wurde, um Funktionen zum Laufen zu bringen Es war ein schrecklicher Schmerz, ihn aufrecht zu erhalten. Ich hatte Angst, etwas Neues hinzuzufügen, aus Angst, etwas anderes zu zerbrechen.

Ich habe den Code zu einem HSM umgestaltet, der für mich persönlich viel sinnvoller ist, wie sich das System verhalten soll. Es hat viel besser funktioniert, als ich mir vorstellen konnte. Es war so viel einfacher zu modifizieren und zu warten, als ich es mir jemals erträumen konnte. Ich musste sogar fast einen Großteil der Zustandsmaschine wiederholen, weil sich das System unerwartet verhält. Mit dem Framework, das ich erstellt hatte, war es viel einfacher zu reparieren, und ich bin sicher, dass es in QP genauso einfach gewesen wäre. Das Framework, das ich erstellt habe, wurde populär und verbreitete sich auf einige andere komplexe Zustandsmaschinen in unserer Codebasis.

Ich hatte einen Freund, der das Quantenframework mithilfe von Java in einem Roboter implementierte, der ziemlich gut funktionierte. Es war Teil des Entscheidungsalgorithmus des Roboters, der auf bestimmten Eingaben beruhte. Angesichts der Entscheidungen, die auf der Grundlage des Roboterzustands getroffen werden mussten, war dies eine natürliche Passform.

Was ich von der Schönheit von QP verstehe, ist die Fähigkeit, ein fertiges Framework für ein Zustandsmaschinendesign zu haben, das für Ihren Prozessor optimiert ist, und nicht auf CASE-Tools angewiesen zu sein, die ineffizienten Code für Boilerplates ausspucken. Ich würde QP jedoch nur verwenden, wenn Sie eine Reihe komplexer Zustandsautomaten implementiert haben, die Ihr Design beschreiben.

Wenn alles, was Sie haben, etwas so Einfaches wie Jobys Beispiel ist, dann tun Sie es einfach so, wie er es erklärt hat. Aber wenn Sie feststellen, dass Ihre Zustandsmaschine mit allen Arten von "if else" -Anweisungen wächst und wächst, die sich um verschiedene Bedingungen drehen ... dann ist es möglicherweise an der Zeit, etwas wie QP zu versuchen, um es in HSMs zu zerlegen.

Um das Beispiel von Joby zu erweitern, müssen Sie die case-Anweisung durch ein Array von Funktionszeigern ersetzen, um eine sehr große Zustandsmaschine übersichtlicher zu implementieren. Dann können Sie den gesamten Code für einen bestimmten Zustand innerhalb einer Funktion isolieren. Ich habe festgestellt, dass die Implementierung auf diese Weise viel weniger Programmspeicher benötigt.

Ersetzen Sie die case-Anweisung durch ein Array von Funktionszeigern

So funktioniert das QP-Zeug. Die Darstellung eines Zustands ist nur ein Funktionszeiger (auf die Funktion für den aktuellen Zustand). In C ++ könnte es sich um einen Zeiger auf eine Member-Funktion handeln, aber im Grunde ist es dasselbe. Die aktuelle Statusfunktion wird sowohl mit Ereignissen als auch mit einigen Pseudoereignissen (Eingang, Ausgang) aufgerufen, von denen eines immer unbehandelt ist und zur Bestimmung der Statusverschachtelung bei verschachtelten Übergängen verwendet wird (QP unterstützt hierarchische Statusmaschinen).

Miro Samek sagt, dass er bald einen auf Arduino ausgerichteten Port machen wird.