Автор:
Антон Бондарев
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
В последнее время активно развивается тематика встроенных (embedded) систем, и многие крупные компании, такие как Google, Microsoft, Intel, вкладывают огромные ресурсы в исследования и разработки в данной области.
Взять, например, проект Microsoft по созданию специализированной ОС для умных домов homeos или процессоры от Intel для встроенных решений Intel Quark, а о различных исследовательских проектах от Google по робототехнике иговорить не стоит – они и так на слуху.
Подобные системы всегда имели свои особенности: ограниченность вычислительных ресурсов, различные процессорные архитектуры, порядок байт и многое другое. Все это накладывает отпечаток на процесс разработки встроенного ПО. И, несмотря на то что в последнее время для создания встроенных систем все чаще применяются принципы и технологии из области «обычных» десктопных систем, сам процесс остается специфичным. Поэтому считается, что порог вхожденияпри разработке системного и встроенного ПО очень высокий.
Для подготовки хороших специалистов в этой области на математико-механическом факультете СПбГУ организовали исследовательский проект по созданию ОС реального времени для встроенных применений Embox, в котором активную роль играют студенты.
Embox – открытая операционная система реального времени, поддерживает:
- шесть процессорных архитектур (x86, ARM, MIPS, Microblaze, SPARC, PPC);
- сетевой стек;
- несколько файловых систем (FAT, ext2/3/4, jffs2, nfs);
- несколько языков программирования (Java, Python, Lua, Lisp, C/C++);
- и применяется в различного рода встроенных и телекоммуникационных устройствах, например, маршрутизаторах, потоковых шифраторах, контроллерах управления светодиодами.
Кратко опишу проблемы, с которыми приходилось сталкиваться участникам проекта Embox, поскольку проект существует уже пять лет. Их было несколько.
- Во-первых, требовалось решение для простой отладки аппаратуры. Для этого было сделано минимальное окружение, позволяющее автоматически стартовать набор тестов, разработанных на языке C, а также очень легковесный shell, способный запускаться фактически на голом железе.
- Во-вторых, исходный код нужно было сертифицировать, а, значит, в дистрибутиве должны быть только те части, которые несут функциональную нагрузку. При этом код в неиспользованных ветках #if – #def конструкций не должен был быть представлен для сертификации. Для решения этого вопроса была разработана система сборки на основе специального языка описания модулей, которая позволяет избежать #if – #def конструкций и гибко задавать список используемых функциональных модулей и их параметров.
- В-третьих, результаты работы можно было бы использовать в научной и учебной деятельности, а, значит, проект должен быть открытым.
Основные проблемы, с которыми сталкивались разработчики при внедрении в различных областях, в том числе в робототехнике, телекоммуникации и АСУ-ТП, как и для многих встроенных систем, заключались в аппаратной составляющей, отсутствии железа на ранних стадиях разработки, ограниченных ресурсах системы, «дорогом» времени работы на реальном оборудовании и во многом другом.
Например, для запуска на роботах Lego Minstorm 2, который имеет 64к ОЗУ, пришлось многое умещать в эти скромные килобайты. А для того чтобы не разрабатывать кучу драйверов для всевозможных контроллеров, был придуман механизм использования BSP от производителей аппаратуры.
Кроме того, по мере роста проекта возникла проблема запуска открытого ПО на платформе Embox. И такой механизм с учетом особенностей встроенных систем был придуман и реализован в проекте.
Поскольку с ростом проекта поддержка корректной работоспособности функциональных модулей на всех возможных архитектурах и в различных конфигурациях становилась невыносимой, в проекте было внедрено автоматическое тестирование.
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
|