Embedded разработка что это
Проектирование архитектуры embedded-приложения
Добрый день! Хотелось бы поговорить на тему архитектуры embedded приложений. К сожалению, книг по этой теме очень мало, а в связи с тем, что, в последнее время, интерес к embedded и IoT растет, хочется уделить внимание этому вопросу. В этой статье, я бы хотел описать один из возможных вариантов того, как можно проектировать такие приложения.
Вопрос этот дискуссионный! Поэтому предлагают поделиться своим виденьем в комментариях!
Для начала определимся с областью: в рамках данной статьи, под embedded разработкой будем понимать разработку ПО под микроконтроллеры (далее МК, напр. STM32) на языке C / Asm.
Проекты для систем на базе МК условно можно разделить на не требующие и требующие многозадачности. Что касается решений первого типа, они, как правило, не очень сложные (со структурной точки зрения). Например, простой проект, в рамках которого необходимо считывать данные с датчика и показывать их на экране, не требует многозадачности, здесь достаточно реализовать последовательное выполнение перечисленных операций.
Если же приложение более сложное: в рамках которого необходимо считывать данные как с цифровых датчиков, так и с аналоговых, сохранять полученные значения в память (например, на sd-карту), обслуживать пользовательский интерфейс (дисплей + клавиатура), предоставлять доступ к данным через цифровой интерфейс (например, RS-485 / Modbus или Ethernet / TCP/IP) и максимально быстро реагировать на определенные события в системе (нажатие аварийных кнопок и т.п.), то в этом случае будет тяжело обойтись без многозадачности. Существует два способа решения вопроса многозадачности: реализовывать ее самому, либо воспользоваться какой-то операционной системой (далее ОС). На сегодняшний день, одной из самых популярных ОС реального времени для встраиваемых систем является FreeRTOS.
Попробуем представить, как должна выглядеть архитектура “сложного” embedded приложения, выполняющего достаточно большое количество разнородных операций. Я допускаю, что можно предложить еще более сложный вариант, который предполагает решение вопросов обработки звука, криптографию и т.п., но остановимся на варианте, который был описан чуть выше.
Поставим задачу более четко, пусть в рамках нашего приложения необходимо:
Если проанализировать задачу, то можно увидеть, что разные компоненты системы используют одни и те же данные. Например: данные с датчиков необходимо получить, отобразить на экране, записать на носитель и предоставить внешним системам для считывания. Это наводит на мысль, что нужна какая-то база данных реального времени (RTDB) для хранения и для предоставления самых актуальных данных различным подсистемам.
Задачи, выполняющиеся в системе (считывание данных, запись, отображение и т.п.), могут иметь различные требования к частоте их вызова. Нет смысла обновлять данные на дисплее с частотой 1 раз в 100 мс, т.к. для человека это не критично, а вот считывать данные с датчиков (особенно, если необходимо выдавать по ним управляющие воздействия) нужно часто (хотя в зависимости от ТЗ может и нет). Еще один важный момент связан с решением задачи доступа к одним и тем же данным на чтение и запись. Например: поток, опрашивающий датчики записывает полученные значения в RTDB, а в этот момент поток, отвечающий за обновление информации на дисплее, их считывает. Здесь нам помогут механизмы синхронизации, которые предоставляет операционная система.
Начнем проектировать архитектуру нашего приложения!
База данных реального времени
В качестве такой базы может выступать обычная структура, содержащая необходимый набор полей или массив. Для доступа к “RTDB” будем использовать API, который позволит записывать и считывать данные из базы. Синхронизацию доступа к данным внутри функций API можно построить на мьютексах, предоставляемых ОС (либо использовать какой-то другой механизм).
Работа с датчиками на шинах
Работа с датчиками предполагает следующее:
“Port” — реальный порт МК;
“Protocol driver” — драйвер протокола (например, Modbus). К такому драйверу желательно сделать свой интерфейс и работать через него. В рамках такого интерфейса можно реализовать управление доступом к ресурсу через мьютексы, так как это было сделано для “RTDB”. Некоторые разработчики предлагают это делать на уровне порта, чтобы быть уверенным в том, что никто другой в этот порт записывать ничего не будет, пока мы через него передаем свои Modbus пакеты.
“Sensor reader” — задача (task), которая опрашивает датчики, приводит в порядок полученную информацию и записывает ее в ”RTDB”.
“RTDB” — база данных реального времени, описанная выше, в соответствующем разделе.
Надпись “Pr: 1” над задачей означает приоритет, суть в том, что у каждой задачи может быть приоритет, если у двух задач, ожидающих процессорное время, разный приоритет, ресурс получит та, у которой приоритет выше. Если у задач приоритет одинаковый, то запустится та, у которой дольше время ожидания.
Работа с дискретными входами
В общем случае работу с дискретными входами можно организовать точно также как и с цифровыми датчиками. Но может возникнуть необходимость в быстром реагировании на изменение состояния входов. Например, по нажатию кнопки как можно быстрее замыкать релейный выход. В таком случае, лучше применить следующий подход: для обработки релейного выхода мы создаем специальную отдельную задачу с более высоким приоритетом, чем у остальных. Внутри этой задачи находится семафор, который она пытается захватить. На срабатывание конкретного дискретного входа заводится прерывание, в котором сбрасывается упомянутый выше семафор. Т.к. приоритет прерывания максимальный, то связанная с ним функция выполнится почти мгновенно, в нашем случае, она сбросит семафор, и, после этого, следующей задачей в очереди на выполнение будет как раз та, в рамках которой осуществляется управление реле (т.к. у нее приоритет выше, чем у остальных задач и блокировка по ожиданию семафора снята).
Вот так может выглядеть схема данной подсистемы.
Помимо быстрого срабатывания на изменение состояния конкретного входа, дополнительно можно поставить задачу “DI reader” для считывания состояния дискретных входов. Эта задача может быть как самостоятельной, так и вызываться по таймеру.
Работа “Interrupt handler’а” и “Relay controller’а” в виде диаграмм представлена ниже.
Запись данных на внешний носитель
Запись данных на внешний носитель идеологически очень похожа на чтение данных с цифровых датчиков, только движение данных осуществляется в обратную сторону.
Мы читаем из “RTDB” и записываем через “Store driver” во внешний носитель — это может быть SD карта, USB-флешка или что-нибудь ещё. Опять-таки, не забываем в функции интерфейса помещать мьютекс-обертки (или какие-либо другие инструменты для организации доступа к ресурсу)!
Предоставление доступа к данным реального времени
Важным является момент предоставления данных из “RTDB” для внешних систем. Это могут быть практически любые интерфейсы и протоколы. В отличии от ряда рассмотренных подсистем, ключевым отличием этой является то, что некоторые из протоколов, широко применяемых в системах автоматизации, предъявляют особые требования ко времени ответа на запрос, если ответ не приходит в течении определенного времени, то считается, что с данным устройством нет связи, даже если он (ответ) придет через некоторое время. А т.к. доступ к “RTDB” в нашем примере может быть временно заблокирован (по мьютексу) необходимо предусмотреть защиту внешнего master-устройства (master — это устройство, которое пытается прочитать данные из нашего) от такой блокировки. Также стоит предусмотреть защиту самого устройства от того, что master будет опрашивать его с большой частотой, тем самым тормозя работу системы постоянным чтением из ”RTDB”. Один из вариантов решения — это использовать промежуточный буфер.
“Data updater” читает данные из “RTDB” с заданной периодичностью и складывает, то, что прочитал в “Protocol cache”, из которого “Protocol handler” будет данные забирать. В данном случае возникает проблема блокировки на уровне протокольного кэша, для ее решения можно завести ещё один кэш, в котором “Protocol handler” будет хранить данные на случай, если не смог прочитать из заблокированного “Protocol cache”, дополнительно можно:
— сделать для “Protocol handler” более высокий приоритет;
— увеличить период чтения из “RTDB” для “Data updater” (что так себе решение).
Работа с пользовательским интерфейсом
Работа с пользовательским интерфейсом предполагает обновление данных на экране и работу с клавиатурой. Архитектура этой подсистемы может выглядеть так.
UI worker занимается тем, что считывает нажатия клавиш, забирает данные из “RTDB” и обновляет дисплей, который видит пользователь.
Общая структура системы
Теперь взглянем на то, что получилось в итоге.
Для того чтобы балансировать нагрузку можно ставить дополнительные кэши, так, как мы это сделали в подсистеме, отвечающей за предоставление доступа к данным внешним системам. Часть задач по перебросу данных можно решить с помощью очередей, благо они, как правило, поддерживаются операционными системами реального времени (во FreeRTOS точно).
На этом все, надеюсь было интересно.
Как стать грамотным разработчиком встраиваемых систем?
Доброго времени суток, в начале этого года я написал пост как жить чуть больше чем на МРОТ и тут же настал коронавирус. Через некоторое время меня сократили, и чет стало вообще грустно. Не знал куда податься, хотел попробовать себя в web разработчиках, но обстоятельства сложились так, что я стал делать несложные проекты на ардуино, а теперь и на esp32, благо я понимаю в схемотехнике и моделировании, но был полным нулем в программировании (да и сейчас не далеко ушел). Но мне понравилось это направление и в будущем хочу стать серьезным разработчиком, не только на атмегах, esp и stm, но вообще на любых микроконтроллерных системах. И вот тут я опять столкнулся с отсутствием информации, в универе нас этому не учили и я понимаю, что могу не осознавать, что какие то вещи надо учить уже сейчас, например FreeRTOS, работа с аппаратной частью микроконтроллеров, взаимодействие программно с ними, высшая математика вдруг нужна оказалась и углубиться в нее надо. Просто поверхностное знание C++ и Phyton не позволит что то серьезное создавать. Сам С++ это тоже не просто синтаксис, я знаю что в нем есть очень мощные инструменты, которыми те же ардуинщики не пользуются. Время у меня есть, минимум год, есть база, есть желание и заказы в этом направлении, очень простые, но на хлеб хватит. Хочу делать серьезные и крутые штуки. Может подскажите подходящие книги, может зарубежные каналы или даже курсы, если надо летом в Москву поеду. А вот поступать 3й раз в вуз точно не хочу, это бесполезно.
Просто прошу совета. Без рейтинга.
Жаль что только в 33 пришло осознание чем хочу заниматься.
P.S. Кстати в университете успел пообщаться с системами National Instruments, но было это лет 10 назад.
Arduino & Pi
1.1K пост 18.2K подписчик
Правила сообщества
В нашем сообществе запрещается:
• Добавлять посты не относящиеся к тематике сообщества, либо не несущие какой-либо полезной нагрузки (флуд)
• Задавать очевидные вопросы в виде постов, не воспользовавшись перед этим поиском
• Рассуждать на темы политики
на с++ конфе услышал такой мем, смысл такой:
«разработчики встраиваемых систем должны страдать».
самая недружественная с технической стороны среда это встраиваемые системы.
Когда обычные программисты прыгают жопой на клаве и рубят бабло, романтики встраиваемых систем наматывают сопли на кулак.
ембед это очень романтично, но тернист этот путь, тернист.
Я желаю тебе в нем всяческих успехов!
Пили посты об этом, от себя плюсов обещаю!)
Здравствуйте! Советую в первую очередь прокачать базовые навыки разработчика, они пригодятся всегда, вне зависимости от выбранной вами специализации:
— умение писать безопасный код (wiki: Контрактное программирование, Defensive Programming);
— умение писать Unit-тесты (востребованное в коммерческой разработке умение, есть фреймворки и для чистого C);
— хороший технический английский.
По части Embedded разработки считаю, что в ближайшее время будут востребованы следующие навыки:
— Embedded Linux (портирование загрузчика, сборка и модификация ядра, написание драйверов устройств, даже для прикладного разработчика полезно знать, что такое системный вызов, функции из состава Posix API);
— Работа в Matlab с последующей кодогенерацией и развертыванием системы обработки на целевой платформе (ПЛИС, SoC под управлением того же Linux или RTOS).
— C для работы с ядром Linux, разработки драйверов;
— C/C++ для прикладной разработки;
— Python для разработки технологического ПО, ПО с графическим интерфейсом;
Assembler в настоящее время используется крайне редко, сильно углублятся в изучение конкретного диалекта я рекомендую только по необходимости.
По интерфейсам передачи данных:
Однако, я могу дать один совет, который очень сбережет тебе время и нервы.
Не метайся между контроллерами. Сейчас свой взгляд на будущее ты описал очень сумбурно и из разряда «хочу всё и сразу, но не знаю чего хочу» как раз поэтому.
Могу привести пример из своего опыта. Он более приземленный, разумеется. Я долгое время разрабатывал и писал для платформы atmel. Ардуины тогда еще не было, это была чистая атмега. Опыт электроники у меня уже был порядочный, и я быстро разобрался в тонкостях. Не во всех, разумеется, но мне хватало, чтобы делать относительно производительные штуки и понимать как именно они работают.
Так уж сложилось, что «дядьки с заводов» не оценят и не поприветсвуют автоматизацию производственных процессов не на промышленных ПЛК.
+ у предприятий есть деньги и они не гнушаться платить большие деньги за оборудование\монтаж\настройку\обслуживание.
Меня всегда поражала стоимость ПЛК, такое ощущение, что создатели этих контроллеров, считают за дойных коров, собственников предприятия.
Советую ехать в мск. С эмбед в регионах просто беда. Работа низкооплачиваемая и маловостребованная в регионах. В мск куда больше знаний поднимешь за короткий срок.
Учиться чему либо без конкретного применения вообще мало смысла. Везде если и нужен, то практический опыт коммерческой разработки, а не дома на коленке.
В общем идеальный вариант, это найти работу.
Есть неплохая книжка «сопряжение пк с внешними устройствами». Автор Пей Ан. Там от простого к сложному рассказывается как с компа подергать ножками и поуправлять железяками. Есть неплохой трехтомник «микроконтроллеры? Это же просто» А. В. Фрунзе. Там рассказывается как контроллером подергать ножками и поуправлять железяками. Если в ассемблер и регистры контроллера лезть тяжеловато, можно сначала освоить ассемблер для х86 и понять сам принцип, книга П. Абеля «ассемблер для ibm pc».
Спроси вот тут, как и чему тебе поучиться
Сам после 30 лет прошёл путь от ардуино до профессионального программиста в сфере промышленной автоматизации.
Хотя, ты вот пишешь что у тебя есть уже проекты. Ну, тогда хочется пожелать тебе удачи, надеюсь у тебя получится.
P.S. А что вы уже умеете и что вы уже делали? На каком уровне навыков и знаний находитесь?
Надо понимать что написано на:
0: Ассемблер для выбранного МК.
1: Си, без плюсов. Как код на си будет транслироваться в АСМ-код.
2: понимать принцип работы битовых сдвигов и битовых операций.
3: понимать и эффективно использовать механизм указателей.
4: понимать и правильно использовать механизм прерываний.
Я вот курс нашёл, без сертификата бесплатный, может успеешь зарегиться. Хотя первые 3 модуля философия
смотри
есть куча стульев
можно ТОЛЬКО разводить схемы
можно ТОЛЬКО пилить принципиальные схемы
можно ТОЛЬКО прожить
но для узкой специализации нужно сначала быть фулстеком
нельзя разводить схему если ты не понимаешь логики как это должно работать
нельзя рисовать схему если ты не знаешь как это потом разводить и для каких целей используется
нельзя прожить не зная что у тебя там за железо, как с ним работать и как на него влияют внешняя среда
вообще могу только успехов пожелать))
30 лет это не приговор)
Сколько я подобных вопросов не встречал, решение как правило одно, специализироваться на один контроллер и писать под него и на нём же всё и собирать, и изучать тех документацию на него а она порой бывает многотомная. Ну и изучать стоит контроллер поновей и поумней. В этой профессии лёгких путей нет.
В 33. Мне 36 а я не знаю чем заниматься, потому что всё то, чем я хотел заниматься раньше уже не подходит.
Сходи на хабр со своим вопросом. Там больше профильных специалистов будет.
Еще можно поискать стажировку, лучше в Москве или в Питере, удаленную. С прицелом на работу джуном.
сесть на геру, ито было бы более адекватным поступком
Вопрос из разряда как быть хорошим человеком.
Сила Пикабу, помоги, очень нужна работа
Ответ на пост «Похоже наказания из рос-армии добрались по интернету и до обычной жизни»
Главное, чтобы работало.
Похоже наказания из рос-армии добрались по интернету и до обычной жизни
Я работаю в школе программирования. Если студенты нарушают правила, то в наказание им заменяют клавиатуры на это.
Go gopher милая вязаная игрушка
Создавать этого малыша было одно удовольствие, хоть это и на первый взгляд просто «синяя сосиска с ушами» ))))
При создании gopher я использовала различные материалы как: пряжа Пехорка «цветное кружево», крючок для вязания 0,7мм., синтепон, полимерную глину для зубов, немного пластмассы для очков авиаторской шапки, ну и конечно хорошее настроение))))
Оживляем робота с манипулятором на Arduino
Игрушка получилась довольно забавная, жалко в детстве такой не было. Хотя мы то знаем, до какого возраста у мужчин длится детство)
Повторяем поделки из ТикТока
Решил сделать проекты из двух вирусных видео, на Пикабу они тоже были:
Для обоих вариантов понадобится
— Адресная светодиодная лента (я брал WS2812b)
— Микрофон (я брал модуль на MAX9814
— Блок питания на 5V
Ссылки на исходники прошивок (там несколько вариантов) есть в описании под видео на ютубе. Пара статичных картинок с результатом:
Экстренный набор
Разработчик с нуля спустя год и сложности дальнейшего развития
Прошел почти год, как я тут создавал пост с вопросом, как стать разработчиком. Год этот был тернист, так как я никогда ранее не занимался программированием и работой с микроконтроллерами, знал совсем немного схемотехнику и единственное что это CAD моделирование.
Как не крути, но для хорошего начала нужна толика везения и я через знакомых смог найти контору, где требовалось делать примитивные вещи, уровня помигать светодиодом, но в основном монтаж, при том навесной. Это мне позволило зарабатывать на хлеб и обучаться. По этому в первую очередь я закупился моим кумиром и кормильцем, китайской паялкой на T12, которая верой и правдой служит мне и сейчас и не поменяю я ее даже на индукционку. Купил фен, ЛБП сам собрал, нормальный мультиметр, кучу ручного инструмента для работы с проводами, в основном мгтф:
Понимаю, что лучший способ, это пойти работать в фирму, где занимаются подобными разработками, но это не путь самурая. Недавно даже приглашали в Московскую фирму, но блин, они тоже используют esp32, а он мне уже не интересен. Я бы даже заплатил кому-нибудь, что бы меня ввели в курс, что где сейчас используют, что мне надо изучить, куда копать и ответили на пару сотен моих вопросов, но что то я ни нашел таких вариантов.
Кстати, я тут пару лет назад делал пост как прожить на МРОТ, сейчас то время вспоминаю с ужасом и непониманием, как я так жил. Даже моих примитивных знаний хватает, что бы зарабатывать в несколько раз больше. И спасибо короне, из-за которой меня сократили и я решил попробовать себя в самозанятых, а то так бы и продолжал работать, думая что это нормально.
Карьера в 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, щоб не пропустити найважливіші статті.