Автоматный подход (SWITCH), Поделитесь опытом использования Опции

[Lem]

Решил в последнее время освоить более строгие-формальные методы проектирования программ для МК (да и для ПК). Делаю уже третий проект с помощью КА. правда, я использую некую смесь из того, что где-то прочитал и того, что сам придумываю по ходу. При этом всё выполняется на бумаге (проектирование КА), а далее ложится на код, по моим личным предпочтениям.

Результаты положительные, но тут хотелось бы спросить совета профессионалов, каким путём дальше идти, стоит ли использовать кодогенераторы и прочее ПО и т. д.

Интересно было бы узнать, насколько часто микроконтроллерщики используют автоматный подход к проектированию программ. Какое ПО при этом используется (Visual State etc.), каковы результаты (увеличение скорости разработки, надёжности, улучшение взаимопонимания в коллективе разарботчиков).

[bialix]

Хотел бы пару слов сказать в ответ исходному посту.

Вижуал Стейт пробовал-смотрел. Мне не понравилось. Хотя идея с виду красивая, но есть ряд ограничений, которые не переплюнешь никак. Поэтому в дальнейшем отказался.

Вижуал Стейт предлагает практически замкнутый процесс разработки -- от проектирования и симуляции, до отладки на прототипе или реальном железе. Их символ -- колесо, как отображение идеи замкнутого цикла разработки. Или итеративного цикла.

Сами по себе диаграммы состояний IVS (Iar Visual State) -- это часть стандарта UML, слегка модифицированные под нужды IVS (чего-то добавлено, даже кажется полезного). В итоге получаем проектирование жесткой системы. Наиболее вероятным кандидатом в качестве целевой платформы для генерируемой системы являются ПЛК. На это указывает многое. В частности, так любимый в ПЛК принцип "сначал читаем все входы - затем обновляем все выходы".

Генерируемая система хоть и представляет собой си-код, но на самом деле это табличный жесткозашитый автомат, т.е. руками сгенерированный код не отредактируешь даже при большом желании. Плохо это тем, что IVS нельзя использовать для кодогенерации отдельных разнообразных автоматов для нетипичных с точки зрения IVS задач. Так, например, IVS определяет понятие параллельных автоматов, но желание создать массив однотипных параллельных автоматов в количестве N штук не позволяет, т.е. необходимо как-то выкручиваться с copy-paste и не факт, что вам это удастся. По крайней мере для меня это стало одним из главных препятствий в использовании.

Сам редактор расчитан на большую и вдумчивую работу и несложные автоматы по своей сути. Нащелкивать мышкой сложный автомат -- дело весьма трудоемкое, особенно для тех, кто любит, чтобы было еще и красиво (это как с рисованием схем в OrCad -- как начнешь красоту наводить, так пару часов на это потратить нефиг делать).

В общем, несмотря на красивый фасад и уйму потенциальных возможностей, для областей не связанных с ПЛК использование IVS, особенно на мелких контроллерах (типа АВР) представляется мне неоправданным.

Сам по себе автоматный подход (оно же синхронное программирование -- в западных источниках) мне видится единственным способом писать логику работы. НО! не всего устройства в целом в виде одного огромного автомата, а в виде N количества паралелльных слабозависимых (в идеале независимых вообще) автоматов. А там или ОС применить для жонглирования этими автоматами или просто в один бесконечный цикл их засунуть -- это дело личных пристрастий каждого.

Поэтому с точки зрения делать всю программу на одном жестком конечном автомате или на ОС -- я не стал бы выбирать первое (только если это задача по написанию ПО для открыванию лотка CDROM или миганию лампочек). Для реальных задач лучше использовать россыпь небольших квазипараллельно работающих конечных автоматов.

Сам я ОС до сих пор не пользовался, ибо по сути тщательно спроектированная система в виде набора параллельных автоматов -- это практически тоже самое, что и кооперативная ОС, только памяти жрет еще меньше и ты всегда имеешь полный контроль над процессом. Т.е. каждый раз я делаю примитивную кооперативную карусель, и мне хватает. Из набора сервисов: таймеры, фифо, реже семафоры. Это позволяет обеспечивать максимальную независимость работы разных задач, плюс регулировать насколько часто та или иная задача будет выполнять свою работу. Т.е. deadlock в таком виде невозможен, система работает предсказуемо. Что еще нужно для счастья?

[Crystaly]

...Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).
Расписывание действий на выходах состояний тоже "отягощает" рисунок...
Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?
Соответственно, есть вопрос и по оформлению документанции на программу. Вроде, в нашем родном ГОСТе предусматриваются только алгоритмы ("схема программы")...

Я использую автоматное программирование на AVR, сразу предупреждаю что программирую на ассемблере. Для реализации автоматной структуры написал несколько макросов и простеньких подпрограммок(которые вызываются макросами). Макросы звучат типа так:

1. СТАРТОВАТЬ_АВТОМАТ_СРАЗУ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ
2. СТАРТОВАТЬ_АВТОМАТ_С_ЗАДЕРЖКОЙ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ
3. ОСТАНОВИТЬ_АВТОМАТ ИМЯ_АВТОМАТА
4. ВЫПОЛНИТЬ_АВТОМАТ ИМЯ_АВТОМАТА
5. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_СРАЗУ ИМЯ_СОСТОЯНИЯ
6. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ
7. ОСТАНОВИТЬСЯ
8. ПОВТОРИТЬ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

Макросами 1-4 пользуются в любом месте программы. Макросами 5-8 пользуются внутри состояния автомата.
С помощью этих макросов реализуется в общем любая автоматная структура (любое количество атоматов, любое количество состояний, вложенные автоматы с любой глубиной вложенности). Даже такие вещи как автомат состоящий из одного состояния Автоматы могут управлять друг другом. Все задержки отрабатываются каждым автоматом независимо с кратностью единого кванта времени. При этом нет холостых циклов.

Документированием в графике стараюсь не заниматься - уходит много времени, к тому же при изменении структуры надо документацию менять. Вместо этого стараюсь максимально комментирвать текст самой программы. Но если все-таки рисую графы (не алгоритмы) то делаю это в Visio.

...Сам по себе автоматный подход (оно же синхронное программирование -- в западных источниках) мне видится единственным способом писать логику работы. НО! не всего устройства в целом в виде одного огромного автомата, а в виде N количества паралелльных слабозависимых (в идеале независимых вообще) автоматов. А там или ОС применить для жонглирования этими автоматами или просто в один бесконечный цикл их засунуть -- это дело личных пристрастий каждого...

Сам я ОС до сих пор не пользовался, ибо по сути тщательно спроектированная система в виде набора параллельных автоматов -- это практически тоже самое, что и кооперативная ОС, только памяти жрет еще меньше и ты всегда имеешь полный контроль над процессом. Т.е. каждый раз я делаю примитивную кооперативную карусель, и мне хватает. Из набора сервисов: таймеры, фифо, реже семафоры. Это позволяет обеспечивать максимальную независимость работы разных задач, плюс регулировать насколько часто та или иная задача будет выполнять свою работу. Т.е. deadlock в таком виде невозможен, система работает предсказуемо. Что еще нужно для счастья?

Так и есть. Куча параллельных автоматов. Фактически многозадачность. Загружаем процессор равномерно - задачи "размазываются" по времени.

Последняя программа построенная описанным способом - для полуавтомата сортировки пружин - опрашивает датчики, управляет пневмоцилиндрами, электроприводом, отсчитывает различные задержки, контролирует аварийные ситуации и пр.

Реализации могут быть разные смотря что надо - быстродействие, удобство, размер кода. Приведенные макросы реализуют понятную и удобную структуру с коротким кодом, но не самую быструю. Избавившись от возможностей задержек, вложенности и исключив вызовы подпрограмм можно повысить быстродействие но увеличить размер кода.
Кому интересно - предлагаю обсудить мою реализацию на ассемблере с целью оптимизировать набор макросов для максимального удобства-быстродействия-размера, может быть на конкретных примерах.