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

Итак есть контроллер LPC2138, к нему LCD экран 128*64, клавиатура на прерывании, пищик, EEPROM, использован канал АЦП и ЦАП, SPI. Система однозадачная. Файловой системы нет.

Понятно, что использование RTOS (в данном случае ucos) несколько затормозит систему. А какая будет от нее польза, кроме возможности перехода на другой кристалл? Есть ли существенное ускорение в написании программы (и за счет чего)?

С уважением, Андрей

ARM'ами не занимаюсь, но позволю себе ответить от лица человека, который применил ОС scmRTOS на МК AVR. На мой взгляд ваш вопрос не имеет смысла, ибо не указано, какими вычислительными задачами занимается ваша система. А в таком случае посмотрите ветки по AVR, операционным системам и по ARM. Преимущества применения RTOS обсуждались не один раз...

Позволю себе заметить что scmRTOS переехала -- scmRTOS on SF.net.

По прежнему адресу она пока ещё тоже наблюдается.

Но там и тут свежих версий не появится.
"
Version 3.00beta has been released. scmRTOS v3 project is resided on sourceforge.net/projects/scmrtos. The RTOS v3 sources can be obtained from SourceForge Subversion (SVN) repository or from downloads page.

If you are interesting in scmRTOS v2 you can get it from scmrtos.narod.ru or from scmrtos.igpss.com.

"
" scmRTOS v2 project is frozen.

"

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

Например printf() не самая легкая функция, часто съедает место сравнимое с остальным кодом, но.... Правильно, никаких проблем с формированием строк любого вида и возможность изменить формат представления заменой двух-трех форматных флагов. Более того, копая этот код много времени спустя, легко понять, что идет на вывод, что не всегда возможно в случае супероптимальных самописных функций.

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

Обычно любой сложный код обязательно содержит флаги, которые говорят о занятости какой-либо периферии, определяют последовательность выполнения задач и их приоритет.

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

Если контроллер крутится на одной задаче (контроллер клавиатуры-индикации, опрос датчика), то RTOS скорее всего излишня. Если надо работать с двумя УАРТами, сканить клавиатуру, выводить на дисплей текущее время, писать лог в датафлэш и при этом успевать дергать ногами, RTOS позволит легко структурировать эти задачи по отдельным процессам. С возможностью легко добавлять и изымать оные из общей программы.

2beer_warrior


Спасибо за ответ.
Рискну еще немного продолжить эту тему. Общался с несколькими знакомыми программистами (сам я в основном "железом" интересуюсь). Я им приводил точно такой же довод, но они в один голос утверждали, что "особенности программирования идущие от программиста (творческое начало) приведут к тому, что написанное одним другому будет также чуждо как и в случае отсутствия операционной системы. Более того ОС только усложнит программу". Мне кажется это дико, поскольку ОС (как правило) стоит денег и есть умственно здоровые люди которые эти деньги тратят (аналогию с игровыми автоматами приводить не надо). Но убедить их я пока не могу.

С уважением, Андрей

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

Рискую вызвать эмоциональные возражения в свой адрес, но тем не менее, скажу следующее - для ответственных встроенных систем RTOS не нужна. На это есть ряд причин:
1. Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт.
2. Повторное использование кода - задача вполне решаемая с помощью сочетания кнопок Ctrl+C и Ctrl+V, при условии, конечно, что Вы хорошо структурируете и документируете свои тексты.
3. Реализация пвсевдопараллельности вычислительных процессов (т. е. многозадачности) и обмен данными при правильном подходе - дело достаточно простое даже при значительном количестве этих самых процессов.
4. Время, потраченное на изучение RTOS, можно смело считать выкинутым на ветер. Нового, с познавательной точки зрения, там ничего нет. Лучше потратить это время на что-то более стоящее, вот к примеру ...
5. Весь Ваш проект целиком будет работать медленнее под RTOS, чем без оной. Ну это очевидно и без меня...

В защиту своего подхода сошлюсь на методики, принятые в промавтоматике.
1. Использование де-факто LD или FBD в качестве основных языков программирования для PLC (стандарт МЭК 61131-3).
2. Полное отсутствие каких либо внешних ОС.
3. Жесткие требования к структуре программы и данных, реализуемые на уровне среды проектирования.
4. Жесткие требования к платформе, на которой реализуется проект. Она должна быть абсолютно надежной и испытанной.

Иное дело системы HMI, документирование больших объемов данных и другие задачи с большими массивами информации. Но там используются достаточно дорогостоящие методы резервирования и защиты от потери данных.

Ага, полностью поддерживаю, самая главная дыра это надежность RTOS. И самый прикол в том, что в каждом новом релизе новые глюки и это от тебя не зависит.
Сам был свидетелем такой истории : спроектировали ребята устройство, сделали, работает, но плохо. Начали искать глюки, нашли, много, платы перезаказывать не стали, наделали соплей
фторопластовых. Сдали.
Теперь, вместо того, чтобы переразвести плату и просто добить устройство, это ж неинтересно, надо МОДИФИЦИРОВАТЬ, мысль то инженерная не дремлет. Модифицировали, круто. Заказали. Работает, но плохо. Стали искать глюки, появилось новых, много.
И так по кругу уже четвертый раз. В итоге есть плата, красивая,
работает, но плохо...
Так вот с операционкой та же песня. Глюки будут сажать буржуи.
Наоборот, самая песня это замороженный проект. Можно смело
браться за тестирование и быть уверенным, что никто и никогда не влезет в твою операционку...

Рискну задать вопрос:
А стандартную библиотеку С использовать тоже некошерно?
И все эти memcpy()/strcmp() использовать только домашнего приготовления?

Пункты 2..5 - мысль понятна. А вот п.1 - так можно договириться до написания своего компилятора.


А как, простите, LD или FBD связаны с ОС в контроллере? Если Вы не взаимодействуете с сервисами ОС - это не значит, что ОС в контроллере нет. Просто Вы (программист-технолог) про нее не знаете.
Пункты 3 и 4 вполне понятны (не понятно только какое отношение они имеют к ОС).

Я видел такой пример. Человек написал свою библиотеку, в общем-то похожую на libc, но отличающуюся в некоторых существенных моментах. В частности, у memcpy в этой библиотеке был другой порядок параметров (сначала указатель на источник, потом на приемник). Долго мы ошибку искали, прежде чем добрались до этого memcpy.
Так что изобретать велосипеды с квадратными колесами это всегда очень занятно. Может занять на долго.

2Прохожий: из ваших мыслей у меня сложилось представление, что нужно разрабатывать все самому с нуля, включая железо) Просто не понятно, а откуда такая уверенность, что ОС - дыра и скопление глюков? Скорее всего, Вы с ней никогда не работали. В конце концов, ОС-обычная программа. Конечно в ней есть баги и ошибки. Но они есть и в любой (ИМХО) программе. Просто не всегда их видно) Также скорей всего доступны исходники и хорошая документация к ОС, как пример выше упомянутая мной scmRTOS. Все это позволяет сделать выводы о надежности применения операционной системы.

2Прохожий


Абсолютно согласен, более того рискну вызвать всенародное освистывание - лучше вообще отказаться от программы и реализовать на "железном" уровне (например, программируемой логике).



Тоже самое можно сказать и про все вещи которые Вас окружают (и сделаны не Вами) - компьютер, телевизор, холодильник, автомобиль и т.п. - все это "злобные монстры", готовые всбрыкнуть в самый критический момент. Примеры подобного поведения этих монстров, я думаю, всем знакомы. Но что-то очень мало людей, которые готовы ради надежности бытия отказаться от всего этого благолепия.



Без сомнения. Аналогия переход от DOS к Windows - каждая новая операционка "тормознее" старой. К сожалению (искреннему) другого пути нет.

2rvk


Следуя Вашему примеру, любая плата - источник потенциальной опасности.

2all
Пока все обсуждение RTOS свелось к тому, что часть людей говорит, что RTOS - это "давленые и кислые помидоры", а другая часть говорит - "эти помидоры просто мятые, но кушать можно".
Хотелось бы услышать есть ли польза от RTOS для однозадачных приложений и сабых кристаллов. Может польза в приемственности ранее написанных программ?

>> есть ли польза от 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. Должно уже о чем-то говорить, пожалуй

Если вдобавок написано, что система сертифицирована (например ARINC 653 Avionics Application Software Standard) то это о чем-то говорит, иначе - маркетинговые фантазии.