Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Кто пользовал IAR visualSTATE?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
ubobrov
Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.
ig_z
Цитата(ubobrov @ Sep 8 2005, 12:51)
Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.
*


Я оказался не таким храбрым, дальше тестов не пошел. На предыдущей работе делали огромный проект на подобной тулзе - все хорошо, только тяжело управлять проектом. Единственный вариант управления - del, copy, past. Я так и не понял, как вообще возможно оформлять автономные части (аналоги модулей или классов) для последующего использования. А как вы в VS делали?
Опять таки нет аналогов препроцессора, а в любом проекте всегда есть условная компиляция/сборка. Кроме того, для меня не очень ясен вопрос с приоритетами конкурентных состояний - кто первый вышел из очереди евентов, тот и меняет состояние системы. Как вариант ИАРовцы предлагают использовать движок VS поверх РТОС. Но тогда похоже теряется возможность отладки стейт машины средствами VS. А в какой конфигурации вы сделали свой проект и как отлаживали?
ubobrov
Цитата(ig_z @ Sep 9 2005, 03:19)
Цитата(ubobrov @ Sep 8 2005, 12:51)
Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.
*


Я оказался не таким храбрым, дальше тестов не пошел. На предыдущей работе делали огромный проект на подобной тулзе - все хорошо, только тяжело управлять проектом. Единственный вариант управления - del, copy, past. Я так и не понял, как вообще возможно оформлять автономные части (аналоги модулей или классов) для последующего использования. А как вы в VS делали?
Опять таки нет аналогов препроцессора, а в любом проекте всегда есть условная компиляция/сборка. Кроме того, для меня не очень ясен вопрос с приоритетами конкурентных состояний - кто первый вышел из очереди евентов, тот и меняет состояние системы. Как вариант ИАРовцы предлагают использовать движок VS поверх РТОС. Но тогда похоже теряется возможность отладки стейт машины средствами VS. А в какой конфигурации вы сделали свой проект и как отлаживали?
*


По ходу проекта, созданный/изменённый в VS проект я отлаживал в валидаторе (этого оказалось достаточно!), затем генерил код. Что касается копирования, то я делал по другому: Я работаю в Keil с МК Cygnal. В кейле я создал проект в той директории, где создал проект VS. Все файлы, которые генерит VS, я включил в прект, и при генерации кода, файлы VS просто обновлялись.
Непосредственная отладка идёт через JTAG и сигналовский плагин к кейлу. Код, созданный в VS я не отлаживаю, он работает нормально, отлаживаю только драйвера, и кое-какую логику.
Проблем с приоритетами у меня не возникает, все события обрабатываются довольно быстро, параллеоьные задачи работают независимо: если ода из них станет в ожидании события, то другие выполняются нормально.
Я вот только с таймерами и guard expression's не разобрался вобще, в документации ничего толком не написано.
ig_z
Цитата(ubobrov @ Sep 9 2005, 08:36)
По ходу проекта, созданный/изменённый в VS проект я отлаживал в валидаторе (этого оказалось достаточно!), затем генерил код. Что касается копирования, то я делал по другому: Я работаю в Keil с МК Cygnal. В кейле я создал проект в той директории, где создал проект VS. Все файлы, которые генерит VS, я включил в прект, и при генерации кода, файлы VS просто обновлялись.
Непосредственная отладка идёт через JTAG и сигналовский плагин к кейлу. Код, созданный в VS я не отлаживаю, он работает нормально, отлаживаю только драйвера, и кое-какую логику.
Проблем с приоритетами у меня не возникает, все события обрабатываются довольно быстро, параллеоьные задачи работают независимо: если ода из них станет в ожидании события, то другие выполняются нормально.
  Я вот только с таймерами и guard expression's не разобрался вобще, в документации ничего толком не написано.
*


Именно это я и хочу сказать - валидатор и прототайпер великолепно работают на чистом проекте, но более правильно имхо запускать автоматы состояний на верхнем уровне как задачи со своими приоритетами.
О копировании. Скажем у меня есть кнопка. Совершенно автономная вещь. Она должна посылать в систему события - одинарный клик, двойной ... длинный клик и т.д. Ес-сно всеэто реализуется автоматом состояний - таймеры уровни на портах проца и логика.
Всю эту байду я написал и отладил хз сколько лет назад в виде сишного модуля. Под конкретную ос настраивается за 5 мин. А вот как это сделать в VS, кроме как вырезать кусок диаграммы состояний из старого проекта и вставить в новый - я не представляю.
Ну и с приоритетами тоже рано или поздно придется столкнуться. Какой нибудь кудрявый принтф или корень из чего нибудь легко сможет загрузить проц на десятки мСек, даже светодиоды криво моргать начинают. В этом смысле я рассматриваю преемптивные ос как попытку приблизить реалии существующих аппаратных средств к идеальным мат моделям теории конечных автоматов.
Olxx
Мнение о visual state неоднозначное. Если Ваша задача вписываеться в класическое понятие state machine и эта Ваша state machine довольно простая (до сотни состояний) то возможно VS можно пользоваться. Но как только проект начинает разрастаться - начинаеться серьезная путаница во всех этих стрелках и внутренних условиях. К тому-же довольно сложно интегрировать готовые куски кода на C. Про отладку я вообще молчу. Если Вы делаете embedded проект с кучей самописных драйверов и что-то где-то по каким-то причинам не работает (причем исключительно в run real time), то отладка может превратиться в кошмарный сон т.к. генерируемы код абсолютно нечитаемый. Я помучился немного и переделал все на C под RTOS.
Хотя мое мнение субьективно.
ubobrov
Цитата(Olxx @ Sep 22 2005, 05:37)
Мнение о visual state неоднозначное. Если Ваша задача вписываеться в класическое понятие state machine и эта Ваша state machine довольно простая (до сотни состояний) то возможно VS можно пользоваться. Но как только проект начинает разрастаться - начинаеться серьезная путаница во всех этих стрелках и внутренних условиях.  К тому-же довольно сложно интегрировать готовые куски кода на C. Про отладку я вообще молчу. Если Вы делаете embedded проект с кучей самописных драйверов и что-то где-то по каким-то причинам не работает (причем исключительно в run real time), то отладка может превратиться в кошмарный сон т.к. генерируемы код абсолютно нечитаемый. Я помучился немного и переделал все на C под RTOS.
Хотя мое мнение субьективно.
*

Согласен, с отладкой драйверов, не написанных в VS тяжко. А под понятие state machine можно подогнать любой проект, только варьируется количество состояний. Мы издовна писали все проекты (GSM.GPRS...) на реактивных конструкциях switch/case без всякой временной задержки и ОСРВ, причём количество таких автоматов доходило до 50 - 60, и у каждого по 50-60 состояний. Мозг привык и путаницы не возникает. VS попробовали из-за графического интерфейса.
Хотим попробовать uCos-II, а дальше как карта ляжет.
Olxx
Если вы о полноценном стеке протоколов GSM/GPRS от ETSI, то о VisualState рекомендую забыть сразу. Была практика использовать значительно более продвинутые продукты типа Telelogic Tau в подобных проектах, но даже очень дорогие коммерческие UMS/SDL системы в конечном результате добавляют проблем больше чем решают (сразу хочу добавить, что это исключительно мое мнение - наверняка найдуться те кто с этим не согласиться). Лучше чем С + хорошая RTOS + правильно выбранное железо Вам не найти.
Tran
Подскажите, пожалуйста, как отключить очередь событий в VS?
ubobrov
Цитата(Tran @ Oct 14 2005, 11:52)
Подскажите, пожалуйста, как отключить очередь событий в VS?
*

Я никогда её не отключал, в противном случае как вы зафиксируете событие?
SEQAddEvent(event1) добавляет событие event1 в очередь событий, и если оно допустимо, то сработает action (если назначен) на это событие и переход в другое состояние. Я знаю как отключить очередь сигналов, может вы это имели ввиду?
Tran
Событие можно отработать в теле case для данного состояния, опросом входного порта, например. Очередь событий можно отключать в TSControl, в результате быстродействие повышается примерно в 2 раза. Я долго копался в настройках VS, но ничего не нашел, подумал, что не там ищу и решил здесь спросить.
ubobrov
Цитата(Tran @ Oct 14 2005, 14:45)
Событие можно отработать в теле case для данного состояния, опросом входного порта, например.  Очередь событий можно отключать в TSControl, в результате быстродействие повышается примерно в 2 раза. Я долго копался в настройках VS, но ничего не нашел, подумал, что не там ищу и решил здесь спросить.
*

А если возникло к примеру 3 события раньше, чем система успела обработать хотябы одно? Получается полная бессмыслица в её работе без очереди... В среде я сам не нашёл, где очередь отключается.
Tran
В общем-то да, Вы правы, ерунда будет полная, просто я пробовал среду на простых проектах, там заметно, что много времени на саму систему уходит. Хотя я код сейчас погонял, основное время уходит на обработку команды SEM_GetOutput, так что, может и не стоит с очередью особо париться.
ubobrov
Цитата(Tran @ Oct 14 2005, 15:07)
В общем-то да, Вы правы, ерунда будет полная, просто я пробовал среду на простых проектах, там заметно, что много времени на саму систему уходит. Хотя я код сейчас погонял, основное время уходит на обработку команды SEM_GetOutput, так что, может и не стоит с очередью особо париться.
*

А что касается обработки событий, то лучше их не в case обрабатывать, а прямо из тела функций, так оно быстрее получается.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.