Хтось переніс рамки стану QP для Arduino?

Переглядаючи можливі підходи до мого проекту реєстрації даних, я виявив, що книга "Практичні станси UML в C / C ++" є дуже цікавою для більш серйозної роботи з Arduino. QP - це сімейство ультралегких, відкритих джерел, державних машинних рамок для вбудованих систем, і вони поширюють код і порти для своїх фреймворків (GNU GPL2) за адресою http://www.state-machine.com/, де вони мають порт для мегаполісів AVR та AVR за допомогою набору інструментів 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.

Розширюючи на прикладі Джобі, більш чистим способом реалізації дуже великої машини є заміна оператора справи масивом функціональних покажчиків. Тоді ви можете виділити весь код для певного стану всередині функції. Я виявив, що реалізувати його таким чином потрібно набагато менше пам'яті програми.

замініть оператор справи масивом функціональних покажчиків

Ось як працює QP матеріал. Представлення стану - це лише покажчик функції (на функцію для поточного стану). У C ++ це може бути вказівник на функцію члена, але в основному те саме. Функція поточного стану викликається подіями, а також деякими псевдоподіями (запис, вихід), одна з яких завжди не оброблена і використовується для визначення стану вкладення під час здійснення вкладених переходів (QP підтримує ієрархічні машини стану).

Міро Самек каже, що незабаром буде робити порт, орієнтований на Ардуїно.