RTOS: распространенные заблуждения

Шесть распространенных заблуждений о применении RTOS в малоресурсных МК

(18.03.2011 изменил название статьи: "… при проектировании встраиваемых приложений" -> "… в малоресурсных МК")

Среди опасений, являющихся препятствием к освоению RTOS, встречаются и малообоснованные, которые, тем не менее, зачастую являются решающим фактором выбора не в пользу RTOS. С другой стороны существуют и противоположные заблуждения, сильно преувеличивающие возможности RTOS и выгоды ее применения. Некоторые довольно часто встречающиеся заблуждения довольно легко развеиваются.

Заблуждение 1. «Моя программа очень простая. Зачем там RTOS?»

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

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

Первые электрические чайники, начавшие вытеснять традиционные «кастрюли с носиком», представляли из себя те же кастрюли, но с нагревательным элементом внутри и проводом снаружи для включения в розетку. Такие чайники было неудобно наполнять водой и мыть из-за намертво вмонтированного провода, поэтому со временем чайники начали снабжать разъемом и отсоединяемым проводом. Часто нагревательный элемент выходил из строя, когда про включенный чайник забывали, тогда чайники стали снабжать кнопкой включения и автоматом отключения. Иногда провод чайника вынимали из розетки, чтобы воспользоваться другим прибором, а потом забывали его вставить обратно — чайники начали снабжаться световым индикатором. Далее – сделали изолированный нагревательный элемент, индикатор уровня воды, контактную подставку, защитный механизм на крышку (чтобы не открывалась, когда внутри кипяток) и т.д. и т.п.

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

Разумеется, приведенные доводы не означают, что RTOS следует применять везде и всюду. Остается класс задач, где она помешает, но это уже за рамками постановки данного вопроса.

Заблуждение 2. «RTOS – черный ящик, а я хочу контролировать все»

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

Когда кто-то задается вопросом «а как я буду все контролировать?», хорошо бы еще ответить на вопрос «действительно ли это нужно в конкретной программе?». Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой. А теперь ответьте себе на вопрос: какие из узлов программы, которую бы вы написали для управления этими устройствами, требуют абсолютного контроля генерируемого кода со стороны программиста?

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

Заблуждение 3. «RTOS отнимает слишком много ресурсов»

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

Программист, считающий, что пишет оптимальные и эффективные программы, для которых можно использовать более дешевый контроллер с меньшим объемом памяти, и думающий, что добавление такой ненужной сущности, как RTOS, приведет к нехватке нескольких байт, должен задать себе вопрос: каков его личный профессиональный уровень?

Если один программист сумел в выбранный контроллер втолкать программу без RTOS, то может найтись более квалифицированный программист, который сделает то же самое, но с RTOS. И с этой стороны миф о нехватке ресурсов оборачивается в правду о нехватке квалификации. С другой стороны, на одного очень квалифицированного программиста придется десять менее квалифицированных, которым подобная оптимизация даже без RTOS окажется не по силам, т.е. им в любом случае понадобится микроконтроллер с большими ресурсами.

Кроме того, есть какая-то опрометчивость в том, чтобы еще на этапе проектирования предположить, что программа будет использовать все ресурсы под завязку. В самом деле, нельзя же быть уверенным в том, что любая программа потребует «почти 1кб» программной памяти, или «почти 2кб», или «почти 4кб», или «почти 8кб» и т.д.

В результате получается, что проблема нехватки ресурсов при использовании RTOS касается немногих программистов, да и то – далеко не на всех проектах. Поэтому проблема надуманна, и ее вряд ли можно всерьез рассматривать как аргумент в пользу отказа от RTOS.

Заблуждение 4. «Код написан дядей. Он ошибется, а я – расхлебывай!»

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

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

Во-вторых, в отладке RTOS, помимо ее авторов, принимают участие еще и пользователи. Сама RTOS эксплуатируется в самых различных условиях разными людьми с разным подходом к программированию. Это создает благоприятные условия для эффективного тестирования. Часть пользователей сообщают авторам об обнаруженных ошибках, зачастую сопровождая сообщения подробным описанием условий проявления, а иногда даже исходными текстами, где ошибка проявляется. Это значительно ускоряет и упрощает процесс отладки и исправления ошибок. Не каждый программист может рассчитывать на такое массивное тестирование своей программы: результаты месячного тестирования программы одним человеком не идут ни в какое сравнение с результатами многолетнего тестирования сотнями программистов.

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

Заблуждение 5. «Если используешь RTOS, то контроллер и язык программирования можно изучить только поверхностно»

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

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

Заблуждение 6. RTOS делает контроллер мощнее

Как ни странно, распространенное заблуждение о том, что если мощности контроллера не хватает для полноценного функционирования программы, то добавление в программу RTOS может решить проблему, — присуще даже опытным программистам. Нередко можно услышать от них довод: «Зачем тут RTOS? Я вот писал такое, да растакое на ассемблере – и справился без всяких RTOS!» Довод довольно нелепый и скорее говорит за невладение вопросом, чем за умение обходиться ассемблером (или Си).

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

На самом же деле надо понимать, что ни памяти, ни скорости микроконтроллеру RTOS не добавит, а даже наоборот – часть этих ресурсов заберет под свои нужды. Поэтому, если микроконтроллер не справляется с возложенными на него задачами, в большинстве случаев это означает, что нужно применить другой, более мощный, контроллер.

Заключение

В заключении можно сказать, что подавляющее большинство программ могут быть одинаково эффективно написаны с использованием любой парадигмы (+/- килобайт, +/- мегагерц). А задачи, требующие конкретного подхода (будь то RTOS, или прерывания, или автомат состояний, или чистый ассемблер), появляются намного реже. Ниша, где RTOS может оказаться эффективней остальных парадигм — сложные программы с большим количеством параллельных процессов, состояний и режимов работы. Но это не означает, что такие программы могут быть написаны только с использованием RTOS. Так же, как не означает и того, что все остальные программы должны быть написаны без нее.

Зачастую проблема не в критериях выбора инструмента (или парадигмы программирования), а в умении конкретного программиста построить эффективную абстрактную модель и реализовать ее с помощью предпочитаемого им инструмента.
  • +13
  • 16 марта 2011, 01:09
  • tester

Комментарии (23)

RSS свернуть / развернуть
на конкурс и в блог :) хорошо, годно.
0
ой, а может это в виде FAQ(http://we.easyelectronics.ru/blog/faq/) сделать?
0
Познавательно
Неплохо бы еще пару примерчиков.
0
Каких именно? В смысле, какие моменты статьи они должны пояснять?
0
Народ, а может придумаем какой-нибудь другой термин для обозначения этих ОС? Например МикроОС (мкОС), или что-нибудь типа того… А то термин RTOS в многих местах этого сообщения смотрится нелепо, особенно в третьем пункте — RTOS, соответствующая хоть какому-нибудь стандарту будет требовать весьма значительные ресурсы, даже если речь идёт не о OS целиком, а об одном только шедуллере задач.
0
Нет, новых терминов не надо. Само понятие RTOS (ОСРВ) настолько широко, что охватывает все его области применения. Иногда применяется термин Embedded RTOS, но это там, где без этой приставки может быть непонятно, о чем речь. А тут в заголовке указано, что разговор о встраиваемых системах.

Насчет значительных ресурсов: в 3м пункте речь не о количественной характеристике занимаемых ресурсов, а о преувеличении программитами опасений о том, что из-за RTOS не хватит ресурсов под приложение.
0
Ну может быть, наверно у меня просто слишком строгое понятие о том, что должна уметь операционная система реального времени…
0
+1
RTOC как то больше ассоциируется с RealTime, которым тут не особо…

Но все уже к этому привыкли, точнее мало кто знает что такое RTOS и ещё меньше человек с ней работали…

рыть в сторону QNX — доходчиво и есть на описания на русском
0
Почему «не особо»? Обязанность RealTime OS снабдить задачу небходимыми ей ресурсами в заданный интервал времени. Это вне зависимости от того, Embedded она или нет.
А вот обеспечить требуемую реакцию устройства в целом — это уже лежит на плечах программиста.

Читать QNX — обязательно. Правда, моя статья — выдранный фрагмент из другого материала (еще не публиковал), посвященного малоресурсным МК. Я не указал этого в заголовке, моя ошибка. Поправлю.
0
Хорошая статья, все грамотно разложено по полкам. Спасибо
0
Спасибо. Хотелось бы, чтобы это была лишь первая статья из цикла)
0
Да, все довольно толково, большое спасибо за статью. Мне только думается, что все то же самое можно сказать не только про ОСРВ, но и про любые ОС для встраиваемых систем вообще.
0
Заблуждение 2 и 4 — очень и очень существенны! и никакие дяди и тёти 100% гарантию на работу своего кода не дают. В писанных профессионалами текстах ошибки могут выскочить в самый не подходящий момент (например при запуске ракеты), а если сам писал то ещё на этапе тестирования :)

Кажется мне, что во большинстве лицензий написано что вся ответственность возлагается на пользователя… а им тока деньги за использование давай, ну и может быть если будет время они поправят те ошибки которые мы пользователи нашли…

есть такая поговорка: Хочешь сделать хорошо, СДЕЛАЙ САМ!
0
А Вы много ракет запустили со своим софтом? :)

Если бы все собственные баги вылавливались на этапе тестирования, то не нужно было бы этапа опытной эксплуатации. (А он есть и длится иногда по несколько лет). Так что при запуске ракеты может вылезти и своя и чужая ошибка (всем известный «Ariane 5» — вылезла собственная ошибка).

Про лицензии — так и есть. А еще то же самое написано в лицензиях на компиляторы.

Поговорка немного не к месту. Она гласит «Не поручай другому, делай сам», а не «Не бери карандаш, рисуй пальцем».
0
Вперёд, у вас ещё вся жизнь впереди, много чего написать успеете.
0
tester, Вы, насколько я понимаю, разработчик RTOS OSA. Сейчас читаю документацию по Вашей RTOS, Вы можете ткнуть меня носом или дать простейший пример использования Вашей RTOS для AVR… Буду признателен.
0
С вопросами по OSA лучше на почту (osa на pic24.ru).
Пример есть в папке osa\example\winavr и osa\example\iaravr. Он проверен в железе. Или он не устраивает по каким-то причинам?
0
ок, я почемуто для avr не нашел, а может и avr studio 5 протупила, не помню уже… если что, я вам напишу. Спасибо.
0
Если есть у кого, поделитесь книжкой плиз:

MicroC OS II: The Real Time Kernel (With CD-ROM) 2ed Jean J. Labrosse

~11..15 метров архив с PDF. К сож в сети только куски куски нашел.
0
Мейл давайте, скину. Только откуда 11..15 метров? У меня 1Мб сам пдф (305 страниц) и 2.5 Мб сдром.
0
Извиняюсь, наврал. У меня не 2ed
0
А может и секонд…
0
Вообще PDF должен так выглядеть:


На 11-15 метров я видел битые ссылки
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.