Кто-нибудь портировал рамки состояния QP для Arduino?

Рассматривая возможные подходы для моего проекта регистрации данных, я обнаружил, что книга «Практические диаграммы состояний UML в C / C ++» очень интересна для более серьезной работы с Arduino. QP - это семейство сверхлегких сред с открытым исходным кодом, основанных на конечных автоматах для встраиваемых систем, которые распространяют код и порты для своих платформ (GNU GPL2) по адресу http://www.state-machine.com/, где они имеют порт для AVR и AVR mega с использованием набора инструментов WinAVR / Gnu C ++.

Хотя заголовки конкретных чипов подходят, кто-нибудь создал файл BSP платы или имел какой-либо опыт работы с этими платформами? Я только начинаю с книги, поэтому любые комментарии с благодарностью.

Я бы избегал таких вещей, как чума.

Самым «серьезным» программным обеспечением низкого уровня, с которым я столкнулся, был конечный автомат в такой форме:

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

Есть много других хороших подходов в C / C ++, но они не мои любимые.

Большая проблема с такими инструментами, как QP, заключается в том, что зачастую очень трудно делать то, чего они от вас не хотят. Если вы решите поиграть с кодом вручную, вам придется поддерживать особый случай навсегда.

Я бы сказал, диаграммы состояний UML - это фантастический инструмент для документирования, обучения и анализа. Но не для реального программирования - для этого есть гораздо лучшие инструменты :)

Лично я не использовал каркас / библиотеку QP из-за лицензии GPL. В то время я не думал, что мой работодатель был готов выкашивать тесто для меня, чтобы экспериментировать с HSM (иерархическими конечными автоматами), используя QP. Мне пришлось реализовать свой собственный, который был похож на QP, когда я рефакторинг ужасного конечного автомата, который занимал сотни строк кода, как пример Джеби, но раз 1000. Старый дизайн, который был заимствован, чтобы получить функции для работы в сжатые сроки была ужасная боль, чтобы поддерживать. Я боялся пытаться добавить что-то новое, боясь сломать что-то еще.

Я переделал код в HSM, который лично для меня имел больше смысла в том, как должна вести себя система. Это сработало намного лучше, чем я мог себе представить. Это было намного легче модифицировать и поддерживать, чем я мог мечтать. Мне даже пришлось почти переделывать большую часть конечного автомата из-за неожиданного поведения в системе. Это было намного проще исправить с помощью фреймворка, который я сделал, и я уверен, что это было бы так же легко в QP. Созданный мною фреймворк стал популярным и распространился на некоторые другие сложные конечные автоматы в нашей кодовой базе.

У меня был друг, который реализовал квантовую среду, используя Java в роботе, который работал довольно хорошо. Это было частью алгоритма принятия решений робота, основанного на определенных входных данных. Это было естественно, учитывая решения, которые он должен был принять, основываясь на состоянии робота.

То, что я понимаю о красоте QP, - это способность иметь готовую среду для проектирования конечного автомата, оптимизированного для вашего процессора, и при этом не нужно полагаться на инструменты CASE, выплевывающие неэффективный шаблонный код. Но я бы использовал QP, только если у вас есть сложный набор конечных автоматов для реализации, который описывает ваш дизайн.

Если все, что у вас есть, является чем-то таким же простым, как пример Джеби, просто сделайте это, как он объяснил Но если вы обнаружите, что ваш конечный автомат растет и растет со всевозможными «если еще» утверждениями, заключенными в разные условия ... тогда, возможно, пришло время попробовать что-то вроде QP, чтобы разбить его на HSM.

Расширение на примере Joby более чистого способа реализации очень большого конечного автомата состоит в замене оператора case массивом указателей на функции. Затем вы можете изолировать весь код для определенного состояния внутри функции. Я обнаружил, что для его реализации требуется гораздо меньше программной памяти.

заменить оператор case массивом указателей на функции

Вот как работает QP. Представление состояния - это просто указатель функции (на функцию для текущего состояния). В C ++ это может быть указатель на функцию-член, но в основном то же самое. Функция текущего состояния вызывается с событиями, а также с некоторыми псевдо-событиями (вход, выход), одно из которых всегда не обрабатывается и используется для определения вложенности состояний при выполнении вложенных переходов (QP поддерживает иерархические конечные автоматы).

Миро Самек говорит, что в ближайшее время он собирается сделать порт, ориентированный на Arduino.