>> есть ли польза от RTOS для однозадачных приложений
>> и сабых кристаллов
есть, в первую очередь скорость разработки и гибкость кода. Даже с кооперативным планировщиком. Одно НО - нужно некоторое время поработать, потому что понимание API приходит быстро, а вот КАК сервисы применять - только после опыта.

Andr2I, если хотите получить более развёрнутую и обоснованную информацию о возможности и пользе применения RTOS во встроенных приложениях, то прочитайте документ (русскоязычный и довольно небольшой) по одной из них.
Конечно можно сформировать своё мнение и на основании мнения других участников форума, но откуда Вам знать, что эти мнения правильные либо, хотя бы, обьективные?
Многие из участников ведь даже и не применяли RTOS ни разу, хотя их высказывания выглядят достаточно убедительно. И в большинстве случаев это в основном базируется на утверждении типа: "Была DOS - было всё компактно и быстро, появилась Windows - стало медленно, огромно, глючно, ...
Стало быть - RTOS в МК имеет ту же тенденцию."
Можете думать точно так же, это Ваше дело. Я не стану приводить контрдоводов, даже из собственного опыта, этого уже было довольно много по всему форуму.
Я лишь хочу напомнить, что у Вас есть шанс сформировать собственное мнение насчёт RTOS во встроенных приложениях. Пробуйте, экспериментируйте, сравнивайте.

Тут нет и не может быть однозначного ответа. Это как выбор между С и Асм. Асм быстрее, С переносИм. Разработчик выбирает.
Если хватает фоновой задачи и пары прерываний - ОС не нужна.
Если начинаются тяжкие раздумья над приоритетами задач - ставить ОС и не мучится.
Это вопрос не священных войн, а скорости и удобства разработки.

PS Лично я в большинстве работ не использую ОС как таковую, однако в основе всегда лежит стандартный переключатель задач, софтварные таймеры и драйвера периферии, которые кочуют из проекта в проект. Поэтому код написный пару лет назад читаеться также легко, как и написаный сегодня.

Прежде всего, стоит определить, что есть "польза", а что "вред". Ибо кроме категоричных определений " RTOS - безусловный вред всегда и везде", можно определить требования к коду и разбираться, как влияет RTOS на достижение поставленных целей, таких как:
-- минимальное время разработки (time-to-market)
-- максимальное быстродействие кода
-- минимальный размер кода (footprint)
-- и т.д.

Кроме того есть и субьективный фактор:
-- квалификация разработчиков
-- степень их знакомства с CPU

Также могут повлиять требования заказчика: некоторые военные проекты в некоторых странах ПРЕДПИСЫВАЮТ использовать сертифицированную OS.

Так какие же требования ?

Кроме того, ситыация с использованием RTOS не описывается дилеммой : "использовать/не использовать". Есть и промежуточные решения:
-- использовать на начальном этапе проекта (ага, попробуй потом выкинуть OS...)
-- взять Open Source RTOS и модифицировать как душе угодно

Многие так и поступают.



Зато много людей, готовых заплатить и немало именно за надежные технические решения, даже в этих областях.



И еще забыли. С каждой новой ОС требуется все больше ресурсов.
Другой путь есть. А то, что творится в области программирования и ОС, в том числе и встроенных систем, на мой взгляд, напоминает театр абсурда. Лично я в этом стараюсь участия не принимать. В принципе - это дело вкуса.


Про "железо" немного не понял. Если речь идет о МК, то нет - разрабатывать его не надо, а вот изучать матчасть строго необходимо, тщательнейшим образом, начиная с программной модели и заканчивая временными параметрами. Ассемблер выбранного вычислителя просто обязательно. Если же подразумевается обвязка МК, то да - ИМХО, тот, кто пишет программу должен делать обвязку.


Уверенность по поводу ОС проистекает из просмотра кода от УКОС, как ее самой, так и портов к ней. Все решения достаточно тривиальные и громоздкие. Не говоря о явных проколах.
По поводу работы с RTOS. Есть такой раздел медицины - уринотерапия называется. Многим помогает. Но для того, чтобы определиться, подходит это дело твоему организму или нет, вовсе не обязательно пробовать его на вкус. Достаточно со стороны ознакомиться с самой методикой.
Насчет ошибок в программе. А Вы уверены, что они есть в любых программах?


Компиляторы с ЯВУ, по возможности, просто не использовать. Вот и все. Средства должны быть соразмерны со сложностью задачи. А если взял грех на душу, то проверять нещадно...


Я прекрасно осведомлен о наличии ОС в ПЛК. Но в отличие от всяких новомодных RTOS эта штука прошла проверку временем, хотя иногда и с ней случаются сбои. Результаты этих сбоев, к стати, выглядят не очень... Речь, однако, была не об этом.
Технологу-программисту тоже нужны все прелести, якобы предоставляемые RTOS - переносимость, скорость программирования и т. д. Однако, разработчики ПЛК имея внутри достаточно мощный вычислитель, почему-то отказались не только от внешнего ЯВУ, но и от внешней оболочки и предпочли примитивнейшие языки типа Ассемблера, совместимые исключительно внутри линейки ПЛК одного типа. Почему, как Вы думаете?


Постараюсь ответить. Можно, но только после тщательного изучения внутренностей, чтобы никакого сала и свинины. Обычно там ничего хорошего нет, сплошные задержки в виде замкнутых на себя циклов.

Кажется, уже идем по второму кругу
http://electronix.ru/forum/index.php?showtopic=23089
а может и по третьему
http://electronix.ru/forum/index.php?showtopic=13407

Наверное, здесь следует именно к ucos вернуться.

Известная позиция. Посмотреть со стороны и покидать камней, не особо разбираясь в сути.
Французы вот лягушек едят, фу какая гадость? Как же это можно? Я пробовал - на вкус та же курица.
Но зато я хоть могу сейчас аргументировать. Это аналогия.


Может просветите нас как о громоздких решениях, так и о явных проколах?
С примерами, чтоб не быть голословным?

По поводу лягушки...Ну, Вы молодец. Я в этом плане более консервативен.
А насчет камней и сути все очень просто. Я ни разу не видел ни одного сотового телефона, который бы не "глючил". Купил эту гадость ребенку, теперь жалею. Ребенок, когда вырастет будет считать, что так и положено, когда девайс вроде бы в общих чертах работает, но слегка "глючит". По моему, такие устройства просто не должны иметь места.


Первое, что бросается в глаза это обилие макросов OS_ENTER_CRITICAL() и ответной части OS_EXIT_CRITICAL(). Похоже нормальной системе прерываний капец, поскольку между этими макросами вставлены достаточно большие куски текста.
Об остальном чуть позже, если можно. Нужно собраться с мыслями, чтобы действительно не быть голословным.

Телефон является примером достаточно сложного и высокотехнологичного устройства. Объем ПО
в современных телефонах таков, что было бы глупо предполагать, что существует телефон без ошибок
в ПО и просто недоработок в интерфейсе.
Вы можете с этим мириться. можете нет, это ничего не изменит.
Тайм ту маркет, законы рынка. Надо быстро выпустить новую модель, забить место, потом к ней
выходят в течение года-полутора обновления ПО, потом модель перестает поддерживаться.
Но к спору про ОС этот пример не имеет совершенно никакого отношения.
Я бы даже утверждал, что без ОС такие сложные изделия обладали бы еще большим числом глюков.


А как вы еще обеспечите атомарные операции, которые не поддерживаются непосредстенно ядром
процессора? Потом критические секции там сделаны таким образом, чтобы закрывать минимально
необходимый набор действий. То есть надолго прерывания запрещены не бывают.
Действительно большие критические секции есть в функциях создания и удаления задач.
Но эти действия происходят при инициализации или переконфигурации системы.
В остальных случаех секция закрывает несколько ассемблерных команд.


Да уж соберитесь. И побыстрее, пока у меня настроение располагает _аргументированно_ поспорить.

Телефон это ширпотреб (ИМХО) и по нему нельзя судить о надежности встраиваемых систем. И еще телефон это не гадость, а средство общения, причем сомнительно, нужен ли этот девайс ребенку.


Если мне не нравится уринотерапия, я ее не буду использовать. Если мне не нравятся оливки, я их не буду есть. Но я не буду навязывать Вам своего мнения, потому что это личное дело каждого, и я буду заведомо не прав. Может быть и Вы не будете говорить этих глупостей про ОС? Либо приведите серьезное доказательство, чтобы мы убедились в вашей правоте? Успехов!

Возвращаясь к uCOS:
1. никто не заставляет использовать всю ОС со всеми сервисами. Это к вопросам о футпринте и постепенности освоения;
2. если функциональность предлагаемого реалтайма устраивает и большинство сервисов Вам подходят, то смело берите эту ОС - она Вам необходима;
3. поскольку ОС поставляется в тщательно документированных исходниках, то методика поиска глюков такая же как и в Вашем приложении;
4. поскольку эта ОС обкатана огромным количеством людей, то глюки в ней маловероятны;
5. для более комфортной отладки имеется плагин к IAR отладчику и вьюер;
6. в будущем можно будет легко пересесть на другую платформу.
7. ...

Не всегда. И uCOS (FreeRTOS и т.д.) - хороший тому пример. Не все RTOS делаются гениями из Microsoft и WindRiver.




МК пользоваться нельзя. Его же тоже кто нибудь на VHDLe написал. :-)




Аналогичный подход может быть применён и к RTOS. Вы, например, изучили Sources uCOS и пришли к выводу, что там немало багов. (Кстати, не опубликуете ли информацию об этих багах??)
Может есть какая нибудь другая, получше...

Оффтоп: производители кошерной пищи приложили немало усилий для эмуляции ветчины на индюшатине.

Они вставлены там, где при обычном программировании по-любому поставишь запрет и разрешение прерываний. Каждый из этих макросов как раз и состоит из одной или двух ассемблерных команд.

Народ, у кого-нибудь есть примеры, которые рассматриваются в книжке. А то pdf ку скачал, а там их нет

А вообще везде пишут, что попробовав один раз, уходить с RTOS уже не хочется.

Это точно.
Вот только непонятно, Вы к этому стремитесь или Вы этого опасаетесь (типа как пристраститься к курению)?

Замечу про µC/OS-II. Эта ОС is suitable for use in safety critical embedded systems such as aviation, medical systems and nuclear installations. Должно уже о чем-то говорить, пожалуй