Quelqu'un a porté le cadre d'état QP pour Arduino?

En examinant les approches possibles pour mon projet d'enregistrement de données, j'ai trouvé le livre "Statecharts UML pratiques en C / C ++" très intéressant pour un travail plus sérieux avec l'Arduino. QP est une famille de frameworks ultralégers, open source et basés sur des machines à états pour les systèmes embarqués et ils distribuent du code et des ports pour leurs frameworks (GNU GPL2) sur http://www.state-machine.com/ où ils ont un port pour l'AVR et AVR méga à l'aide de l'ensemble d'outils WinAVR / Gnu C ++.

Bien que les en-têtes spécifiques aux puces soient appropriés, quelqu'un a-t-il créé un fichier BSP de carte ou a-t-il eu une expérience avec ces frameworks? Je ne fais que commencer par le livre, donc tous les commentaires sont grandement appréciés.

J'éviterais ce genre de chose comme la peste.

Le logiciel de bas niveau le plus "sérieux" que j'ai rencontré est une machine à états sous cette forme:

#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;
}

Il existe de nombreuses autres bonnes approches en C / C ++, mais ce ne sont pas mes préférées.

Le gros problème avec des outils comme QP est qu'il est souvent très difficile de faire des choses qu'ils ne veulent pas que vous fassiez. Si vous choisissez de jouer du code manuellement, vous devrez conserver le cas spécial pour toujours.

Je dirais que les statechart UML sont un outil fantastique pour la documentation, l'enseignement et l'analyse. Mais pas pour la programmation réelle - il existe de bien meilleurs outils pour cela :)

Personnellement, je n'ai pas utilisé le framework / bibliothèque QP, à cause de la licence GPL. À l'époque, je ne pensais pas que mon employeur était prêt à tousser pour que j'expérimente avec les HSM (machines à états hiérarchiques) en utilisant QP. J'ai dû implémenter le mien qui était similaire à QP lorsque je refactorisais une horrible machine à états qui prenait des centaines de lignes de code comme l'exemple de Joby mais jusqu'à 1000 fois. était une douleur terrible à entretenir. Je redoutais d'essayer d'y ajouter quelque chose de nouveau de peur de casser autre chose.

J'ai repensé le code dans un HSM qui avait beaucoup plus de sens pour moi personnellement sur la façon dont le système devrait se comporter. Cela a fonctionné bien mieux que je ne pouvais l'imaginer. C'était tellement plus facile à modifier et à entretenir que je ne pourrais jamais rêver. J'ai même dû refaire presque une grande partie de la machine d'état, en raison d'un comportement inattendu du système. C'était tellement plus facile à corriger avec le framework que j'avais créé, et je suis sûr que cela aurait été tout aussi facile dans QP. Le framework que j'ai construit est devenu populaire et s'est étendu à d'autres machines à états complexes à l'intérieur de notre base de code.

J'ai eu un ami implémenter le framework quantique en utilisant Java dans un robot qui fonctionnait assez bien. Cela faisait partie de l'algorithme de prise de décision du robot basé sur certaines entrées. C'était naturel, étant donné les décisions qu'il devait prendre en fonction de l'état du robot.

Ce que je comprends de la beauté de QP, c'est la possibilité d'avoir un cadre prêt à l'emploi pour une conception de machine d'état optimisée pour votre processeur et de ne pas avoir à s'appuyer sur des outils CASE crachant du code passe-partout inefficace. Mais, je n'utiliserais QP que si vous avez un ensemble complexe de machines à états à implémenter qui décrivent votre conception.

Si tout ce que vous avez est quelque chose d'aussi simple que l'exemple de Joby, faites-le comme il l'a expliqué. Mais si vous constatez que votre machine d'état grandit et grandit avec toutes sortes de déclarations "sinon" enveloppées dans des conditions différentes ... alors il pourrait être temps d'essayer quelque chose comme QP pour la décomposer en HSM.

En développant l'exemple de Joby, une façon plus propre d'implémenter une très grande machine d'état consiste à remplacer l'instruction case par un tableau de pointeurs de fonction. Ensuite, vous pouvez isoler tout le code d'un état particulier à l'intérieur d'une fonction. J'ai trouvé que sa mise en œuvre de cette façon nécessite beaucoup moins de mémoire programme.

remplacer l'instruction case par un tableau de pointeurs de fonction

C'est ainsi que fonctionnent les trucs QP. La représentation d'un état n'est qu'un pointeur de fonction (vers la fonction de l'état actuel). En C ++, il pourrait s'agir d'un pointeur vers une fonction membre, mais fondamentalement le même. La fonction d'état actuelle est appelée avec des événements, ainsi qu'avec certains pseudo-événements (entrée, sortie), dont l'un est toujours non géré et est utilisé pour déterminer l'imbrication d'état lors des transitions imbriquées (QP prend en charge les machines à états hiérarchiques).

Miro Samek dit qu'il va bientôt faire un port ciblé Arduino.