Intel Quark. Лучше поздно, чем никогда

Выход нового SoC процессора Intel Quark и первых систем на его базе заставили сжаться мое сердце и предаться воспоминаниям. У каждого инженера-системщика был любимый проект, даже детище, родиться которому и выйти в свет так и не было суждено по разным причинам.
Хочу немного рассказать о своем подобном проекте и порассуждать, что было бы, если б тогда мне были доступны сегодняшние технологии типа Quark. Также хотелось бы спросить Хабросообщество: что бы вы смогли реализовать, имея выбор из сегодняшних систем. Ну а комментарии к этому посту — самое подходящее место для холивара ARM vs. x86, так как Intel вступает на опасную территорию, где давно правят контроллеры с RISC-ядрами от ARM и Atmel. Но тогда просьба сравнивать не просто железки (мегагерцы, килобайты, и милливатты), но рассматривать в комплексе с программной экосистемой и в контексте конкретного применения контроллеров.

Итак, лет десять назад, я работал в одной маленькой психиатрической научно-исследовательской медицинской фирме, разрабатывающей сложное диагностическое оборудование. Наилучшей особенностью этой фирмы, по моему мнению, было то, что некоторым инженерам давали возможность помечтать, пофантазировать несколько месяцев, и при этом не переставали платить зарплату, несмотря на сложные экономические условия. Судя по тому, что фирма и сейчас живет и процветает, мой уход не подорвал ее способность стоять на ногах и успешно бороться за бутерброд с маслом на своем рынке с такими монстрами как GE Healthcare, Philips и Hewlett-Packard. Прежде всего, это произошло благодаря отличным и талантливым инженерам, которые остались там работать и воплощать свои фантазии.



Я поработал и системным разработчиком, и прикладным программистом чуть более трех лет, принеся свой опыт из «железочного» прошлого и много почерпнув от коллег в программировании. R&D фирмы составлял отдел системных разработчиков (6-7 человек, выполняющих дизайн электронной начинки и низкоуровневое программирование, в основном контроллеров и сигнальных процессоров), отдел прикладных программистов (10-12 человек, пишущих GUI для рабочих станций на Windows, внедряющих алгоритмы обработки данных и формирующих пользовательскую инфраструктуру), и мозг компании — отдел алгоритмистов (3-4 человека, взаимодействующих с наукой, медициной, пишущих алгоритмы на математических симуляторах – они вообще не программисты).

Не вдаваясь в подробности обо всем широком ассортименте разрабатываемой и выпускаемой продукции (приборы для энцефалографии, полисомнографии, миографии, кардиографии, и многого другого), опишу проект, в котором я трудился и прототип нового поколения, для которого мне позволили поразрабатывать на бумаге — свою «лебединую песню» в компании. Данным проектом был комплекс для электро-энцефалографического исследования, отличительной особенностью которого было то, что блок сбора информации был автономным и компактным, сейчас его назвали бы мобильным. Для того времени это было вполне революционное решение, и даже далеко не все мировые производители медоборудования имели такой в своем арсенале. Основное преимущество состояло в том, что пациент, которому снимают электро-энцефалограмму, не привязан к рабочей станции шлейфом проводов, может свободно передвигаться или спать. Особенно востребовано такое решение среди маленьких пациентов, которых, в виду некоторых болезней, тянущиеся куда-то от головы провода приводили в непрекращающуюся истерику, что сильно осложняло обследование.



Таким образом, требования к блоку сбора первичных данных были довольно жесткие и противоречивые:

• Минимальный вес и размер пылевлагонепронепроницаемого корпуса (без шлейфа и датчиков), в идеале до 200-250 грамм, и размером с мобильный телефон (да, телефоны в 2004-м году были побольше, чем сейчас)
• Возможность автономной работы до нескольких часов, в идеале часов 12.
• Постоянная беспроводная коммуникация с рабочей станцией врача-диагноста, с пропускной способностью канала передачи данных до 0.5 Мб/c, а в идеале до 2-3-х Мб/c, с расстоянием устойчивой связи до 10 м.
• Возможность группировать устройства в одноранговую сеть, а так же безопасно и помехозащищенно управлять группами устройств, зарегистрированных в локальной сети рабочей станции.
• Первичная цифровая обработка сигналов 19 и более каналов в режиме реального времени DSP-процессором – фильтрация, снижение шумов, сегментация и упаковка данных для передачи.
• Возможность сохранения суточных данных мониторинга на съемный носитель, а также возможность считывания данных на станцию без разбора устройства для съема этого носителя.
• Система управления, коммуникации, конфигурирования, передачи и хранения данных, контроля заряда, сигнализации. Тоже в реальном времени. Работа для контроллера или процессора общего назначения.
• Ну и еще такая мелочь, как сертификация Росстандартом и разрешение Минзрава для использования в качестве медицинского оборудования.

Как водится, первый прототип был построен на базе уже существующих решений – была использована наработанная схема на основе DSP от Analog Devices (как наиболее трудоемкая часть устройств) с DRAM, EEROM и генератором тактовых импульсов, которая и раньше использовалась в стационарных приборах, а вся остальная обвязка уже навешивалась на нее:

• Контроллер карты памяти CF
• Контроллер USB
• Модуль ввода звука
• Датчики ускорения
• Система световой/звуковой индикации
• Контроллер заряда
• Bluetooth-интерфейс со своим контроллером (единственно возможное на тот момент беспроводное решение, удовлетворяющее требованиям)

Это был монстр, во всех смыслах, на ускоренную разработку которого (с целью завоевания рынка) были брошены лучшие силы фирмы, и это заняло почти год — довести продукт до первых рабочих образцов. Но, в тоже самое время, этот первый продукт на базе прототипа «сделал маленькую революцию» в индустрии, и она обещала быть еще больше, если ли бы мы смогли спроектировать принципиально новую систему, которая не требовала бы таких неимоверных усилий по подключению всей этой периферии к DSP-процессору и управлению всей этой цветомузыкой с помощью программы, написанной на низкоуровневом языке. Да, да, все то, что делается в обычных системах с помощью драйверов, во встроенных системах управляется из основного цикла программы. Вы можете себе представить стек коммуникационных протоколов для Bluetooth, поддержка файловой системы, либо алгоритм оптимизации записи адресов flash-памяти, написанный с нуля на ассемблере, или на embedded С? Нет? Добро пожаловать в мир встроенных устройств!


(картинка взята специально от другого энцефалографа, но в целом она отражает требование отрасли)

Стало ясно: чтобы развиваться дальше, нужен System-on-Chip в основе устройства, который бы своим CPU и интерфейсами решил все описанные задачи без экстремально трудоемкого программирования. В этот момент меня, оторвав от работы в почти законченном первом прототипе, запустили в свободное плавание: анализировать рынок, сравнивать разные решения от микроконтроллеров до готовых мини-компьютеров, и самое главное, понять, как можно переиспользовать уже существующую программную инфраструктуру, open source или проприетарную. Так как оказалось (сюрприз!), что склепать устройство в железе – дело одного месяца, а наполнить его жизнью – нужно очень много и упорно программировать. А чтобы эти ожившие устройства соединить в сеть, нужно вообще совершить чудо. В тоже самое время весь остальной отдел системных разработчиков искал в другом, более консервативном направлении, то есть, не сильно отходя от концепции «DSP с функциями управления».

Сложно вместить в одной статье обзор, какие варианты были рассмотрены (думаю, что все возможные) и что учитывалось при выборе, так как помимо основного устройства нам требовалось заложить системную базу для других изделий, которые со временем тоже были бы перенесены на нее. Некоторые из перспективных устройств требовали наличия дисплея, что резко меняло подход, и поворачивало вектор поиска от контроллеров в сторону SoC или даже мини-компьютеров, для которых традиционно существует достаточно широкий выбор и операционных систем, программных стеков, и драйверов. Некоторые устройства были довольно просты, чтобы использовать там микроконтроллеры, но с мощной периферией, так как они должны были тоже взаимодействовать и с рабочими станциями, и с диагностическим оборудованием. Например, система стимуляции отклика у пациента, этакий набор свистоперделок световых и звуковых стимуляторов, активация которых по заданному алгоритму при определенных заболеваниях (той же эпилепсии) вызывает в мозге у пациента определенные волны, которые регистрируются энцефалографом еще до проявления приступов. Раньше для таких стимуляторов использовался дополнительный PC. С ним и производилось взаимодействие (подготовка, синхронизация) основной станции. А теперь представьте, сколько работы необходимо проделать в плане коммуникационного стека, если построить такое устройство на простом микроконтроллере.


(так выглядит фото-фоно-стимулятор на стойке, жестко привязанный к рабочей станции)

Естественно, мои пути поиска пересеклись с аппаратными решениями на базе х86, как наиболее перспективными в плане оцененной трудоемкости на разработку софта (простите меня за этот жаргонизм). Про ARM, вернее про программную экосистему для него, в то время еще не слышали. Однако, имеющиеся индустриальные платы с пассивно охлаждающимся i486-м процессором (пассивно-охлаждаемых Pentium не существовало) были все же такими огромными и потребляли так много (до 12-15W), что об их применении не могло быть и речи.



И тут на рынке появился знаменитый XScale PXA255, SoC с 400 MHz ядром ARMv5TE от Intel (StrongARM), имеющий на борту все, что требовалось из железа и даже больше. Системные платы для него поставлялись различными производителями, а так же сопровождались базовым набором стартового софта: минималистичный Linux c BusyBox, с драйверами, IP стеком, и стеком протоколов для Bluetooth. Нам оставалось только присоединить к нему на шину наш основной модуль-поставщик данных DSP-процессора и «всего лишь» написать для него драйвер. Был ли у нас опыт написания драйверов под ARM? Нет, конечно. Ну, правда, оставалась еще одна мелочь – разобраться с новой фичей Linux ядра 2.6 — возможностью вытеснения задач для поддержания «мягкого реального времени» системы, но это было бы уже вторым этапом, так как огромное количество памяти на борту и процессорные возможности позволяли паковать данные на лету, и требования к жесткости реального времени снижались.Кроме того, мы рассматривали возможные «готовые решения» от различных Embedded-Linux вендоров до MontaVista Linux и QNX Neutrino.



Для лучшего ознакомления с программной экосистемой для XScale я срочно выехал для участия в IDF, который тогда еще проводился в Москве, и стал приставать к инженерам Intel, выясняя все возможные подробности относительно программной поддержки со стороны Intel Software Services Group. Каково же было мое разочарование, когда кроме как нескольких утилит для разработки пользовательских приложений (под Windows CE!) Intel ничего не предлагал. Ну, почти ничего. Позже, где-то глубоко в недрах тогдашнего интеловского web-сайта, который представлял из себя свалку драгоценных статей и материалов, я выудил Linux-based software kit, который был еще более ограниченным, чем то, что предлагали за деньги производители модулей – только BusyBox и кросскомпилятор. Видимо, этот кит и был ими взят за основу.

Таким образом, я узнал, что Intel важны только ODM’ы, в частности Dell, Acer, Compaq, которые допиливали наперегонки свои PDA под Windows CE, а мелкие производители мобильного оборудования вообще не представляли интереса. Нет, конечно, с моей стороны была отчаянная попытка слепить на коленках прототип и предоставить хоть какие-то результаты, но ценовая политика относительно плат разработчика StarterKit (направленная на тех же Microsoft, Dell и прочие) просто убивала на корню всю идею.

Тем временем отдел системных разработчиков получил первые платы с OMAP от Texas Instruments. Я уже не помню, какая точно это была серия, кажется 5912, но он содержал в себе DSP-процессор серии C55xx – один из лучших сигнальных процессоров с фиксированной точкой на рынке, и управлялся 204 MHz ядром ARM926EJ-S. Плата и StarterKit тоже были недешевые, но знаете, что растопило сердце нашего руководителя, и по совместительству председателя научного совета? Несколько тысяч долларов были с легкостью выделены за то, что с платой поставлялся Code Composer Studio for OMAP – полный программный набор для эмуляции, разработки real-time приложений для DSP и ARM-процессора на C/C++, с кучей библиотек, драйверов и блекджеком JTAG-эмулятором.



Платформа была идеальна. То, что нужно с аппаратной точки зрения: отличный DSP, экономный CPU общего назначения и куча периферии. И мечта системного программиста – полный набор для эмуляции, разработки и отладки. Работало ли это как написано в даташитах? Нет! Железо, в основном, работало, но как-то не всегда предсказуемо. Софт же (CCS) был написан китайцами по аутсорсинговому контракту, студия постоянно падала, а драйвера не работали так, как положено и их приходилось переписывать. Заняла ли в целом эта работа столько же времени, сколько выполнялась бы в случае использования XScale? Думаю, примерно, да. Но первоначальный старт был намного более стремительным и успешным с решением от TI.

Однако, насколько мы знаем, несмотря на политику TI намного более долгосрочной поддержки своих аппаратных решений и дальнейшее развитие платформы OMAP, компания отказалась от планов сыграть решающую роль в мобильном рынке, рискуя проиграть более дешевым и менее совершенным в техническом плане платформам. Intel тоже недолго продержалась, продав XScale-бизнес компании Marvell. Что же делать небольшим компаниям, разрабатывающим свои компактные, носимые, возимые и прочие мобильные устройства? Мне думается, что если позволяет форм-фактор, то есть размеры и вес, то нужно делать максимально универсальные решения с использованием стандартных средств разработки, в том числе и открытых (а может даже и предпочтительнее).

И я позволил себе помечтать, как бы выглядела система, имея мы в распоряжении сегодняшние аппаратные возможности, но помня о финансовых и ресурсных ограничениях небольшой фирмы. В качестве DSP несомненно взял бы процессор от TI, например, сегодняшняя серия C6204. С шиной PCI нам чип не нужен, так как она все равно не совместима с PCI-E, а вот Expandable Bus, наверное, возможно прикрутить (хотя это потребует дополнительных усилий). Да, у TI есть процессоры KeyStone с ARM-ядром, но мы это уже проходили: имея в наличие разработчиков системы и Windows-программистов приложений для рабочей станции, будет непозволительной роскошью еще набирать людей, либо заставлять системщиков писать драйвера и систему управления для ARM. Хотя, насколько я знаю, мои коллеги пошли именно по этому пути, и исключительно потому, что уже набили шишек наработали опыт программирования ARM-ядра процессора.



Далее, по моему мнению, системой должен управлять универсальный модуль с развитой периферией, для которого существуют и есть огромный выбор open source приложений и средств разработки, а программистам не нужно изучать еще одну микроархитектуру и язык ассемблера (все-таки, они не с DSP asm знаниями родились, и вышли из среды старого доброго x86). А если еще и производитель процессора добавляет свой стек инструментов, то это вообще было бы отлично. Система должна начать работать out-of-box, а разработчики коммуникационного софта писать свои слои, не дожидаясь появления железки. Вопрос разработки компонентов беспроводной связи вообще не должен возникать. SoC на x86-совместимом CPU подходил бы для этого идеально, если бы х86 были контроллерами, а они ими не были никогда. И тут появляется Intel Quark. Да, сейчас он далеко не идеальный контроллер. Да, (построенный на 32 нм) пока еще потребляет около 2W в пике производительности. Но посмотрите с другой стороны (на спецификации):

• Есть уже Edison – Quark испеченный на 22 нм технологии. И это не новогодние бредни пьяных маркетологов, как некоторые товарищи пытались в комментах пошутить. Intel c такими анонсами не шутит, тем более его CEO, объявляя новости на Consumer Electronics Show 2014.
• Чип поддерживает C0-C2 CPU power states, и S0, S3, S4 power states для системы. То есть он не будет потреблять 2W все время, а в основном в период упаковки и передачи данных.
• У Intel есть roadmap для семейства контроллеров Quark (пока не опубликованный, но, как говорится, stay tuned).
• Ядро Quark является масштабируемым, то есть него не нужно переразрабатывать заново при переносе на новую, более экономичную технологию.
• 32-битное 400 MHz ядро с Pentium ISA, контроллер памяти DDR3 с 800 MT/s, быстрая e-SRAM память для системы, PCI Express c пропускной способностью 2.5 GT/s. При желании и энергетических возможностях на таком ядре можно даже обработку регистрируемых сигналов производить, например для логирования или сигнализации критических состояний в мобильном кардиографе.
• Периферия: в системе есть 10/100 Ethernet, USB 2.0, Wi-Fi, контролер SD-карт, ну и самое интересное контроллер I2C и 16 GPIO портов, 6 из которых работают, даже если система спит в S3-состоянии. Просто грандиозные возможности по подключению различных датчиков и сенсоров, которых в специальных устройствах обычно в изобилии.

Конечно, есть определенная функциональная избыточность в модульном построении устройства: потребуется двойной набор DRAM и EEPROM регуляторов напряжения. Хотя надо отметить, что львиную долю места в устройстве все равно занимает не системный модуль, а батарея и аналоговый модуль с трансформаторами, многоканальными операционными усилителями и АЦП. Но взамен мы получаем практически независимые части проекта, переносимые от одного функционального устройства к другому без существенной переработки, и разрабатываемые разными командами почти асинхронно. Имея в распоряжении готовый модуль управления, в свое время, мы могли бы выпустить изделие на за год, а за каких-нибудь три-четыре месяца. Таков перспективный цикл выпуска обновленных модульных устройств.


(три модуля, из которых можно построить прототип мобильного электроэнцефалографа)

И самое главное, Intel наконец-то сопровождает свои новые платформы набором инструментов для разработки, отладки и оптимизации. Не будем брать в расчет вариант модуля с расширенным температурным диапазоном и идущий в комплекте с ним WindRiver Linux и VxWorks. Эти наборы предполагаются для использования в индустриальном секторе, в устройствах с повышенной оказоустойчивостью, и скорее всего стоить будут немало.

Board Support Package для референсного модуля Intel Quark SoC X1000 сопровождается пропатченным для Quark Linux (Yocto), набором для отладки ядра OpenOCD с gdb или Eclipse, поддерживающих пару JTAG-железок. Насколько я знаю, пользуясь инсайдерской информацией, на Mobile World Congress ’14 в Барселоне будет представлен более широкий набор системного софта, который должен еще больше облегчить старт работы с модулем. В помощь прикладному разработчику Intel предлагает комплекты инструментов как для обычных Intel Core процессоров, так и для SoC, например Atom-based. Новая Intel System Studio 2014 (ISS) уже вышла в beta-версии и в добавок к BSP и огромному количеству open source инструментов, мы получаем кросс-компилятор C/C++, JTAG отладчик, библиотеки производительности, инструменты удаленной профилировки и проверки корректности пользовательских приложений.

Еще пока рано о чем-либо заявлять, но мне очень хочется, чтобы в этот раз Intel не недооценила важность системного софта и прикладного инструментария для своего контроллера, и ISS полностью поддержала Quark-процессоры, как это принято для всех остальных семейств от Intel Atom до Xeon Phi. А сообществу разработчиков и энтузиастов хочется пожелать не сбрасывать со счетов первую попытку Intel войти в мир «больших» контроллеров (в мире микроконтроллеров Intel уже сделала серьёзный вклад) и успешно воплощать свои инженерные фантазии – сегодня для этого намного больше возможностей.