`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

ARM mbed OS (и пара полезных мелочей в качестве компенсации)

+77
голосов

Примерно год назад ARM опубликовала timeline выхода операционной системы mbed OS. И это уже было событием для самых разных индустрий – всё-таки «родная ОС» от производителя, лучше всех знающего свои архитектуры, это что-то, да значит. И вот mbed OS появилась. Пока только в бета-версии. Потому сразу никаких выводов «что этот факт может значить» делать не буду вообще, а сделаю краткий обзор – что это, чем интересно, что уже доступно.

mbed OS – нетривиальная операционная система, которую в ARM позиционируют как «ОС для IoT», и речь идёт о потенциально самой большой (если оценивать по численности инсталляций) части IoT – об оконечных устройствах, неисчислимых сенсорах и актуаторах.

Естественно, в ARM не ограничиваются только этой частью IoT, и полный технологический стек для реализации завершённых IoT-систем называют «mbed IoT Device IoT Platform». В более привычных для традиционных IT терминах mbed OS по сути является программным стеком, реализующим всю «клиентскую часть», включая безопасность и сетевые протоколы разных уровней.

Нетривиальность mbed OS (в её текущем состоянии) заключается в фундаментальной идее – это управляемая событиями (event-driven) система. Нельзя сказать, что такое решение уникально, и что mbed OS является единственным представителем event-driven архитектур. Сделаю короткое отступление, буквально несколько предложений о сути идей, лежащих в основе таких архитектур.

Понятийный аппарат: состояние (state) – «точка» в дискретном временном пространстве, полностью описывающая информационный «снимок» системы (или, если хотите, всех переменных в ней), событие (event) – это значимое изменение состояния. Классическим образцом event-driven архитектур являются конечные автоматы (FSM, Finite State Machines), которые технологически реализуются как угодно (даже полностью аппаратно) – от традиционного оператора switch() в бесконечном цикле до управляемой данными табличной структуры и шаблона проектирования State (рекомендую C-программистам этот замечательный и детальный обзор Адама Петерсена). Латентное принципиальное отличие управляемых событиями ОС от классических систем – однопоточность и отсутствие механизма диспетчеризации потоков или процессов (tasks scheduler). А уже это, в свою очередь, означает, что вся ответственность за принципиальную работоспособность системы в целом лежит полностью на программисте, и что о соблюдении фундаментальных для систем реального времени принципов речь вести можно только на уровне «прикладного ПО». Этот базис можно считать достаточным для дальнейшего обзора.

В отличие от многих RTOS с широким диапазоном разрядностей поддерживаемых архитектур, mbed OS создана исключительно для 32-битовых микроконтроллеров ARM, и, возможно этот факт стал основой выбора главного языка реализации – C++. Но язык реализации унаследованных высокоуровневых подсистем безопасности (например, разработанные в приобретённой ARM компании Offspark библиотеки PolarSSL) и даже таких важных абстракций, как сокеты (sockets), остаётся прежним, C. Так что в итоге получается «двуязычная embedded платформа», в которой почти вся низкоуровневая системная часть – объектно-ориентированная, на С++ (что само по себе весьма необычно).

Основной «навигатор» по исходным текстам всего проекта располагается в репозитории mbed-os. Надо отдать должное разработчикам ARM – уровень качества документирования проекта даже в этом его «сыроватом» и для «бета-» состоянии, весьма высок.

С высоты птичьего полёта вся «системная часть» ОС в текущей бета-версии состоит из настроенного над двухуровневым стеком абстракции аппаратных средств «диспетчера событий» (event manager), названного MINAR. Упомянутые два уровня абстракции образованы минимальными С-библиотеками HAL (Hardware Abstraction Layer) и использующими их C++ классами «драйверов». Несмотря на открытость исходных текстов, уровень HAL явно будет претерпевать достаточно серьёзные изменения (сейчас фактически есть две конкурирующих реализации, одна – "оболочка" над официальным "уровнем абстракции железа" ARM CMSIS) и не рекомендуется разработчиками для прямого доступа из пользовательского уровня, поэтому последний, уровень драйверов, умышленно «поднят» до объектно-ориентированного дизайна и языка реализации.

С точки зрения embedded-программиста, MINAR почти предельно прост, это по сути «переключатель» вызовов функций из заданной в теле программы очереди. Что очевидно означает – если управление из такой функции вообще не возвращено программистом в диспетчер, никакого переключения событий больше не будет вообще. Большинство embedded-программистов неизбежно писали что-то подобное «руками», обходясь без высокоуровневых объектно-ориентированных абстракций. И здесь кроется сразу несколько опасных деталей. Обманчивое слово «функция» может обозначать и метод класса, имеющего время жизни и область видимости. И если логика программы такова, что между переключениями видимость или существование объекта класса изменится – всю систему, в которую встроен вычислитель, вероятнее всего ожидает крах. Вторая очень большая сложность систем с таким принципом переключения задач – конечно же, согласование времён исполнения функций-событий. Это заслуживающая отдельного обсуждения тема из области практического программирования, здесь же стоит ещё раз подчеркнуть – mbed OS не является системой реального времени, но написанное для неё ПО можно разработать так, что оно будет соответствовать специфическим требованиям задачи.

Следует заметить, что MINAR не «окончательно единственное ядро» системы, а всего лишь «одно из возможных, работоспособное в текущем состоянии проекта». В планах ARM реализация полноценного ядра RTOS с вытесняющей многозадачностью (точнее, многопоточностью) в 2016 году, и защищённое ядро-гипервизор uVisor для высокоуровневых микроконтроллеров, имеющих аппаратные подсистемы защиты памяти.

Кроме диспетчера событий и уровня абстракции аппаратных средств mbed OS фактически традиционен и предлагает уровень абстракции сокетов с поддержкой Ethernet и 6LoWPAN интерфейсов (естественно, список физических контроллеров пока очень ограничен), Bluetooth LE стек (только для контроллеров компании Nordic Semiconductor), стек SSL/TLS безопасности (популярные библиотеки PolarSSL), стеки некоторых высокоуровневых IoT-протоколов (до сих пор рано говорить о существование «единого стандарта в IoT», потому можно считать эту часть системы «одной из возможных»).

В проекте довольно интересна собственная технологическая поддержка. Своя система компиляции-сборки yotta (на базе популярной Cmake), своя поддержка регрессионного тестирования etc. В целом, параллельно с ПО для целевых платформ, в ARM создают и свой технологический стек.

Итак, ARM делает очередную заявку на «полное замыкание» мира её интеллектуальной собственности (IP) на себя, вплоть до технологического кросс-инструментария. Заявка не первая (уже в 2012 году у ARM была операционная система в составе CMSIS 3). И, похоже, этот процесс оказался весьма непростым (если судить по срокам и наблюдаемым результатам). Для основанных на IP ARM реальных микросхем есть десятки конкурирующих проверенных временем и опытом ОС, и ARM нужно сказать разработчикам какое-то такое «волшебное слово», которое сделает новую систему настолько привлекательной, чтобы оправдать затраты на её освоение и поддержку в своих разработках. Пока, по моему скромному мнению, этого слова не слышно. Проект безусловно интересный и заслуживающий внимания, но этого мало.

А теперь, в качестве компенсации за всё это – немного очень полезных маленьких утилит.

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

И ещё одна «игрушка» в копилку всякого полезного – высокоинформативный ping с «человеческим лицом». О ней ничего даже не буду рассказывать, по описанию всё понятно. Тоже очень приятная утилита, но не настолько «прилипчивая», как yank.

Откланиваюсь.

+77
голосов

Напечатать Отправить другу

Читайте также

Ссылка на "этот замечательный и детальный обзор Адама Петерсена" битая

Спасибо, исправил (ссылка на pdf с пробелами в имени, и, видно, что-то в предыдущий раз пошло не так)

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT