Всем привет!Я — один из основателей открытого проекта 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! :)
Комментарии (65)
Iceg
15.04.2015 15:32+1янипонил :( В итоге, Embox это RTOS или нет?
для изменения состояния одного пина из пользовательского режима необходимо 3 мсек
а в Embox?
Встпуление хорошее, а непосредственно о вашем проекте мало сказано. Давайте продожение :)
abondarev Автор
15.04.2015 15:41+1скорее RTOS, чем нет:)
Embox можно сконфигурировать таким образом, что из прикладных приложений будет фактически прямой доступ к регистрам. Это конечно менее безопасно, но предполагается, что программист знает, что делает. Поэтому у нас можно из tcl скрипта фактически без накладных расходов писать и читать регистры.
Спасибо. Продолжение следует, надеюсь в ближайшем будущем!
Big_Lebowski
15.04.2015 15:50Если можно в регистры, то вероятно и непосредственно в DRAM адреса можно? ;)
abondarev Автор
15.04.2015 15:57+1Ну да, во все адресное пространство, в том числе и DRAM. Но это конечно если сконфигурировать без MMU и остального.
Big_Lebowski
15.04.2015 16:09+1А есть в плане безопасности в вашей архитектуре между модулем ядра и юзерским процессом?
Странички например с кернелом никто же не мешает попортить.abondarev Автор
15.04.2015 17:13Планы у нас большие:) Про безопасность в том числе.
На самом деле, у нас есть поддержка MMU, некоторая необходима на некоторых платформах для включения cache. Просто ее можно не включать или настроить трансляцию один к одному. Для небольших устройств мы хотим добавить поддержку MPU, как раз для защиты страниц,
Ну, и как я написал выше, при статической линковке образа, ответственность можно переложить на программиста, ведь он должен осознавать, что он делает. А для многих устройств, которые управляют ножками, алгоритм работы можно описать заранее.Big_Lebowski
15.04.2015 17:25+1Я пропустил слово :)
Должно быть
«А есть в плане безопасности в вашей архитектуре _разница_ между модулем ядра и юзерским процессом?»
Но я понял ответ так или иначе — эмбеддед программист в ответе за все.abondarev Автор
15.04.2015 18:21+1Да, вы правы, мы жертвуем безопасностью и универсальностью в угоду эффективности. Точнее даем такую возможность:)
Indemsys
15.04.2015 16:30+1Про недостатки FreeRTOS как-то невнятно сказано.
Сейчас во встраиваемых системах хорошо известны как минимум 5-ть операционных систем реального времени (RTOS) способных работать на STM32F407 и ниже с открытыми исходными текстами (хотя и под разными лицензиями).
Это: FreeRTOS, Micrium (uC/OS-II, III), Keil (RTX) она же mbed.org, Freescale MQX, Texas Instruments RTOS
Они все! идут с демонстрационными примерами включающими WEB сервер и работу в интернете по разным протоколам.
Некоторые из них совместимы с POSIX.
Так в чем же смысл Embox?abondarev Автор
15.04.2015 17:28+1Изначально смысл Embox был в фане, который мы получали, плюс мы обучали (и обучаем) студентов архитектуре ОС и embedded systems на практике, что оказалось очень эффективным.
Ну, а потом, найдя нескольких заказчиков, мы подумали, что можем улучшить жизнь простых разработчиков, достаточно простым образом, просто позволив в ОСРВ использовать приложения из Linux. Эта идея была у uCLinux. Кроме того, изначально у нас была возможность включать только минимум приложений, это действительно похоже на различные ОСРВ которые Вы привели, но в отличие от остальных у нас нет единственного main и в нем цикла обработки, а есть main для каждого приложения.
В общем, мы хотим совместить в проекте плюсы от Linux и RTOS. И надеемся, что это может кому нибудь пригодиться.
Ogoun
15.04.2015 17:31+9А для чего на конечном железе поднимать веб-сервер? В чем минус решения когда на микроконтроллере крутится только критичный функционал, а интерфейс выносится на внешнее устройство, где падения высокоуровневого кода не сломает работу критичных задач? Конечно получится лишнее звено, но на него можно навесить много переферийных задач и оно вполне окупится.
Т.е. например ардуино которая по тому же modbus обменивается командами с полноценным компьютером, большую часть времени при этом работая автономно, и не зависящая от работы ОС на компьютере.abondarev Автор
15.04.2015 17:52Не уверен, что это достаточная аргументация, но…
В общем, когда то мы хотели сделать квадракоптер, сделать мы его хотели на gumstix, и к нему шла отдельная плата с автопилотом. И тогда нам пришло в голову, а почему же не перенести функциональность автопилота на большой процессор. Естественно должна быть защита, чтобы критичные задачи не могли сломаться прикладным ПО. Это можно было достичь, например, с помощью гипервизора о котором говорилось в первом комментарии. Мы же пошли немного другим путем, описанным в статье. То есть, позволили совмещать критичную и не критичную функциональность, а разруливается это программистом с помощью приоритетов и остальных плюшек нашего проекта.
Кроме того, с увеличением компонентов и связей между компонентами надежность устройства падает, ну и следовательно в системе нужно оставить как можно меньше процессоров.barabanus
16.04.2015 00:43Интересно, что Pixhawk — крутейшая железка для беспилотников — именно так и работает: «функциональность автопилота на большом процессоре». Учитывая размер комьюнити, разрабатывающего ArduPilot и Pixhawk, подозреваю, что эти решения станут вездесущими не только в мире беспилотников.
Indemsys
16.04.2015 08:02+5Pixhawk построен на PX4 Flight Stack.
А тот в свою очередь базируется на одной из старейших RTOS — NuttX
Начиналась эта RTOS еще от 8-и разрядных микроконтроллеров AVR
Никакого большого процессора там нет.
Автопилоты этого класса делаются на нескольких средненьких STM32F.
RTOS там вообще только в одном из них применяется.
Хотя да, NuttX поддерживает POSIX, но никогда к Линуксу и большим процессорам с MMU никакого отношения не имела.abondarev Автор
16.04.2015 12:20Ого, не знал что NuttX, старейшая ОСРВ, думал она довольно молодая. Автор кстати в нашу группу рассылки писал, и мы с ним общались. Да идея у него похожая, добавить в RTOS достаточно полноценный POSIX, для совместимости с имеющимся ПО.
Indemsys
16.04.2015 08:07+2Это коммерческий AR.Drone делают на Линуксе. Но нельзя забывать что у них там всегда есть еще оконечные интеллектуальные ESC модули и проч. Вот они то и работают в жестком риалтайме.
А Линукс там нужен чтобы запускать для забавы пользователям JavaScript.abondarev Автор
16.04.2015 12:18Вот когда для забавы ставится Линукс, причем только для забавы, это все таки отдельный мощный процессор и память и остальное, вот именно этого можно постараться избежать. То есть, если развлекухи будут работать с низким приоритетом и не затронут работу задач с жестким реалтаймом, то можно ограничится одним корпусом, пусть даже с несколькими ядрами.
Noliki
15.04.2015 17:43+3В СССР, уже на излете, проблему совместимости железячников и программистов в оборонке решили убиранием программистов на уровень писания средств разработки. А средство разработки сделали доступным для железячников — это ДРАКОН.
abondarev Автор
15.04.2015 18:17+2Да, я слышал о таком графическом языке, насколько я знаю, его сейчас пытаются применять. Еще можно отметить различные языки для ПЛК. Но мне кажется чисто графические языки не дают достаточно возможностей программисту. Это хорошо для верхнего уровня и для определенного класса задач, например, где нужно ограничивать, эти самые возможности, но всю разработку вести на них крайне трудно.
Ну а идея убирания программистов на написание средств разработки понятна. Сами мы начинали на кафедре системного программирования СПбГУ. И Андрей Николаевич Терехов, зав кафедрой, как раз и придерживается тех самых взглядов. В свое время на кафедре написали графический язык REAL, он конечно меньше известен, но применялся для создания АТС. Кроме того было еще несколько технологий для оборонки и даже своя вычислительная машина Самсон.
Да и Embox в принципе можно отнести к технологиям. :) Поскольку инженеры нас используют и у них получается.
kxlab
15.04.2015 17:52Вопрос №1: Пожалуйста дайте сравнительный анализ emBox и MINIX (Таненбаума 3th edition).
Вопрос №2: Возможна ли сборка прикладных программ вне вашей системы сборки? Или надо собственные утилиты встраивать в ваше дерево.
Вопрос №3: Где можно найти более подробную информацию о emBox и увидеть примеры.abondarev Автор
15.04.2015 18:311. Уточните пожалуйста по каким параметрам интересует сравнение. Первое, что приходит в голову, мы русские и нашим студентам было проще общаться с нами, в том числе и лично.
2. Сейчас к сожалению нет. Но мы сейчас разрабатываем новую версию системы сборки в которой такая возможность обязательно будет. Раньше просто такой проблемы не было.
3. На нашем вики можно найти некоторую информацию. К сожалению с документацией у нас крайне плохо, поэтому лучше спрашивать в нашей группе рассылки или вообще обращаться лично. Со временем, надеюсь это исправится.kxlab
15.04.2015 19:43По первому пункту: я тоже русский и с удовольствием рассматривал бы ваш проект как основу нашей OS. С первого же взгляда на код, я вспомнил об идеях Таненбаума, которые не были поддержаны сообществом. А сравнение хотелось бы, для начала, с точки зрения идеологических основ и возможности развития. Может быть пора собирать сообщество на поддержку.
По второму пункту: было бы неплохо иметь отдельно систему сборки микроядра, систему сборки компонентов ядра вне исходников ядра, и возможность собирать приложения отдельно. Все системы сборки должны поддерживать параллельную сборку (это важно в условиях широкого набора разного железа).
По третьему пункту: документации не бывает много, спасибо, что она есть. Кстати, перенесите ее с закрывающегося code.google.com.
А вообще мне очень понравилось то, что вы подошли к работе основательно и даже собственную систему сборки создали.
Но главное надо выяснить ваши отношения с Таненбаумом.abondarev Автор
15.04.2015 22:59Вы нам льстите, к сожалению, у нас нет отношений с Таненбаумом:)
Мы безусловно изучаем код Minix и порой заимствуем идеи, но мы не так категоричны по поводу микроядерности.
На самом деле, я считаю, что у нас из за нашей модульной структуры, система получилась порой даже более подходящая для изучения чем в Minix. Но конечно за Minix огромный опыт и нам трудно с ним соревноваться, все таки классика ее нужно знать.
С документацией согласен, много ее не бывает. Конечно перенесем, ниже в комментариях об этом где то было.
По поводу отдельных приложений и модулей ядра. Да идея у нас приблизительно следующая, а давайте сделаем библиотеки которые не будут зависеть от конкретного ядра, и тогда из них можно собрать и микроядерную архитектуру и монолитную и гибридную, в общем по-экспериментровать от души. А приложения, хотим вообще свои маленький аналог busybox сделать, но с преферансом и поэтессами:) В общем идей много, постараемся реализовать.
Под нашей OS вы подразумеваете отечественную разработку? Нам бы хотелось, чтобы проект был интернациональным. У нас даже несколько иностранных контрибьютеров было, к сожалению, мало. Это кстати к слову о сообществе. Конечно мы пытаемся его создать и будем рады любому сотрудничеству!
kxlab
16.04.2015 11:15C busybox категорически не согласен. Сделав такую замкнутую систему, вы несомненно попадете к ней в рабство. Лучше сделайте микро posix библиотечку языка C наподобие newlib или klib. Тогда сообщество портирует для вас ключевые утилиты и shell типа sash. Давая людям свободу, вы получите поддержку многих. Делая замкнутые системы, вы ограничите сообщество.
abondarev Автор
16.04.2015 13:52Я наверное не совсем правильно выразился.
По busybox я имел в виду набор легковесных библиотек и приложений которые легко отделяются и включаются в проект.
Стандартная библиотека у нас своя, пытались использовать nelib, но не получилось. У нас слишком конфигурироемое решение. То есть не понятно как быть с системными вызовами, которые в каждой системе свои, но они одинаковые для системы, а у нас все может меняться, и системных вызовов может не быть, а быть прямые вызовы функций.
По поводу свободы. Да, мы пытаемся сделать максимально открытый проект, именно поэтому мы задумали новую систему сборки, которая позволит сообществу легко отделять и включать куски. Ну, это одно из требований.:)
Disasm
15.04.2015 17:54+1Скажите, кто тот человек, который написал систему сборки Embox, и как он это сделал?
abusalimov
15.04.2015 17:57+2Только не бейте меня сильно =)
P.S. Старая статья на хабре.kxlab
15.04.2015 18:05+1code.google.com закрывается. Летом этого года прекратят создание новых проектов, а затем вообще закроют. Куда собираетесь переносить WiKi?
abusalimov
15.04.2015 18:12Скорее всего, тоже на Гитхаб. Автоматически переносить не стали, поскольку хотим перетрясти структуру, да и вообще в порядок привести.
С переездом на Гитхаб (всего остального) вообще целая эпопея вышла, потому как мы заморочились еще и переносом всех ишью с сохранением авторства и дат. Плюс добавили к гитовой истории самые ранние коммиты, которых не было на Гугл Коде. Вики будем воссоздавать скорее всего вручную.
Disasm
15.04.2015 18:10+1Можете объяснить, как она работает? 18кБ кода это как-то немало) Я так понимаю, система сборки решает довольно много проблем, связанных с зависимостями и конфигурацией сборки.
abusalimov
15.04.2015 18:22+1Оу, боюсь, это на целую статью потянет, в прошлой, пожалуй, только поверхностное описание. А какая именно часть вас интересует?
Вообще мы сейчас работаем над следующей инкарнацией системы сборки (пишем на Питоне, а под капотом Waf). Вот про неё, думаю, было бы круто рассказать, но пока что мы только пилим сам код. =)Disasm
15.04.2015 18:40Ого, даже статья есть, спасибо! В общем-то нашёл ответы почти на все свои вопросы. Остался вопрос с реализацией генерации всяких файлов. В статье упоминается генерация списка загрузки модулей. Как это сделано или где на это можно посмотреть?
abusalimov
15.04.2015 18:49Сам скрипт генерации вот тут, а вызов его декларируется в модуле, который отвечает за разрешение зависимостей в рантайме. Скрипт просто генерирует Сишный код в stdout, а вывод сохраняется в файл, который уже компилируется и линкуется как обычный.
Disasm
15.04.2015 18:48Ещё забыл: как работает определение тулчейна, параметров компиляции и всяких таких вещей, зависящих от архитектуры? Кто предоставляет путь к тулчейну и все эти параметры?
abusalimov
15.04.2015 18:53Эта часть не менялась очень давно, там все просто задается руками в конфигурации, например, для ARM:
TARGET = embox ARCH = arm CROSS_COMPILE = arm-none-eabi- CFLAGS += -O0 -g CFLAGS += -march=armv7-a -mtune=cortex-a8 LDFLAGS += -N -gDisasm
15.04.2015 18:56То есть все модули компилируются с одними и теми же параметрами? Или можно скомпилировать, скажем, отдельно с PIC и без PIC? И как система сборки определяет, когда нужно просто скомпилировать, а когда слинковать что-то в один файл?
antonkozlov
15.04.2015 19:14Тот файл задаёт глобальные флаги, конкретно для процессора.
Мы старались добавлять фичи по необходимости, поэтому pic не поддерживается.
Но есть такая запись в src/framework/mod/Mybuild:
@DefineMacro("__FRAMEWORK__") source "core.c"
позволяет определить макрос. Разворачивается в -D__FRAMEWORK__ опцию во время компиляции
Другой пример: страшный файл third-party/qpid/Mybuild
@BuildArtifactPath(cppflags="-I$(abspath $(EXTERNAL_BUILD_DIR))/third_party/qpid/core/install/include") ... module core { ...
позволяет экспортировать флаги компиляции для зависящих модулей. Т.е. только те модули, которые зависят от core, получают -Ipath, где можно найти его хидеры.
В настоящее время, все модули просто компилируются и линкуются в один образ в конце сборки. В новой версии системы сборки обещаем поправить =)
Zuy
15.04.2015 23:52Не могли бы вы развить мысль, почему использование Linux как ОС автоматически увеличивает время реакции до 3 мс, и о каких именно дополнительных накладных расходах идет речь при прямой работе с регистрами под Linux?
abusalimov
16.04.2015 00:28+2Это из обсуждения статьи olartamonov из Black Swift:
Через sysfs минимальный квант — 3 мсек, прямая работа с регистрами — 100 нсек.
3 мсек требуется для переключения из user space, прохождения всего стека Linux vfs и отработки драйвера sysfs (ну и на то, чтобы вернуться по стеку обратно, наверное). При прямой работе с регистрами из ядерного драйвера Linux таких накладных расходов, конечно, нет.Zuy
16.04.2015 03:30+1Иными словами если работать с портами так как это должно быть сделано под Linux то никаких 3мс задержек не будет. Да и из userspace есть вариант как дергать регистры без накладных расходов с той же скоростью как и из ядра, правда совсем не переносимый между разными платформами.
Big_Lebowski
16.04.2015 05:06Это как?
Zuy
16.04.2015 05:51+1По-моему это делается через ioremap в ядре в ответ на mmap из user space. Т.о. в user space получаем кусок памяти в который драйвер отобразил диапазон адресов I/O переферии.
Один из драйверов аппаратного видеодекодера, который я видел, именно так и работал. В ядре только ремапинг, в вся логика работает напрямую с регистрами из user space.abondarev Автор
16.04.2015 07:55+1Вы правы, есть ряд ухищрений в Линукс для работы с памятью напрямую. Например через файл /dev/mem. Но это совсем не безопасный метод, к тому же непонятно как это использовать в скриптовых языках, в общем это не самые правильные методы работы в системе общего назначения.
olartamonov
16.04.2015 11:11+1Работа с GPIO
Там же замеры скорости на самой дубовой задаче — дёргать ножку 0-1 в бесконечном цикле.
amarao
16.04.2015 06:50Буквально недавно на LWN была статья о том, что для ARM'ов сделали гибридные процессоры (не путать с big.LITTLE), когда рядом с обычными computational cores находятся низкопроизводительные (200МГц) сопроцессоры с фиксированными таймингами доступа к памяти, без прерываний и прочих затруднений для realtime.
lwn.net/Articles/639258abondarev Автор
16.04.2015 07:57Прикольно, спасибо за инфу. Раньше, в такоей конфигарации, в основном встречал DSP ядра
McSava
16.04.2015 08:21+2у Freescale есть семейство Vybrid ARM Cortex-A5. В нем старшие модели имеют встроенный дополнительно Cortex-M4.
Младший процессор может работать в режиме реального времени, а старший разгребать более глобальные задачи.Indemsys
16.04.2015 08:42+1Для Vybrid Freescale имеет специальную RTOS MQX которая портирована на оба ядра этого SoC-а.
Так что и глобальные задачи можно без Линукса решать.abondarev Автор
16.04.2015 12:28Различных решений, достаточно эффективных много. Но возникает вопрос, почему так упорно используют Линукс. Мое мнение, потому что в нем есть удобство отладки и огромное количество готового ПО.
Indemsys
16.04.2015 12:57А я бы посмотрел на это иначе.
Почему Линукс полностью не захватил все встроенные системы?
По прогнозам 2014 Embedded Market Study в этом или следующем году лидером по применяемости станет FreeRTOS обогнав Android!
Мой ответ.
Потому что Линукс реально очень трудно отлаживать. И в нем не так уж много готового ПО для встраиваемых систем.
Вот какой софт вы взяли из Линукса для встраиваемых систем?abondarev Автор
16.04.2015 13:46На вскидку libmodbus. Вообще мы взяли довольно много ПО: Qt, dropbear, ZeroMQ ну и еще куча всего, но наверное вопрос именно для мелких устройств, поэтому лучше всякие легковесные языки типа lua, tynypy и так далее назвать.
FreeRTOS безусловно хорошая штука и очень популярная. Но как я уже отмечал, сейчас даже от чайника хотят чтобы он твитил. Ну а такую «продвинутую» функциональность все же проще брать готовой или отладить по максимуму на десктопном линуксе.
На самом деле, это всего лишь мое личное видение ситуации. Но из опыта в системах все же присуствует и богатый линукс (например для qt графики) и отдельно части работающие в реальном времени, тот же ардуино. И если удастся совместить эти вещи, то возможно это будет то что нужно.Indemsys
16.04.2015 14:24+1Qt это интересно. Но почти 100% уверен, что под STM32 у вас не работает.
dropbear это не готовое приложение, а просто SSH канал доступа к неким функциям которые разработчик сам должен реализовать на своей платформе. Дублирование по сути встроенного WEB сервера по SSL.
ZeroMQ не приложение, а инструмент. Эт еще понять надо как его приладить и для разработки чего он нужен.
libmodbus тоже еще не приложение, а только реализация протокола, причем настолько примитивного что он в свое время на ATMEGA8 делался без всяких осей.
Скрипты? Так они тоже без осей есть достаточно реализованых. И LUA (eLUA) и JavaScript (Espruino) и Python (в OpenPilot реализован) и т.д. Опять же это не готовое ПО. Скрипты требуют серьезной низкоуровневой прослойки доступа к периферии.Которую писать самому надо.
И, как я уже говорил, на сегодняшний день все! малые RTOS умеют твитать в интернет. Для этого есть общеизвестные lwIP и uIP.
И SSL для них тоже есть.
Все же хотелось бы услышать какое же реальное практическое приложение или инструмент для встраиваемой системы можно взять только из Линукса и которого еще нет под малые RTOS.antonkozlov
16.04.2015 14:49+3Фишка с modbus'ом не в том, что есть какая-то реализация, а в том, что она весьма конкретная (http://libmodbus.org/) и самое главное, исходный код для Linux и для Embox один и тот же. Мы так и разрабатывали свой веб интерфейс, сначала собрали modbus-сервер на хосте, который вместо управления GPIO делал printf. А затем перенесли modbus-сервер на Embox, заменив только GPIO часть.
Другой пример: httpd, один исходный код работает под Linux и под Embox.
Этот modbus сервер и httpd работают в составе системы на STM32. И там же ещё запускаются CGI-программы, которые генерируют контент, которые тоже можно просто скомпилировать на хосте и разрабатывать/отлаживать.
abondarev Автор
16.04.2015 14:56+2Безусловно libmodbus достаточно простой и может быть сделан без помощи осей и библиотек, но:
- Придется потретить время
- Новый код может содержать ошибки
- Собственный код нужно поддерживать
А если взять стандартную реализацию то всего этого можно избежать
По поводу Qt, ZeroMQ и других платформ, то же самое если ваш код уже написан под данную библиотеку, то переписать его можно и может это будет более эффективно, но все те же перечисленные проблемы.
И кстати можете пояснить почему Вы уверены, что Qt на STM32 не возможен? Если мы говорим об объеме памяти, то соглашусь, но если говорим о STM в внешней памятью, то вполне решаемая задача. Если Вы беспокоитесь по поводу отсутствия виртуальной памяти, то вот статья в которой описано как мы обходим эту проблему.
На ваше желание услышать реальное практическое приложение, у меня встречное предложение. Уточните какое приложение для Вас будет доказательством?
Indemsys
16.04.2015 18:11+1Моя мысль была в том, что не нужно Линукса и линуксоподобных сервисов операционки, чтобы иметь все то что вы имеете на STM32 в вашей ОС. И сил это потребует меньше.
Я не за то чтобы переписать что-то, а говорю о том что это уже сделано, написано, портировано без Линукса и POSIX-а.
И вряд ли вы найдете что-то готовое, вот прям под STM32 чтобы оно было только в Линуксе и больше нигде.
OneLady
16.04.2015 10:17+3Поздравляю с открытием блога! Так держать! :)
Буду ждать новых публикаций о Embox.
Big_Lebowski
А бывают архитектуры, когда RTOS является в некотором смысле гипервизором для OS более высокого уровня?
Тогда получается что основная функциональность (например, управление клапаном) будет находится на уровне RTOS, а свистелки — в OS более высокого уровня
CodeRush
Бывают, для семейства микроядер L4 существуют проекты L4Linux, L4Android и другие, позволяющие запустить ОСи более высокого уровня как процессы.
grossws
Был ещё RTLinux, который выполнял обычное ядро linux в качестве вытесняемого процесса.
abondarev Автор
Ну почему же был, он вроде бы еще живой и имеет свое применение. :)
grossws
Они не ушли целиком в VxWorks? Старого сайта нет, редиректит на Wind River'овский.
abondarev Автор
Возможно я что то упустил. Жаль если так.