Автоматный подход (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 в таком виде невозможен, система работает предсказуемо. Что еще нужно для счастья?

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

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

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

[bialix]

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

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

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

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

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

У вас какая-то смесь получается сервисов ОС (запустить/остановить) и КА (перейти в состояние).

Насчет "перейти с задержкой" берут меня сильные сомнения в целесообразности этого. КА основывается на предположении, что все автоматы переходят в новое состояние одновременно и как бы "мгновенно". Вы разрушаете эту модель. С моей точки зрения это плохо, потому что не понятно в каком состоянии автомат находится во время ожидания.

В классическом КА нужно создать промежуточное состояние, если нужно выдержать паузу. А вообще непонятно зачем это может быть нужно.

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

Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

Запуск и останов таймера -- это должно делаться на уровне сервисов, т.е. КА не обязан заниматься такими вещами. КА должен послать сигнал сервису таймера "начни отсчет". Потом дождаться сигнала "таймаут истек". Достаточно одного состояния. Если нужно досрочно остановить, посыдаем сигнал "остановить таймер".