Кто пользовал IAR visualSTATE? Опции

[ubobrov]

Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.

[ig_z]

Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.

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

[ubobrov]

Где не спрошу, никто с ней не работал, а я один проект на ней сделал, правда не доконца сам в ней разобрался, целая куча вопросов есть.

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

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

[ig_z]

По ходу проекта, созданный/изменённый в 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]

Мнение о 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]

Подскажите, пожалуйста, как отключить очередь событий в VS?

Я никогда её не отключал, в противном случае как вы зафиксируете событие?
SEQAddEvent(event1) добавляет событие event1 в очередь событий, и если оно допустимо, то сработает action (если назначен) на это событие и переход в другое состояние. Я знаю как отключить очередь сигналов, может вы это имели ввиду?

[Tran]

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

[ubobrov]

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

А если возникло к примеру 3 события раньше, чем система успела обработать хотябы одно? Получается полная бессмыслица в её работе без очереди... В среде я сам не нашёл, где очередь отключается.

[Tran]

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

[ubobrov]

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

А что касается обработки событий, то лучше их не в case обрабатывать, а прямо из тела функций, так оно быстрее получается.