В программировании микроконтроллеров (MK) нет как таковой общепринятой градации на Junior->Middle->Senior.
Давайте попробуем вместе разобраться, где же проходит водораздел между Junior->Middle->Senior программистом МК и что справедливо требовать от каждого из них?
Далее речь пойдет в основном про программирование микроконтроллеров. Тут не будет затронут Embedded Linux и разработка на FPGA.
Школьник из кружка робототехники (8-ой класс ГОУ СОШ)
Он умеет запустить примеры для PCB Arduino (UNO/Mega) в Arduino IDE на Windows. Может поменять константу в сорцах и прошить проект из-под IDE. При условии, что солнце под углом к горизонту примерно 38 градуcов. Всю программу пишет в одном лишь только main.c файле в котором уже 1000+ строк. C-код толком не понимает. Схемотехникой не интересуется. Если спросить какой у него на плате микроконтроллер, то школьник не сможет назвать PartNumber микросхемы.
Школьник не делает пошаговой отладки прошивки. Embedded школьник испытывает религиозный страх сломать что-то как в среднике века боялись ходить на кораблях в океаны.
Если школьнику надо передать прошивку другу, то школьник просто посылает код исходника одним мега-сообшением в мессенджере.
Когда embedded школьнику хочется открыть диспетчер задач, то школьник отчаянно нажимает разные комбинации тех четырех кнопок, что под монитором внизу справа.
А когда школьник поработает за ПК, он просто закрывает браузер выдерживает кабель 220 AC из розетки прямо перед заставкой запущенного рабочего стола.
Junior Embedded Рrogrammer *
Junior может работать только в какой-нибудь рафинированной проприетарной user friendly IDE (IAR, Keil, Atolic True Studio, Code Composer Studio). Поэтому его рабочее место стоит на 3k-4k EUR больше чем у Middl(a). Обычно умеет программировать только один единственный микроконтроллер из одного семейства. Например STM32F20xxx. И всё. Он не догадывается о существовании *.ld *.o *.elf файликов. Он знает только про *.с, *.cpp и *.h.
Junior не понимает make файлов. Для него содержимое Make это как китайские иероглифы для средневекового североамериканского индейца. Junior(y) не комфортно жить даже от того, что *.mk лежит рядом с его *.с/*.h файлами. Junior от этого не ест, ночи не спит. Лоб у него от makefile(ов) трещит...
Junior не догадывается о существовании такого формата как *.bin файл для прошивки. Junior видел только *.hex файлы прошивок. Если Junior(у) прислать *.bin файл с прошивкой, то он не поймёт, что с ним делать. Он ведь привык прошивать из-под IDE кликом на зелёный треугольник. А как прошить отдельно лежащий *.bin файл Jun знать не знает.
Причем Junior(ы) они такие смешные у них даже GUI-IDE открыта не на весь экран, а всего-лишь на 60-80% площади монитора, как какой-то там VLC player c крамольными новостями или что-то подобное...
Junior никогда не читал лог сборки проекта компилятором. Более того, Jun даже не догадывается, что компилятор вообще печатает какой-то отчёт.
Когда Jun собирает прототип, то он обычно выглядит как бесформенный клубок ниток. Пчелиный улей из проводов! Ещё Junior при сборке прототипа активно использует клей, гвозди, верёвки малярный скотч и т.п..
Я был свидетелем как один Jun в прототип устройства с шиной I2C совал выводные подтягивающие резисторы только потому, что он не догадывался, что микроконтроллер STM32 может устанавливать внутренние подтяжки программно на уровне SoC(а).
Если Junior поручить задание и не спрашивать сводки о прогрессе, то Junior будет делать задачу хоть до самой пенсии (40 лет none-stop). Причем задача может быть бесконечно простая, например, инвертировать байты в uint16_t или что-то в этом роде.
Embedded Junior не догадывается, что существует такое понятие как переменные окружения. Тем более он не знает для чего нужны переменные окружения.
Если embedded Junior(а) спросить какая у него сейчас система сборки для компиляции прошивки, то он даже не поймёт о чём идёт речь. Скорее всего ответит IAR, Keil или Cube-IDE.
Junior может пошагово отлаживать прошивку только в IDE. Будь то IAR или Keil. Junior(у) очень тяжело даже освоить IDE Eclipse. А если IDE не может открыть поврежденный *.xml или *.ewp файл с проектом для IDE, то у Junior(а) начинается паника, судороги и конвульсии.
Для него не существует ничего вне и за пределом IDE. Он видит только то, что в радиусе 2-3х сантиметров вокруг да около курсора. При этом Junior(ы) такие ленивые. У Junior(а), как правило, чувствительность мышки настроена в режим кометы. Если двинуть мышку относительно коврика на 1мм, то курсор на мониторе мгновенно улетает в соседнюю комнату! Один Junior как-то мне жаловался, что у него за день руки затекают. Это как раз потому, что Junior не двигает руками из-за высокой чувствительности своего курсора.
Jun не представляет как можно работать за компьютером без мышки, курсора и GUI(ни). Мечта Junior(а) это чтобы в следующую версию IDE добавили Mickey Mouse(а), который будет давать подсказки (hint(ы)) по разработке прошивки.
Junior может максимум писать однопоточный код. Junior не догадывается от том, что существует модульные тесты.
Junior плохо знает английский язык и поэтому пишет транслитом в комментариях и в компанейских чатах (павершел, бутлодэр, сериальник, KAН, ватчдог, юзать, инлайн, хидер, дифайн, тула). Junior глубоко убежден, что транслит в его исполнении - это самый правильный вариант транслита!
Junior не умеет читать схемотехнику. А если ему порекомендовать найти что-то в файле топологии, то он сочтет, что Вы его оскорбили! У него на жестком диске часто даже *.PDF со схемотехникой для платы, что на его столе тоже просто нет!
Как-то раз проходил мимо Junior(а), который анализировал схемотехнику. Почему-то он раcсматривал электронную плату вот с таких необычных кинематографических ракурсов. Junior абсолютно не понимает с какой стороны следует подходить к электронным платам.
Junior никогда не открывает datasheet(ы) на ASIC(и). Он просто ковыряет примеры проектов прошивки в IDE из интернета. Он нашел на форумах бинарную строку для прописывания 17 I2C регистров и тупо загнал её в память по I2C. Junior(а) даже не интересует в каком именно режиме работает ASIC.
Однажды у нас одного Junior(а) попросили написать драйвер для ASIC FM-Tuner(а) Si4737. Дак вот, Junior через 3-4 месяца написал драйвер, который позволял слушать только одну единственную радиостанцию! И пылко утверждал, что сделать переключение радиостанции в run-time это ну нереально трудно, практически невозможно.
А если Junior работает с аудиокодеком который может принимать данные либо по I2S либо по TDM, то Junior вам никогда не сможет толком ответить на простой вопрос по какому именно интерфейсу сейчас у него, собственно, передается звук. Также Jun не знает какой частотой тактируется ASIC. Если спросить Junior(а) на какой частоте у него работает ядро микроконтроллера, то он тоже не сможет ответить на этот вопрос. Junior бесконечно далек от физики происходящего.
Я был свидетелем как один Junior пытался подключить CAN шину в физику 100-Base-TX (Fast Ethernet)! Cмастерил переходник c клеммников витой пары c CAN на разъём RJ45 и удивлялся почему не работает отправка пакетов!
Однажды мне в наследство достался проект от Junior разработчика. Человек работал над проектов полтора года! Я взял плату. На PCB было два LED, UART и пр. Junior сказал, что там осталась его прошивка. Представьте себе, когда я подал питание на PCB LED светодиоды не мигали! В единственный UART не печатался никакой лог загрузки! Это как?... Как Jun отлаживался? Очевидно, что Jun всё и всегда запускал наугад вслепую и просто молился какому-то божеству. У одного знакомого Junior(а) я даже видел на рабочем столе музыкальный бубен! Да, вот так... Дело в том что типичный Embedded Junior верит в экстрасенсов, астрологов и нумерологов. Ну это и понятно, ведь когда в программе отсутствуют модульные тесты только и остается, что призывать всяческих эльфов...
Если Jun(на) попросить написать драйвер например для микросхемы at24c02, то Jun по ошибке вообще напишет драйвер для другой микросхемы, например at24c256. Причём первый результат покажет через месяц. Junior(ы) - они не понимает классификации микросхем. Junior(ы) никогда не проверяют маркировку микросхем. Ему, Jun(у) не стоит доверять писать драйверы ASICSs. Пусть пишет лучше MCAL покак не доведёт это до автоматизма.
Про то как Junior пишет код можно сочинять анекдоты:
--У Junior(а) на диске только один проект. Одна единственная сборка-Франкенштейн. И Junior собирает её одновременно для всех электронных плат, нескольких разных микроконтроллеров поочерёдно меняя что-то в *.h файлике перед прошивкой. При этом собирается всё, как то, что нужно так и то, что не нужно. При этом Junior убежден, что это его решение c *.h файликом гениальное.
Метафорично выражаясь, у junior программиста-микроконтроллеров всего лишь одна прошивка-Frankenstein для всех электронных плат и для всех проектов.
Ох если бы Jun создал хотя бы две сборки, то он бы увидел, что конфиг для электронной платы можно вынести в отдельную папку. Если бы Jun создал 3 сборки, то он бы увидел, что конфиг для микроконтроллера можно тоже вынести в отдельную папку. А пока у него одна сборка, то и код у него валяется в одной мега-куче.
--Еще Junior любит вставлять #include(ом) *.с файлики!
--У Junior(а) на плате один микроконтроллер (например STM32F413ZGJ6), а собирает проект он для другого микроконтроллера (например STM32F207VG). Junior об этом естественно не догадывается. Программа не зависает только лишь из-за обратной совместимости между ARM Coretx-M3 и ARM Coretx-M4.
--Jun в обработчике прерываний вызывает печать логов в UART!
—Junior в обработчике прерываний делает вычисления с плавающей точкой!
--Jun прописывает в настройках IDE абсолютные пути и поэтому его IDE проекты не собираются на компьютерах у коллег и последователей, так как его папки с транслитом в названиях просто уникальны!
--Embedded Junior не знает такого понятия как абстрактные структуры данных (ADT). Поэтому Junior не понимает разницы между циклическим буфером и очередью (FIFO).
--Junior в принципе не воспринимает чужой код, если в коде нет комментариев.
--У Junior(а) 80...90 % кода сохранены в папке utils (utility/helpers/miscellaneous/misc). Он просто не может классифицировать код по логическим компонентам и просто кидает всё в одну мега кучу.
--Если Junior(у) в коде заменить tab(ы) на пробелы, или сделать перенос фигурной скобки на строку c именем функции, то Junior полностью перестанет понимать код. Как будто он стал быть написан на другом языке программирования.
--Junior передает конфиги в сборку через (про)hard code(женые) константы разбросанные по всей прошивке.
--Вот так Junior вставляет и исключает код в проекте if(0){...} if(1){...}. Jun просто не подозревает о наличии препроцессора.
if(1){
... some code...
}
if(0){
... some code...
}Когда Junior(у) надо найти конкретную функцию, то он открывает встроенный в IDE поиск и набирает ключевое слово.
Junior не догадывается, что существует консоль и утилиты консоли. Он даже слов таких как "консоль" ещё не слышал, разве, что на курсе сопромата в ВУЗ(е).
А если ему кто-то из смежников будет доказывать пользу UART Shell(а) в прошивке, то Junior будет резко-агрессивно осуждать это. Будет утверждать, что ему, якобы, полностью хватает пошаговой отладки в GUI-IDE (кнопка F11 в IAR). На самом деле Jun просто понятия не имеет как реализовать TUI(UART-CLI) в прошивке. К слову, Jun частенько пользуется printf отладкой в UART и выглядит это как ниагарский водопад из белых логов, к котором даже прочитать ничего не успеваешь. А то, что это его художество нагружает процессор Junior(а) абсолютно не волнует. Большинство Junior(ов) даже не знают про утилиту Tera Term.
Junior не пользуется UART-CLI только лишь потому, что он не может её реализовать.
Один знакомый Junior на третьем году работы с удивлением для себя узнал, что в релизных прошивках продукта компании есть on-chip NVRAM. При этом на планерках раз в месяц регулярно упоминали про существование этой NVRAM. Junior абсолютно не интересуется структурой компанейского репозитория.
Junior не понимает 80% акронимов, которые слышит на работе и его это даже не беспокоит. Junior не владеет терминологией из Computer Science (CS). NVRAM он почему-то называет memory-manager. Когда Junior что-то излагает, то его не может понять ни Middle ни Senior. Junior как собака: если что-то понимает, то объяснить ничего не может.
Junior(у) надо объяснять всё максимально подробно. Буквально какую папку открыть и в каком файле, что изменить.
Junior в компанейском мессенджере вместо того чтобы писать текстовые сообщения посылает сообщения голосом (аудио дорожки).
Также попадаются некоторые Junior(ы) которые пытается компенсировать отсутствие компетенций через лесть.
Junior умеет создавать проекты только путем скачивания примеров из интернета и ковыряния в них. Девиз Junior - "ковыряться в примерах до победного!" Jun может максимум сгенерировать проект для IAR из STM32 Cube MX и при этом гордится этим как будто стал каким-то маэстро. При этом Junior потом 2-3 дня хвастается коллегам, что вот он смог аж сгенерировать проект из STM32 Cube MX для IAR! О-го-го!!
Для Junior(а) часто проблема в том, чтобы просто довести сборку до компиляции без ошибок. Не говоря уже об отладке в run-time(е). Jun обычно неделю борется с одной ошибкой компилятора, которая мешает ему наконец пере прошить микроконтроллер.
Junior часто программирует под музыку. Ему никак это не мешает сосредоточиться на алгоритмах и структурах данных.
Junior в принципе не понимает конечно автоматной методологии разработки программ (FSM). Поэтому ему не стоит доверять разработку программных компонентов в основе которых лежит конечный автомат.
Jun часто не понимает legacy код. Но это даже не проблема. Проблема в том, что Jun не может даже сформулировать, что именно он не понимает в legacy коде как письменно, так и устно.
В мире Junior(а) микроконтроллер это просто
Волшебная коробочка, которая исполняет мой С-код
Если Junior(а) попросить прислать фото электронной платы, то Junior присылает фото только с одной стороны. Junior не догадывается, что у платы есть ещё обратная сторона и что там тоже припаяны микросхемы.
Если даже не смотреть код Jun(а), а просто взять прототипы его функций и покрыть их модульными тестами, то выяснится, что у Jun (а) мало того, что вообще ничего не работало, дак еще и код сваливается в HardFaultISR-исключения.
Junior работает с кодом только локально. Junior не умеет пользоваться системами контроля версий как SVN или GIT. Он не может совладать с GIT(ом). А когда надо передать сорцы другому разработчику, то Junior скопает всё на USB-flash(ку), весь SDK c объектниками на 16+GByte. Или отправит Вам этот много гигабайтный *.zip архив по e-mail почте. В лучшем случае положит архив в DropBox или яНДЕКС Диск.
Даже если бы Junior вдруг узнал про GIT, то он бы стал подвергать версионному контролю исключительно только *.с и *.h файлики. А пользуется GITом Junior только из GIT GUI. Мышкой. При этом Junior обычно делает git pull раз в две недели, а потом жалуется всем, что появилось уж слишком много изменений.
У Junior(ов) как правило проблема с запоминанием паролей. Junior даже не помнит своего пароля для github. Каждый раз когда ему надо зайти на github Junior нажимает на кнопку восстановления пароля по e-mail.
Что можно доверить Junior(у)?
На самом деле очень много чего полезного. Главным образом это писать MCAL драйверы для какой-нибудь простенькой аппаратной подсистемы на SoC(е). Это может быть MCAL драйвер для GPIO, SPI, PDM, I2S, I2C, ADC, DAC, I2C, UART, AES, RTC, Timer, PWM для конкретного микроконтроллера. Драйвер в хорошем смысле-слова с конфигом, диагностикой командами CLI и модульными тестами.
Максимум, что можно доверить Junior(у) это писать MCAL. Или написать простой драйвер, например для микросхемы RTC где 7-12 регистров. причем, чтобы написать драйвер GPIO (400 строк) Junior(у) понадобится 3-4 месяца.
Причем всё потом придется проверить Middle(у). При этом Junior обычно жалуется и негодует, что Middle предлагает много поменять. Junior агрессивно спорит с Middle(ом). Junior обижается. Junior не понимает, что не так. Junior считает, что он всё сделал единственным правильным образом с первого раза!
По хорошему надо, чтобы Middle сам вручную прописал Junior(у) прототипы всех ключевых функций, а тело позволить Junior(у) написать самому. Иначе Junior напишет ну полную ахинею, которую потом придётся полностью переделывать Middle(у).
Работать с Junior(ом) трудно, порой тяжко. Хорошо, когда Jun готов учиться и учится. Плохо, когда попадается упрямый Jun.
Junior не пишет документацию к коду. Junior очень агрессивно относится к просьбам составить хоть какой-то текст или инструкцию про его прошивку или программный компонент.
Также Junior не пишет постов так как ничего толком ещё не знает. Плюс у него большие проблемы с грамотностью и пунктуацией. Да и вообще, мысли излагать Junior не умеет. Ему трудно связать даже три-четыре предложение в единый параграф. Junior убежден, что habr - это развлекательный сайт. А то, что там есть функция вставки формул на LaTex он естественно не знает.
Middle Embedded Programmer ***
Когда Middle приходит на работу, он первым делом открывает сервер сборки (например Jenkins) и смотрит, что поломалось в результате ночных тестов. Далее он чинит что-то, делает fix -коммиты и уже в 11:00 приступает к задачам из backlog(а) что у него записано в Kanban board(e).
У Middle разработчика прототип выглядит аккуратно. Middle умеет чертить детали и все прототипы собирает на подложке из плексигласа (оргстекло). При сборке прототипа Middle использует такие детали как стойки, болты, гайки и шайбы. Прототип Middle(a) на 100% удобный, разборный и ремонтно-пригодный.
Middle пишет на С или С++, умеет читать аssembler и четко понимает какой путь проходят сорцы в пищеварительной системе данного ToolChain(а) с момента написания до исполнения кода во flash микроконтроллера. Middle умеет писать не только С-код, но и скрипты сборки на Make, Ninja и СMake.
Он также покрывает свой и чужой код модульными тестами и умеет пользоваться интерфейсом командной строки поверх UART. https://habr.com/ru/post/698092/
Он умеет написать хороший компактный загрузчик с шифрованием и аутентификацией. https://habr.com/ru/articles/754216/
Умеет пользоваться GIT(ом).
У Middle много паролей и все разные. Поэтому он просто пользуется аппаратным менеджером паролей.
Может отличить аппаратную ошибку от программной. Может выполнить bring-up платы с производства.
Middle отлично ориентируется в схемотехнике цифровых электронных цепей. Он даже может найти в топологии оптимальное и удобное место, чтобы установить туда щуп осциллографа для верификации сигнала.
Middle использует clang-format для автоматического выравнивания отступов. Код у него аккуратный и чистый.
Middle собирает код из общей пере используемой кодовой базы. Добавление новой сборки у него сводится к тому, чтобы просто написать крохотный makefile (12 строк) c конфигами. Вся сборка у него из makefile https://habr.com/ru/post/723054/
У Middle(а) в репозитории много сборок. На все случаи жизни. Сборки появляются и исчезают как вспышки на Солнце. Для каждой платы в отдельности у него есть загрузчик, mbr, generic, assembly test, debug, release. Каждая сборка собирает только то, что нужно здесь и сейчас и в ней нет ничего лишнего. Так он гарантирует модульность кодовой базы. Всё собирается и никто ни с кем не конфликтует. https://habr.com/ru/post/689542/
Middle может не просто написать код. Он может оформить код в аппаратно-независимый программный компонент с конфигами, диагностикой, CLI командами, тестами. Далее этот компонент можно будет легко конфигурировать, мигрировать, масштабировать и, что важно - тестировать. https://habr.com/ru/articles/683762/
У Middle(а) в прошивке всегда есть NVRAM для хранения параметров. Это позволяет ему уменьшить количество сборок. https://habr.com/ru/post/706972/
Middle хорошо понимает архитектуру одного процессорного ядра до уровня ALU (чаще всего ARM Cortex-M4) и знает, что происходит с микроконтроллером между подачей питания и запуском функции main(). Также Middle четно представляет, что происходит с микропроцессором между нажатием на кнопку в PCB и запуском прерывания по внешнему аппаратному прерыванию, и как процессор потом возвращается обратно в функцию main().
Middle активно пользуется консольными утилитами из CygWin(а) или MinGW: grep, find, cat, awk, sed, sort, curl, wc, uniq. Он также умеет составлять и применять нетривиальные регулярные выражения. Middle пользуется GIT исключительно из командной строки. Находит ступенчатым grep(ом), что нужно и делает очень прицельные коммиты.
Middle практически не использует пошаговую отладку через SWD/JTAG. Разве, что для запуска и отладки UART. Далее он ориентируется на интерфейс командной строки CLI поверх UART, уровни логирования и модульные тесты, которые он добавил в сборку и вызвал из командной строки поверх UART. https://habr.com/ru/post/694408/
Middle может модифицировать существующую сборку с RTOS, но сам завести любую RTOS скорее всего нет.
Middle может проектировать конечный автомат, или транслятор сложного синтаксиса и реализовать его в прошивке.
Он может отладить платформа-независимый код на laptop(е) в отдельной сборке прошивки для x86.
Middle может добавить Job(ы) на сервер сборки Jenkins.
Middle передает конфиги в сборку через *.mk файлы.
У каждого Middle присутствует склонность в какую-нибудь конкретную и достаточно узкую предметную область и глубокая экспертиза в ней. Будь-то понимание глубоких принципов GNSS навигации, инерциальные навигационные системы (INS), беспроводные радио интерфейсы, РЛС, АФАР(ы), радио электронная борьба (РЭБ), цифровая обработка сигналов ЦОС/DSP, гидроакустика, пластиковые карты с чипом, SIM карты, контрольно-кассовые терминалы, сетевые протоколы, аудиотехника, управление электродвигателями (BLDS/SеpperMotors и т.п.), управление инжекторным ДВС, Battery Management System (BMS), DC->AC инверторы, баллистические вычислители, головки само наведения ракет (ГСНы), электро-кардиография, дозиметрия, астрономические спутниковые вычислители, теория автоматического управления (ТАУ, LQR), криптография, ядерный магнитный резонанс (ЯМР), формальные грамматики и тому подобное. Да всё что угодно, где так или иначе работают микроконтроллеры.
Дело в том, что программирование - это всего лишь инструмент, своего рода, отвертка. Настоящую же материальную ценность представляют именно предметные знания.
Программист МК без экспертизы в какой-либо предметной области это однозначно Juniour.
В целом Middle прекрасно понимает, что такое нормальная прошивка https://habr.com/ru/post/655641/ и следует лучшим традициям в разработке firmware. Работать с Middle всегда легко и здорово!
Что можно доверить Middle(у)?
Настроить toolchain для очередного чипа. Выполнить bring up платы с производства, написать загрузчик с обновлением по воздуху, написать драйвер сложного spi чипа, проектировать конечный автомат для подавления дребезга, реализовать цифровой фильтр, написать модульные тесты для драйвера. Перенести код на другую аппаратную платформу или перевести на MISRA совместимость. Реализовать бинарный протокол для общения между платками. Написать парсер nmea пакетов. Реализовать cli.
Middle в основном не пишет постов на habr так как опасается делиться экспертизой. Middle боится конкуренции как огня.
Senior Embedded Рrogrammer *****
Senior чётко понимает отличия всех известных процессорных архитектур 8051, ARM, SPARC, PowerPC, MIPS, RISC-V, Xtensa между собой.
Senior спокойно пишет прошивки с RTOS(ами): RTEMS, Zephyr RTOS, TI-RTOS, FreeRTOS. Причем он может завести любую существующую RTOS на любом существующем MCU любого вендора с чистого листа, а не взяв примеры из интернета. Senior пишет реентабельный и потоко безопасный код.
Он собирает код сразу двумя-тремя компиляторами: GCC, TCC, Clang, GHS и т.п. Cборка двумя-тремя компиляторами позволяет ему найти больше ошибок. https://habr.com/ru/post/656449/
Senior передает конфиги в сборку прошивки через Linux(овые) механизмы, такие как Device Tree и Kconfig.
Senior(у) не нужна мышка для работы на компьютере. Он всё может быстро сделать из консолей или утилит типа far manager.
Senior понимает, что происходит на уровне ABI. Senior может, например, добавлять в прошивку функционал путем добавления бинарей в RAM память из SD-карты прямо в run-time без пере сборки всего проекта, подобно тому как в Linux подгружаются модули.
Senior может загрузить скомпилированное приложение в *.bin файле по любому смещению в Flash памяти микроконтроллера путем модификации адресов таблицы прерываний в *.bin на лету. https://habr.com/ru/articles/575014/
Он умеет на пустом месте настраивать полный DevOps, например в Jenkins. Причем OS не имеет особого значения, что Linux, что Windows. Он пишет скрипты для автосборки на Python, скрипты авто развертывания через загрузчики и скрипты запуска автотестов из CLI. Между платами передает данные по Protobuff. https://habr.com/ru/post/695978/
У Senior тоже много паролей. И он тоже пользуется аппаратными менеджером паролей. Вот только прошивку для аппаратного менеджера паролей он собирает сам из сорцов. Это дает ему полную гарантию и контроль над процессом и возможность добавлять custom функционал для DevOps процедур.
Senior пишет код генераторы, например, для синтаксического разбора CAN пакетов, или карты регистров сложных SPI/I2C/MDIO чипов.
Senior может обновить прошивку через audio кодек. То есть передавать прошивки по воздуху звуком. От смартфона в embedded устройство. За счет специфической модуляции, которую генерирует звуковая карта на плате (или waw файл на смартфоне) и специального DSP алгоритма внутри прошивки, который распознает байты из FSK(OOK) модуляции в аудиодиапазоне.
Senior знает каждую опцию компилятора и может, например, построить таблицу-отчет сколько времени компилировался каждый *.с файлик.
Он умеет снимать code coverage после прохождения модульных тестов. Находит сколько раз прошивка прошла по каждой строчке, находит код, который не исполняется и удаляет его.
В коде, когда Senior обходит матрицу NxM, он перебирает элементы зигзагом по диагонали от верхнего левого угла. Так он быстрее находит нужный элемент в таблице.
Когда Senior пишет драйвер аппаратного PWM, то он первым делом реализовывает функцию установки произвольной фазы сигнала.
Senior знает как работает JTAG под капотом (установка точки останова). Senior может пошагово отлаживать прошивку прямо из командной строки, вообще без какой-либо IDE. ttps://habr.com/ru/post/694708/
Senion может исполнять прошивки прямо на PC. Он cоединяет PC и Target-PCB интерфейсом JTAG через микросхему переходник USB-JTAG (FT232H), пишет на DeskTop консольное приложение симулятор прошивки с CLIшкой в stdin/stdout и прокручивает код прошивки без прерываний прямо на NetTop(e).
При этом на MCU отрабатывает вся аппаратура (GPIO, I2C, SPI, PLL). Переходник USB-JTAG, по сути читает и пишет физическую память микроконтроллера. Senior через интерфейс JTAG получает тотальный доступ ко всем внутренностям микроконтроллера (GPIO, SPI, PLL, RCC, UART и прочее). Если говорить метафорами, то получается, что у Senior(a) микроконтроллер - это марионетка. Вместо куклы микроконтроллер, вместо ниточек 4 провода JTAG. А кукловод это Host PC.
Senior пишет embedded код учитывая мировые индустриальные стандарты качества софтвера: MISRA, CERT, ISO26262, DO-178C, AUTOSAR.
Кода Senior собирает прототип прибора, то прототип приобретает третью размерность и получается в виде сэндвич конструкции, которая выглядит компактно и функционально.
Или вот так. Дело в том, что Embedded Senior умеет чертить механику в CAD ПО (например Moi-3D). И умеет делать заказы на лазерную CO2 резку на profi.ru в своём городе. Поэтому его прототипы выглядят удобно и стильно!
Что можно доверить senior(у)?
Настроить надёжную makefile сборку с какой-нибудь RTOS, с диагностикой, с тестами с конфигурацией из Device Tree и Kconfig, под пару компиляторов. Настроить загрузку бинарных модулей для микроконтроллера, подобно тому как Simens телефоны могли подгружать приложения без перепрошивки. Развернуть полный DevOps в организации на отдельном NetTop компьютере. Настроить среду Gerrit для инспекции программ. Снять code coverage после тестов. Написать кодогенератор для разбора пакетов. Проводить ежедневные короткие планёрки среди программистов. Содействовать при найме программистов.
Senior пишет посты на habr. Он заинтересован, чтобы его окружение было способными и чтобы с ними было комфортно работать.
Вывод
Junior относится к коду как ребёнок к пластилину. Он лепит и приговаривает: "A ладно, и так сойдет".
Middle относится к коду как писатель к прозе. Всё грамотно. Мысль передана, но можно было и по другому сделать.
Senior относится к коду как конструктор к чертежу. В его коде нет ничего лишнего. Всё написано по строгим и обоснованным правилам.
Вот так я себе примерно представляю градацию навыков в разработке микроконтроллеров. Повторюсь, что конечно же всё очень условно.
Очень важно ещё отметить и осознавать, что функция Jun ->Mid ->Sen никак не привязана к опыту работы и стажу. В России я видел как 27-летних Senior(ов) так и 43-летних Junior(ов). Причём и первый и второй не меняли профессии начиная с 22х лет.
Если Вам известны другие атрибуты водораздела Junior->Middle->Senior программиста микроконтроллеров, то пишите, пожалуйста, их в комментариях.
А вот в этом реестре я привёл суммарный разбор навыков Junior->Middle->Senior, который буду пополнять по ходу времени.
Итак, суммируя вышесказанное:
Embedded школота - это Arduino, AVR.
Embedded Junior - это C, STM32, IAR, SPL, IDE, GUI, курсор мышки, транслит, пошаговая отладка, DropBox, магические циферки, спагетти код.
Embedded Middle - это ARM, C, GCC, UART-CLI, grep, Make, Cmake, uTests, GIT, NVRAM, FSM, RexEX, clang-format, GDB в CLI, BootLoader.
Embedded Senior - это PowerPC, RTOS(ы), Zephyr, ASM, C++, RTOS, DeviceTree, Kconfig, Ninja, Jenkins, DevOps, CI, CD, ABI, ProtoBuff, кодогенераторы, code coverage, ISO26262, AUTOSAR и т. п.
Словарь
Акроним | Расшифровка |
MK | микроконтроллер |
MCU | microcontroller |
ALU | arithmetic logic unit |
CS | Computer Science |
TUI | Text User Interface |
ЦОС (DSP) | Цифровая обработка сигналов (digital signal processing) |
IDE | Integrated development environment |
ARM | Advanced RISC Machine |
MISRA | Motor Industry Software Reliability Association |
RTC | Real Time Clock |
ТАУ | Теория автоматического управления |
PCB | Printed circuit board |
STM | Società Thomson Microelectronics |
UART | universal asynchronous receiver-transmitter |
MIPS | Microprocessor without Interlocked Pipelined Stages |
AUTOSAR | AUTomotive Open System ARchitecture |
ABI | Application binary interface |
RTOS | real-time operating system |
https://habr.com/ru/articles/668368/
https://habr.com/ru/articles/555498/
