Comments 17
Искренне рад за вас, и за ваш новый выбор. Обладая багажем знаний очень сложно бывает сменить вектор работы.
Еще рад за вас потому что ваш стол наконец-таки станет свободным от программаторов и всяких плат с бп.
Скажите, вы тоже в своей жизни искали что-то не обычное и посложней когда были юны?
На последнем проекте была плата из 2-х мк nrf + stm32, а третим был мобильный проц под управлением android. Все это требовало своих тулчейнов. AOSP это отдельная басня, и как ее собрать. Некоторый код был разделяемым, типа protobuf, подключаемые исходники либ из других репозитариев. Это конечно ад адский, все это собрать. Для сборки всего этого использовали отдельную билд систему. Из удобств было разве что OpenOCD был собран под android, и можно было прошить контроллеры. А вот дебажить через него скорее нельзя было, из-за сложных межпроцессных коммуникаций.
Аналогичная фигня с попыткой перейти в Linux embeded. Тонны спагети кода, тонны обвесов, повальное применение Питона, и всё это на мелко-контроллерах по своей сути. Куча чуждых и избыточных протоколов, вместо того, чтобы просто общаться с драйверами напрямую, ну и .. ни разу не RTOS, со всем вытекающим.
И точно также постоянная переработка, постоянное гугление и часто "на ровном месте".
Embedded, как и front-end, как известно, являются филиалами ада в разработке. Хаос, слабая оплата и тп. Есть относительно тихий и уютный островок в этом море безобразия и это backend.
По своему опыту, могу сказать, что зависит прямиком от того, куда вы попадете — в продуктовую команду или проектную. Судя по моему опыту в полу-проектной команде, есть огромные шансы так же не всегда поспевать за темпами разработки и одновременно изучать то, над чем ты работаешь, более глубоко.
Так что даже бекенд может быть не таким уютным.
Много лет наблюдаю за всякими программистами (я и сам в некотором роде программист). И заметил некоторую интересную особенность (она, конечно, не претендует ни на что).
Так вот, есть такой навык как чтение чужого исходного кода. Вроде бы как ни у кого не возникает вопроса зачем это надо. Я и сам считаю, этот навык одним из самых важных. И вот я заметил, что программисты "больших" вычислительных систем читают чужой исходный код намного проще, легче и самое главное спокойней. А программисты всякой микроконтроллерной мелочи как только видят чужой код сразу впадают в пессемизм, который довольно часто заканчивается "я лучше сам все напишу с преферансом и профурсетками". Понятно, что это не абсолютная истина и с обеих сторон есть обратные примеры, но "статистически" выглядит именно так.
Для себя этот феномен я назвал "ограничение на сложность". И этот феномен тесно связан с возможностями постигать чужой исходный код. Так вот, программирование МК это не сложно, а вот создание ПО для больших вычислительных систем, это на порядки более сложная задача. При этом есть обратная корреляция, программисту больших систем, очень сложно дауншифтнуться на микроконтроллер, хотя казалось бы сложность меньше, а определенности больше.
Все это попытка, объяснить страдания автора.
К сожалению,разработчики не желают и не умеют писать документацию. Из-за подхода "вот вам код, читайте" другие вынуждены тратить излишне много времени на понимание как работать с разработанной кем-то системой/утилитой.
В линуксе чтобы разобраться как что-то сделать часто приходится собирать информацию по кусочкам и постоянно проверять актуальность на данный момент.
Соглашусь, но лишь отчасти. Будучи еще микроконтроллерщиком, мне приходилось перекапывать FatFS: изучать функционал и дополнять его. Так что с чтением больших блоков кода проблем не было. Была проблема скорее с системностью знаний, точнее несистемностью получаемых знаний по Embedded
Я бы еще добавил, про чувство "я лучше сам все напишу с преферансом и профурсетками" - вот на определенном этапе карьеры его пришлось прям перебарывать. В целом избавиться от этого ощущения довольно просто, нужно просто чуток дисциплины.
Вы весьма заблуждаетесь, если полагаете что работа разработчика Эмбеддед систем это просто написание кода. Могу вас заверить, что это лишь половина если не меньше. Огромное кол-во документации на все микросхемы по 300 страниц каждый минимум, аппноуты по интерфейсам чуть более сложнее чем стандартные UART / SPI / I2C, особенности их работы в конкретном микропроцессоре, ограничения аппаратной платформы, баги заложенные на этапе проектирования печатных плат, электромагнитная совместимость и частотные характеристики многих связанных узлов системы. Это все должно отражаться в вашем коде.
Владение асм, эмбеддед си, с++, Qt, аппаратными отладчиками - это все тоже должно быть.
Но самое главное это наличие подробной и стандартизированной документации. Что в ваших пресловутых "больших" вычислительных системах отсутствует как класс. Особенно если это опенсорс - там вообще хоть вешайся! Эмбеддед разработчик не обязан читать чужой код вместо документации, а лишь для внесения изменений в функционал, если это вдруг становится необходимо. Вы просто видимо не читали техническую документацию на промышленные системы. Кстати много лет наблюдаю за всякими программистами "больших" систем и глубоких абстракций, а так же за их феноменом "ограниченности технической документации")))
По факту я тоже не так давно перешел на Embedded Linux по надобности проекта, и так же прошел всю эту боль, как и автор. К примеру попробуйте сделать драйвер для межпроцессорного взаимодействия между CortexA (Embedded Linux) и CortexM (RTOS) внутри одного SoC кристалла. Изучите особенности работы вашего микропроцессора с адресами памяти, конвертируйте ваш линковочный файл для работы с CMA DDR. Разберитесь с библиотеками, зависимыми от аппаратной реализации, где нет ни то что бы документации, а даже комментариев. Соберите с этим драйвером ядро, добавьте туда ваш DTS файл для управления общими ресурсами (интерфейсы, линии, области ДДР памяти, области памяти ядра и прочее), внесите изменения в загрузчик, настройте всё соответственным образом в RTOS, используя прерывания периферийного модуля. Напишите демо с GUI для сенсорного экрана, в котором покажите как инициализировать и использовать добавленные в систему библиотеки для межъядерной коммуникации, сделайте несколько бенчмарков на аппаратных таймерах что бы прогнать всю систему в риалтайме. А так же не забудьте настроить JTAG debug для параллельной работы с CortexM при работающей Эмбеддед Линукс на CortexA.
А потом посчитайте кол-во кода, прикиньте его сложность с точки зрения алгоритмов и абстракций "больших" проектов - и основываясь лишь на коде дайте оценку проделанной вами работы. Не учитывая тонны документации, аппаратных особенностей и длительной работы с утра до ночи)))
В моей карьере эмбеддера только у одной компании было что-то похожее, что вы описали. Там был SoC со сдвоенным Cortex-M4 ядром, двумя DSP-ядрами и еще парой-тройкой других подсистем. Документация - референс-мануал на 6000+ страниц, в которой есть пробелы в описании подсистем. Исходники с примерами от вендора, чтобы запустить тесты и патчить под свои нужды. Оглядываясь назад на этот проект я даже доволен, что там не было Линукса, в противном случае утонули бы.
В том проекте мне, к сожалению, не довелось настраивать IPC, этим тогда занимался ведущий разработчик. Но, честно говоря, я только с одним Cortex-M ядром работал на тот момент.
Могу вам пожелать только удачи с этим Cortex-A + Cortex-M монстром. Но судя по тому, что вам нужно писать код для Cortex-M, да еще и загрузчик с ядром патчить для Cortex-A, да еще и морду прикрутить - моё почтение, меня бы инфаркт хватил, если честно.
По большей части, всё это именно так, как описано: тонны побочных знаний, даташитов и пр., что надо осваивать в embeded разработке, и всё это "узко применимо", практически ровно к одной системе. Для иного SoC всё надо начинать, по сути заново. Есть такое. Но свое разачарование отписал не за это. Это как раз нормально и штатно, как и желание велосипедостроения с преферансами и профурсетками. ;)
Хотел акцентировать иную сторону, а именно активное внедрение Питон, Джаваскрипт в ембедед, ещё и под Линукс. Да, возможности SoC растут, МК позволяет .. но всё это приводит к понижению, и часто катастрофическому, реализаций которые часто тебе выдают за "верх совершенства" и оно .. а точно также лишено документации, комментариев и пр. Бардак растет пропорционально росту возможностей SoC и наверное даже быстрее, увы. Вот это - проблема, кмк.
Где-то в 2018 или около, в свое первое погружение в ембедед на базе Atmel Mega 2560 с разработкой собственной платы "Ардуино Мега + 520кб SRAM" находил сравнение: в космос и на Луну летали процы и компы слабее типовой Ардуино Мега.. справлялись, однако. А сейчас? Джетсон Орин - справится? А с "современным ПО на Питон? ;)
Понимаю вас, классно что все наладилось.
А есть ли развернутый ответ или мысли на тему управленческого подхода? Мне казалось в современном ИТ так почти везде.
Очень жду продолжения. Спасибо.
Из всей этой лирики я вывел главное: переход на Linux был произведен "для интересу" а не из практической необходимости?
Страх и ненависть в разработке или как не надо входить в хату