Карьера в IT: должность Embedded-разработчик

Продолжаем серию «Карьера в IT»: на этот раз поговорим о позиции Embedded-разработчика. Это специалист, который занимается разработкой встроенного ПО.

По данным DOU, среднему украинскому Embedded-разработчику 30 лет, он имеет опыт работы 5-6 лет и получает $880 на уровне Junior, $1750 на уровне Middle и $3500 на уровне Senior. Зарплата тим- и техлидов — около $4200.

Об особенностях своей специальности нам рассказали 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-разработчик пишет 10-20 строчек кода, а весь оставшийся день тратит на выяснение причин, по которым он не работает. Ведь приходится иметь дело с разными производителями, разными микроконтроллерами, разными чипами — и у каждого своя имплементация. К тому же на некоторые компоненты нет хорошей документации. Приходится искать форумы, узнавать, не сталкивался ли кто-то с аналогичными проблемами. Нередко в таких случаях доходит до подключения более серьезного дебага, осциллографа, логического анализатора. Такой глубокий анализ может занять весь день». (Вадим Ткачук, Ring Ukraine)
«По моему опыту, на написание кода у Embedded-разработчика уходит максимум 30% рабочего времени. До 50% всего времени занимают исследования сути проблемы, которую нужно решить. Остальное — дебаг». (Виктор Семенов, TowerIQ)
«На текущем проекте я занимаюсь интеграцией кода от 5 разных Software house в одно целое. Около 40% времени уходит на на интеграцию, 30% — на код ревью, 20% — на деловую переписку и 10% — на рефакторинг и улучшения. До позиции интегратора 60% времени занимался написанием кода, 20% — интеграцией, 10% — код ревью, 10% — рефакторингом и прочими улучшениями. В любом случае около 4-х часов в неделю трачу на чтение статей и изучение исходного кода AOSP. Обычно делаю это во время сборки проекта». (Денис Глусский, GlobalLogic)
«Иногда нужно просидеть пару дней в окружении электрических схем, файлов печатных плат и контрольно-измерительного оборудования в поисках неисправности или пути оптимизации работы какого-либо узла. Если аппаратная часть отлажена, можно весь день писать код, прерываясь на разного рода митинги и обсуждения. Также время от времени появляются задачи, связанные с настройкой рабочего окружения и оптимизацией процесса разработки, чтением и написанием документации или тестированием. В среднем по времени 50-60% времени уходит на написание кода, 30-40% — на тестирование и 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-разработчик, изучая новые направления встраиваемых систем;
  • стать архитектором Embedded-решений;
  • перейти в менеджмент — стать тимлидом команды или СТО компании;
  • попробовать себя в смежных отраслях — например, телекоме или инфраструктурной архитектуре.
«Куда дальше? Строить космические корабли, например. Вообще, прогресс постоянно держит в тонусе, спрос на Embedded-решения растет. Кстати, использовать свои знания можно и для личных целей. Мой знакомый построил себе автоматизированную теплицу. Система выполняет все необходимые действия сама, а он приезжает исключительно собрать урожай». (Денис Глусский, GlobalLogic)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному2
LinkedIn

Схожі статті




61 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Для мотивации студентов мы на кафедре решили собирать вакансии прямо у себя на сайте по направлению Embedded doed.nure.ua/vakansii

Мы расширяем список. Это только начало пути. doed.nure.ua/vakansii/page/2

Недавно мы с совместно с Phoenix Contact открыли лабораторию «Встроенных систем управления». Теперь у нас есть PLCnext Control также. Стараемся материальную базу поддерживать на уровне, иначе интерес падает быстро у студентов если бы были только КР580. doed.nure.ua/...​vmestno-s-phoenix-contact

Embedded это обычный computer science (который кстати отпочковался от electrical engineering), с той лишь разницей что работаешь не с facebook api, а с api аппаратного модуля. Или у тебя линукс и тебе вообще пофиг какое у тебя железо.

Не понятно выражение

Или у тебя линукс и тебе вообще пофиг какое у тебя железо.

". Правильно скорее так — или у тебя есть Операционная система или нету. Если нет, то надо учить железо. Иначе сложно будет настроить даже порт МК, не зная например регистра направления.

Да Вы можете возразить, что под МК уже есть библиотеки и решения, но всё же, если нужно что-то очень быстрое, то нужно понимать все механизмы.

Embedded

 же в целом можно разделить на:
Embedded software engineer;
Embedded design engineer;
Embedded hardware engineer.

если нужно что-то очень быстрое

То это «быстрое» оффлоадят в железо.

И у нас в стране пока почти забыли про FPGA и DSP.

.

Согласно Спольскому основная разница не в том, чей API, а в сложности отладки, обновления, организации фидбэка, и часто — ограничениях в ресурсах. Кроме того, достаточно часто добавляются проблемы, что ошибка выливается не в просто не работающий код, а в окирпиченное или сожжённое устройство.

Ну а если всё это проигнорировать — да, «обычный computer science» :crash:

который кстати отпочковался от electrical engineering

Нет. Потому что не только. Половина — от электроинженерии, другая — таки от математики.

Это можно хорошо проиллюстрировать на примере книжного УДК. В начале 90-х, когда я учился в вузе, вся компьютерная литература распределялась между категориями 195.3 (прикладная математика) и 681.3 (радиотехника/электроника), и куда какая книга попадала — было иногда сложно заранее предсказать (а УДК был важным критерием в библиотечном поиске). Где-то на границе 2000 года этот консерватизм был устранён, возникла категория 004, куда переместили всю тематику.

Или у тебя линукс и тебе вообще пофиг какое у тебя железо.

Не пофиг. Потому что железо может менять то, что выглядит для непросвещённого мировой константой примерно того же уровня стабильности, как гравитационная постоянная.
Вот приходишь ты на другую платформу, а там размер страницы 16K. А у тебя всё заточено на 4K, потому что думал, что других не бывает.
Или там деление реализовано подпрограммой, и тебе надо срочно переоптимизировать всю логику.
Ну и так далее.

а в окирпиченное или сожжённое устройство

Если вы удалите содержимое жесткого диска, то ваш ПК окирпичится. Где здесь embedded? А то что устройство можно сжечь, так это сильно зависит от схемотехники, пожлобились ставить защиту, получайте сгоревшее устройство. Большинство пассивных компонентов выполняют ограничительную функцию, на это можно экономить, но лучше не надо.

часто — ограничениях в ресурсах

У всех ресурсы всегда ограничены. Это особенно важно если вы пишите серверные приложения, где от качества вашего кода, зависит то насколько этот сервер будет эффективно работать и не нужно будет докупать еще один. В SoC если ты куда-то уперся, то это уходит в железо. И обычно у тебя просто физически нет времени заниматься отладкой, т.к. проще запилить алгоритм в железе и перевыпустить чип.

Нет. Потому что не только.

1. «Нет» — значит что CS не вышло из EE, а потом вы пишите что таки вышло.
2. Почему вы решили что в EE не нужна математика?

А у тебя всё заточено на 4K, потому что думал, что других не бывает.

Это больше определяет подход к решению проблемы, чем собственно embedded или нет.
До 2000 года все истерически переписывали свои приложения потому что даты считались как-то не очень хорошо. Лет 10 назад, все начали переход с 32-х бит на 64-х.
Что-то провтыкать можно на любом уровне.

Да ладно. Посмотри на вебсайты нынче и вообще уеб-программинг.

Есть такой вебсайт google.com, у них много-много серверов и если они вдруг замутят оптимизацию в 0.1% процент, то вполне может оказаться что у них разгрузится целая стойка с серверами. Более того, они сильно паряться по энергоэффективности, потому что сервера электричество жрут дико, и если оптимизируют потребление на 0.1%, то это вполне может вылиться в семизначные суммы денег.

Справедливости ради они уже дошли до ручки когда у них джуны успевают продать жОлтых прямоугольников на $10 млн ещё до того как их кто-то успеет схватить за руку или за что там положено хватать джунов в таком случае ))

Если вы удалите содержимое жесткого диска, то ваш ПК окирпичится.

Нет, он скажет Insert disk или что-то подобное. Любой загрузочный носитель, задумчивые 20 минут — и готов простой линукс. И в этом принципиальное отличие.

А то что устройство можно сжечь, так это сильно зависит от схемотехники, пожлобились ставить защиту, получайте сгоревшее устройство.

Я немного о других ситуациях. Например, два PLL должны быть инициализированы с разницей в частотах N:1, иначе что-то таки сгорит (и это никак не защита от внешних воздействий). Да, дизайн дурной, но это бывает. Слишком многое сейчас перекладывают на софт.

У всех ресурсы всегда ограничены. Это особенно важно если вы пишите серверные приложения,

Там совсем другой характер ограничения. Оно работает, просто не держит нагрузку (а часто это ещё и лечится распараллеливанием). А когда ты вообще не можешь вместить код и данные даже для 1 условного клиента, это качественно другая ситуация.

2. Почему вы решили что в EE не нужна математика?

Я этого не говорил, не надо домысливать.
Но та математика, которая от разностных схем и до B-деревьев, это не та математика, что в EE.

«Нет» — значит что CS не вышло из EE, а потом вы пишите что таки вышло.

Потому что «CS вышло из EE» это недопустимое упрощение.

Что-то провтыкать можно на любом уровне.

Да. Но от того, что линукс, «пофиг какое железо» не становится.

Окирпичиться это не проблема. Всегда можно перезалить бутлоадер. Тот или иной способ всегда предусмотрен.

Ага, только между «вставить флэшку и нажать F12» и «подключить JTAG контроллер (ещё знать какой — и денег, например, 300$ за приличный) на площадки без выводов, только распаянные (требуется паяльщик с опытом) и найти/купить/украсть спеку на команды конкретного устройства» — «дистанции огромного размера» (tm).
А так, да, можно и все микрухи перепаять. Ну подумаешь, дороже покупки нового...

Это не слишком высокий барьер, из собственного опыта.
Гораздо большая проблема это плохая документация и ошибки в чипах когда сложно понять где именно происходит проблема.
Причём документация плохая и внутри компании. Та же проблема что и с софтом. Sw engineer мучаются с тем что приходит от asic, fae с тем что пришло от sw.

Это не слишком высокий барьер, из собственного опыта.

Когда постоянно занимаешься восстановлением из такого — да, не слишком. Разумеется, если смог достать те самые спеки на отладку (JTAG или что там будет).
Хотя припаиваться каждый раз я б задолбался.
И то — у тебя есть данные на 300 моделей, а приносят 301-ю, которая почему-то не описана.
Но по сравнению со «вставил флэшку, а чтобы удовлетворить все BIOS, полупил поочерёдно по F2 и Del; прочитал, что нажать для boot menu, и нажал» разница катастрофическая.

Гораздо большая проблема это плохая документация и ошибки в чипах когда сложно понять где именно происходит проблема.

Тут согласен, влияет существенно. Сам помогал мучиться :) сидели кружком, пытались разгадать, где могла быть опечатка или что могли исправить, не откорректировав документацию. Стандартная проблема «мало кто любит и умеет писать документацию» усугубляется тем, что внутрь микрухи не залезешь с программным отладчиком, да и аппаратные строить сильно сложнее (процесс не остановишь, частоты безумные, и т.п.)

Та же проблема что и с софтом. Sw engineer мучаются с тем что приходит от asic, fae с тем что пришло от sw.

Ну софт-то обычно откорректировать легче? Если на софтовой стороне не укумаренный дуболом, за пару дней можно уговорить :)

Там обычно где то у кастомера что-то случается. В лучшем случае fae с ним пообщался. Но не может справиться, есть логи, дампы какие-то. Приходит к sw engineer. А у него (у меня) своя работа, пытаешься из этих логов что-то понять. Если получилось — отлично, а нет то запрос кастомеру на какие-то эксперименты и на больше логов. Ну может за пару итераций все решится. А иногда понимаешь что дело не в софте. Начинаешь пытаться убеждать в этом asic, у которых своя работа и свои дедлайны. Получилось убедить хорошо. Они начинают расширять свои тесты которые они писали когда писали verilog, или оживляют fpga который использовали для симуляции чипа в начале, и добавляют в него сигналы на вывод. И все это затягивается и тянется и тянется. И когда кастомер жирный и проблема блокер, то и выхода нет кроме как её решить.

Ну и JTAG подебажить иногда помогает. Ну и встроенный отладочные debug bus которые на gpio внутреннее состояние чипа выведет, ну и logic analyser его подхватить и посмотреть. А вообще на одного дизайнера пишущего verilog несколько кто пишет тесты для этого verilog. А на них в несколько раз больше sw engineer, да ещё system engineer. И у каждого свой domain knowledge и каждый понимает только в общем что делают другие. А ещё убивает когда купленный IP со своими багами. Я вообще не понимаю как хоть какие-то результаты получаются с этим нагромождением :)

И в этом принципиальное отличие.

Все серию потребительских процессоров от freescale можно с пустой флешкой прошить через usb.

Например, два PLL должны быть инициализированы с разницей в частотах N:1

Обычно это делают hardware engineer, которому ты показываешь как менять битики, и дальше они делают это в обнимку с даташитом и схемой.
Возможно у вас другой опыт.

А когда ты вообще не можешь вместить код и данные

Тогда берешь МК размером больше. Часто они в пределах одного корпуса, все pin-2-pin compatible.

Но та математика, которая от разностных схем и до B-деревьев, это не та математика, что в EE.

Матрицы и графы это очень даже в духе EE.

Потому что «CS вышло из EE» это недопустимое упрощение.

Математика в EE очень даже используется, итого получаем что EE (где есть математика), вышла CS (где тоже есть математика), но вы говорите что CS произошла от математики, но другой. Ну ок.

Да. Но от того, что линукс, «пофиг какое железо» не становится.

Всегда можно найти экстремальный случай, но в большинстве случаев ты пишешь именно под linux api, а не под железо, и все сложность работы с железом, linux должен нивелировать.

Цілеспрямовано перетер вбудований

Как?

По факту це будеш робити саме ти

А мебель потаскать? А в офисе убрать-подмести? Уборщица заболела, пусть программисты этим занимаются, у них и так зарплата высокая.

А замовник cкаже — ні, треба цей, бо ми вже замовили партію

У меня были ситуации, когда от начала процесса, до его конца, менялись компоненты, но никто и никогда не покупал компоненты с расчетом на mass production.

а ще Кумар із конкуруючої команди сказав

Тогда слушайте не меня, а слушайте Кумара, в чем проблема?

Без низькорівневого досвіду людина просто буде сидіти за компом і винити всіх

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

В SoC если упёрся в железо то продолжаешь дальше оптимизировать в софте и пытаться все таки сделать. Цикл выкатки нового чипа длинный, новые маски дорого.
Если ты выпускаешь чипы то software engineer огромное количество времени проводят за отладкой. В моей области это несколько лет живешь с ним, где то год до того как он в силиконе пришёл с фабрики и после этого пару лет.

Если фичу может решать железо и это затратная фича, то ей будут делать offload и железо. Сделают это через год или через два, не важно, но это сделают. Перед этим могут потратить некоторое количество человекочасов на оптимизацию, но эта оптимизация будет по умолчанию хуже чем реализация в железе.

Согласно Спольскому основная разница не в том,

Нетч, это тоже самое, когда споришь о политике ссылаться Маркса как истину в последней инстанции. Всё, забыли о Спольском, нет никакого Спольского.

Я не ссылался ни на Маркса, ни на Спольского как на истину в последней инстанции. Я ссылался как на источник концентрированной формулировки того, что я видел. Да, я лично эмбедщиком не работал, только смотрел через плечо и слушал ругань :) Но считаю, что видел достаточно, чтобы делать выводы.
И забывать о Спольском я не собираюсь. Болтает он слишком много, да. Но среди этого попадаются несколько умных мыслей, которые имеет смысл сохранить — и схема «пяти миров» с их детализацией, считаю, входит в них — несмотря на то, что с появлением нынешнего веба и мобилок она сломана чуть менее, чем полностью. Тебе он не нравится — верю. Но для меня это не аргумент.

Тебе он не нравится — верю. Но для меня это не аргумент.

На секундочку, его размышления про тему эмбеддеда были 16 лет назад, которые на сегодняшний день невалидны полностью.

в сложности отладки

Зачастую сейчас средства отладки для эмбеддеда намного превышают качество таких же средств под десктоп. Например, взять нашу IDE с инструментацией выполнения задачи и всей системы в целом. Я даже иногда портирую опенсорс приложение в QNX, чтобы инструментировать его там и потом вкатываю изменения назад.

организации фидбэка

Сейчас non-connected устройств практически нет.

и часто — ограничениях в ресурсах

Тоже неправда, доступны системы под любые нужды, некоторые уделывают десктопные по наличию доступных ресурсов. Ограничения накладываешь ты сам.

обновления

Это первое, что делается на сегодняшний день при разработке эмбеддед системы.

Вы не напишите программу для стирки кружевного белья в машинке без знаний о текстиле и швейном деле. Не напишите ПО для станции автоматического полива растений без знаний по биологии.

Не напишите конфигурацию 1C без знания бухучета

Да блин, в инсте у нас был курс 1С, и перед ним был курс по бухучету, благо мама бухгалтер, на пальцах всё разжевала.

Если этот выбор окажется неправильным и аппаратных средств платформы не хватит, придется начинать работу с нуля на новой платформе

Ах, если бы это было самой большой проблемой :) Зачастую этот зло..чий квест приходится начинать совсем не с возможнoстей аппаратных средств. Корень проблемы в товарной доступности в необходимых количествах. В интернетике как бы есть тысячи железяк на любой вкус, успевай уносить. Но то в интернетике. В реальной жизни посмотришь на складские остатки у поставщиков, и всплакнёшь: выбор сразу сокращается раз в 20. (*).

Embedded-разработчик не работает с интерфейсом пользователя, базами данных или файлами сложных форматов.

Почему же, некоторые работают. Специально для них придумали и легковесный Immediate UI, и встраиваемые БД. Сложные файлы да, в embedded редкость, однако забористый сетевой стриминг сложных форматов данных — сплошь и рядом.

Вряд ли эта профессия подойдет любителям высоких объектно-ориентированных абстракций и теоретикам

Странное заявление. Тот же JVM как раз изначально придумывали под embedded, например. Или концепцию CSP. Так что и высоколобым теоретикам там есть место.

Аппаратные отладчики... сложности в том, чтобы организовать удаленную работу

Откройте для себя почту :) Если, конечно, разрабатываете сверхсекретную аппаратуру двойного назначения, или плату нового айфона, то да, с цитируемым пунктом не поспоришь.

(*): Понятное дело, что это проблема стартапов и прочей мелочёвки, крупняк над такими страданиями только посмеётся :)

Вы не напишите программу для стирки кружевного белья в машинке без знаний о текстиле и швейном деле.

Чтобы заниматься сексом нужно быть не менее чем кандидатом биологических наук.

ты просто завидуешь просто!

«Куда дальше? Строить космические корабли, например. Вообще, прогресс постоянно держит в тонусе, спрос на Embedded-решения растет. Кстати, использовать свои знания можно и для личных целей. Мой знакомый построил себе автоматизированную теплицу. Система выполняет все необходимые действия сама, а он приезжает исключительно собрать урожай». (Денис Глусский, GlobalLogic)
Мой знакомый построил себе автоматизированную теплицу. Система выполняет все необходимые действия сама, а он приезжает исключительно собрать урожай

This is how mad weed grows by its own :-P

Может его система еще и оповещает когда рядом полиция и сбор урожая, этой самой weed, не лучшая идея ?

Вы не напишите программу для стирки кружевного белья

якщо не помацаєте його на добрі сраці...

К сожалению в случае с Embedded, это именно так, количество нужных здесь знаний просто зашкаливает, а платят меньше любой джава макаки, паподокс однако. Кандидатом какой-то науки здесь не нужно быть, но быть на его уровне, и иногда даже и превосходить придётся. И да не поймите меня не правильно, я имею ввиду действительно специалиста который способен работать с любым МК и переферией.

а платят меньше любой джава макаки, паподокс однако.

Нет никакого парадокса. Это сознательный выбор макаки:

я имею ввиду действительно специалиста который способен работать с любым МК и переферией.

Тут нет никакого рокет сайнса, просто стык железа и софта. Переферий и МК — кот наплакал, их все можно выучить за пару лет, поэтому и зарплаты низкие. Нужно переквалифицироваться в high end embedded, где нет МК, есть полноценные SoC, периферий столько, что жизни не хватит всё выучить, полноценная ОС и т.п. Вот тут платят выше джавы макаки.

Ну... Я это примерно и имелл ввиду в целом, но ARMv8-A это тот же SoC, a cудя с этой статьи ЗП не особо впечатляет.

но ARMv8-A это тот же SoC, a cудя с этой статьи ЗП не особо впечатляет.

Я этого в статье не увидел, Renesas R-Car Gen3 только у GL, они недоплачивают своим эмбеддерам?

С дальнейшим развитием IoT, мехатроники.. все больше будут востребованы Embedded-разработчики. Так ещё 3-4 года назад на work были лишь единицы вакансий, сейчас уже десятки.

С дальнейшим развитием IoT, мехатроники..

Да нет никакого большого развития, просто больше стали говорить и ввели кучу новых базвордов, которые у всех на слуху. Из-за развития тулчейнов теперь IoT занимаются даже домохозяйки и .net девелоперы.

А что вы имеете против домохозяйки, которая реализовала простейший девайс, выполняющий требуемые для неё функции, или, например, ученого, который за короткое время самостоятельно, не прибегая к услугам электронщиков и программистов, сделал экспериментальную установку или провел опыт при помощи элементарных и доступных средств автоматизации? ))
По поводу кучи новых базвордов, согласен — вся теорбаза цифровой электроники прописана ещё в прошлом столетии (сегодняшний всплеск IoT и робототехники напоминает вторую волну популярности автоматизации с 60-70г. 20 ст.)

А что вы имеете против домохозяйки, которая реализовала простейший девайс, выполняющий требуемые для неё функции, или, например, ученого, который за короткое время самостоятельно, не прибегая к услугам электронщиков и программистов, сделал экспериментальную установку или провел опыт при помощи элементарных и доступных средств автоматизации? ))

ничего кроме того что они ничего не имеют отношения ни к embedded ни к программистам вообще ))

схемотехника с трассировкой, с эмуляцией и отладкой — удел не домохозяек)

А что вы имеете против домохозяйки, которая реализовала простейший девайс, выполняющий требуемые для неё функции, или, например, ученого, который за короткое время самостоятельно, не прибегая к услугам электронщиков и программистов, сделал экспериментальную установку или провел опыт при помощи элементарных и доступных средств автоматизации? ))

Нужно просто называть вещи своими именами. Там нет никакого эмбеддеда, ни по духу, ни по факту, просто дали возможность всем подряд что-то делать на маленьком устройстве, также как и написание формулы в экселе не делает каждого разработчиком, хотя они и запрограммировали эксель на выполнение нужных им действий.

Одно время (лет 6-8 назад) была очень популярна плата BeagleBone Black (BBB). Которая даже очень нравилась мне самому. Она стоила 40 долларов, против 1000 на подобном, но уже OMAP процессоре, но для индустриальных применений, чем подстёгивала многих, даже вполне серьёзных и уважаемых заказчиков делать прототипы на нём. Нас начали все прессовать по поводу BSP для этой платы, я делал графику и все драйвера под QNX для неё. Она могла тянуть даже Full HD разрешение и относительно сложную графику в нём. Но ... кроме этого она делать больше ничего не могла, пропускная способность по памяти у этого чипа ниже плинтуса. Построить медиа-плеер на базе BBB — нефиг делать, а вот если добавить туда что-то ещё, например, камеру, то всё умирало, чуть увеличили разрешение видео и производительность упала в десятки раз — чип упёрся в свои барьеры. Даже андроид запустить на нём было тяжело, люди использовали специальные облегчённые древние сборки. Отдельным гвоздём в гроб шла стабильность этого процессора — она была никакая, под нагрузкой он еле отрабатывал часов 8 до сбоя. Прокатилась огромная волна разочарования среди заказчиков, все повздыхали и забыли как страшный сон.

Делает ли тех, кто возится с этой платой эмбеддерами? Нет, не делает, т.к. они не представляют и 10% того, что находится под капотом и как оно работает. От прототипа на столе до индустриального применения целая пропасть. И что меня очень сильно лично раздражает, так это количество дурней, которые носились с этими платами (да и многим другим ширпотребом, типа малинки) по различным предприятиям в Украине, предлагая удешевить всю автоматизацию в 10-20 раз, используя BBB.

Тем не менее эта плата до сих пор в топе у любителей повозиться с почти полноценным линуксом в крохотной плате, подключить какие-то датчики, различные устройства и т.п. Просто нужно знать своё место и отдавать отчёт в своих действиях, где заканчивается аматорство и начинается профессионализм.

Кто-же спорит, что применение и разработка платок — разные вещи? Но и распространение подобных платок стимулирует к разработке новых со всеми сопутствующими.

Эталон, Витя, эталон!

С дальнейшим развитием IoT

ну да ну да )) сегодняшнее «развитие иОт» это «подключить твою ардуинку в облаку помигать светодиодом через айфон» (к) (тм)

Все верно — деток в школах по всему миру начинают и обучают подобному. А в верхнем контексте имею ввиду рост количества и разнообразия девайсов и систем, которые постоянно разрабатываются .

деток в школах по всему миру начинают и обучают подобному

это такое же ж «общее обучение» как и литература и экономика в рамках школьного курса литературы и экономики.

Хороший подход в обучении. Когда-то также начинали с радиокружков и радиоконструкторов на основе простейшей элементной базы.

на основе простейшей элементной базы.

Угу угу и что сейчас многие смогут построить детекторный приёмник? ))

На картошке легко)

вот зачем ты Philips Hue обижаешь?)

Защекотать кружевами до смерти.

Включить подтягивающий резистор

Чтобы заниматься сексом нужно быть не менее чем кандидатом биологических наук

Займатись сексом і програмувати автомат, який займається сексом, це дуже різні речі.

Підписатись на коментарі