mRTOS-кооперативная операционная система, порт CodeVision, порт WinAvr, mRTOS-кооперативная операционная система для AVR Опции

[LVII]

Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени для малых и средних контроллеров AVR, правда никто не запрещает использовать ее для всех типов контроллеров. Существует два порта - под CodeVision и WinAVR.
Сразу же хочу оговориться, что понятие реального времени в случае кооперативных систем достаточно условно - это описано в статье на сайте и документации к ОС.
Используя эту систему начинаю разработку с проектирования ПО - используя упрощенную нотацию UML в бесплатном редакторе DIA.
Разрабатывать проекты получается быстрее, существенно легче стало обеспечивать модификацию, сопровождение и отладку программного обеспечения. Понятнее и прозрачнее стали тексты программ.

Адрес сайта - http://movilavn.narod.ru/

Зайти в раздел "Статьи", выбрать статью - "mRTOS - кооперативная операционная система для микроконтроллеров".
Для загрузки доступны сама ОС, документация и примеры использования.

Сообщение отредактировал LVII - Oct 30 2009, 11:58

[oll]

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).
Показалось что удобно:
в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает. Использовал Кодевижн, хотя пробовал и GCC.

Да еще вопрос автору - в старых версиях Кодевижена почему-то не удалось запустить, только в версии 2.хх.

Сообщение отредактировал oll - Nov 1 2009, 17:32

[ReAl]

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).

Причём тут это? Я где-то хоть слово сказал про то, что обсуждаемая ОС фигня, потому что не вытесняющая?
ОЗУ и код даром выброшены на вещи абсолютно не нужные (сохранение SREG в невытеснялке) и в данном исполнении при анализе на худший случай бесполезные ("кагбе" приоритеты)

Показалось что удобно:
в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает.

Ну так и скажите - что будет хуже, если из обсуждаемой ОС убрать то, про что я сказал, что на него даром выброшены ресурсы. Неужели данные "приоритеты" так Вам помогли? Расскажите, какие они были и что это дало.
Возможно, всего два приоритета - "высокий" и "низкий" - два массива задач, задачи из второго вызываются по одной по очереди после полного прокрута первого массива - было бы ничем не хуже, ОЗУ было бы потрачено меньше, кода тоже, переключение быстрее.
А может и одного массива хватило бы, искать тех, кто дождался события (точно так же, как это сделано сейчас), при отсутствиии таковых продолжать топать по кругу по массиву.

Будет так - ABACADABACADABACAD....... - именно когда все молотят.
Проверьте в AVR Studio. Это просто.

Хм. Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.

Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.
Существует такая необходимость.

Например?