Использование автоматного програмирования на примере Quantum Leaps. Вступление.

Года три назад устроился я програмистом микроконтроллеров на одну фирму, и там мне мой руководитель предложил разобраться с так называемым автоматным программированием. Но не просто с методом, а поставил задачу освоить framework Quantum Leaps.

С данной задачей я справился, но этот фреймворк мне настолько понравился, что я решил поделится своим опытом использования с общественностью.
Итак, что же такое Quantum Leaps. Это набор из трёх фреймворков с открытым исходным кодом, позволяющий быстро написать готовый продукт. Почему набор? Потому как есть реализация на С (QP/C), на С++ (QP/C++), и отдельная очень компактная реализация на С(QP-nano). Каждый из этих фреймворков представляет из себя платформо-компиляторо-независимый код, так называемый QP™ Baseline Code.
Для адаптации под конкретную архитектуру и компилятор используются различные QP™ Development Kits(QDK). На этой страничке доступны для скачивания как базовый код всех трёх вариантов фреймворка, так и большой набор Development Kits под различные архитектуры и компиляторы.
На этой же страничке можно скачать QP Modeler(QM), очень полезная програмка! Я ждал её с тех пор, как разобрался с QP. Позволяет графически нарисовать диаграмму состояний и по ней сгенерировать код, это если кратко.
Ну и отдельный плюс данного фреймворка — это большая книга по автоматному программированию на C/C++ на примере QP от его создателя, доступная для скачивания здесь(.pdf 4МБ).

Приятной особеностью QP является возможность работать поверх любой операционки, от Windows до какой-то экзотики для AVR. Но этот вопрос оставим на потом, когда будем с QP на «ты».

Итак, с чего же начать. А начнём пожалуй с попытки объяснить как это всё работает.

Скажу сразу, так как я в основном пишу на С++, то и все примеры я буду приводить на «плюсах».

Как и любая реализация многозадачности QP имеет в своём составе диспетчер задач, либо вытесняющий(QK) либо нет(Vanilla). По своей сути это бесконечный цикл, в котором проверяется наличие событий для определённого автомата, которые ему необходимо обработать. Если событий нет, можно уйти в спячку до возникновения оного.

Событие(QEvent) и конечный автомат — это ключевые понятия в QP.

QP поддерживат два типа конечных автоматов — простой(QFSm) и иерархический(QHSm). Любой из этих типов автоматов — это набор определённых состояний(QState), в которых автомат можен находится и набор правил, по которым автомат может изменять своё состояние. Различие между ними состоит в том, что состояние автомата типа QHSm, фактичеки может содержать в себе ещё один автомат хоть QFSm, хоть QHSm типа. Уровень вложености настраиватся и по умолчанию равен 10.

Событие.

struct QEvent{
  QSignal sig;
  uint8_t dynamic_;
}

Это основной механизм взаимодействия автоматов с внешним миром и между собой. Событие обязательно состоит из сигнала(QSignal sig) и поля служебной информации(uint8_t dynamic_), а так же может содержать не обязательные поля определяемые пользователем. Именно реакция на сигналы описана в состояниях.
Существуют динамические и статические события. Статические события — это не изменяемые события, которые существуют всегда. У статических событий поле dynamic_ всегда равно нулю.
Динамические события — это события, которые создаются в области динамической памяти, и существуют до тех пор, пока не будут обработаны всеми автоматами, которым они предназначены.

Сигналы.

enum QSignal{Q_EMPTY_SIG = 0, Q_ENTRY_SIG, Q_INIT_SIG, Q_EXIT_SIG, Q_USER_SIG};
enum QSignal{Q_EMPTY_SIG = 0, Q_ENTRY_SIG, Q_INIT_SIG, Q_EXIT_SIG, Q_TOUT_SIG, Q_USER_SIG};// для QP-nano

В QP есть 4 сигнала зарезирвированых системой Q_EMPTY_SIG, Q_ENTRY_SIG, Q_INIT_SIG и Q_EXIT_SIG а в QP-nano ещё и Q_TOUT_SIG об их назначении поговоримпозже.

Состояние(QState) — по своей сути это функция, которая должна обработать событие. Результатом работы данной функции является либо переход в другое состояние, либо какое-то действие без смены состояния.
Для наглядности рассмотрим абстрактную функцию-состояние:

QState AbstractState(QFSm * me, QEvent const * e){
  switch(e->sig){
    case Q_ENTRY_SIG:{
      return Q_HANDLED();
    }

    case Q_INIT_SIG:{
      return Q_HANDLED();
    }

    case Q_USER_SIG:{
      return Q_TRAN(&AnotheAbstractState);
    }

    case Q_EXIT_SIG:{
      return Q_HANDLED();
    }
  }
  return Q_SUPER(QFSm::top);  
}

Как видим возможны 3 варианта «ответа» обработано — Q_HANDLED(), перейти в другое состояние — Q_TRAN(), и «что делать не знаю, спросите выше» — Q_SUPER(). Для QFSm — Q_SUPER() равносильно Q_HANDLED(), хотя если поковыряться в исходниках мы увидим, что там реально Q_IGNORED(), но идейный смысл тот же.
Теперь пройдёмся по сигналам, которые обрабатывает данное состояние.
Q_ENTRY — этот сигнал framework автоматически дает на обработку состоянию каждый раз, когда в него входят.
Q_INIT — очень актуально для QHSm — тоже генерируется автоматически, когда состояние является конечной точкой назначения перехода.
Q_EXIT — автоматически генерируется при выходе из состояния.
Обработка этих трёх сигналов должна присутствовать в каждом состоянии.

На этом пока всё, если у уважаемого сообщества будет интерес к данной теме — с удовольствием продолжу.
З.Ы. Извините за орфографию и некоторую сумбурность изложения, русский язык не изучал, да и статья эта первая в моей жизни. Буду рад конструктивной критике.

UPD: Прикрепил полную версию книги