Embedded systems: что это? Коротко про встраиваемые системы
Embedded программист — это уникальный специалист по работе со встраиваемыми системами управления приложениями в реальном времени. Данные системы (Embedded systems) состоят из 3-х основных вещей:
Решение поставленных задач на прикладном уровне. В этом случае нужно просто найти эффективные методы и инструкции без их детальной разработки.
Само программирование. При этом необходимо внедрять все полученные решения из прикладного уровня и корректировать, беря во внимание аппаратное обеспечение устройства.
Реализация. Когда вся команда, участвующая в разработке, выполняет все сформулированные требования к продукту, такие как соблюдение точной функциональности, защищенность и надежность в эксплуатации, точные технические характеристики и др.
Embedded System — специальная система подобранных аппаратных и программных компонентов, которая отвечает за точное выполнение приложением всей возложенной на него функциональности. Часто такие системы разрабатывают для конкретных приложений или устройств. Embedded-программист — это специалист, который разрабатывает, тестирует и обслуживает эти системы.
Embedded system — что это?
Embedded System — это системы, которые выстраиваются на уровне микропроцессоров и микроконтроллеров. Они отвечают за какие-то специальные функции приложения или устройства и являются частью более крупных систем приложения, а не самостоятельной частью.
Где используются Embedded System?
Embedded System применяются во многих областях человеческой жизни. Так как IT-сфера постоянно развивается, то и применение встроенных систем также расширяет свою сферу деятельности. На данный момент Embedded System можно найти в:
бортовом компьютере автомобиля;
системах безопасности и сигнализации;
Как работают Embedded System?
ASIC — интегральные схемы;
FPGA — программируемые логические матрицы;
прочие компоненты, предназначенные для наладки взаимодействия с интерфейсом пользователя.
Как программируют Embedded System?
Программирование Embedded System не ограничивается только знаниями самого языка программирования, также нужно понимание электроники, информатики, автоматизации процессов, робототехники и друго го — многое зависит от области применения встраиваемых систем. Поэтому можно сказать, что Embedded-программист — это не просто программист, а специалист широкой направленности.
Чтобы встраиваемая система получилась максимально успешной, к ее разработке нужно подходить очень ответственно и обязательно хорошо продумать архитектуру и функциональность. Очень часто небольшие ошибки приводят к тотальному провалу систем, поэтому программирование должно быть аккуратным, а тестирование — очень тщательным.
Иногда Embedded System бывают настолько сложными, что их разработка превращается в целое событие, которое управляется несколькими командами инженеров и программистов.
Заключение
технологий дополненной и виртуальной реальности;
Поэтому стоит рассмотреть Embedded-программирование как род своей будущей деятельности.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Разработка встроенного ПО: введение
Привет, Хабр! Представляю вашему вниманию перевод статей Chris Svec, оригинал здесь. Публикуется с разрешения автора по лицензии CC-A-NC-ND.
Embedded software engineering 101: введение
Я запускаю цикл статей по обучению разработке встроенного программного обеспечения. Мы начнем с описания простого микроконтроллера, и после того, как Вы поймете, как он работает, разовьем это до понимания работы относительно сложных систем, таких как Fitbit или Nest.
Я назвал эту серию Embedded Software Engineering 101, и она начинается с этой недели прямо здесь в этом блоге.
Продолжайте читать для дальнейших объяснений и подробностей.
Одни строительные блоки на других строительных блоках.
Я работаю со встроенными системами и разрабатываю микросхемы уже более 14 лет. Мне нравятся встроенные системы — железо, софт и ограничения, которые связывают их вместе.
Любительская электроника и такие идеи, как Arduino, Adafruit и Sparkfun дали возможность легко накидать что-то из железа и софта за выходные (или месяц, или семестр), создав что новое, интересное и может быть даже полезное.
Это здорово! Предоставление людям возможности созидать — изумительная штука; если бы я хотел выражаться выспренно, то с придыханием назвал бы это «демократизирующей технологией».
Большая часть любительских проектов единовременные. Вы собираете нечто, делаете это настолько хорошим, насколько хватает времени или энергии, и двигаетесь дальше.
Я провел свою карьеру на противоположном конце спектра — создавая продукцию, которая выпускается в сотнях тысяч или миллионах или больше экземпляров — и это требует совсем другого образа мышления и системного подхода.
Я хочу учить людей, как писать встроенное ПО для такого рода систем. Я уже давно вынашивал эту идею курса/руководства/книги/блога «Embedded Software Engineering 101», и благодаря блогу Embedded.fm начинаю ее реализацию сейчас.
Я человек фундаментального типа, так что мой план — начать с основ, с простого описания простого микропроцессора, и развивать эту основу, пока вы не поймете, как работает относительно сложная встроенная система.
Моя цель — чтобы к концу этого цикла вы могли разобраться как работает Fitbit, термостат Nest или подобная встроенная система. Вы сможете начать работать со встроенными программными системами используя профессиональный опыт.
Embedded Software Engineering 101 предназначен для:
Так вот, я не Фейнман, но я уверен, что лучший способ понять систему — это начать с основ. Вооруженные этим пониманием, вы сможете создавать простые встроенные системы с простым софтом. И поняв сначала очень простую программу, вы сможете развивать это, создавая более сложное ПО по мере роста опыта.
Основы в первую очередь — это конечно только мое личное убеждение. Множество людей сделали полезные штуки с Ардуино без понимания чего бы то ни было из основ. Этот цикл статей для тех, кто все-таки хочет понимать основы и все, что на них построено.
Конечно мы должны задаться вопросом — где правильный уровень чтобы начать с этих самых «основ»? Транзисторы и логические вентили? Нет, это слишком низкий уровень для старта со встроенным ПО. Подключение к распространенным датчикам? Нет, это слишком высокий уровень, требуется слишком много знаний чтобы начать с этого.
Я думаю правильный уровень основ это встроенный микропроцессор. Не обязательно понимать физику или электронику чтобы использовать встроенный микропроцессор, также не обязательно быть экспертом в программировании.
Так что с этого мы и начнем в следующей статье.
Предупреждение о предвзятости: в прошлой жизни я был архитектором/разработчиком процессоров. Начать этот цикл с понимания как работает ЦПУ может быть не лучшим способом для понимания встроенных систем, но именно так работает мой мозг. Обязательно попробуйте другие курсы/руководства и т.д., если не станете понимать этот после нескольких статей.
Embedded software engineering 101: основы микроконтроллера
Мы начнем наше путешествие Embedded Software Egineering 101 со скромного микроконтроллера. Микроконтроллер (или микропроцессор) это основной строительный блок всех вычислительных систем, встроенных и прочих.
МК кажется довольно сложным, но он состоит из трех простых вещей: инструкции, регистры и память. Инструкции это те штуки, которые микроконтроллер знает как выполнять. Простой МК умеет выполнять не так уж много — у него может быть например 20 или 30 инструкций. В дальнейшем в этом цикле я буду использовать микроконтроллер MSP430 от Texas Instruments, у которого только 27 инструкций.
Просто фотография МК (TI MSP430F5529)
Эти 27 инструкций — единственное, что MSP430 умеет делать. Он может сложить два числа, вычесть из одного числа другое, переместить числа с одного места в другое или выполнить 24 другие простые операции. 27 операций может показаться недостаточно чтобы сделать что-либо полезное, но на самом деле их хватит с избытком, чтобы выполнить любую мыслимую программу.
Хорошо, значит у микроконтроллера есть инструкции, которые делают что-то с числами. Но где находятся эти числа? Регистры и память! Инструкции оперируют числами, которые хранятся в регистрах и памяти.
Регистры это очень быстрое хранилище, содержащее числа, которыми оперируют инструкции. Можно думать о них, как об используемом инструкциями блокноте. МК содержит немного регистров, обычно 8-32. Например, у MSP430 16 регистров.
Память это тоже хранилище для чисел, но она гораздо объемнее и медленнее чем регистры. У микроконтроллера может быть 64 кБ, 256 кБ или даже более 1 МБ памяти. У MSP430F5529 около 128 кБ памяти; это более чем в 8000 раз превосходит количество его регистров!
Прежде чем мы начнем рассматривать примеры, я призываю вас достать лист бумаги и ручку или карандаш и прорабатывать эти примеры по мере чтения. Прорабатывать их на бумаге сложнее, чем просто читать, что я написал. Таким образом вы внимательнее подойдете к процессу, и шансы на запоминание изученного будут выше.
Давайте рассмотрим вымышленный, но характерный пример микроконтроллера.
Пусть скажем у нашего МК 4 регистра и 8 ячеек памяти. Регистры обычно называют как-нибудь креативно, например «R0», «R1» и т.д., поступим и мы так же. На ячейки памяти обычно ссылаются по их номерам, также называемым адресами памяти, начиная нумерацию с 0. Вот так будут выглядеть наши регистры и память:
И теперь я помещу в них некоторые значения:
Теперь нашему вымышленному микроконтроллеру нужны какие-нибудь инструкции.
Совокупность инструкций, которые знает МК, называется его набором инструкций. Пусть скажем в наборе будет три инструкции: ADD (сложить), SUB (сокращение от «subtract» — вычесть) и MOVE (переместить). Инструкции должны получать откуда-то числа, которыми они оперируют, и также помещать куда-то свои результаты, так что некоторые из них содержат информацию о том, где находятся входные и выходные данные.
Пусть, например, у нашей инструкции ADD два источника и один приемник данных, и все они должны быть регистрами. Руководство может описывать эту инструкцию примерно так:
ADD регИст, регПрм
Инструкция ADD добавляет значение регистра «регИст» к значению регистра «регПрм» и сохраняет результат в регистре «регПрм»
Резюме: регПрм = регИст + регПрм
Пример: ADD R1, R2 выполняет операцию R2 = R1 + R2
Это общепринято в инструкциях — использовать один из источников также в роли приемника, как делает инструкция ADD, используя регПрм в качестве и источника и приемника данных.
«ADD R1, R2» — это язык ассемблер для микроконтроллера, это нативный язык программирования МК.
Давайте определим SUB в том же стиле:
SUB регИст, регПрм
Инструкция SUB вычитает значение регистра «регИст» из значения регистра «регПрм» и сохраняет результат в регистре «регПрм»
Резюме: регПрм = регПрм — регИст
Пример: SUB R3, R0 выполняет операцию R0 = R0 — R3
И наконец пусть у инструкции MOVE один источник и один приемник, и либо:
1. MOVE регИст, регПрм
2. MOVE памИст, регПрм
3. MOVE регИст, памПрм
Инструкция MOVE копирует данные из аргумента Ист в аргумент Прм.
Резюме: есть три типа инструкции MOVE
1. регПрм = регИст
2. регПрм = мемИст
3. мемПрм = регИст
Пример: я покажу примеры инструкции MOVE ниже в этом посте.
Одно замечание о слове «move», используемом для этой инструкции: большая часть наборов инструкций используют именно его, хотя в действительности данные копируются, а не перемещаются.
Название «move» может создать впечатление, что операнд-источник инструкции уничтожается или очищается, но на самом деле он остается в покое, модифицируется только приемник.
Давайте пройдемся по нескольким примерам используя наш вымышленный микроконтроллер.
На старте наши регистры и память выглядят так:
Теперь выполним на МК следующую инструкцию:
Она берет значение R1, складывает его со значением R2 и сохраняет результат в R2. Процессор выполняет большую часть инструкций за одну операцию, но я разобью выполнение каждой инструкции ADD, SUB и MOVE на несколько шагов стрелкой «=>» ведущей через замены (регистр/память => значение):
После выполнения этой инструкции память неизменна, но регистры теперь выглядят следующим образом, с изменившимся значением написанным красным:
Обратите внимание, что R1 неизменен; изменился только регистр-приемник R2.
Следующей давайте попробуем инструкцию SUB:
Она берет значение R3, вычитает его из значения R0, и сохраняет результат в R0:
После выполнения этой инструкции память неизменна, но регистры теперь выглядят таким образом:
И наконец давайте попробуем пару версий инструкции MOVE:
Эта инструкция MOVE копирует в R0 значение R2:
И теперь регистры выглядят так:
Дальше мы скопируем регистр в память:
Эта инструкция MOVE копирует в ячейку памяти 3 значение R3. Квадратными скобками в нашем наборе инструкций обозначаются ячейки памяти.
Регистры неизменны, но память меняется:
И для нашего последнего примера мы скопируем значение из памяти в регистр:
Здесь значение ячейки памяти 6 копируется в регистр R0:
Память неизменна, а регистры теперь выглядят следующим образом:
Верите или нет, но если вы поняли большую часть того, что мы только что обсудили насчёт инструкций, регистров и памяти, то вы понимаете основы микроконтроллеров и языка ассемблер.
Конечно я опустил множество деталей. Например, как МК получает инструкции для выполнения?
Есть ли более интересные инструкции, чем только простые математические и инструкции копирования? Память это то же самое, что RAM или флэш, или нет?
Мы ответим на эти вопросы в следующей статье.
Необходимые знания для embedded developer’a?
Доброго времени суток. Перейду сразу к сути: интерсует исчерпывающий список направлений для обучения программированию микроконтроллеров (прямо попредметно, включая то какие языки программирования следует освоить). Начать хочу с самых ранних азов.
Интересуют так же такие вещи как: стоит ли учится писать сценарии программ для Arduino, сможет ли это помочь абстрагироваться в выбранной сфере разработки и получить те самые азы?
Нужно ли учиться паять и разбираться в микросхемах, теристорах, тестерах и прочем железе что бы работать embedded программистом?
Нужны ли знания программирования под линукс? Читая вакансии не один раз встречал требования знания работы с линукс.
Зачем это все: хочу обучится программированию для автомобилей. По диплому выпущусь на специальность связанную с автомобилями, до этого самостоятельно изучал джаваскрипт, был интересен вэб, но к 20 годам захотелось пойти в более серьезную среду, чем заниматься сайтошлепством где то на галере.
Средний 6 комментариев
Добрый день. (Вопрос посвящен не только автору комментария, ибо его ответ был написан более двух лет назад)
Я всего лишь планирую входить в мир Embedded, первый курс университета. Для меня мотивацией принятия такого решения послужил именно тот факт, что разработчики в этой области получают больше, чем веб-программисты. Да и работа по сложнее будет, в моем понимании. Сама область очень загадочная для простого обывателя.
С вашей колокольни, скажите, это ведь правда, что Embedded-разработчики все же получают больше? Какого пика зарплаты или около того можно достичь при должных знаниях и умениях? (Берем за границей, естественно)
Начать хочу с самых ранних азов.
Правильно. Если хотите стать профессионалом, начинать надо с базовой теории. «Нет царских путей в геометрию».
Интересуют так же такие вещи как: стоит ли учится писать сценарии программ для Arduino, сможет ли это помочь абстрагироваться в выбранной сфере разработки и получить те самые азы?
Нужно ли учиться паять и разбираться в микросхемах, теристорах, тестерах и прочем железе что бы работать embedded программистом?
Нужны ли знания программирования под линукс? Читая вакансии не один раз встречал требования знания работы с линукс.
Опционально, будет плюсом.
Что касается процесса обучения, то он примерно идентичен процессу обучения инженера-электронщика.
Почему embedded-разработчикам следует использовать статический анализ кода
Первая причина: не надо тратить время на мучительный поиск некоторых ошибок
Статический анализ кода == удешевление процесса тестирования и отладки устройства. Чем раньше ошибка найдена, тем дешевле её исправление. Статический анализ находит ошибки ещё на этапе написания кода или, по крайней мере, во время ночных запусков на сервере. В итоге, поиск и исправление многих ошибок обходится гораздо дешевле.
Особенно полезен статический анализ может быть при отладке embedded-систем. В таких проектах разработчики сталкиваются не только с ошибками в программах, но и с ошибками в самом устройстве или с некачественным изготовлением макета (плохой контакт и т.п.). В результате, процесс поиска ошибки может сильно затянуться, так как часто непонятно, где её искать. Если программист посчитает, что код написан правильно, то это может повлечь долгие изыскания с привлечением схемотехников и других коллег, отвечающих за hardware-часть. Тем неприятней будет позже вернуться к коду программы и обнаружить, наконец, дурацкую опечатку. Колоссально неэффективный расход сил и времени коллектива. Великолепно, если такую ошибку найдёт статический анализатор.
Вот как один знакомый описывал мне подобную ситуацию:
«Еще будучи магистром, я начал работать в компании, занимающейся изготовлением на заказ различных мелкосерийных устройств. Например, автоматизация парников или сбор информации с датчиков на предприятии, что нигде ничего не протекло и не перегрелось.
Мне ставится очередная типовая задача, с которой я справляюсь буквально за пару часов и отдаю её двум коллегам для прошивки в созданное ими устройство. Коллеги удивляются, как быстро всё сделал, хвалят, на что я гордо заявляю „ну я уже профессионал подобные вещи писать и вообще там всё просто“. Коллеги удаляются с флешкой, куда я им записал бинарный файл для прошивки микроконтроллера.
И я забываю про это дело. Есть другие большие и более интересные задачи. Тем более, раз они не пришли, значит всё хорошо.
А они пришли. Но только через неделю. Говорят, ничего не понимаем. Всю голову сломали. Не работает наш стенд. Вернее, работает, но не совсем как надо. Мы уже перепаяли его заново и исполнительные электромеханические детали заменили. Не работает… Может, посмотришь? Может, всё-таки, в программе что-то не так…
Открываю код и сразу вижу ошибку в духе:
За основу был взят другой мой проект, и код во многом написан методом Copy-Paste. В одном месте я забыл заменить 4 на 3. Мне так стыдно было, что я двух людей заставил проработать впустую неделю.»
Вторая причина: обновить программу дорого, невозможно или поздно
Ошибки во встраиваемых устройствах крайне неприятны тем, что их невозможно или почти невозможно исправить, если началось серийное производство. Если уже выпущены сотни тысяч стиральных машин и они разъехались по магазинам, то что делать, если в определённом режиме машина работает неадекватно? В общем-то вопрос риторический и реальных вариантов два:
Вывод очень простой. Код встраиваемых устройств должен тестироваться как можно тщательнее, особенно, если ошибки могут привести к жертвам или серьёзным материальным потерям.
Статический анализ кода не гарантирует отсутствие ошибок в коде. Однако просто необходимо использовать любую возможность дополнительно проверить корректность кода. Статические анализаторы могут указать на множество разнообразнейших ошибок, которые умудряются остаться в коде даже после нескольких Code-Review.
Если в устройстве, благодаря статическому анализу, будет на несколько ошибок меньше, это великолепно. Возможно, благодаря обнаружению именно вот этих ошибок, никто не погибнет, или компания не потеряет большие деньги или репутацию из-за претензий со стороны клиентов.
Третья причина: программист может не знать, что делает что-то неправильно
Ошибки в программах образно можно разделить на два типа. Про ошибки первого типа программист знает, и появляются они в коде случайно, по невнимательности. Ошибки второго рода возникают в ситуации, когда программист просто не знает о том, что так писать код нельзя. Другими словами, он может сколько угодно читать такой код, но всё равно не найдёт ошибку.
Статические анализаторы имеют базу знаний о различных паттернах, которые в определённых условиях приводят к ошибке. Поэтому они могут указать программисту на ошибку, о существовании которой он сам бы вряд ли догадался. Примером может служить использование 32-битного типа time_t, что может привести к неправильной работе устройства после 2038 года.
Другим примером может служить неопределённое поведение программы, которое возникает из-за неправильного использования операторов сдвига >. Эти операторы очень широко используются в коде микроконтроллеров. К сожалению, программисты часто используют эти операторы крайне безалаберно, делая программы ненадёжными и зависимыми от версии и настроек компилятора. При этом программа вполне себе может работать, но вовсе не потому, что написана правильно, а потому, что везёт.
Используя статический анализатор, программисты могут подстраховать себя от множества подобных неприятных ситуаций. Дополнительно анализатор может использоваться для контроля качества кода в целом, что актуально, когда состав участников проекта растёт или изменяется. Другими словами, анализатор помогает отследить, не начал ли новичок писать плохой код.
Заключение
Есть ещё одна причина в обязательном порядке использовать статический анализатор кода. Это когда проект должен соответствовать определённому стандарту разработки программного обеспечения на языке, например, MISRA C. Однако это, скорее, относится к административным мерам, и лежит немного в стороне от обсуждаемой темы.
Я хотел показать, что использование статического анализатора однозначно целесообразно для любого встраиваемого проекта. Используйте эту методологию, и вы сможете:
Используйте статические анализаторы кода! Их много.
Мы, естественно, предлагаем обратить внимание на наш анализатор кода PVS-Studio, который недавно начал поддерживать ряд ARM-компиляторов.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. Why embedded developers should use static code analysis.
Карьера в IT: должность Embedded-разработчик
Продолжаем серию «Карьера в IT»: на этот раз поговорим о позиции Embedded-разработчика. Это специалист, который занимается разработкой встроенного ПО.
Об особенностях своей специальности нам рассказали Embedded-разработчики из компаний Celeno, eZLO Smart Home Automation, GlobalLogic, Ring Ukraine, TowerIQ и Ubiquiti Labs Ukraine.
Задачи и обязанности
Embedded-разработчик работает со встроенными устройствами. Встраиваемая система — это та, которая работает под управлением компьютера. То есть под это определение попадают все девайсы и гаджеты, оснащенные аппаратной платформой.
По сути, эта специальность лежит на стыке программирования и аппаратной инженерии. Задачи бывают разными — от разработки драйвера для какого-то модуля до интеграции кода с существующим ПО. Все зависит от конкретного проекта. Иногда обязанности ограничиваются только работой с платой, а иногда Embedded-разработчики принимают участие в написании бизнес-логики продукта или разработке самого «железа».
«Я адаптирую код к прошивке камеры и улучшаю работу существующего кода. Много общаюсь с коллегами со всего мира, чтобы вместе эффективнее решать задачи». (Александр, Ubiquiti Labs Ukraine)
В отличие от классических Software программистов, Embedded-разработчики работают не только с кодом, но и с «железом».
«Объясню суть своей работы на примере нашего проекта. В Японии выпускают „железо“, которое должно стать частью автомобиля. Наш эксперт едет на завод в Японию и делает все, чтобы Android с периферийной платой заказчика ожил. Дальше „железо“ попадает к нам в офис. Мы занимаемся всем — от момента включения устройства и заканчивая пользовательским интерфейсом. Будь то kernel, драйвер, демон или красивая анимация при нажатии на кнопочку». (Денис Глусский, GlobalLogic)
Главный вызов Embedded-разработчика в начале проекта — правильно выбрать аппаратную платформу, на которой всё будет реализовываться. Если этот выбор окажется неправильным и аппаратных средств платформы не хватит, придется начинать работу с нуля на новой платформе. Если же, наоборот, аппаратная платформа была выбрана со слишком большим запасом, конечный продукт получится более дорогим, чем мог бы быть.
Следующая задача — выбор и адаптация существующих реализованных алгоритмов под ограниченные ресурсы выбранной платформы. Для этого нужны навыки Kernel, System и Application-инженерии в одном лице.
«Прежде чем начинать программировать, Embedded-разработчик должен обеспечить себе базовую функциональность. Заставить плату работать, запустить начальный загрузчик, написать или обновить какие-нибудь драйвера. Часто это приходится делать без какой-либо поддержки со стороны софта: для отладки используется не отладчик и даже не серийная консоль, а мигание светодиодом на плате или анализ сигналов осциллографом. Недаром у эмбеддеров „Hello, World!“ — это помигать светодиодом на новой плате». (Андрей Лукин, GlobalLogic)
Примеры Embedded-систем (image source)
Embedded-разработчик не работает с интерфейсом пользователя, базами данных или файлами сложных форматов. Как правило, все его внимание сосредоточено вокруг «железа» и его характеристик, например: мощности процессора и количества памяти. Из-за особенностей среды эти ресурсы всегда ограничены. А потому приходится делать упор на оптимизации по памяти, производительности, а также энергопотребление.
«В Embedded крайне важно уделять внимание вопросам надежности и долговременной автономности, так как продукт может годами работать без внимания пользователя. Нужно учитывать крэши, пропадания или ослабления питания, перевод дат и прочее. Существенную роль играет автоматическая процедура обновления ПО и его компонентов — например, обновления SSL сертификатов». (Александр С. и Александр Е., Celeno)
«Работая с платами, девайсами, микроконтроллерами, Embedded-разработчик тесно сотрудничает с hardware-командой. Это помощь не только в подборе компонентной базы, но и в принятии архитектурных решений: от того, как спроектировать систему или какие интерфейсы использовать, — и до того, какой сенсор на какую шину посадить». (Вадим Ткачук, Ring Ukraine)
Еще одна специфика Embedded — необходимость работать с различными устройствами. Обычный программист может разработать софт на своем компьютере и там же заняться запуском или дебагом. У Embedded-разработчика такой возможности, как правило, нет. Для разработки и тестирования ему необходимо иметь при себе свое устройство. Сначала он компилирует код на своем компьютере, потом заливает на девайс и уже там запускает.
Типичный рабочий день Embedded-разработчика включает в себя:
Конкретные активности зависят от специфики проекта, а также методологий и практик, которым следует команда. Вот несколько разных сценариев:
«В Embedded меньше времени уходит на написание кода и больше, к примеру, на ту же отладку. Вполне привычная ситуация: Embedded-разработчик пишет строчек кода, а весь оставшийся день тратит на выяснение причин, по которым он не работает. Ведь приходится иметь дело с разными производителями, разными микроконтроллерами, разными чипами — и у каждого своя имплементация. К тому же на некоторые компоненты нет хорошей документации. Приходится искать форумы, узнавать, не сталкивался ли кто-то с аналогичными проблемами. Нередко в таких случаях доходит до подключения более серьезного дебага, осциллографа, логического анализатора. Такой глубокий анализ может занять весь день». (Вадим Ткачук, Ring Ukraine)
«По моему опыту, на написание кода у Embedded-разработчика уходит максимум 30% рабочего времени. До 50% всего времени занимают исследования сути проблемы, которую нужно решить. Остальное — дебаг». (Виктор Семенов, TowerIQ)
«На текущем проекте я занимаюсь интеграцией кода от 5 разных Software house в одно целое. Около 40% времени уходит на на интеграцию, 30% — на код ревью, 20% — на деловую переписку и 10% — на рефакторинг и улучшения. До позиции интегратора 60% времени занимался написанием кода, 20% — интеграцией, 10% — код ревью, 10% — рефакторингом и прочими улучшениями. В любом случае около часов в неделю трачу на чтение статей и изучение исходного кода AOSP. Обычно делаю это во время сборки проекта». (Денис Глусский, GlobalLogic)
«Иногда нужно просидеть пару дней в окружении электрических схем, файлов печатных плат и контрольно-измерительного оборудования в поисках неисправности или пути оптимизации работы какого-либо узла. Если аппаратная часть отлажена, можно весь день писать код, прерываясь на разного рода митинги и обсуждения. Также время от времени появляются задачи, связанные с настройкой рабочего окружения и оптимизацией процесса разработки, чтением и написанием документации или тестированием. В среднем по времени времени уходит на написание кода, на тестирование и 10% — на различные митинги и обсуждения». (Владимир Свистельников, eZLO Smart Home Automation)
Меняются задачи и на разных стадиях жизненного цикла продукта:
«Чем больше работаешь с устройством, тем больше времени занимает работа, собственно, с кодом. В самом начале вообще вряд ли кодишь, больше разбираешься в документации, читаешь принципиальные схемы, если есть. Уточняешь требования с заказчиком. Потом много времени может уходить на пересборку операционных систем. Под конец проекта больше всего времени, по-хорошему, уходит на тесты». (Андрей Лукин, GlobalLogic)
Иногда Embedded-разработчикам приходится самим брать в руки паяльник — например, если нужно срочно припаять какой-то проводок или кнопку на плату.
Преимущества и недостатки
Embedded-разработчиков привлекает эта специализация тем, что позволяет не просто увидеть, но и и «пощупать» результаты своей работы. В Embedded идут инженеры, которым интересно работать с «железом», микросхемами и низкоуровневыми деталями.
«Мне нравится создавать новые вещи физического мира. К примеру, раньше смартфонов не было, а теперь они есть. Раньше вы платили в метро жетонами, сейчас смартфоном. Еще один плюс профессии — ее востребованность. Принимая участие в найме персонала, я понял, что рынок сильно нуждается в квалифицированных Embedded-разработчиках». (Виктор Семенов, TowerIQ)
«В Embedded меня всегда привлекало „железо“. То, что ты можешь потрогать результат своей работы, а он тебе каким-нибудь диодиком подмигнёт». (Андрей Лукин, GlobalLogic)
«Embedded привлекателен для тех, кто желает видеть результаты своего труда, свой код, оживляющий изначально мертвое, неподвижное железо. Вряд ли эта профессия подойдет любителям высоких объектно-ориентированных абстракций и теоретикам». (Александр С. и Александр Е., Celeno)
«Embedded-разработчик каждый день делает то, что до него никто не делал. Ты приходишь на работу — и завертелось то, что без тебя никогда бы не завертелось. Это довольно круто. Льстит самолюбию. Лично я по образованию радиоинженер, потому писать программы для меня было логичным развитием моих знаний о электронике и радиотехнике». (Максим, Ubiquiti Labs Ukraine)
«Я по образованию инженер-электрик и поначалу в основном занимался электроникой. Но с течением времени стал больше увлекаться программированием. Мне нравится возможность вдохнуть жизнь в железяку, посмотреть, как бегают электроны». (Виталий Васильский, GlobalLogic)
Работа с Embedded-системой (image source)
Среди минусов профессии Embedded-разработчики отмечают проблемы с отладкой, узкую специализацию, а также сложности в том, чтобы организовать удаленную работу:
«Сложность работы очень высока. Помимо программирования нужно знать аппаратуру. Чем ближе к аппаратному уровню, тем меньше ресурсов для отладки. Вплоть до того, что с определенного уровня программные средства отладки уже невозможно использовать, и нужен уже аппаратный отладчик. С этим всем нужно уметь работать». (Виталий Васильский, GlobalLogic)
«Есть не недостатки, но некоторые сложности. Например, то „железо“, которое вы используете, может быть экспериментальным. Если это engineering-образец, он часто глючит сам по себе — и без вашего кода. Это необходимо учитывать при отладке». (Александр С. и Александр Е., Celeno)
«Бывает, ты целый год разрабатываешь определенную прошивку для устройства какого-то специфического производителя. К концу проекта уже знаешь его досконально. Но проект заканчивается, и в следующем тебе дают процессор другого производителя. Принципы одни и те же, но все равно приходится разбираться заново. Получать новые знания, которые, вероятно, в дальнейшем тебе не пригодятся, — это бывает не так интересно, как кажется со стороны». (Вадим Ткачук, Ring Ukraine)
«Embedded-разработчику, который занимается низкоуровневой разработкой под микроконтроллеры, практически невозможно работать удалённо. При большом желании такую работу найти можно, но вам всё равно нужно будет обустроить рабочее место дома или ещё где-то. А также придется самостоятельно снабжать себя вспомогательными инструментами: отладочными платами, кабелями, переходниками, принадлежностями для пайки. Так что работать с ноутбуком сидя на пляже — не получится». (Виктор Семенов, TowerIQ)
Как стать и куда двигаться дальше
Чтобы стать Embedded-разработчиком, необходимо быть знакомым с базовыми понятиями электроники и электротехники, иметь хорошие знания аппаратной части, понимать работу сетей. Понадобятся знания схемотехники, теории обработки сигналов, математики, алгоритмов, Linux OS и языков программирования С и С++.
Начать изучение специальности можно с книг «Искусство схемотехники» Хоровица и Хилла, «Архитектура компьютера», «Компьютерные сети» и «Операционные системы» Эндрю Таненбаума. В Embedded-разработке не обойтись без фундаментальных знаний по компьютерным наукам.
Для более детального знакомства с устройствами придется изучать документацию к разным составляющим «железа». Для этого понадобится знание английского — все руководства пользователя, как правило, написаны на нем.
«Документация — наше всё, если она есть 🙂 Например, руководство Programmers Guide для процессора ARMv8-A занимает 296 страниц и описывает лишь основы. А Architecture Reference Manual для него же — уже 6354 страниц». (Андрей Лукин, GlobalLogic)
«Обязательно стоит посвящать время изучению форумов и community-порталов. По возможности посещайте различного рода ивенты, смотрите вебинары, следите за трендами». (Владимир Свистельников, eZLO Smart Home Automation)
Чтобы закрепить знания на практике, Embedded-разработчики советуют придумывать и разрабатывать собственные проекты:
«Для получения опыта и знаний я рекомендую сделать собственный сложный проект, включающий разработку платы, программирование, дебаг и калибровку. К примеру, я делал самодельный квадрокоптер. Во время разработки узнал множество фундаментальных вещей. После того, как он полетел, уже ничего не страшно :)» (Виктор Семенов, TowerIQ)
«Попробуйте собрать какую-то схему или готовый набор вроде Arduino. Это поможет освоить базовые шины обмена данными и поработать с периферией. Придумайте себе задание — к примеру, подключить к схеме датчики и написать программу, которая будет обрабатывать их сигналы. В том же Arduino есть много библиотек для работы с шинами, датчиками, клавиатурой — сначала можно использовать их. А затем попробуйте написать все драйвера самостоятельно. Следующий шаг — работа с Raspberry Pi. После такой практики можно подавать резюме в компании». (Александр, Ubiquiti Labs Ukraine)
Платформа Raspberry Pi (image source)
Из личных качеств важны:
Также понадобится широкий кругозор в предметной области продукта, над которым вы планируете работать.
«Вы не напишите программу для стирки кружевного белья в машинке без знаний о текстиле и швейном деле. Не напишите ПО для станции автоматического полива растений без знаний по биологии. А ведь кто-то пишет программы для аппаратов УЗИ, для исследований слуха, зрения. В этом случае разработчик должен руководствоваться той же клятвой Гиппократа, не так ли?» (Максим, Ubiquiti Labs Ukraine)
Возможные карьерные пути Embedded-разработчика:
«Куда дальше? Строить космические корабли, например. Вообще, прогресс постоянно держит в тонусе, спрос на Embedded-решения растет. Кстати, использовать свои знания можно и для личных целей. Мой знакомый построил себе автоматизированную теплицу. Система выполняет все необходимые действия сама, а он приезжает исключительно собрать урожай». (Денис Глусский, GlobalLogic)
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.
