Некоторое время назад я наконец‑то осуществил свою маленькую мечту — перешел с bare‑metal разработки для микроконтроллеров на работу с Embedded Linux. Причина заключалась в том, что работа с МК, как мне казалось уже продолжительное время, становилась однообразной: берешь очередной чип и документацию, поднимаешь на нём очередной UART / SPI / I2C, пишешь драйвера общения с устройствами и более‑менее несложный основной алгоритм. Хотя временами возникали интересные задачи, когда ты работаешь с незнакомым доселе интерфейсом, пишешь какой‑нибудь протокол или алгоритм верхнего уровня. Но такое случалось редко, а хотелось уже чего‑то более масштабного...
Итого имеем:
5+ лет работы с МК и причем только в нескольких IDE, без знаний CI/CD, контейнеров, утилит тестирования, фреймворков и т.д.;
профильное образование, которое вообще ни к селу, ни к городу, хоть и техническое и изредка помогающее;
устойчивое мнение, что реальные знания приобретаются в работе;
желание наконец-то вынырнуть из болота... в другое.
И вот наконец я оказался в новой компании с новыми задачами и с оговоркой, что без опыта в Embedded Linux, что в самом линуксе я далеко не продвинутый пользователь (ну там в терминале по директориям побегать, что-то удалить/создать, не более), но есть огромное желание развиваться, упорство и нескончаемые запасы вазелина стрессоустойчивость. Тут стоит добавить, что эта оговорка была сказана еще на собеседовании и вполне устроила соискателей. Кошмар начался с малого - с загрузчика.
Волею судьбы первый проект был связан с U-Boot чисто для того, чтобы было не слишком больно. Первые 1,5 месяца я работал только с ним, из которых 1 месяц - это внесение правок в загрузчик одновременно с привыканием к линуксу, командной строке, докеру, тоннам спагетти-кода, экзистенциальному кризису.
До сих пор помню мою первую попытку сборки загрузчика из исходников: проект не собирается, компилятор ругается на синтаксис, начинаешь рыскать в гугле в поиске ответов... Оказывается нужен тулчейн, гуглишь, что это такое и не понимаешь. Пишешь в поиске быстрого совета более опытным коллегам - ответ: "так а какой тулчейн ты используешь для сборки?"... Блин блинский, да кто такой етот ваш тулчейн?
Ладно, с этим разобрался, научился работать с докером (ну как я тогда думал) и задачу выполнил в поставленные сроки. Как выяснилось, это были цветочки...
После меня временно перекинули в другой отдел (на поддержание проекта после ухода сотрудника), в котором собиралась уже полноценная прошивка через Buildroot со всякими подмодулями, патчами и нефритовым стержнем. Да-да, взаимодействие с китайскими вендорами и их творчеством в виде процессоров, кода из костылей и неполной документации. Здесь я уже привыкал именно к работе в билдруте, а затем вернулся обратно в свой отдел работать с этим же процессором, но над другим проектом, к работе с драйверами, модулями, особенностями отладки. И вот это были уже ягодки...
Нет смысла пересказывать все события дней минувших, но, думаю, стоит сказать одну мысль: несмотря на то, что учиться нужно всегда, перед погружением в новую сферу следует всё-таки пару-тройку месяцев эту сферу хоть немного изучить. И не просто почитать, а именно потыкать - почитать литературу или глянуть видео-гайды на ютубе, затем попробовать сделать маленький домашний проект или на худой конец пройти онлайн курсы. Я это говорю для людей, которые начинают изучать новую специальность только после прихода в неё без предварительной подготовки. Таковым являлся я, так как считал, что лучшее обучение происходит в бою - если перед тобой ставится задача да еще и в сжатые сроки, то ты в лепёшку расшибёшься, но задачу сделаешь. Увы, это работает не всегда. Это работало только поначалу, потому что дальше происходят следующие процессы:
начинаешь систематически задерживаться на работе, так как тратишь больше, а иногда много больше времени на задачу, так как больше половины времени уходит на изучение инструментария, методов и т.д.
как следствие, накапливается усталость и свободное время (если таковое имеется) тратится не на то, чтобы с удовольствием изучить что-то новое, а на то, чтобы повтыкать в развлекательный контент
если продолжать с переработками в том же духе, накапливается апатия, мозг будто блокирует процессы обучения, любая новая задача превращается в стресс, что отражается и на личной жизни тоже
процесс обучение новому теряет какой-либо систематизированный вид - информация поступает урывками и только та, которая нужна конкретно для задачи. Целостного знания предмета, как такового нет
В результате возникает очень странная ситуация, когда ты вот казалось бы влетел в ту сферу, которая тебя так манила и звала, но... У тебя нет ощущения, что ты в теме хоть сколько-нибудь разобрался. Любой вопрос по теме ставит в ступор, так как ты попал в замкнутый круг: все силы тратишь на выполнение локальной задачи, и больше нет сил, чтобы сформировать глобальное знание.
Очень простая аналогия со спортом: прежде чем приступить к марафону, начни хотя бы с одного километра каждый день. И начни заранее, сильно заранее, чтобы не страдать на тренировках и не мучить свой неприученный к дистанции организм. Иначе просто будешь бежать от лавочки к лавочке (если они вообще по пути попадутся) и достигнешь цели очень и очень не скоро. Если вообще добежишь.
Подводя итог под выше упомянутым, очень хотелось бы сказать, что все невзгоды пройдены, атлант расправил плечи и гордо терпит все тяготы и лишения Embedded Linux разработки, но... оказалось, что у запаса прочности есть предел и выгорание меня добило. Впервые в моей карьере. Как позже выяснилось, причина была не столько в нехватке опыта, сколько в управленческой особенности "мало разрабов - много проектов". Описание причин по объёму тянет на ещё одну статью, но как говорил Леонид Каневский: "Это уже совсем другая история".
Спустя некоторое время после написания первой версии этой статьи я начал работу в другой компании с бОльшим количеством сотрудников, развитой корпоративной культурой и более спокойным темпом работы. Это всё та же работа с Linux, но уже далеко не Embedded
Если будет интересно, то можно выпустить продолжение в виде оценки управления командой со стороны разработчика
Комментарии (16)
VladimirFarshatov
16.08.2023 04:57+2Аналогичная фигня с попыткой перейти в Linux embeded. Тонны спагети кода, тонны обвесов, повальное применение Питона, и всё это на мелко-контроллерах по своей сути. Куча чуждых и избыточных протоколов, вместо того, чтобы просто общаться с драйверами напрямую, ну и .. ни разу не RTOS, со всем вытекающим.
И точно также постоянная переработка, постоянное гугление и часто "на ровном месте".
akurilov
16.08.2023 04:57+3Embedded, как и front-end, как известно, являются филиалами ада в разработке. Хаос, слабая оплата и тп. Есть относительно тихий и уютный островок в этом море безобразия и это backend.
anayks
16.08.2023 04:57+1По своему опыту, могу сказать, что зависит прямиком от того, куда вы попадете — в продуктовую команду или проектную. Судя по моему опыту в полу-проектной команде, есть огромные шансы так же не всегда поспевать за темпами разработки и одновременно изучать то, над чем ты работаешь, более глубоко.
Так что даже бекенд может быть не таким уютным.
andi123
16.08.2023 04:57+2Много лет наблюдаю за всякими программистами (я и сам в некотором роде программист). И заметил некоторую интересную особенность (она, конечно, не претендует ни на что).
Так вот, есть такой навык как чтение чужого исходного кода. Вроде бы как ни у кого не возникает вопроса зачем это надо. Я и сам считаю, этот навык одним из самых важных. И вот я заметил, что программисты "больших" вычислительных систем читают чужой исходный код намного проще, легче и самое главное спокойней. А программисты всякой микроконтроллерной мелочи как только видят чужой код сразу впадают в пессемизм, который довольно часто заканчивается "я лучше сам все напишу с преферансом и профурсетками". Понятно, что это не абсолютная истина и с обеих сторон есть обратные примеры, но "статистически" выглядит именно так.
Для себя этот феномен я назвал "ограничение на сложность". И этот феномен тесно связан с возможностями постигать чужой исходный код. Так вот, программирование МК это не сложно, а вот создание ПО для больших вычислительных систем, это на порядки более сложная задача. При этом есть обратная корреляция, программисту больших систем, очень сложно дауншифтнуться на микроконтроллер, хотя казалось бы сложность меньше, а определенности больше.
Все это попытка, объяснить страдания автора.
quaer
16.08.2023 04:57+2К сожалению,разработчики не желают и не умеют писать документацию. Из-за подхода "вот вам код, читайте" другие вынуждены тратить излишне много времени на понимание как работать с разработанной кем-то системой/утилитой.
В линуксе чтобы разобраться как что-то сделать часто приходится собирать информацию по кусочкам и постоянно проверять актуальность на данный момент.
Vanovsky714 Автор
16.08.2023 04:57Особенно выбешивало то, когда приходилось работать с разными версиями ядра и загрузчика, которые отличаются друг от друга значительно
quaer
16.08.2023 04:57+1Есть ещё проблема, что часто доки и книги написаны "снизу-вверх", то есть объясняют азы, потом переходят к верхнему уровню, тогда как для понимания удобнее наоборот - сначала общий вид, понимание слоев абстракции, подсистем, потом детали.
Vanovsky714 Автор
16.08.2023 04:57Соглашусь, но лишь отчасти. Будучи еще микроконтроллерщиком, мне приходилось перекапывать FatFS: изучать функционал и дополнять его. Так что с чтением больших блоков кода проблем не было. Была проблема скорее с системностью знаний, точнее несистемностью получаемых знаний по Embedded
Vanovsky714 Автор
16.08.2023 04:57Я бы еще добавил, про чувство "я лучше сам все напишу с преферансом и профурсетками" - вот на определенном этапе карьеры его пришлось прям перебарывать. В целом избавиться от этого ощущения довольно просто, нужно просто чуток дисциплины.
Stan88
16.08.2023 04:57+2Вы весьма заблуждаетесь, если полагаете что работа разработчика Эмбеддед систем это просто написание кода. Могу вас заверить, что это лишь половина если не меньше. Огромное кол-во документации на все микросхемы по 300 страниц каждый минимум, аппноуты по интерфейсам чуть более сложнее чем стандартные UART / SPI / I2C, особенности их работы в конкретном микропроцессоре, ограничения аппаратной платформы, баги заложенные на этапе проектирования печатных плат, электромагнитная совместимость и частотные характеристики многих связанных узлов системы. Это все должно отражаться в вашем коде.
Владение асм, эмбеддед си, с++, Qt, аппаратными отладчиками - это все тоже должно быть.
Но самое главное это наличие подробной и стандартизированной документации. Что в ваших пресловутых "больших" вычислительных системах отсутствует как класс. Особенно если это опенсорс - там вообще хоть вешайся! Эмбеддед разработчик не обязан читать чужой код вместо документации, а лишь для внесения изменений в функционал, если это вдруг становится необходимо. Вы просто видимо не читали техническую документацию на промышленные системы. Кстати много лет наблюдаю за всякими программистами "больших" систем и глубоких абстракций, а так же за их феноменом "ограниченности технической документации")))
По факту я тоже не так давно перешел на Embedded Linux по надобности проекта, и так же прошел всю эту боль, как и автор. К примеру попробуйте сделать драйвер для межпроцессорного взаимодействия между CortexA (Embedded Linux) и CortexM (RTOS) внутри одного SoC кристалла. Изучите особенности работы вашего микропроцессора с адресами памяти, конвертируйте ваш линковочный файл для работы с CMA DDR. Разберитесь с библиотеками, зависимыми от аппаратной реализации, где нет ни то что бы документации, а даже комментариев. Соберите с этим драйвером ядро, добавьте туда ваш DTS файл для управления общими ресурсами (интерфейсы, линии, области ДДР памяти, области памяти ядра и прочее), внесите изменения в загрузчик, настройте всё соответственным образом в RTOS, используя прерывания периферийного модуля. Напишите демо с GUI для сенсорного экрана, в котором покажите как инициализировать и использовать добавленные в систему библиотеки для межъядерной коммуникации, сделайте несколько бенчмарков на аппаратных таймерах что бы прогнать всю систему в риалтайме. А так же не забудьте настроить JTAG debug для параллельной работы с CortexM при работающей Эмбеддед Линукс на CortexA.
А потом посчитайте кол-во кода, прикиньте его сложность с точки зрения алгоритмов и абстракций "больших" проектов - и основываясь лишь на коде дайте оценку проделанной вами работы. Не учитывая тонны документации, аппаратных особенностей и длительной работы с утра до ночи)))Vanovsky714 Автор
16.08.2023 04:57В моей карьере эмбеддера только у одной компании было что-то похожее, что вы описали. Там был SoC со сдвоенным Cortex-M4 ядром, двумя DSP-ядрами и еще парой-тройкой других подсистем. Документация - референс-мануал на 6000+ страниц, в которой есть пробелы в описании подсистем. Исходники с примерами от вендора, чтобы запустить тесты и патчить под свои нужды. Оглядываясь назад на этот проект я даже доволен, что там не было Линукса, в противном случае утонули бы.
В том проекте мне, к сожалению, не довелось настраивать IPC, этим тогда занимался ведущий разработчик. Но, честно говоря, я только с одним Cortex-M ядром работал на тот момент.
Могу вам пожелать только удачи с этим Cortex-A + Cortex-M монстром. Но судя по тому, что вам нужно писать код для Cortex-M, да еще и загрузчик с ядром патчить для Cortex-A, да еще и морду прикрутить - моё почтение, меня бы инфаркт хватил, если честно.
Diversantos
16.08.2023 04:57+1Понимаю вас, классно что все наладилось.
А есть ли развернутый ответ или мысли на тему управленческого подхода? Мне казалось в современном ИТ так почти везде.
Очень жду продолжения. Спасибо.
NutsUnderline
16.08.2023 04:57Из всей этой лирики я вывел главное: переход на Linux был произведен "для интересу" а не из практической необходимости?
Vanovsky714 Автор
16.08.2023 04:57Да. К моменту перехода хотелось погружаться в Embedded Linux. В этом случае практическая необходимость создается автоматом, когда приступаешь к этим задачам
truebest
Искренне рад за вас, и за ваш новый выбор. Обладая багажем знаний очень сложно бывает сменить вектор работы.
Еще рад за вас потому что ваш стол наконец-таки станет свободным от программаторов и всяких плат с бп.
Скажите, вы тоже в своей жизни искали что-то не обычное и посложней когда были юны?
На последнем проекте была плата из 2-х мк nrf + stm32, а третим был мобильный проц под управлением android. Все это требовало своих тулчейнов. AOSP это отдельная басня, и как ее собрать. Некоторый код был разделяемым, типа protobuf, подключаемые исходники либ из других репозитариев. Это конечно ад адский, все это собрать. Для сборки всего этого использовали отдельную билд систему. Из удобств было разве что OpenOCD был собран под android, и можно было прошить контроллеры. А вот дебажить через него скорее нельзя было, из-за сложных межпроцессных коммуникаций.
Vanovsky714 Автор
Моя "карьера" в кодинге началась в школе с геймдева))))) Я тогда писал на Delphi игрушку-авиасимулятор для локальной конференции и это было не более чем увлечение. Уже спустя время, когда я погрузился в мир МК, не хватало того самого ощущения масштабности