[_artem_ 0]

Visual state говорите? Бррр, вот куда автоматика нас завела. Еще немного и у меня к автоматам аллергия начнется.)

 

к чужой аллергии у меня претензий нет. ваша аллергия -- ваше личное дело.

 

но предлагаю не путать теплое с мягким.

 

И где ж я путаю и в чем?

[bialix 0]

Visual state говорите? Бррр, вот куда автоматика нас завела. Еще немного и у меня к автоматам аллергия начнется.)

 

к чужой аллергии у меня претензий нет. ваша аллергия -- ваше личное дело.

 

но предлагаю не путать теплое с мягким.

 

И где ж я путаю и в чем?

 

4 слова: visual state, автоматика, автоматы, аллергия

[_artem_ 0]

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

Кстати а чем Вам слово аллергия как определенное состояние человека в множестве его всех конечных состояний описанных русским языком не нравится?

 

Надеюсь мои слова не вызовят у Bас ассоциации о другом автомате - Калашникова?)

[CD_Eater 0]

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

Сам я никогда РТОСи (сторонних производителей) не использовал, но всегда делал именно так, как рекомендуется в этой цитате.

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

Если же вы - единственный автор этой программы, то все полезные идеи, заложенные в понравившуюся вам РТОС, можете реализовать в логике работы своей программы.

[osnwt 0]

Имхо, ОСи нужны, когда проект состоит из большого количества параллельных задач и пишется несколькими программистами, да ещё в разное время

...

Если же вы - единственный автор этой программы, то все полезные идеи, заложенные в понравившуюся вам РТОС, можете реализовать в логике работы своей программы.

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

[bialix 0]

Имхо, ОСи нужны, когда проект состоит из большого количества параллельных задач и пишется несколькими программистами, да ещё в разное время

...

Если же вы - единственный автор этой программы, то все полезные идеи, заложенные в понравившуюся вам РТОС, можете реализовать в логике работы своей программы.

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

 

Ваши слова можно понимать как кому удобнее. Попробую немного прояснить ситуацию.

 

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

 

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

 

Причем под конкретный проект эта библиотечка может быть подточена, тонко подтюнингована.

 

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

 

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

 

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

[Crystaly 0]

...Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).

Расписывание действий на выходах состояний тоже "отягощает" рисунок...

Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?

Соответственно, есть вопрос и по оформлению документанции на программу. Вроде, в нашем родном ГОСТе предусматриваются только алгоритмы ("схема программы")...

 

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

 

1. СТАРТОВАТЬ_АВТОМАТ_СРАЗУ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ

2. СТАРТОВАТЬ_АВТОМАТ_С_ЗАДЕРЖКОЙ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ

3. ОСТАНОВИТЬ_АВТОМАТ ИМЯ_АВТОМАТА

4. ВЫПОЛНИТЬ_АВТОМАТ ИМЯ_АВТОМАТА

5. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_СРАЗУ ИМЯ_СОСТОЯНИЯ

6. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ

7. ОСТАНОВИТЬСЯ

8. ПОВТОРИТЬ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

 

Макросами 1-4 пользуются в любом месте программы. Макросами 5-8 пользуются внутри состояния автомата.

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

 

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

 

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

 

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

 

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

 

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

 

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

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

[bialix 0]

...Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).

Расписывание действий на выходах состояний тоже "отягощает" рисунок...

Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?

Соответственно, есть вопрос и по оформлению документанции на программу. Вроде, в нашем родном ГОСТе предусматриваются только алгоритмы ("схема программы")...

 

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

 

1. СТАРТОВАТЬ_АВТОМАТ_СРАЗУ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ

2. СТАРТОВАТЬ_АВТОМАТ_С_ЗАДЕРЖКОЙ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ

3. ОСТАНОВИТЬ_АВТОМАТ ИМЯ_АВТОМАТА

4. ВЫПОЛНИТЬ_АВТОМАТ ИМЯ_АВТОМАТА

5. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_СРАЗУ ИМЯ_СОСТОЯНИЯ

6. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ

7. ОСТАНОВИТЬСЯ

8. ПОВТОРИТЬ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

 

Макросами 1-4 пользуются в любом месте программы. Макросами 5-8 пользуются внутри состояния автомата.

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

 

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

 

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

 

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

 

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

 

 

Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).

Расписывание действий на выходах состояний тоже "отягощает" рисунок...

Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?

Соответственно, есть вопрос и по оформлению документанции на программу. Вроде, в нашем родном ГОСТе предусматриваются только алгоритмы ("схема программы")...

 

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

 

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

[krdmitry 0]

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

 

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

 

Дак это понятно, что сервисом лучше.

Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.

Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.

SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.

Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.

[Lem 0]

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

 

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

 

Дак это понятно, что сервисом лучше.

Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.

Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.

SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.

Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.

 

 

А это вы читали?http://www.softcraft.ru/auto/switch/umlswecl/umlswecl.pdf

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

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

[Crystaly 0]

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

 

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

 

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

В общем правильно говоришь. Но эти промежуточные состояния - лишние. Пример автомата-светофора:

 

Состояния автомата:

R_STATE - горит красный 20 секунд

RY_STATE - горят красный и желтый 5 секунд

G_STATE - горит зеленый 20 секунд

GY_STATE - горит зеленый и желтый 5 секунд

 

Где-то в программе описаны временнЫе константы

RG_TIME = 20секунд

Y_TIME = 5секунд

 

Описания состояний:

R_STATE:

Включить красный, выключить желтый и зеленый.

NEXT_STATE_CDELAY RY_STATE,RG_TIME ;Перейти на состояние RY_STATE через 20сек

Возврат

 

RY_STATE:

Включить красный и желтый, выключить зеленый.

NEXT_STATE_CDELAY G_STATE,Y_TIME ;Перейти на состояние G_STATE через 5сек

Возврат

 

G_STATE:

Включить зеленый, выключить желтый и красный.

NEXT_STATE_CDELAY GY_STATE,RG_TIME ;Перейти на состояние GY_STATE через 20сек

Возврат

 

GY_STATE:

Включить зеленый и желтый, выключить красный.

NEXT_STATE_CDELAY R_STATE,Y_TIME ;Перейти на состояние R_STATE через 5сек

Возврат

 

Другой пример:

 

Автомат из одного состояния. Например, надо опрашивать датчик каждые 20мс, тогда единственное состояние выглядит так (граф из одного состояния с петлей):

 

SENSOR_STATE:

Опросить датчик

Обработать результат

REPEAT_STATE TIME20MS ;Повторить состояние через 20мс

Возврат

 

Здесь еще один макрос о котором я не упомянул - ПОВТОРИТЬ_ТО_ЖЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

 

Последний пример:

 

Пример, который совсем не увязывается с автоматными принципами, но тем не менее эффективно работает. Например, надо включить закрывание заслонки. Если через 2сек не закроется, то выполнить аварийную ситуацию. В этом случае имеем два автомата - один закрывает заслонку, второй аварийный (состоит из одного состояния):

 

 

1. Определяю автоматы (в памяти данных)

 

ZASLONKA_AUTOMATON:

...

 

ALARM_AUTOMATON:

...

 

2. Инициализирую автоматы (в самом начале программы до разрешения прерывания)

Здесь автоматы инициализируются, но не работают - отдыхают пока (выполняют холостое СТОП_СОСТОЯНИЕ, состоящее из одного возврата)

STOP_AUTOMATON ZASLONKA_AUTOMATON

STOP_AUTOMATON ALARM_AUTOMATON

 

 

4. Где-то в программе включаем заслонку

 

START_AUTOMATON ZASLONKA_AUTOMATON,ONZASLONKA_STATE

 

 

4. Описываю состояния автоматов (подпрограммы)

 

ONZASLONKA_STATE:

Включить заслонку

START_AUTOMATON_CDELAY ALARM_AUTOMATON,ALARM_STATE,TIME2S ;Запустить аварийный автомат через 2сек

NEXT_STATE WAITZASLONKA_STATE ;Перейти на ожидание закрывания заслонки

Возврат

 

WAITZASLONKA_STATE:

Заслонка закрылась?

НЕТ - возврат (ждать дальше)

STOP_AUTOMATON ALARM_AUTOMATON ;ДА - остановить аварийный автомат

NEXT_STATE STOP_STATE ;Остановиться

Возврат

 

ALARM_STATE:

STOP_AUTOMATON ZASLONKA_AUTOMATON ;Остановить автомат закрывания заслонки

Выполнить действия при аварии

NEXT_STATE STOP_STATE ;Остановиться

Возврат

 

В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.

Но это не есть плохо! Это очень логично. Пример из реальной жизни:

Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.

 

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

 

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

 

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

В общем-то так все и есть. Макрос (он же сервис) "перейти с задержкой" запускает таймер. Затем скрытое состояние считает этот таймер и при окончании счета запускается состояние, заданное тем же "перейти с задержкой".

 

Насчет ув.Шалыто - все у него хорошо, но слишком уж строго-формально.

[Evgeny_CD 0]

Может кому пригодится

********************************************************************************

***

=== Abstract State Machines: A Method for High-Level System Design and Analysis ===

********************************************************************************

***

Egon Boerger, Robert Staerk, "Abstract State Machines: A Method for High-Level System Design and Analysis"

Springer | ISBN 3540007024 | 2003 Year | PDF | 2 Mb | 438 Pages

 

Качать: (2 Мбайт)

http://rapidshare.de/files/8717800/EBorger.rar.html

Пароль:

www.AvaxHome.ru

 

The systems engineering method proposed in this book, which is based on Abstract State Machines (ASMs), guides the development of software and embedded hardware-software systems seamlessly from requirements capture to actual implementation and documentation. The method bridges the gap between the human understanding and formulation of real-world problems and the deployment of their algorithmic solutions by code-executing machines. Within a single conceptual framework it covers design, verification by reasoning techniques, and validation by simulation and testing. ASMs improve current industrial practice by using accurate high-level modeling and by linking the descriptions at the successive stages of system development in an organic and efficiently maintainable chain of rigorous and coherent system models at stepwise-refined abstraction levels. In several industrial projects the ASM method has proven its superiority compared to the popular UML methodology when designing complex parallel or dynamic systems. This book combines the features of a textbook and a handbook: the reader will find detailed explanations, proofs, and exercises as well as numerous examples and real-world case studies. Researchers will find here the most comprehensive description of ASMs available today and professionals will use it as a "modeling handbook for the working software engineer." As a textbook it supports self-study or it can form the basis of a lecture course. The book is complemented by a CD containing the whole book text, additional course material, solutions to exercises, and additional examples. Even more information can be found on the related website maintained by the authors: http://www.di.unipi.it/AsmBook/

 

Источник информации:

http://www.avaxhome.ru/ebooks/abstract_state_machines.html

///////////////////////////////////////////////////////////////////////////////

[bialix 0]

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

 

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

 

Дак это понятно, что сервисом лучше.

Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.

Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.

SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.

Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.

 

Как я уже написал IAR Visual State использует диаграммы UML, точнее его подмножество, которое отвечает за конечные автоматы. О какой собственно embedded специфике вы говорите? Где она должна присутствовать на диаграммах? Что-то вы путаете, диаграммы они и в африке диаграммы.

 

Судя по всему, вам таки надо внимательно поизучать IAR Visual State, оценочная версия позволяет проектировать систему из 20 состояний -- этого с головой хватит чтобы понять что это за зверь. Как раз Visual State исповедует принцип сквозного проектирования, который вам нужен (от ТЗ до конечного кода).

[bialix 0]

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

 

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

 

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

В общем правильно говоришь. Но эти промежуточные состояния - лишние. Пример автомата-светофора:

 

Каждый кулик хвалит свое болото -- народная мудрость. Тебе удобнее решать задачу так как ты привык и считаешь правильным. В то же время приведенное решение в некоторых вещах противоречит принципам КА.

 

Вобщем хочешь строить свою теорию -- строй. Только это уже будет не классические КА.

 

В классике: действия производятся при переходе из состояния в состояние. Все состояния выделяются явно.

 

В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.

Но это не есть плохо! Это очень логично. Пример из реальной жизни:

Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.[/i]

 

Пусть управляют, если так нравится. Больше головной боли и всего-то...

 

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

 

нет такого понятия "в неком промежуточном" состоянии. Теория, излагаемая на сайте softcraft и группой Шалыто говорит о явном выделении состояний. Как ты эти свои промежуточные состояния отобразишь на диаграмме состояний? Тут как ни изобразишь -- придешь к выводу, что они лишние и твоя схема приводится к обычной классической системе с явным выделением состояний.

 

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

 

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

В общем-то так все и есть. Макрос (он же сервис) "перейти с задержкой" запускает таймер. Затем скрытое состояние считает этот таймер и при окончании счета запускается состояние, заданное тем же "перейти с задержкой".

 

Насчет ув.Шалыто - все у него хорошо, но слишком уж строго-формально.

 

Без комментариев.

[bialix 0]

Перепишем алгоритм светофора в терминах классической теории КА.

 

Итак, явно выделим состояния:

 

1) Начальное

2) Горит красный

3) Горит красный+желтый

4) Горит зеленый

5) Горит зеленый и желтый

 

Действия производим во время перехода из состояния в состояние:

 

* при переходе в состояние 2 из любого другого: включить красный, выключить желтый, зеленый; запустить таймер на 20 секунд

* при переходе в состояние 3: включить красный, желтый, выключить зеленый; запустить таймер на 5 секунд

* при переходе в состояние 4: включить зеленый, выключить красный, желтый; запустить таймер на 20 секунд

* при переходе в состояние 5: выключить красный, включить желтый, зеленый; запустить таймер на 5 секунд

 

Начинается все с начального состояния (1) в котором все лампы выключены. По сигналу начать работу (это может быть просто запуск автомата) сразу же производим переход в состояние 2.

 

В состоянии 2 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 3.

 

В состоянии 3 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 4.

 

В состоянии 4 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 5.

 

В состоянии 5 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 2.

 

Кольцо замкнулось.