Добрый день. Хотелось бы еще раз более подробно поговорить о switch-технологии.
Ввиду наличия свободного времени начал разрабатывать библиотеку классов для этого дела, хотелось бы узнать мнение специалистов о правильности самого подхода.
В целом, идея такова. Создать набор виртуальных классов, реализующих базовую функциональность. Сами автоматы создаются в виде наследников. Требование - должна быть реализована виртуальная функция переходов. Функция может быть написана как вручную, так и сгенерирована автоматически из dot файла (формата GraphViz) (в этом случае имеем дополнительно картинку, соответствующую функции переходов).
Такая библиотека кажется довольно удобной, особенно в случае программирования логических контроллеров (управление различными задвижками, пневмоцилиндрами, контакторами и т.д.), так как допускает множественное использование единожды написанного автомата сразу для нескольких объектов (для этого используются шаблоны). Единственная проблема - недостаток опыта. Хочется создать не просто одиночный проект, а именно библиотеку, а здесь все зависит от того, по тому ли пути пошел в самом начале.
В общем, подскажите, стоит ли игра свеч, и в каком направлении двигаться. В прикрепленных файлах - самое начало. Может, у кого есть подобные вещи - прошу поделиться, в целях, так сказать, повышения образованности.

Ресурсов сожрет немеряно...
По сравнению с концепцией "точка входа в подпрограмму, реализующую автомат есть состояние автомата". Применительно к АВР - это статическая переменная размером в 2 байта.

http://ru.wikipedia.org/wiki/%D0%A3%D1%81%...%84%D1%84%D0%B0
http://en.wikipedia.org/wiki/Protothreads

Ага. Ну и конструкцию новомодную ГЦЦ-шную тоже нельзя не упомянуть

Вызов такого треда

Впрочем, в помянутых Protothreads это как вариант и так есть.
ЗЫ помогает избавиться от двухбайтового оверхеда

Фреймворк использующий иерархические машины состояний http://state-machine.com/. Реализация на С и С++ под разные архитектуры.

Finite State Machine Operating System (FSMOS) http://www.nilsenelektronikk.no/nenesos.html

Возможно Вам будет интересно почитать
http://www.rsdn.ru/article/alg/Static_Fini...ate_Machine.xml

Вы не первый и не последний.
IMHO главная проблема писателей подобных систем - чрезмерная универсальность, превышающая реальные потребности решаемых с помощью подобных инструментов задач.

+1
Где предел абстрактности? Иногда идея возводится в абсолют.
Не знаю как у кого, но я, если превышаю какой-то порог универсальности, то потом этим воспользоваться всё равно не могу. То есть, по прошествии какого-то времени, мне надо сначала изучить свой же (!!!) вариант реализации и уж потом им воспользоваться. Написание документов и описаний (делаю всегда) не очень помогает. Надо перечитать документ (описание) вспомнить, вникнуть, и уж потом воспользоваться.

Если созданной библиотекой с таким уровнем абстракции, пользоваться постоянно, то, безусловно, это себя окупит. А если от раза к разу, то это работа ради идеи. Это моё мнение.

Не знаю как у кого, но у меня, как мне кажется, организм борется с избытком информации. И борется простым методом. Я забываю. Начисто. Хорошо усваиваю и тут же забываю.
Доходит до смешного. Бывали случаи когда я наново создавал некоторые вещи. Потом находишь - "Во! Так я это уже делал! Интересно! И решение интересное!"

Применительно к данной тематике, я бы предпочёл несколько разных решений, пусть менее универсальных, но более наглядных с точки зрения универсальности. Либо применил бы промежуточное ПО (скорее всего именно так). То есть реализовал бы систему с управлением состояниями в виде внешних данных. Интерпретатор.

Сколько всего вкусного ))))
Спасибо всем за отзывчивость.
Информации не на одну неделю. Нужно все это переосмыслить.
Пока более всего заинтересовал вариант, на который дал ссылку Dima_G.
(Кто-нибудь пользовал? В IAR откомпилится?)
Ладно, буду думать.

Сделал перевод статьи о конечных автоматах. Эта статья где-то упоминалась на форуме - Martin Gomez "Embedded State Machine Implementation"