|
|
  |
Кто пользовал IAR visualSTATE? |
|
|
|
Sep 8 2005, 09:51
|
Участник

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

|
Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.
|
|
|
|
|
Sep 9 2005, 00:19
|
Местный
  
Группа: Свой
Сообщений: 437
Регистрация: 27-08-04
Пользователь №: 551

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

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

|
Цитата(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 не разобрался вобще, в документации ничего толком не написано.
|
|
|
|
|
Sep 10 2005, 01:13
|
Местный
  
Группа: Свой
Сообщений: 437
Регистрация: 27-08-04
Пользователь №: 551

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

Группа: Свой
Сообщений: 26
Регистрация: 28-07-04
Пользователь №: 406

|
Мнение о visual state неоднозначное. Если Ваша задача вписываеться в класическое понятие state machine и эта Ваша state machine довольно простая (до сотни состояний) то возможно VS можно пользоваться. Но как только проект начинает разрастаться - начинаеться серьезная путаница во всех этих стрелках и внутренних условиях. К тому-же довольно сложно интегрировать готовые куски кода на C. Про отладку я вообще молчу. Если Вы делаете embedded проект с кучей самописных драйверов и что-то где-то по каким-то причинам не работает (причем исключительно в run real time), то отладка может превратиться в кошмарный сон т.к. генерируемы код абсолютно нечитаемый. Я помучился немного и переделал все на C под RTOS. Хотя мое мнение субьективно.
|
|
|
|
|
Sep 23 2005, 13:30
|
Участник

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

|
Цитата(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, а дальше как карта ляжет.
|
|
|
|
|
Sep 29 2005, 04:19
|
Участник

Группа: Свой
Сообщений: 26
Регистрация: 28-07-04
Пользователь №: 406

|
Если вы о полноценном стеке протоколов GSM/GPRS от ETSI, то о VisualState рекомендую забыть сразу. Была практика использовать значительно более продвинутые продукты типа Telelogic Tau в подобных проектах, но даже очень дорогие коммерческие UMS/SDL системы в конечном результате добавляют проблем больше чем решают (сразу хочу добавить, что это исключительно мое мнение - наверняка найдуться те кто с этим не согласиться). Лучше чем С + хорошая RTOS + правильно выбранное железо Вам не найти.
|
|
|
|
|
Oct 14 2005, 08:52
|
Частый гость
 
Группа: Свой
Сообщений: 135
Регистрация: 21-06-04
Пользователь №: 70

|
Подскажите, пожалуйста, как отключить очередь событий в VS?
--------------------
Настоящее чревато будущим.
|
|
|
|
|
Oct 14 2005, 09:28
|
Участник

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

|
Цитата(Tran @ Oct 14 2005, 11:52) Подскажите, пожалуйста, как отключить очередь событий в VS? Я никогда её не отключал, в противном случае как вы зафиксируете событие? SEQAddEvent(event1) добавляет событие event1 в очередь событий, и если оно допустимо, то сработает action (если назначен) на это событие и переход в другое состояние. Я знаю как отключить очередь сигналов, может вы это имели ввиду?
|
|
|
|
|
Oct 14 2005, 11:45
|
Частый гость
 
Группа: Свой
Сообщений: 135
Регистрация: 21-06-04
Пользователь №: 70

|
Событие можно отработать в теле case для данного состояния, опросом входного порта, например. Очередь событий можно отключать в TSControl, в результате быстродействие повышается примерно в 2 раза. Я долго копался в настройках VS, но ничего не нашел, подумал, что не там ищу и решил здесь спросить.
--------------------
Настоящее чревато будущим.
|
|
|
|
|
Oct 14 2005, 11:55
|
Участник

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

|
Цитата(Tran @ Oct 14 2005, 14:45) Событие можно отработать в теле case для данного состояния, опросом входного порта, например. Очередь событий можно отключать в TSControl, в результате быстродействие повышается примерно в 2 раза. Я долго копался в настройках VS, но ничего не нашел, подумал, что не там ищу и решил здесь спросить. А если возникло к примеру 3 события раньше, чем система успела обработать хотябы одно? Получается полная бессмыслица в её работе без очереди... В среде я сам не нашёл, где очередь отключается.
|
|
|
|
|
Oct 14 2005, 12:07
|
Частый гость
 
Группа: Свой
Сообщений: 135
Регистрация: 21-06-04
Пользователь №: 70

|
В общем-то да, Вы правы, ерунда будет полная, просто я пробовал среду на простых проектах, там заметно, что много времени на саму систему уходит. Хотя я код сейчас погонял, основное время уходит на обработку команды SEM_GetOutput, так что, может и не стоит с очередью особо париться.
--------------------
Настоящее чревато будущим.
|
|
|
|
|
Oct 14 2005, 12:35
|
Участник

Группа: Свой
Сообщений: 64
Регистрация: 15-08-05
Пользователь №: 7 636

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