Если интересует интересный инструмент, то посмотри сей инструмент: http://www.softcraft.ru/download/auto/switch/v2s.zip
Вот его описание:
Конвертор Visio2SWITCH предназначен для автоматической генерации С/С++ кода по автоматным графам, нарисованных в Visio в соответствии с требованиями SWITCH-технологии.

Теорию по которой оно работает можешь посмотреть на http://www.softcraft.ru/auto.shtml, а более точнее http://www.softcraft.ru/design/switch/sw01.shtml.

провел эксперимент:
PIC18F6620 / 11.059 МГц:
47.67 КГц с откл. прерываниями

по поводу автоматической программы: по совету bialix тоже смотрел VisualState
разложил по затратам времени на этапах:
1. Написание драйверов в/в, служ.прг, и т.п. (вручную) - 30 %
2. рисование диаграммы состояний и согласование с заказчиком - 40% (как минимум - 2 - 3 вида на каждый автомат)
3. реализация кода вручную - 5%
4. отладка и тестирование на макете - 25%

автоматическая генерация кода не оказывает существенного влияния, как мне кажется.

Применение теории конечных автоматов к программированию микроконтроллеров очень заинтересовало. Привидите пожалуйста простой (конкретный пример для двух-трех состояний (код в codevision или winavr) для микроконтроллера семейства avr?! Я пока не могу разобраться с кодом и идеей изложенной в теме форума.
С теорией немного знаком – в институте на курсах по автоматизации учили рисовать графы состояния, а потом переходить к релейно-контакторной схеме. Хотелось посмотреть как это реализовать на С "вручную" применительно к микроконтроллерам avr.
Спасибо за внимание.

Сообщение отредактировал Владимир_2010 - Mar 4 2009, 12:55

Ок.

На самом деле в предыдущих постах все описано достаточно хорошо. А язык С удобен тем, что позволяет писать переносимый код.

Сначала общие слова:


Задача:

светофор имеет выходы: три лампы (кр, жел, зел), входы: кнопка. Есть встроенный таймер (внутренний вход).

Как работает в штатном режиме лень объяснять, при нажатии на кнопку старается зажечь зеленый.

Практическая реализация:

сначала надо это промоделировать (изобразить), это можно сделать по-разному, кому как нравится.

1. можно в каждом состоянии опрашивать только требуемые события - самый простой способ.

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

3. можно каждое состояние представить в виде "состояние вообще", у которого есть действия, предпринимаемые при входе в состояние и действия, предпринимаемые при переходах в другие состояния. Это подход HSM. Удобен для реализации в ООП.

эти три подхода можно рассматривать с различных точек зрения.

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

На этапе рисования состояний следует решить, как будет осуществляться ввод-вывод. Классический подход: считать входы, прокрутить автомат, выставить выходы (как в ПЛК).

Еще надо выбрать политику моделирования: рисуем много состояний, или вводим дополнительные переменные (или иерархии для HSM).

Пример: можно сделать одно состояние "горит желтый" и в нем опрашивать флаг нажатия кнопки, а можно два: "желтый, кнопка была нажата", "желтый, кнопка не была нажата". В первом случае требуется ОЗУ, во втором ПЗУ, отлаживать легче второй.

Про реализацию напишу позже

Рекомендую ознакомиться с реализацией иерархических конечных автоматов
от Миро Самека - http://www.state-machine.com. С тех пор, как проникся этой концепцией, ничего другого и не хочется. Диспетчер использую самописный,
работает пошустрее и GPL не нарушает.


В простейшем виде, без иерархии, это выглядит как набор функций-обработчиков,
по одной на каждое состояние. В каждой функции switch/case с перечислением
всех интересующих в этом состоянии событий и связанных с ними действий,
прямо в теле функции. Отдельно хранится указатель на текущее состояние (текущую функцию-обработчик). При смене состояния этот указатель изменяется.

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

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

Книжку сравнительно недавно искал. Она Здесь лежит


Такшта, без паники 
УПС. Там человек выложил на рапиду. Время вышло, ясное дело. Короче, коллегиально: если кому надо, выложу либо сюда либо в закрома. Пишите.

еще не вышло, спасибо!

Diz спасибо за ссылку на книги. В сети также есть «Samek Miro, Practical UML Statecharts in C/C++. 2008».
Diz писал:

Нельзя ли в этом месте поподробней?! Задачи по дискретным системам автоматики я решал в основном по методе/идее изложено в книге «Юдицкий С.А. Проектирование дискретных систем автоматики. 1980». На русском искал, но больше ничего не встречал по этой теме. Встречались книги просто про конечные автоматы, без приложений к автоматике. Но там одна математика.
Вот как я решал задачки по автоматике: по методе вначале рисовал конечный автомат (графы с переходами) в пакете Stateflow от Matlab, затем проверял логику работы автомата моделируя различные состояния, далее записывал граф в виде уравнений/формул (вручную на бумажке), оптимизировал (вручную на бумажке) если требовалось конечный автомат с применением методов дискретной математики. Потом формулы рисовал в виде релейно-контакторной схемы (или функционально-логической схемы – триггеры, или, и, не), писал программу на Step7 (софт для программирования логических контроллеров Siemens) или на CX-Programmer (софт плк Omron) и прогонял логику работы с использованием симулятора для этих контроллеров.
Применяя эту методу к нескольким различным задачам, убедил себя (возможно зря) что самое главное для любой задачи по автоматике на плк это нарисовать правильно конечный автомат (графы с переходами) и проверить его работу средствами моделирования – все остальное дело техники, рутинный труд, все можно делать по одному шаблону/правилам, выключив мозг, нужно только время. Хотел даже весь этот процесс автоматизировать и написать автоматический генератор из графов всех этих формул и схем. Но потом подумал, что не надо горячиться: наверняка все это давным-давно уже сделано кем-то. Теперь вот вижу что на языке Си IAR реализует этот подход в VisualState, Telelogiс, великий ученый Шалыто А. А. и его друзья.
Вопросы:
1) Какие инструменты для моделирования/визуализации абстрактного конечного автомата есть кроме VisualState, Stateflow? Кто чем пользуется, опишите пожалуйста и поделитесь впечатлениями.
2) Какие инструменты для визуализация/моделирования/отладки уже написанного на языке С алгоритма есть?! Если применительно к мк AVR: в Proteus если загнать hex файл – не видно кода на Си и видны только входы/выходы с мк, при отладке в AVRStudio – код на Си виден, но не наглядно – нет временных диаграмм. И еще: может есть другие инструменты, без приложениям к мк?!
3) Есть ли что-нибудь из книг наподобие Miro Samek на русском для Cи?!

TMX писал

Ждем, интересны детали – уверен, что каждый по-разному генерирует код из графов.

Diz писал

Интересно все и с иерархией и без. Если это возможно – то с простыми примерами, постановка задачи, с графом на 3-4 состояния, с кодом и с комментариями, желательно на Си для микроконтроллеров. Все в форум не войдет – может быть в rar(е) куда-нибудь выложите.
Спасибо.

Сообщение отредактировал Владимир_2010 - Mar 5 2009, 07:17

Присоединяюсь.
У нас вообще рисуют , отлаживают и реализуют автоматы разные люди. В разных средах.
Примерные этапы разработки:
1. Разделение уровня драйверов и автоматов.
2. Спецификация на драйверы.
3. Разработка драйверов для микроконтроллера.
3. Разработка драйверов для LabWindows/CVI
3. Рисование автоматов.
4. Реализация автоматов на С.
5. Отладка на PC в среде CVI.
6. Перенос на мк (сборка).

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

используем ДРАКОН, рисуем в EDGE Diagrammer

А что-нибудь есть в ту же тему, но с текстовым вводом, визуализацией и экспортом в Си? Так сказать, рисовалка наоборот...
ЗЫ текстовый ввод не на LD

C для микроконтроллеров не бывает. Потому-то он так популярен, что где алгоритм не запусти, если стандарту соответствует, то работать будет.

К сожалению, на русском языке можно почитать Шалыто и Парондажанова. На английском есть пяток книг, но там самые азы - только Самек предлагает интересную реализацию.

Если нужно протокол сваять, то можно взять реализацию COCO/R для С и написать в L1 грамматике правила обработки, там генерится автомат, работает очень быстро. Правила обработки распознанных пакетов тоже удобно описывать автоматом, но на другом уровне.

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


преимущества: просто и понятно, минимальное использование стека, что для процессоров HOLTEK, например, весьма важно.
недостатки: если состояний много, то они могут перебираться долго. На самом деле здесь помог бы переход по изменяемой метке, типа GOTO STATE, но в С такого нет.

есть несколько модернизированных реализаций такого типа.

Позволю себе немного поправить Вас:

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




Что мешает  в "рваных" вариантах и вычислять адрес в таблице перехода по какому-нибудь вспомогательному алгоритму?


По поводу вычисляемого goto - в гнусях такая фича ведь есть и давно. Если она войдет в "скрижали"...

Что касается визуализации, то я имел в виду следующее. Автомат описывается на С.
Перед компляцией запускается утилита, которая парсит C-файл, находит все, относящееся к автомату - состояния, события, переходы, иерархию - после чего рисует красивый statechart. Который можно окинуть взглядом и убедиться, что все в порядке.
Вот, для примера Pelican (светофор) от Самека:
 pelican.pdf ( 94.3 килобайт ) Кол-во скачиваний: 301

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

Чтобы не полагаться на компилятор используются модернизированные методы:

выше упоминалась ссылка http://www.embedded.com/2000/0012/0012feat1.htm
там Martin Gomez вручную забивает таблицу переходов: http://i.cmpnet.com/embedded/gifs/2000/001...t1_listing1.gif
Недостатки: во-первых, надо записывать в трех местах и легко ошибиться.
Во-вторых, вообще не понятно, зачем такая громоздкая реализация: состояние храниться в виде номера, функции и указателя на функцию. по номеру выбирается ссылка на функцию состояний и вызывается сама функция. Реализация требует и память и стек.
Гораздо проще хранить состояние в виде ссылки на функцию. Память не используется, стек используется. Ошибиться при переходе сложнее.


не слышал о таком, есть программа, которая flowchart генерирует.
Писать программу без картинки - если получается, тогда зачем картинка?

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

Сообщение отредактировал Diz - Mar 5 2009, 17:32