Железячники vs. Программисты
Всем привет! Я — один из основателей открытого проекта Embox, и по совместительству являюсь генеральным директором компании ООО «Ембокс». Как не трудно догадаться, её основная цель — это оказание коммерческих услуг на базе нашего проекта.
Собственно, блог — это своего рода мой подарок проекту. Поводом для этого послужило появление пятого пользователя, готового оплачивать наши услуги. В итоге мне показалось, что могут существовать и другие компании с проблемами, которые можно решить именно с помощью нашего проекта.
Эта статья первая в нашем блоге, и мне кажется, что будет уместно рассказать не столько о технических решениях и находках, которые мы применяем в нашем проекте, это, безусловно, будет в последующих статьях, а сделать своего рода статью-приветствие. И поскольку Embox — операционная система для встраиваемых решений, речь в статье пойдет прежде всего о сфере embedded systems. По сути дела, в статье я хочу поделиться своим представлением о возможном направлении развития встраиваемого ПО, конечно, подкреплять всё это я буду реальными ситуациями, с которыми мы сталкивались в процессе работы над проектом. Поэтому те, кто интересуется встраиваемыми системами и кому не лень прочитать пару страниц жалоб на трудное детство рассуждений, прошу под кат.
Как я уже отметил, наша сфера деятельности в основном касается встроенных систем, но, как вы сами знаете, под этим понятием скрывается очень большой класс систем. Я бы даже сказал, что всё, что не является десктопными, серверными или мобильными системами, в той или иной мере можно отнести к встроенным. Возможно, именно это привело к возникновению двух больших ярко выраженных кланов. С одной стороны — люди, которые пришли со стороны железа, железячники. Они работают на контроллерах, считают каждый байт и такт процессора. А с другой стороны — программисты, которые пришли из мира Linux, с его огромными функциональными возможностями, но в то же время с большими затратами на память и процессор. И у тех, и у других есть свои аргументы, почему именно их подход верен. На мой взгляд, эти аргументы неплохо описаны в статье от Black Swift. Так как на их плате стоит OpenWRT, они обозначили преимущества мира Linux, а именно:
И в итоге получается не Arduino, которая не умеет примерно ничего, не ESP8266, который, при всей его дешевизне, вряд ли позволит создать веб-интерфейс с PHP, сокетами, женщинами и азартными играми —, а устройство с функционалом, полностью соответствующим современному пониманию «умных вещей».
К недостаткам в этой же статье они справедливо отнесли отсутствие качеств, которыми гордятся железячники: Да, у Black Swift есть ограничения — нет работы в жёстком реальном времени, нет аппаратного ШИМ, нет АЦП.
А в комментариях проскальзывает такая фраза: Через sysfs минимальный квант — 3 мсек, прямая работа с регистрами — 100 нсек.
То есть, получается, что для изменения состояния одного пина из пользовательского режима необходимо 3 мсек, и это при том, что на том же упомянутом arduino это делается намного быстрее и более предсказуемо, несмотря на гораздо более низкую производительность.Тут железячники обычно заявляют, что говорить больше не о чем, что программисты напридумывали себе всякие ненужные свистелки, но забыли об основной функции устройства. На этом разговор заканчивается, причем я их, безусловно, понимаю. Но через какое-то время они всё равно приходят к программистам со словами: «Нам бы к нашему устройству прикрутить консоль с шеллом, ну ещё файловую систему, желательно ещё и сетевую, ну и tcl поставьте, я к нему привык». Это выдержка из реального разговора, правда железячник не на контроллерах программировал, а на ПЛИС, но сути дела это не меняет.
Да, в общем-то, железячники никогда и не ставили под сомнение преимущества богатой функциональности устройства. Вопрос в том, чем за это приходится платить.Вот представьте: у вас есть устройство, основное назначение которого — управлять двигателем какого-нибудь клапана. Чтобы прикрутить к нему веб-интерфейс, потребуется установить на нём Linux, в результате чего время реакции основной функции вашего устройства снизится до 3 мсек. И тут невольно задумаешься, а так ли нужен тебе этот веб-интерфейс?
Но сегодняшние реалии таковы, что все понимают: даже простые устройства должны быть сетевыми, удобными в использовании, а, следовательно, должны быть многофункциональными, и с помощью arduino, скажем так, трудно этого достичь.
Мы, например, столкнулись с этим при создании устройства для управления светодиодами. Кроме стандартного для подобных устройств протокола modbus заказчик захотел, чтобы у него был удобный и понятный веб-интерфейс, по которому обычный оператор в ручном режиме мог бы управлять портами и настраивать устройство.
Ещё один показательный пример приведу от одной компании, самостоятельно выпускающей оборудование для автоматизации. Мы оказывали поддержку по программой части. Есть небольшая лаборатория автоматики в городе Новокузнецк, они задумали сделать платы управления станком с ЧПУ. Их всё устраивало, алгоритм работал быстро, а станок — плавно. Но чтобы отличаться от любительских аналогов, они решили к своим устройствам добавить удобное управление: прикрутить веб-интерфейс и так далее. Вот, собственно, с веб-интерфейсом, по которому нужно было загружать программы для станка, производить калибровку, настройку, диагностику, а главное — передавать статус по сети в момент работы станка, они к нам и обратились. Ведь сами они не программисты, и подобная функциональность, какой бы простой она ни казалась, требует определённых усилий, и нам, как программистам, было проще это сделать. Конечно, главное, чтобы основная функциональность при этом не пострадала, станок должен работать так же плавно. И тут наша ОС отличается в положительную сторону от Linux-а: ведь у нас приложения могут выполняться в том же контексте что и ядро, поэтому можно писать напрямую в регистры, без дополнительных накладных расходов.
Кто-то может сказать, что эти расходы для Linux-а — плата за универсальность и безопасность. Но мы ведь разрабатываем не устройство на все случаи жизни, а специализированное устройство с заранее известной функциональностью, и давать хотя бы потенциальную возможность для оператора поставить себе косынку, чтобы не скучать, пока станок выполняет программу, как-то не очень хорошо. А то в результате появляются посты «Чем айтишнику заняться в армии …». Нет, я, безусловно, восхищаюсь умом и сообразительностью наших военных айтишников, в результате иногда получается полезный результат, но всё-таки это скорее исключение.
Кроме того, в области специализированных систем часто требуется сертификация. Например, один из заказчиков выбрал нас потому, что его устройство должно было пройти проверку в ФСБ на недекларированные возможности. То есть, если в конечном образе прошивки существует программный код, то условия его вызова и функциональность должны быть описаны и проверены на соответствие требованиям сертификационной комиссией. Первое, что приходит в голову, это создать ПО без операционной системы, но тут же выясняется, что функциональность нужна, и довольно богатая: веб-интерфейс, файловая система, удаленный доступ на основе ssh, firewall и так далее. Мы в свое время тоже сталкивались с этой дилеммой, тогда мы пытались подготовить к сертификации ядро Linux-а с минимальным набором пользовательских утилит. Задача, я вам хочу сказать, не из приятных. В результате, для Embox мы придумали язык описания модулей, который позволяет строить статические модели системы и на основе них генерировать подходящий для сертификации дистрибутив. Этот дистрибутив содержит только необходимые исходники, make- и заголовочные файлы.Данный подход позволил нам решить и другую проблему, которая характерна для области встроенных систем. А именно, применение тех самых контроллеров с небольшим количеством ресурсов на борту и отсутствием виртуальной памяти. Если вы думаете что подобные системы уже не нужны, потому что Raspberry Pi стоит не намного дороже, то вы ошибаетесь. Во-первых, ненамного, но все-таки дороже. Во-вторых, не стоит забывать об электропотреблении, ведь достаточно часто нужно питание или от батарейки/аккумулятора, или PoE (power over ethernet). Ну и надежность, которая также сильно ценится для подобных устройств. Ведь, надеюсь, не нужно объяснять, что несколько припаянных микросхем (процессор, память, …) — менее надежная конструкция, чем один чип, содержащий в себе и процессор, и память, и периферию.
К тому же, если раньше основную массу контроллеров составляли восьмиразрядные mega — и pic-и, и на них трудно было развернуть богатую функциональность в виде веб-серверов, файловой системы на SD-карте и так далее, то сейчас доступны мощные мобильные ARM-контроллеры серии Cortex M3/4. Последние вообще содержат dsp-команды, плавающую точку и могут работать на частотах, близких к 200 MHz. В общем, есть, где построить полноценную многофункциональную систему. Именно на одном из таких контроллеров, STM32F407, содержащем 1 MB флеш и 192 kB, мы и делали упомянутые контроллеры для светодиодов, и по нашему совету в лаборатории автоматики делают станок с ЧПУ и другие устройства, для которых важны с одной стороны свойства для жезячников, а с другой — преимущества от программистов.
На этих мобильных ARM-контроллерах, в силу ограниченности памяти, всё ещё невозможно установить Linux, если, конечно, не использовать внешние микросхемы. Поэтому наиболее распространенной ОС является FreeRTOS. Это, безусловно, хорошая ОС РВ, но она является последовательницей, пусть и более функциональной, различных железячных проектов. То есть, разработчики этого проекта отталкивались от железячных ценностей, так называемого подхода «libOS», когда система разрабатывается, по сути дела, с нуля, естественно, используя в качестве базовой библиотеки саму ОС. В этом подходе есть, как я говорил, свои плюсы: разработчик полностью контролирует всю систему. Но в тоже время такой подход тяжело укладывается в идею переиспользования кода. Это уже достаточно серьезный недостаток, ведь перенос какого-нибудь POSIX-совместимого ПО, скажем sshd или httpd, очень трудоемок, поскольку подобные ОС в целях экономии используют свое собственное API.
Идея запустить Linux/POSIX на платформах с ограниченными ресурсами известна довольно давно, одним из таких проектов был ucLinux. Его основной идеей был запуск написанных для Linux приложений на аппаратной платформе без MMU. Насколько я знаю, сейчас наработки проекта влились в основной Linux, и, как следствие, Linux можно сконфигурировать как NOMMU систему. Но остаётся проблема монолитного ядра, то есть, даже если отключить все неиспользуемые драйвера, в ядре будут присутствовать все системные вызовы, и, следовательно, все подсистемы, пусть и в минимальном объеме. Поэтому в те ограничения по памяти, которые я привел (192кБ), Linux опять-таки не укладывается, и нужно ставить внешнюю память. Минимальным компьютером, на котором работает Linux, является Picotux, он содержит 8 MB оперативной памяти. На самом деле, я нашел упоминание о работающем Linux-а на плате с x86 процессором и всего 2.5 MB оперативки, но даже после такого подвига всё ещё нужна внешняя память.
Ещё одним, на мой взгляд, перспективным проектом является eCos. Одно время он был очень популярным в области встроенных систем. Его основная идея заложена в самом названии проекта, eCos: embedded configurable operating system. Эта система имела довольно приличную совместимость с POSIX, поэтому могла в какой-то мере пользоваться широким набором приложений Linux, и при этом она могла запускаться на платформах с сотнями килобайт памяти. Почему она не завоевала весь пьедестал почёта и не стала стандартом де-факто для встроенных систем, мне не совсем понятно. Возможно потому, что поддерживая многопоточность, eCos могли иметь только один процесс, а в Linux-е очень часто используют процессы. Возможно, не удалось договориться с производителями контроллеров. Возможно, как я несколько раз слышал от производителей оборудования, не было достаточной поддержки проекта. В общем, я не знаю, но вижу, что с одной стороны этот проект вытесняется FreeRTOS, а с другой стороны — Linux-ом.
Но в тоже время, мне кажется, что идеи именно eCos совместно с идеями от ucLinux, могут изменить ситуацию в области встроенных систем в недалеком будущем. Ведь, как я уже отмечал, сейчас появились контроллеры (системы на кристалле), позволяющие строить эффективные многофункциональные системы. Единственным препятствием, на мой взгляд, является сильное различие подходов, принятых в мирах железячников и программистов, и нежелание понять друг друга.
Подводя итоги своих рассуждений, приведу несколько характерных особенностей в области встраиваемого ПО на сегодняшний день:
Ограниченные ресурсы — Сегодня, как и раньше, в области встраиваемых систем ресурсов существенно меньше, чем в десктопных. Это обусловлено не столько стоимостью ресурсов, которая сильно понизилась в последнее время, сколько надежностью, энергопотреблением и другими характерными для области требованиями. Специфические аппаратные платформы — Тесно переплетающееся с предыдущим пунктом утверждение. Тут я хочу отметить, что системы не только используют отличную от x86 архитектуру, но и используют процессоры без аппаратной поддержки виртуальной памяти. Уникальное программное обеспечение — Часто встраиваемое программное обеспечение проектируется вообще без использования ОС или использует ОС, имеющие собственное API, не совместимое с другими платформами. Высокие требования к функциональности — В последнее время к встраиваемым устройствам предъявляют всё большие требования, как минимум, они должны быть сетевыми, иметь удобный и привычный интерфейс, что ведёт за собой использование Linux, Android и других полнофункциональных универсальных ОС. Первые пункты характерны и для предыдущих этапов развития отрасли, а вот последний получил широкое распространение относительно недавно (5–10 лет) и всё больше набирает популярность, но это противоречит традиционным требованиями и зачастую выливается в архитектурные решения типа использования в одной системе разных аппаратных частей: одна работает в реальном времени, например, на ПЛИС или контроллере без ОС, а ещё одна отвечает за общее назначение и работает на полноценном Linux-е и каком-нибудь «большом» ARM-е. Это не только уменьшает надёжность и увеличивает стоимость устройства, но и требует привлечения к разработке как железячников, так и программистов, что, конечно, увеличивает время разработки.
Мы, в проекте Embox, относимся к программистам, и нам, как нормальным программистам, казались несущественными (легко решаемыми) проблемы железячников, но постоянно сталкиваясь с этими проблемами, мы вынуждены были пересмотреть, хоть и незначительно, свои взгляды, а попытки их решить привели к появлению нашего проекта. На правах рекламы, я даже приведу цитату от той самой лаборатории автоматики о нашем проекте:
То, что Embox — это то, о чем мы долго мечтали, уже факт, …
Поэтому мы и считаем, что наш проект может помочь решить похожие проблемы и для других пользователей.P.S. Для тех кто следит за проектом, сообщаю, что мы выпустили версию 0.3.9.P.P. S. Мы перешли на github. Это, по мнению многих участников проекта, упростит подключение новых контрибьюторов. Так что ждем наплыва желающих окунуться в мистический мир OSDev! :)
