Железячники vs. Программисты

Всем привет!

Я — один из основателей открытого проекта Embox ^[1], и по совместительству являюсь генеральным директором компании ООО “Ембокс”. Как не трудно догадаться, её основная цель — это оказание коммерческих услуг на базе нашего проекта.

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

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

Как я уже отметил, наша сфера деятельности в основном касается встроенных систем, но, как вы сами знаете, под этим понятием скрывается очень большой класс систем. Я бы даже сказал, что всё, что не является десктопными, серверными или мобильными системами, в той или иной мере можно отнести к встроенным. Возможно, именно это привело к возникновению двух больших ярко выраженных кланов. С одной стороны — люди, которые пришли со стороны железа, железячники. Они работают на контроллерах, считают каждый байт и такт процессора. А с другой стороны — программисты, которые пришли из мира Linux, с его огромными функциональными возможностями, но в то же время с большими затратами на память и процессор. И у тех, и у других есть свои аргументы, почему именно их подход верен. На мой взгляд, эти аргументы неплохо описаны в статье от Black Swift ^[2]. Так как на их плате стоит OpenWRT, они обозначили преимущества мира Linux, а именно:

И в итоге получается не Arduino, которая не умеет примерно ничего, не ESP8266, который, при всей его дешевизне, вряд ли позволит создать веб-интерфейс с PHP, сокетами, женщинами и азартными играми — а устройство с функционалом, полностью соответствующим современному пониманию «умных вещей».

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

Да, у Black Swift есть ограничения — нет работы в жёстком реальном времени, нет аппаратного ШИМ, нет АЦП.

А в комментариях проскальзывает такая фраза:

Через sysfs минимальный квант — 3 мсек, прямая работа с регистрами — 100 нсек.

То есть, получается, что для изменения состояния одного пина из пользовательского режима необходимо 3 мсек, и это при том, что на том же упомянутом arduino это делается намного быстрее и более предсказуемо, несмотря на гораздо более низкую производительность.

Тут железячники обычно заявляют, что говорить больше не о чем, что программисты напридумывали себе всякие ненужные свистелки, но забыли об основной функции устройства. На этом разговор заканчивается, причем я их, безусловно, понимаю. Но через какое-то время они всё равно приходят к программистам со словами: “Нам бы к нашему устройству прикрутить консоль с шеллом, ну ещё файловую систему, желательно ещё и сетевую, ну и tcl поставьте, я к нему привык”. Это выдержка из реального разговора, правда железячник не на контроллерах программировал, а на ПЛИС, но сути дела это не меняет.

Да, в общем-то, железячники никогда и не ставили под сомнение преимущества богатой функциональности устройства. Вопрос в том, чем за это приходится платить.
Вот представьте: у вас есть устройство, основное назначение которого — управлять двигателем какого-нибудь клапана. Чтобы прикрутить к нему веб-интерфейс, потребуется установить на нём Linux, в результате чего время реакции основной функции вашего устройства снизится до 3 мсек. И тут невольно задумаешься, а так ли нужен тебе этот веб-интерфейс?

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

Мы, например, столкнулись с этим при создании устройства для управления светодиодами ^[3]. Кроме стандартного для подобных устройств протокола modbus заказчик захотел, чтобы у него был удобный и понятный веб-интерфейс, по которому обычный оператор в ручном режиме мог бы управлять портами и настраивать устройство.

Ещё один показательный пример приведу от одной компании, самостоятельно выпускающей оборудование для автоматизации. Мы оказывали поддержку по программой части. Есть небольшая лаборатория автоматики ^[4] в городе Новокузнецк, они задумали сделать платы управления станком с ЧПУ. Их всё устраивало, алгоритм работал быстро, а станок — плавно. Но чтобы отличаться от любительских аналогов, они решили к своим устройствам добавить удобное управление: прикрутить веб-интерфейс и так далее. Вот, собственно, с веб-интерфейсом, по которому нужно было загружать программы для станка, производить калибровку, настройку, диагностику, а главное — передавать статус по сети в момент работы станка, они к нам и обратились. Ведь сами они не программисты, и подобная функциональность, какой бы простой она ни казалась, требует определённых усилий, и нам, как программистам, было проще это сделать. Конечно, главное, чтобы основная функциональность при этом не пострадала, станок должен работать так же плавно. И тут наша ОС отличается в положительную сторону от Linux-а: ведь у нас приложения могут выполняться в том же контексте что и ядро, поэтому можно писать напрямую в регистры, без дополнительных накладных расходов.

Кто-то может сказать, что эти расходы для Linux-а — плата за универсальность и безопасность. Но мы ведь разрабатываем не устройство на все случаи жизни, а специализированное устройство с заранее известной функциональностью, и давать хотя бы потенциальную возможность для оператора поставить себе косынку, чтобы не скучать, пока станок выполняет программу, как-то не очень хорошо. А то в результате появляются посты “Чем айтишнику заняться в армии ...“ ^[5]. Нет, я, безусловно, восхищаюсь умом и сообразительностью наших военных айтишников, в результате иногда получается полезный результат ^[6], но всё-таки это скорее исключение.

Кроме того, в области специализированных систем часто требуется сертификация. Например, один из заказчиков выбрал нас потому, что его устройство должно было пройти проверку в ФСБ на недекларированные возможности. То есть, если в конечном образе прошивки существует программный код, то условия его вызова и функциональность должны быть описаны и проверены на соответствие требованиям сертификационной комиссией. Первое, что приходит в голову, это создать ПО без операционной системы, но тут же выясняется, что функциональность нужна, и довольно богатая: веб-интерфейс, файловая система, удаленный доступ на основе 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 ^[7], он содержит 8 MB оперативной памяти. На самом деле, я нашел упоминание о работающем Linux-а на плате с x86 процессором и всего 2.5 MB оперативки ^[8], но даже после такого подвига всё ещё нужна внешняя память.

Ещё одним, на мой взгляд, перспективным проектом является eCos ^[9]. Одно время он был очень популярным в области встроенных систем. Его основная идея заложена в самом названии проекта, eCos: embedded configurable operating system. Эта система имела довольно приличную совместимость с POSIX, поэтому могла в какой-то мере пользоваться широким набором приложений Linux, и при этом она могла запускаться на платформах с сотнями килобайт памяти. Почему она не завоевала весь пьедестал почёта и не стала стандартом де-факто для встроенных систем, мне не совсем понятно. Возможно потому, что поддерживая многопоточность, eCos могли иметь только один процесс ^[10], а в Linux-е очень часто используют процессы. Возможно, не удалось договориться с производителями контроллеров. Возможно, как я несколько раз слышал от производителей оборудования, не было достаточной поддержки проекта. В общем, я не знаю, но вижу, что с одной стороны этот проект вытесняется FreeRTOS, а с другой стороны — Linux-ом.

Но в тоже время, мне кажется, что идеи именно eCos совместно с идеями от ucLinux, могут изменить ситуацию в области встроенных систем в недалеком будущем. Ведь, как я уже отмечал, сейчас появились контроллеры (системы на кристалле), позволяющие строить эффективные многофункциональные системы. Единственным препятствием, на мой взгляд, является сильное различие подходов, принятых в мирах железячников и программистов, и нежелание понять друг друга.

Подводя итоги своих рассуждений, приведу несколько характерных особенностей в области встраиваемого ПО на сегодняшний день:

• Ограниченные ресурсы — Сегодня, как и раньше, в области встраиваемых систем ресурсов существенно меньше, чем в десктопных. Это обусловлено не столько стоимостью ресурсов, которая сильно понизилась в последнее время, сколько надежностью, энергопотреблением и другими характерными для области требованиями.
• Специфические аппаратные платформы — Тесно переплетающееся с предыдущим пунктом утверждение. Тут я хочу отметить, что системы не только используют отличную от x86 архитектуру, но и используют процессоры без аппаратной поддержки виртуальной памяти.
• Уникальное программное обеспечение — Часто встраиваемое программное обеспечение проектируется вообще без использования ОС или использует ОС, имеющие собственное API, не совместимое с другими платформами.
• Высокие требования к функциональности — В последнее время к встраиваемым устройствам предъявляют всё большие требования, как минимум, они должны быть сетевыми, иметь удобный и привычный интерфейс, что ведёт за собой использование Linux, Android и других полнофункциональных универсальных ОС.

Первые пункты характерны и для предыдущих этапов развития отрасли, а вот последний получил широкое распространение относительно недавно (5–10 лет) и всё больше набирает популярность, но это противоречит традиционным требованиями и зачастую выливается в архитектурные решения типа использования в одной системе разных аппаратных частей: одна работает в реальном времени, например, на ПЛИС или контроллере без ОС, а ещё одна отвечает за общее назначение и работает на полноценном Linux-е и каком-нибудь “большом” ARM-е. Это не только уменьшает надёжность и увеличивает стоимость устройства, но и требует привлечения к разработке как железячников, так и программистов, что, конечно, увеличивает время разработки.

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

То, что Embox — это то, о чем мы долго мечтали, уже факт, ...

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

P.S. Для тех кто следит за проектом, сообщаю, что мы выпустили версию 0.3.9 ^[11].
P.P.S. Мы перешли на github ^[12]. Это, по мнению многих участников проекта, упростит подключение новых контрибьюторов. Так что ждем наплыва желающих окунуться в мистический мир OSDev! :)

Автор: abondarev

Источник ^[13]