Шесть распространенных заблуждений о применении RTOS в малоресурсных МК
Среди опасений, являющихся препятствием к освоению RTOS, встречаются и малообоснованные, которые, тем не менее, зачастую являются решающим фактором выбора не в пользу RTOS. С другой стороны существуют и противоположные заблуждения, сильно преувеличивающие возможности RTOS и выгоды ее применения. Некоторые довольно часто встречающиеся заблуждения довольно легко развеиваются.
«Моя программа очень простая. Зачем там RTOS?»
Здесь есть два аспекта. Почти любое устройство решает не одну задачу, а несколько (пускай даже опрос кнопки и мигание светодиодом). Поэтому подобие планировщика и средств разделения ресурсов между ними будет присутствовать. Так что то, что программа работает без управления какой-то конкретной ОС, вовсе не означает, что она не содержит подпрограмм или просто фрагментов кода, по сути выполняющих ее функции. Просто они получаются разбросанными по всему коду так, что их трудно однозначно выделить из программы в целом.
Кроме того, программа, созданная для коммерческого устройства, не всегда может оставаться простой из-за конкуренции на рынке аналогичных устройств. В качестве примера можно рассмотреть эволюцию любого бытового прибора, например, электрического чайника.
Первые электрические чайники, начавшие вытеснять традиционные «кастрюли с носиком», представляли из себя те же кастрюли, но с нагревательным элементом внутри и проводом снаружи для включения в розетку. Такие чайники было неудобно наполнять водой и мыть из-за намертво вмонтированного провода, поэтому со временем чайники начали снабжать разъемом и отсоединяемым проводом. Часто нагревательный элемент выходил из строя, когда про включенный чайник забывали, тогда чайники стали снабжать кнопкой включения и автоматом отключения. Иногда провод чайника вынимали из розетки, чтобы воспользоваться другим прибором, а потом забывали его вставить обратно - чайники начали снабжаться световым индикатором. Далее – сделали изолированный нагревательный элемент, индикатор уровня воды, контактную подставку, защитный механизм на крышку (чтобы не открывалась, когда внутри кипяток) и т.д. и т.п.
И сейчас простой обыватель не купит чайник, не имеющий большей части перечисленных удобств. То же самое с любым другим устройством. Сегодня это обычный датчик влажности, а завтра к нему придется прикрутить цветной дисплей и снабдить его голосовыми сообщениями. Таким образом, вместо одной задачи устройству придется выполнять пять или десять. И здесь RTOS будет хорошим помощником.
Разумеется, приведенные доводы не означают, что RTOS следует применять везде и всюду. Остается класс задач, где она помешает, но это уже за рамками постановки данного вопроса.
«RTOS – черный ящик, а я хочу контролировать все»
Часто программисты испытывают страх перед тем, что будет потерян абсолютный контроль над генерируемым кодом. Подобные страхи возникают на первых этапах применения языка высокого уровня после длительного использования ассемблера. Однако со временем приходит понимание цены полного абсолютного контроля, и эффективности приношения в жертву малого во имя выигрыша в большем. В отношении RTOS все то же самое.
Когда кто-то задается вопросом «а как я буду все контролировать?», хорошо бы еще ответить на вопрос «действительно ли это нужно в конкретной программе?». Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой. А теперь ответьте себе на вопрос: какие из узлов программы, которую бы вы написали для управления этими устройствами, требуют абсолютного контроля генерируемого кода со стороны программиста?
Вариантов будет не так много, как кажется на первый взгляд. Тем не менее, существует круг задач, при решении которых применять RTOS неразумно. Поэтому примерять RTOS на любой проект не стоит, но в большинстве приложений имеет смысл сперва выделить ту часть будущей программы, которая требует постоянного контроля, а затем оценить, есть ли возможность ее решить аппаратными средствами выбранной линейки микроконтроллеров. И только потом делать вывод о нерентабельности применения RTOS в конкретном проекте.
«RTOS отнимает слишком много ресурсов»
Несомненно, RTOS под свои нужды использует часть ресурсов микроконтроллера. Однако не следует преувеличивать предполагаемые потери. Для многих важным аргументом не в пользу использования RTOS в своих проектах является опасение, что из-за лишнего кода в виде ОС, программа не уместится в выбранный контроллер. Помимо очевидных аргументов необоснованности этих опасений (широкий выбор микроконтроллеров, незначительная разница цен), есть менее заметные.
Программист, считающий, что пишет оптимальные и эффективные программы, для которых можно использовать более дешевый контроллер с меньшим объемом памяти, и думающий, что добавление такой ненужной сущности, как RTOS, приведет к нехватке нескольких байт, должен задать себе вопрос: каков его личный профессиональный уровень?
Если один программист сумел в выбранный контроллер втолкать программу без RTOS, то может найтись более квалифицированный программист, который сделает то же самое, но с RTOS. И с этой стороны миф о нехватке ресурсов оборачивается в правду о нехватке квалификации. С другой стороны, на одного очень квалифицированного программиста придется десять менее квалифицированных, которым подобная оптимизация даже без RTOS окажется не по силам, т.е. им в любом случае понадобится микроконтроллер с большими ресурсами.
Кроме того, есть какая-то опрометчивость в том, чтобы еще на этапе проектирования предположить, что программа будет использовать все ресурсы под завязку. В самом деле, нельзя же быть уверенным в том, что любая программа потребует «почти 1кб» программной памяти, или «почти 2кб», или «почти 4кб», или «почти 8кб» и т.д.
В результате получается, что проблема нехватки ресурсов при использовании RTOS касается немногих программистов, да и то – далеко не на всех проектах. Поэтому проблема надуманна, и ее вряд ли можно всерьез рассматривать как аргумент в пользу отказа от RTOS.
«Код написан дядей. Он ошибется, а я – расхлебывай!»
Некоторые мотивируют нежелание использования RTOS опасениями, что ее код написан другими людьми, и если вдруг в нем обнаружится ошибка, то исправить ее самостоятельно окажется очень затруднительно. Опасение, в принципе, обоснованное. RTOS может содержать ошибки, как и компилятор (достаточно посмотреть список обновлений) или даже сам микроконтроллер (можно заглянуть в документы errata). Но все же основания для таких опасений сильно преувеличены.
Во-первых, создание таких комплексов программ, как RTOS, требуют от программиста не только знания принципов работы операционных систем и особенностей платформы, на которую ориентирована RTOS, но также высокой профессиональной подготовки и глубокого знания целевых компиляторов. Другими словами написанием RTOS занимаются программисты высокой квалификации, и вероятность столкнуться с проявлением допущенной ими ошибки намного ниже, чем с проявлением собственной.
Во-вторых, в отладке RTOS, помимо ее авторов, принимают участие еще и пользователи. Сама RTOS эксплуатируется в самых различных условиях разными людьми с разным подходом к программированию. Это создает благоприятные условия для эффективного тестирования. Часть пользователей сообщают авторам об обнаруженных ошибках, зачастую сопровождая сообщения подробным описанием условий проявления, а иногда даже исходными текстами, где ошибка проявляется. Это значительно ускоряет и упрощает процесс отладки и исправления ошибок. Не каждый программист может рассчитывать на такое массивное тестирование своей программы: результаты месячного тестирования программы одним человеком не идут ни в какое сравнение с результатами многолетнего тестирования сотнями программистов.
Наконец, в-третьих, нужно учитывать возраст самой RTOS. Поведение программы, которая применяется многими людьми в течение нескольких лет намного более предсказуемо, чем поведение только что написанной программы.
«Если используешь RTOS, то контроллер и язык программирования можно изучить только поверхностно»
Это часто совершаемая начинающими ошибка. Некоторыми начинающими программистами RTOS воспринимается как инструмент, избавляющий от необходимости хорошо знать язык программирования и вникать в тонкости архитектуры применяемого микроконтроллера. Это заблуждение приводит к созданию ненадежных и трудно сопровождаемых программ, а такие результаты отбивают охоту не только использовать RTOS, но и вообще заниматься программированием микроконтроллеров.
А на самом деле программа-то все равно пишется на конкретном языке программирования, по его правилам и с его ограничениями; она все равно пишется под конкретный целевой микроконтроллер, имеющий свою архитектуру и свои особенности. Более того, при использовании RTOS следует как раз более тщательно изучать как архитектуру микроконтроллера, так и тонкости языка программирования. Особое внимание придется уделять таким приемам, как обеспечение атомарного доступа к глобальным переменным и регистрам, знать, как конкретный компилятор организует хранение локальных переменных и пр. Другими словами следует уделять внимание таким аспектам, появление которых при программировании без использования RTOS встречается гораздо реже.
RTOS делает контроллер мощнее
Как ни странно, распространенное заблуждение о том, что если мощности контроллера не хватает для полноценного функционирования программы, то добавление в программу RTOS может решить проблему, - присуще даже опытным программистам. Нередко можно услышать от них довод: «Зачем тут RTOS? Я вот писал такое, да растакое на ассемблере – и справился без всяких RTOS!» Довод довольно нелепый и скорее говорит за невладение вопросом, чем за умение обходиться ассемблером (или Си).
Истоки этого заблуждения, скорее всего, в рассуждениях малоопытных программистов, большинство программ которых написаны крайне неэффективно и неоптимально. При попытке перевести программу под управление какой-нибудь RTOS, имеющей в своем составе намного более эффективные решения, они обнаруживали, что программа вдруг стала быстрее и компактнее, чем была. Это достижение тут же доносится до широких масс и принимается на вооружение всеми, кто не имел дела с RTOS ранее: и опытными и неопытными.
На самом же деле надо понимать, что ни памяти, ни скорости микроконтроллеру RTOS не добавит, а даже наоборот – часть этих ресурсов заберет под свои нужды. Поэтому, если микроконтроллер не справляется с возложенными на него задачами, в большинстве случаев это означает, что нужно применить другой, более мощный, контроллер.
В заключении можно сказать, что подавляющее большинство программ могут быть одинаково эффективно написаны с использованием любой парадигмы (+/- килобайт, +/- мегагерц). А задачи, требующие конкретного подхода (будь то RTOS, или прерывания, или автомат состояний, или чистый ассемблер), появляются намного реже. Ниша, где RTOS может оказаться эффективней остальных парадигм - сложные программы с большим количеством параллельных процессов, состояний и режимов работы. Но это не означает, что такие программы могут быть написаны только с использованием RTOS. Так же, как не означает и того, что все остальные программы должны быть написаны без нее.
Зачастую проблема не в критериях выбора инструмента (или парадигмы программирования), а в умении конкретного программиста построить эффективную абстрактную модель и реализовать ее с помощью предпочитаемого им инструмента.
Виктор Тимофеев, февраль, 2011
osa@pic24.ru