Автоматный подход (SWITCH), Поделитесь опытом использования Опции

[Lem]

Решил в последнее время освоить более строгие-формальные методы проектирования программ для МК (да и для ПК). Делаю уже третий проект с помощью КА. правда, я использую некую смесь из того, что где-то прочитал и того, что сам придумываю по ходу. При этом всё выполняется на бумаге (проектирование КА), а далее ложится на код, по моим личным предпочтениям.

Результаты положительные, но тут хотелось бы спросить совета профессионалов, каким путём дальше идти, стоит ли использовать кодогенераторы и прочее ПО и т. д.

Интересно было бы узнать, насколько часто микроконтроллерщики используют автоматный подход к проектированию программ. Какое ПО при этом используется (Visual State etc.), каковы результаты (увеличение скорости разработки, надёжности, улучшение взаимопонимания в коллективе разарботчиков).

[pitt]

RTOS большая и многогранная тема. Нет и не может быть универсальной на все случаи жизни, а отсюда и все многообразие таких систем. Я преподавал RTOS в Советском Союзе, сейчас делаю это в Америке. Мой опыт позволяет мне судить и делать выводы. Ваше дело, коллеги, соглашаться и разделять мою точку зрения или отвергать ее. Я, ни в коем случае, не претендую на истины в последней инстанции.
Итак. Длая начала надо опредилиться с приоритетами. Что мы имеем и чего стараемся достичь. Для мира AVR характерно ограничение по RAM. а это, в свою очередь серьезно ограничивает, нo не исключает использование preemtive RTOS. Еще интереснее дело обстоит со скоростью. Кооперативная переключает контекст гораздо быстрее - ей не надо сохранять все регистры, а только необходимые (определяется компилятором), кроме того, по системному таймеру нет необходимости переключать контекст активной задачи - переключения не произойдет! Заодно, кстати, и эконом ится стек для каждой задачи и, соответственно, RAM! Еще один аргумент в пользу коопреативности. При весьма ограниченных ресурсах AVR (да и подавляющего большинства других 8 -16 битных микроконтроллеров) разбиение на ос и апликации весьма условно. Проще сказать, что мы имеем scheduler (планировщик) и функции системы. Отсюда следует вывод: каждый проект есть не что иное как новая RTOS с одним и тем же планировщиком и разнообразным набором функций. Когда пишется функция ОС, прекарасно известно о том, что можно делать, а чего нет и какие ограничения необходимо соблюдать - аналогичные требования пред'являются дле задач в кооперативной RTOS. Какое совпадение!
Другой момент, требующий особого внимания - приоритеты задач в кооперативном мире. Если приоритеты постоянны, то низкоприоритетная задача может не получить управления никогда. Если же их менять, то как? Мой совет такой: используйте 2 приоритета: высший для планировщика и round robin для всего остального. В общем случае, работает надежно.
Из всего вышесказанного, в общем случае, кооперативная RTOS это то, что лучше подходит для систем с малым об'емом RAM.
Желаю успехов!

Сообщение отредактировал pitt - Jul 3 2006, 15:02