реклама на сайте
подробности

 
 
4 страниц V  < 1 2 3 4 >  
Reply to this topicStart new topic
_artem_
сообщение Jul 4 2006, 15:16
Сообщение #31


учащийся
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 29-10-05
Из: города контрастов
Пользователь №: 10 249



Цитата(bialix @ Jul 4 2006, 17:34) *
Цитата(_artem_ @ Jul 4 2006, 14:22) *

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


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

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


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


--------------------
Зачем лаять на караван , когда на него можно плюнуть?

Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 4 2006, 17:10
Сообщение #32


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



Цитата(_artem_ @ Jul 4 2006, 18:16) *
Цитата(bialix @ Jul 4 2006, 17:34) *
Цитата(_artem_ @ Jul 4 2006, 14:22) *

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


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

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


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


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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post
_artem_
сообщение Jul 4 2006, 17:26
Сообщение #33


учащийся
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 29-10-05
Из: города контрастов
Пользователь №: 10 249



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

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


--------------------
Зачем лаять на караван , когда на него можно плюнуть?

Go to the top of the page
 
+Quote Post
CD_Eater
сообщение Jul 6 2006, 21:54
Сообщение #34


Частый гость
**

Группа: Новичок
Сообщений: 173
Регистрация: 3-09-04
Из: Moscow
Пользователь №: 595



Цитата(bialix @ Jul 4 2006, 18:54) *
Сам по себе автоматный подход (оно же синхронное программирование -- в западных источниках) мне видится единственным способом писать логику работы. НО! не всего устройства в целом в виде одного огромного автомата, а в виде N количества паралелльных слабозависимых (в идеале независимых вообще) автоматов.

Сам я никогда РТОСи (сторонних производителей) не использовал, но всегда делал именно так, как рекомендуется в этой цитате.
Имхо, ОСи нужны, когда проект состоит из большого количества параллельных задач и пишется несколькими программистами, да ещё в разное время (типичный пример: один что-то делал, уволился, а потом вы с трудом пытаетесь собрать его и ваше в единый рабочий код).
Если же вы - единственный автор этой программы, то все полезные идеи, заложенные в понравившуюся вам РТОС, можете реализовать в логике работы своей программы.
Go to the top of the page
 
+Quote Post
osnwt
сообщение Jul 6 2006, 22:14
Сообщение #35


Частый гость
**

Группа: Свой
Сообщений: 175
Регистрация: 26-01-06
Из: Sevastopol
Пользователь №: 13 664



Цитата(CD_Eater @ Jul 7 2006, 00:54) *
Имхо, ОСи нужны, когда проект состоит из большого количества параллельных задач и пишется несколькими программистами, да ещё в разное время
...
Если же вы - единственный автор этой программы, то все полезные идеи, заложенные в понравившуюся вам РТОС, можете реализовать в логике работы своей программы.

Да, реализовать можно все самому. И если есть такие наработки, то смешно их потом не использовать. С другой стороны, использование готовых механизмов при отсутствии наработок существенно экономит время даже при написании системы одним программистом. А то, что эти механизмы проверены не одним человеком, развиваются и так или иначе поддержаны разработчиками, дает лишний шанс на то, что глюки если и будут, то не в части внутренних механизмов. В непонимании их работы - может быть... Но это уже не их вина.
Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 7 2006, 05:57
Сообщение #36


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



Цитата(osnwt @ Jul 7 2006, 01:14) *
Цитата(CD_Eater @ Jul 7 2006, 00:54) *

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

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


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

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

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

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

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

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

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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post
Crystaly
сообщение Jul 7 2006, 06:45
Сообщение #37


Участник
*

Группа: Новичок
Сообщений: 20
Регистрация: 1-09-05
Из: Рыбинск
Пользователь №: 8 130



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


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

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

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

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

Цитата(bialix @ Jul 4 2006, 18:54) *
...Сам по себе автоматный подход (оно же синхронное программирование -- в западных источниках) мне видится единственным способом писать логику работы. НО! не всего устройства в целом в виде одного огромного автомата, а в виде N количества паралелльных слабозависимых (в идеале независимых вообще) автоматов. А там или ОС применить для жонглирования этими автоматами или просто в один бесконечный цикл их засунуть -- это дело личных пристрастий каждого...

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


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

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

Реализации могут быть разные смотря что надо - быстродействие, удобство, размер кода. Приведенные макросы реализуют понятную и удобную структуру с коротким кодом, но не самую быструю. Избавившись от возможностей задержек, вложенности и исключив вызовы подпрограмм можно повысить быстродействие но увеличить размер кода.
Кому интересно - предлагаю обсудить мою реализацию на ассемблере с целью оптимизировать набор макросов для максимального удобства-быстродействия-размера, может быть на конкретных примерах.
Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 7 2006, 13:04
Сообщение #38


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



Цитата(Crystaly @ Jul 7 2006, 09:45) *
Цитата(krdmitry @ Jul 3 2006, 00:34) *

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


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

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

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

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


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

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

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


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


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

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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post
krdmitry
сообщение Jul 7 2006, 19:34
Сообщение #39


Частый гость
**

Группа: Участник
Сообщений: 160
Регистрация: 24-11-05
Из: СПб
Пользователь №: 11 354



Цитата(bialix @ Jul 7 2006, 17:04) *
Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

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


Дак это понятно, что сервисом лучше.
Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.
Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.
SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.
Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.
Go to the top of the page
 
+Quote Post
Lem
сообщение Jul 7 2006, 19:56
Сообщение #40


Участник
*

Группа: Участник
Сообщений: 37
Регистрация: 20-03-05
Пользователь №: 3 533



Цитата(krdmitry @ Jul 7 2006, 23:34) *
Цитата(bialix @ Jul 7 2006, 17:04) *

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

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


Дак это понятно, что сервисом лучше.
Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.
Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.
SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.
Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.



А это вы читали?http://www.softcraft.ru/auto/switch/umlswecl/umlswecl.pdf
Я скачал тот самый унимод и эклипс, но разбираться с ним, чувствую (с эклипсом) нужно не один день, а со временм совсем беда.
Если кто-нибудь имеет опыт общения с этим самым эклипсом, не поделитесь краткой инструкцией по установке этого самого юнимода, да и вообще, интересно про эклипс что-нибудь услышать от людей, реально его юзавших.
Go to the top of the page
 
+Quote Post
Crystaly
сообщение Jul 10 2006, 06:13
Сообщение #41


Участник
*

Группа: Новичок
Сообщений: 20
Регистрация: 1-09-05
Из: Рыбинск
Пользователь №: 8 130



Цитата(bialix @ Jul 7 2006, 17:04) *
У вас какая-то смесь получается сервисов ОС (запустить/остановить) и КА (перейти в состояние).

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

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

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

Состояния автомата:
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 ;Остановиться
Возврат

В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.
Но это не есть плохо! Это очень логично. Пример из реальной жизни:
Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.


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

Цитата(bialix @ Jul 7 2006, 17:04) *
Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

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

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

Насчет ув.Шалыто - все у него хорошо, но слишком уж строго-формально.
Go to the top of the page
 
+Quote Post
Evgeny_CD
сообщение Jul 10 2006, 07:25
Сообщение #42


Гуру
******

Группа: СуперМодераторы
Сообщений: 2 065
Регистрация: 11-01-05
Из: Москва
Пользователь №: 1 892



Может кому пригодится
********************************************************************************
***
=== 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
///////////////////////////////////////////////////////////////////////////////
Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 10 2006, 09:45
Сообщение #43


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



Цитата(krdmitry @ Jul 7 2006, 22:34) *
Цитата(bialix @ Jul 7 2006, 17:04) *

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

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


Дак это понятно, что сервисом лучше.
Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.
Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.
SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.
Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.


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

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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 10 2006, 09:58
Сообщение #44


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



[quote name='Crystaly' date='Jul 10 2006, 09:13' post='132519']
[quote name='bialix' post='131998' date='Jul 7 2006, 17:04']
У вас какая-то смесь получается сервисов ОС (запустить/остановить) и КА (перейти в состояние).

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

В классическом КА нужно создать промежуточное состояние, если нужно выдержать паузу. А вообще непонятно зачем это может быть нужно.[/quote]
В общем правильно говоришь. Но эти промежуточные состояния - лишние. Пример автомата-светофора:
[/quote]

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

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

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

[quote]В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.
Но это не есть плохо! Это очень логично. Пример из реальной жизни:
Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.[/i]
[/quote]

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

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

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

[quote name='bialix' post='131998' date='Jul 7 2006, 17:04']
Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

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

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

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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post
bialix
сообщение Jul 10 2006, 10:16
Сообщение #45


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 4-11-04
Из: zp.ua
Пользователь №: 1 046



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

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

1) Начальное
2) Горит красный
3) Горит красный+желтый
4) Горит зеленый
5) Горит зеленый и желтый

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

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

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

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

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

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

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

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


--------------------
Имей мужество пользоваться своим собственным разумом! (с) И.Кант
Go to the top of the page
 
+Quote Post

4 страниц V  < 1 2 3 4 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 14th July 2025 - 21:57
Рейтинг@Mail.ru


Страница сгенерированна за 0.01542 секунд с 7
ELECTRONIX ©2004-2016