company_banner

Содержимое Intel IOT development kit

    В феврале я писал о сборке Yocto для Galileo gen1, которая несколько облегчает разработку для Galileo. С тех пор прошел почти год, и у Galileo появились последователи — Galileo gen2, Edison. Про Edison (уже два месяца в продаже) надо писать отдельно, этот же пост об Intel IOT Development Kit.

    image

    Из железок на моем рабочем столе (извините за беспорядок) он совместим с Galileo gen1, gen2 и Edison.
    С декабря 2013 по октябрь 2014 я был архитектором этого продукта, и сейчас я опишу, как продвигался проект, что уже получилось, и что запланировано.

    Зачем вообще мы все это начали? «Родная» (от создателей платформы) Yocto сборка для Galileo должна умещаться в 8 MB, и поэтому использует uClibc. Даже если загружаться с 8GB SD-card. Также она заточена, в основном, для программирования только посредством Arduino IDE. Однако Galileo — это не только Arduino Uno совместимая плата, но и компьютер, сравнимый с персоналкой пятнадцатилетней давности по производительности, но с поддержкой современной периферии. Поэтому очень логично максимально облегчить его программирование как Linux компьютера с PC и Arduino периферией.

    Поэтому мы начали с создания Yocto 1.6 сборки, включающей средства разработки, библиотеки и драйвера популярной периферии. «Из коробки» можно писать на C/C++, Python, Node.JS, shell. Образ диска весит всего 200 MB, но есть еще многогигабайтный репозиторий для opkg, из которого можно проинсталлировать еще несколько тысяч нужных пакетов (Если у вас найдется достаточно большая SD-Card для /root файловой системы). По сравнению с февральской альфой, текущий билд грузится в 3 раза быстрее, несмотря на кучу новых сервисов в загрузке. А всего-то systemd вместо sysvinit.

    Для того, чтобы сохранить совместимость с Arduino IDE, образ диска включает и uclibc, и eglibc. К сожалению, поэтому не получается из скетчей достучаться до всяких полезных библиотек, и приходится использовать IPC.

    Если для периферии РС библиотек хватает, то для большинства простых и дешевых сенсоров/актуаторов есть только Arduino или mbed библиотеки. Их пришлось бы портировать, так как в драйверах продвинутых сенсоров встречается много кода, специфичного для платформы. Поэтому мы решили изобрести велосипед, и опубликовали на Github два полностью открытых проекта с MIT лицензией — libmraa и UPM. libmraa написана на C, а UPM на С++ (нативном C++ aka С c классами). Они обе при сборке также генерируют библиотеки, который можно использовать при программировании на Python и Node.JS.

    libmraa предоставляет интерфейс к Galileo/Edison пинам, которые можно использовать как GPIO, ADC, PWM, I2C, SPI, RS232. Это не драйвер, все происходит в usermode (прощай, риалтайм!). Как и скетчи Arduino, на Galileo gen1, gen2, Edison она работает поверх /sys/class/* устройств. То есть это был бы простой wrapper, если бы привязка этих устройств к Arduino пинам была однообразной и тривиальной. К сожалению, каждая из перечисленных платформ имеет свои особенности и ограничения в области ввода-вывода. Например, подробнее о Galileo gen2 можно почитать здесь. Скоро появится поддержка Minnow max и Baytrail NUC.

    UPM работает поверх libmraa и реализует логику сенсоров/актуаторов. Таким образом, в коде сенсоров/актуаторов нет никакой логики, связанной с платформой, на которой они работают. (Сравните с Arduino, где глаза рябит от #ifdef UNO/DUO/TRE.) Пока UPM поддерживает всего штук сорок устройств, но наша команда с помощью сообщества, надеюсь, за год еще под пару сотен других напишет.

    Помимо обычных средств программирования, в образе диска IOT devkit для Intel Galileo также содержится одно не совсем обычное. Румынский стартап Wyliodrin разработал среду программирования на основе Blockly, облегчающая графическое программирование сенсоров/актуаторов на Intel Galileo, Edison и Raspberry Pi. Ребята из Wyliodrin и их специальное предложение для владельцев Intel Galileo достойны отдельной статьи.

    Также в сборку вошел node.js демон и API, упрощающий работу с Intel IoT analytics cloud. Вообще cloud backend для IoT — сейчас жутко модная тема, и многие известные вендоры уже анонсировали (Azure Intelligent Systems Service) или выпустили свой вариант. Я протестировал несколько, и данные с сенсоров, подсоединенных к Galileo или Edison легко посылаются в клауд для дальнейшей обработки. Конечно, Intel IOT Analytics сейчас использовать проще всего — он уже встроен в IOT devkit, есть примеры.

    Выше я много раз упоминал наш образ диска для Galileo — часть IOT devkit. У некоторых читателей могло возникнуть два вопроса: какие еще части есть в devkit, и что насчет Edison?

    Кроме образа диска, репозитория пакетов opkg, cloud сервисов IoT Analytics и Wyliodrin, мы включили две вещи, облегчающие разработку на хосте (все-таки разрабатывать большие вещи непосредственно на Galileo или даже на Edison может быть не совсем комфортно). IOT devkit поддерживает Intel XDK для разработки на Node.JS и специальный билд Eclipse под Linux, Windows и Mac OS, сконфигурированный как host для разработки на C/C++.

    Кроме того, IOT devkit можно получить в осязаемой форме, поучаствовав в хакатоне (например, скоро один будет проведен в Москве), некоторых академических программах, или просто купить Galileo gen1 kit или gen2 kit.

    По поводу второго вопроса все просто: команда, создавшая платформу Edison, не была ограничена необходимостью использования uClibc, и собрала неплохой образ диска для Edison на основе Yocto 1.6.1. Они включили в свою сборку libmraa и UPM и обеспечили совместимость со всеми плюшками, которые я перечислил выше — XDK, IOT devkit билд Eclipse, IoT analytics, Wyliodrin, и Arduino IDE, совместимое со всеми библиотеками на таргете.

    Во время осеннего Intel Developer Forum мы открыли сайт devkit и форум. Но у Galileo и Edison уже есть свой сайт и форумы, поэтому получилась некоторая путаница. Часть информации есть только на этом сайте мейкеров, часть — только на нашем, а часть дублируется. Например, недавно про devkit написали в Dr Dobbs, но мне показалось, что автор статьи не смог до конца разобраться в этой путанице. Надеюсь, читатели этой статьи разберутся лучше, чем редактор старейшего журнала для программистов.

    На сайте мы выложили для скачивания образ диска и Eclipse IDE и назвали все это IOT devkit 1.1 beta. Beta потому, что у нас в команде был только один part time QA инженер (но мы все сами кушали свою собачью еду, так что очевидные баги подмели). Через пару месяцев планируем от обидного слова «beta» избавиться, попутно исправив все баги, добавив поддержку новых интересных сенсоров, добавив в Eclipse IDE визард для создания новых проектов, и учтя тонны пожеланий участников хакатонов.

    Темы для флейма в комментах, которые автор будет особенно рад поддержать:
    1. Кому нужен ваш Yocto, надо было портировать Ubuntu/Debian/Gentoo/Slackware!
    2. Зачем столько много опций/языков программирования/IDE, надо было оставить что-то одно, но сделать это хорошо.
    3. Почему вы перешли на systemd, на embedded платформе все должно быть в легко редактируемых shell скриптах.
    4. Почему нет прямо из коробки Java/Mono/Haskell/Brainf*&ck?
    5. У меня не работает DHT22 сенсор X, которому нужно посылать микросекундные импульсы в точные временные отрезки — а Arduino Uno это умеет.
    6. Я сделал pull request в UPM, добавив поддержку моего любимого сенсора влажности почвы в цветочном горшке, но злой github user arfoll не делает коммит.
    7. Ну и чем это лучше RasPi/BBB/etc/etc/etc?"
    8. Carthago delenda estПочему даже в Quark не отказались от устаревшего набора x86 инструкций, даешь еще один RISC микроконтроллер!
    Intel
    175,06
    Компания
    Поделиться публикацией

    Комментарии 19

      0
      Когда вы говорите про загрузку «в три раза быстрее» — это сколько в цифрах? Если не использовать всякие хаки, через сколько секунд запустится мое юзерспейсовое приложение?

      Я попробовал Yocto на виртуалке — показалось, что там все очень неторопливо относительно других около-embedded систем (сравниваю с OpenWRT, хотя, конечно, весовая категория разная). Однако допускаю, что я просто не умею его готовить.
        0
        К сожалению, никаких рекордов — просто с sysvinit было медленно, больше 20 секунд. Но openWRT специализированный дистрибутив, а мы включили по умолчанию кучу демонов на Node.JS — для клауда, графической разработки, XDK. Впрочем, можно выключить и получить еще секунду. Плюс я не считал бутлоадер который тоже 3 секунды вместе с грубом.
        +1
        Иду на хакатон, особенно интересует
        У меня не работает DHT22 сенсор X, которому нужно посылать микросекундные импульсы в точные временные отрезки — а Arduino это умеет.

        У меня датчики опрашиваются по i2c, смогу ли я «заюзать» библиотеки от arduino и чтобы всё было реалтайм. Спасибо.
          +1
          Проблемы с RT обычно с датчиками, которые работают с GPIO bit bang. I2C обычно работает. Советы:
          1. на galileo bus N = 0, на edison = 6
          2. Выясните адрес устройства заранее, енумерация может не сработать.
          3. Если повиснет — cold reboot.

          ардуино библиотека может работать, а может и нет. realtime точно не будет, но i2c датчики обычно как раз скрывают за своим микроконтроллером необходимость hard RT
            0
            Завтра meetup, надеюсь более подробно выясню, что из себя этот Galileo представляет
              +1
              Удачи на хакатоне. И да, если критичен realtime — захватите с собой и Uno, которую можно повесить как периферию на galileo/edison — я видел на хакатонах людей, которые так делали.
          0
          ответил выше
            0
            И все-таки, почему не правоверный debian?
            Тоже иду на хакатон, придется потратить значительную часть времени на освоение новой платформы.
            И второй вопрос, есть ли возможность погонять OS на qemu? Я получаю сообщение о не поддерживаемых инструкциях процессора.
              0
              Главное в дебиане — десятки тысяч пакетов и dpkg. Но они все равно в-основном скомпилированы на на 586, то есть придется пересобирать. В мейнлайн дебиана пока попасть не получится, т.к. патчи для ядра, необходимые для загрузки, пока не в апстриме.

              Не пробовал но странно, там все скомпилировано под 586.
              +3
              Принимаю предложение немного похоливарить, тем более от разработчика.
              1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
              2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
              3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
              4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
              5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.

              Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
              Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
              Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
                +2
                Спасибо огромное за длинный, годный комментарий. Я переведу и покажу коллегам в IOTG и NDG. (Можно будет как-нибудь развиртуализоваться, как я буду в очередной раз в Деггендорфе навещать, как я догадываюсь, вашего работадателя на букву C или K)

                Буду отвечать по очереди, постепенно. Баг с локом — не единственная причина отсутствия Дебиана. Еще он не так страшен, как вы описываете. Там не постоянные сегфолты, а редкие и неожиданные. Хрен редьки не слаще, конечно. Главная проблема скорее организационная — пока нет в quark patch в апстриме, мейнтейнеры debian не будут рады такому таргету. Ну и на 586 все перекомпилировать действительно плохо.
                  0
                  Пожалуйста, хорошо, что сейчас можно вот так просто взять и написать непосредственно разработчикам. Будете в офисе Congatec Deggendorf — заходите в отдел R&D, буду рад познакомиться лично.

                  Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.

                  Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.

                    +1
                    К сожалению я уже в другой команде, но даже раньше я отвечал за содержимое git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/ — все открыто в гите, но начинает грузиться после груба.
                  +1
                  >Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО.
                  к сожалению, формат нашего общения не предрасполагает к обсуждению причин распространенности такого мнения, но при личной встрече (if ever) обсудим.
                  > разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная.
                  У Intel embedded продуктов есть огромный плюс, но он же и минус. Практически все они — суть доработки dekstop/mobile/server процессоров-чипсетов. Это позволяет использовать мощный R&D и manufacturing process, но поэтому нет такого фокуса только на этот сегмент, как у компаний, у которых он единственный. Поэтому приоритет фич, нужный для embedded — далеко не первый.
                    +1
                    >4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта >сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме >отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если >все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
                    вычислительное ядро внутри Quark начинался как scunkworks/research проект, и во-многом использовался 486, в который удалось поместить 586 инструкции, но 686 уже нет. Как и у Atom с Core есть roadmap, в котором ваши замечания к первому представителю этого семейства CPU учтены.
                    С i686 на i586 — именно пересобрать, и результирующий бинарник работать будет хоть на Xeon'е. А с i686 на ARM/MIPS — это уже портировать. Может повести, и хорошо написанная софтина портируется простой перекомпиляцией. Но везет не всегда.
                    +2
                    А всего-то systemd вместо sysvinit.

                    А вы не думали о OpenRC? А то меня пугает этот bloatware ну и OpenRC вроде приятнее допиливается/портируется.
                    Как минимум для embedded это должно быть важно.
                      0
                      О, вопрос номер три. Да, лично я предпочитал OpenRC когда мы обсуждали это в команде, но остальные убедили меня, что раз у нас не совсем embedded платформа, а почти PC, то можно сделеть вид, что мы обычный дистрибутив, а они все перешли на systemd, поэтому скоро пользователям станет привычнее, и решения проблем будут гуглиться.
                        +1
                        а они все перешли на systemd

                        Прям соль на рану… :( везде в том числе на ноутбуке у меня gentoo, а на ней OpenRC, eudev…
                        Вот почему маркетинг побеждает здравый смысл? :(

                        PS простите, просто крик души, скоро если у тебя не systemd то и линуксом пользоваться нельзя будет, прям дискриминация.
                      0
                      Спасибо за обзор!
                      Не подскажете новичку — смогу я работать с этим набором, имея обычный компьютер (на Windows или Linux), без Arduino или Edison?
                      Интересно, т.к. разбираюсь с платформой ThingWorx, и хочется с железом поиграться.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое