В программировании микроконтроллеров (MK) нет как таковой общепринятой градации на Junior->Middle->Senior.
Давайте попробуем вместе разобраться, где же проходит водораздел между Junior->Middle->Senior программистом МК и что справедливо требовать от каждого из них?
Далее речь пойдет в основном про программирование микроконтроллеров. Тут не будет затронут Embedded Linux и разработка на FPGA.
Школьник из кружка робототехники (8ой-класс)
Он умеет запустить примеры для PCB Arduino (UNO/Mega) в Arduino IDE на Windows. Может поменять константу в сорцах и прошить проект из-под IDE. При условии, что солнце под углом к горизонту примерно 38 градуcов. Всю программу пишет в одном лишь только main.c файле в котором уже 1000+ строк. Схемотехникой не интересуется.
Junior Embedded Рrogrammer
Junior может работать только в какой-нибудь рафинированной проприетарной user friendly IDE (IAR, Keil, Atolic True Studio, Code Composer Studio). Поэтому его рабочее место стоит на 3k-4k EUR больше чем у Middl(a). Обычно умеет программировать только один единственный микроконтроллер из одного семейства. Например STM32F2xxxx. И всё. Он не догадывается о существовании *.ld *.o *.elf файликов. Он знает только про *.с, *.cpp и *.h. Причем Junior(ы) они такие смешные у них даже IDE открыта не на весь экран, а на 70-80% площади монитора.
Максимум, что можно доверить Junior(у) это написать драйвер GPIO, SPI, UART и прочее BSP. Или написать простой драйвер, например для микросхемы RTC где 7-12 регистров. причем чтобы написать драйвер GPIO (400 строк) Junior(у) понадобится 3-4 месяца. Причем всё потом придется проверить Middle(у).
Junior может пошагово отлаживать прошивку только в IDE. Будь то IAR или Keil. Junior(у) очень тяжело даже освоить IDE Eclipse. У Junior(а) начинается паника, если IDE не может открыть поврежденный *.xml или *.ewp файл с проектом для IDE.
Для него не существует ничего вне и за пределом IDE. Он видит только то, что в радиусе 2-3х сантиметров вокруг да около курсора. Он не представляет как можно работать за компьютером без мышки, курсора и GUI(ни). Мечта Junior(а) это чтобы в следующую версию IDE добавили Mickey Mouse(а), который будет давать подсказки по разработке прошивки.
Junior может максимум писать однопоточный код. Junior не догадывается от том, что существует модульные тесты.
Junior плохо знает английский язык и поэтому пишет транслитом в комментариях и в компанейских чатах (ватчдог, юзать, инлайн, хедер, дифайн, тула). Junior убежден, что транслит в его исполнении это самый правильный транслит.
Junior не умеет читать схемотехнику. Если ему порекомендовать найти что-то в файле топологии, то он сочтет, что его оскорбили. У него на жестком диске даже *.PDF со схемотехникой для платы, что на его столе тоже нет.
Jun также не открывает datasheet(ы). Он просто ковыряет пример прошивки в IDE из интернета.
У Junior(а) на диске только один проект. Одна сборка. И он собирает её одновременно для всех плат меняя что-то в *.h файлике. При этом собирается всё, как то, что нужно так и то, что не нужно. При этом он убежден, что это его решение гениальное.
Junior передает конфиги в сборку через (про)hard code(женые) константы разбросанные по всей прошивке.
Когда Junior(у) надо найти конкретную функцию, то он открывает встроенный в IDE поиск и набирает ключевое слово.
Junior не догадывается, что существует консоль и утилиты консоли. Он даже слов таких как "консоль" ещё не слышал, разве, что на курсе сопромата в ВУЗ(е). А если ему кто-то из смежников будет доказывать пользу UART Shell(а) в прошивке, то Junior будет резко агрессивно осуждать это. Будет утверждать, что ему, якобы, полностью хватает пошаговой отладки в IDE. На самом деле Jun просто понятия не имеет как реализовать TUI(UART-CLI ) в прошивке. К слову, Jun частенько пользуется printf отладкой в UART и выглядит это как ниагарский водопад из белых логов, к котором даже прочитать ничего не успеваешь. А то, что это его художество нагружает процессор его не волнует.
Junior не понимает 80% акронимов, которые слышит на работе и его это даже не беспокоит.
Junior умеет создавать проекты только путем скачивания примеров из интернета и ковыряния в них.
В мире Junior(а) микроконтроллер это просто "волшебная коробочка, которая исполняет мой С-код".
Junior работает с кодом только локально. Junior не умеет пользоваться системами контроля версий как SVN или GIT. А когда надо передать сорцы другому разработчику, то Junior скопает всё на USB-флешку, весь SDK c объектниками гигабайт на 16+. Или отправит этот много гигабайтный *.zip архив по e-mail почте. В лучшем случае положит архив в DropBox.
Даже если бы Junior вдруг узнал про GIT, то но бы подвергал версионному контролю только *.с и *.h файлики. А пользуется GITом Junior только из GIT GUI.
Junior не пишет постов так как ничего толком ещё не знает.
Middle Embedded Programmer
Когда Middle приходит на работу, он первым делом открывает сервер сборки Jenkins и смотрит, что поломалось в результате ночных тестов. Далее он чинит что-то, делает fix -коммиты и приступает к задачам из backlog(а).
Middle пишет на С или С++, умеет читать аssembler и четко понимает какой путь проходят сорцы в пищеварительной системе данного ToolChain(а) с момента написания до исполнения во flash микроконтроллера. Middle умеет писать не только С-код, но и скрипты сборки на Make, Ninja и СMake.
Он также покрывает код модульными тестами и умеет пользоваться интерфейсом командной строки поверх UART. https://habr.com/ru/post/698092/
Он умеет написать хороший загрузчик с шифрованием и аутентификацией. Умеет пользоваться GIT(ом). Может отличить аппаратную ошибку от программной. Может выполнить 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(а) в прошивке всегда есть NVRAM для хранения параметров. Это позволяет ему уменьшить количество сборок. https://habr.com/ru/post/706972/
Middle хорошо понимает архитектуру одного процессорного ядра до уровня ALU и знает, что происходит с микроконтроллером между подачей питания и запуском функции main(). Также Middle четно представляет, что происходит с микропроцессором между нажатием кнопки на PCB и запуском прерывания по внешнему прерыванию, и как процессор потом возвращается обратно в функцию main().
Middle активно пользуется консольными утилитами из CygWin(а): 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 навигация, беспроводные радио интерфейсы, ЦОС, сетевые протоколы, аудиотехника, управление электродвигателями, баллистические вычислители, ТАУ, криптография и т. п.
В целом Middle прекрасно понимает, что такое нормальная прошивка https://habr.com/ru/post/655641/
Middle не пишет постов на habr так как противится делиться экспертизой. Middle боится конкуренции как огня.
Senior Embedded programmer
Senior чётко понимает отличия всех известных процессорных архитектур 8051, ARM, SPARC, PowerPC, MIPS, RISC-V, Xtensa между собой.
Senior спокойно пишет прошивки с RTOS(ами): RTEMS, Zephyr RTOS, TI-RTOS, FreeRTOS. Причем он может завести любую существующую RTOS на любом существующем MCU любого вендора с чистого листа, а не взяв примеры из интернета.
Он собирает код сразу двумя-тремя компиляторами: GCC, Clang, GHS и т.п. Cборка двумя-тремя компиляторами позволяет ему найти больше ошибок. https://habr.com/ru/post/656449/
Senior передает конфиги в сборку gпрошивки через linux(овые) механизмы, такие как Device Tree и Kconfig.
Senior(у) не нужна мышка для работы на компьютере. Он всё может быстро сделать из консолей или утилит типа far manager.
Senior понимает, что происходит на уровне ABI. Senior может, например, добавлять в прошивку функционал путем добавления бинарей в RAM память из SD-карты прямо в run-time без пере сборки всего проекта, подобно тому как в Linux подгружаются модули.
Он умеет на пустом месте настраивать полный DevOps, например в Jenkins. Причем OS не имеет особого значения, что Linux, что Windows. Он пишет скрипты для автосборки на Python, скрипты авто развертывания через загрузчики и скрипты запуска автотестов из CLI. Между платами передает данные по Protobuff. https://habr.com/ru/post/695978/
Он умеет снимать code coverage после прохождения тестов. Находит код, который не исполняется и удаляет его.
Senior пишет код генераторы, например, для синтаксического разбора CAN пакетов, или карты регистров сложных SPI/I2C/MDIO чипов.
Senior знает как работает JTAG под капотом (установка точки останова). Senior может пошагово отлаживать прошивку прямо из командной строки, вообще без какой-либо IDE. ttps://habr.com/ru/post/694708/
Senior пишет embedded код учитывая индустриальные стандарты MISRA, CERT, ISO26262, DO-178C, AUTOSAR.
Senior пишет посты на habr. Он заинтересован, чтобы его окружение было способными и чтобы с ними было комфортно работать.
Вывод
Вот так я себе примерно представляю градацию навыков в разработке микроконтроллеров. Повторюсь, что конечно же всё очень условно.
Важно ещё отметить, что функция Jun ->Mid ->Sen никак не привязана к опыту работы и стажу. В РФ я видел как 27-летних Senior(ов) так и 43-летних Junior(ов). Причём и первый и второй не меняли профессии начиная с 22х лет.
Если вам известны другие атрибуты водораздела Junior->Middle->Senior программиста микроконтроллеров, то пишите, пожалуйста, их в комментариях.
А вот в этом реестре я привёл суммарный разбор Junior->Middle->Senior, который буду пополнять по ходу времени.
Словарь
Акроним |
Расшифровка |
MK |
микроконтроллер |
MCU |
microcontroller |
ALU |
arithmetic logic unit |
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 |
Комментарии (78)
VBKesha
02.04.2023 22:36+10Я удивлен, что в этой статье запретили сеньору использовать что-то кроме Vim, не канон.
BobovorTheCommentBeast
02.04.2023 22:36+5Он умеет написать хороший загрузчик с шифрованием и аутентификацией.Т.е. мидл компетентнее сенйора, а джун это сын директора пристроенный.
aabzel Автор
02.04.2023 22:36-5Самый простой загрузчик это 1 функция на 10 строк.
BobovorTheCommentBeast
02.04.2023 22:36+5Не думаю, что он будет хорошим, с аутентификацией и шифрованием.
aabzel Автор
02.04.2023 22:36-2джун это сын директора пристроенный.
Когда в РФ директор пристраивает сына, то назначает его сразу lead(ом).
lamerok
02.04.2023 22:36+5Миддл какой то не жмбедер, а девопс. непонятно почему вообще мидл и сеньор этим должны заниматься. Они же ембеддеры а не девопсы, у них и развиты должны быть эмбеддерские навыки лучше всего. Например, по требования разработать архитектуру многопоточного приложения для микроконтроллера, разбить проект на небольшие задачи, раздатьзадачи джуниорам, проводить ревью кода и т. д. и т. п.
В целом все какие то кодеры идевопсы, а не embedded программисты.
А кто анализ сичтемных требований проводит? Требования к ПО пишет? архитектуру приложения рисует? Фреймворки в конце концов?
Думаю, сеньор вообще может код не писать ????
aabzel Автор
02.04.2023 22:36-2Миддл какой то не жмбедер, а девопс. непонятно почему вообще мидл и сеньор этим должны заниматься. Они же ембеддеры а не девопсы, у них и развиты должны быть эмбеддерские навыки лучше всего.
В российских организациях, которые занимаются разработкой электроники нет и не было такой статьи расходов как DevOps инженер.
Есть только инженер-конструктор, инженер-схемотехник и инженер-программист. Как вы думаете кто же из троих будет заниматься DevOps(ом)?
beasty4ever
02.04.2023 22:36Вы очень сильно привязались к opensource продуктам, и почему то ранжируете всех по умению работать с ними хотя как вам намекнули выше это devops, а не embedded. Как по мне так ранжирование должно идти по наличию опыта работы с разными задачами и платформам. А судя по вашим постам у вас очень узкий взгляд на embedded через окошко opensource и stm. При этом у вас пропущен такой пласт как dsp процессоры со своими специализированными средами(привет texas instruments, analogdevices, миландр, элвис, модуль-м). Способность собрать код на C с опциями - O3 или - Os и ассемблерными вставками или интринсиками, а так же знание арифметики с фиксированной точкой. Умение писать код под cpld и fpga не как профи конечно, но иметь соответствующий опыт и понимание как он работает чтобы помочь плисоводу с отладкой. Знание цифровой и аналоговой обработки сигналов.
panzerfaust
02.04.2023 22:36+12Когда Junior(у) надо найти конкретную функцию, то он открывает встроенный в IDE поиск и набирает ключевое слово.
Вот же мерзавец. Поиск для поиска использует.
Junior не умеет пользоваться системами контроля версий как SVN или GIT. А когда надо передать сорцы другому разработчику, то Junior скопает всё на USB-флешку, весь SDK c объектниками гигабайт на 16+
Это уже вопрос не к джуну, а к организации. Почему сеньоры-помидоры не удосужились наладить прозрачный процесс онбординга и сходу пояснить джуну правила игры? Наверное, были заняты написанием статей о цветовой диффиренциации штанов. Джун в принципе дурит ровно настолько, насколько позволяют правила. Грамотные практики онбординга, девопса, тестирования, код-ревью и статанализа снижают джуновскую дурь до минимума. Если у вас их нет, то как бы на себя пеняйте.
aabzel Автор
02.04.2023 22:36-4Вот же мерзавец. Поиск для поиска использует.
Может в Microsoft Word поиск через Ctrl+F и оправдан.
А вот в исходниках следует искать утилитой grep.
https://habr.com/ru/post/229501/panzerfaust
02.04.2023 22:36+7Там речь про IDE. Зачем мне переключаться в консоль, если IDE сделает ровно то же самое?
aabzel Автор
02.04.2023 22:36-5Зачем мне переключаться в консоль, если IDE сделает ровно то же самое?
grep позволяет делать вложенные поиски поверх результата предыдущего поиска.
grep -rni gpio_set | grep "\.h:" | grep -i stm32
IDE такое даже не снилось .Если проводить аналогию, то поиск IDE это РСЗО "Катюша", а grep это HIMARS
panzerfaust
02.04.2023 22:36+1grep позволяет
А откуда следует, что мне необходимо делать вложенные поиски? 8 лет в отрасли, ступенчатым грепом только по логам ищу. Для поиска по коду ни разу не было нужды.
aabzel Автор
02.04.2023 22:36-28 лет в отрасли, ступенчатым грепом только по логам ищу. Для поиска по коду ни разу не было нужды.
значит у вас пока ещё слишком маленькая кодовая база в репозитории.
Вот когда перевалит за 3 миллиона строк кода так и пригодится grep
iig
02.04.2023 22:36А что не так с миллионами строк? В grep насколько секретный алгоритм, что в IDE его до сих пор не портировали? В чем удобство переключений между окном с grep и окном с IDE?
aabzel Автор
02.04.2023 22:36в output(е) grep за счет ступенчатого поиска меньше информационного шума (или вообще его нет) от ложных срабатываний поиска+ регулярные выражения можно применять.
А если учесть что 95% программистов МК работаю с 2мя мониторами, то переключение между окнами не составляет вообще никакого трудаiig
02.04.2023 22:36+2регулярные выражения можно применять
Назовите IDE, где нельзя применять регулярные выражения ;)
Ступенчатый поиск, конечно же, полезен иногда. Если не знаешь что ищешь ;) А в программном коде IDE разбирается лучше сторонней утилиты.
aabzel Автор
02.04.2023 22:36-2IDE не поможет Вам найти нужные файлы в консольном выводе git status для формирования коммитов
хорошим фильтром послужит только grep
iig
02.04.2023 22:36+3Хм. В графическом клиенте VCS, как правило, видно, какие файлы изменились. Можно указать какие войдут в коммит. Или у вас 500 файлов изменились, из них надо закоммитить 199?
aabzel Автор
02.04.2023 22:36-2Или у вас 500 файлов изменились, из них надо закоммитить 199?
Примерно так.
Набираешь git status и отображается простыня на 5 этажей вниз.
iig
02.04.2023 22:36+1Он собирает код сразу двумя-тремя компиляторами: GCC, Clang, GHS и т.п..
Есть подозрение что код надерган из разных исходников, их как-то склеили вместе и они как-то работают ;)
aabzel Автор
02.04.2023 22:36Нет. Просто сборка двумя-тремя компиляторами позволяет найти больше ошибок.
Indemsys
02.04.2023 22:36+2Это прикольно, троллить Keil с IAR-ом, но топить за GHS , которые написали такую "замечательную" статью - https://www.ghs.com/FreeSoftware.html
DungeonLords
02.04.2023 22:36+4Это что, не первоапрельская статья? Авто не пошутил, да? Нет, сначало было прям смешно...
beasty4ever
02.04.2023 22:36Middle практически не использует пошаговую отладку. Разве, что для запуска и отладки UART. Далее он ориентируется на интерфейс командной строки и модульные тесты, которые он добавил в сборку и вызвал из командной строки поверх UART. https://habr.com/ru/post/694408/
Вы так усердно впихиваете всем uart и cli, но отладка в принципе возможна через любой интерфейс процессора. Представляете есть процессоры в которых нет uart, да и байта там тоже нет(texas instruments серия c54 и c55) но они способны работать в embedded области и даже не смотря на отсутствие байта крутить ethernet стек на внешнем Mac или rndis через встроенный usb. И вместо uart+ cli будет rndis+wireshark.
aabzel Автор
02.04.2023 22:36-1но они способны работать в embedded области и даже не смотря на отсутствие байта крутить ethernet стек на внешнем Mac или rndis через встроенный usb.
Ну и норм. Запускайте CLI поверх TCP на порту номер 60100.
aabzel Автор
02.04.2023 22:36затем можно подключатся к устройство утилитой hercules
https://www.hw-group.com/software/hercules-setup-utility
и отлаживаться, скрестив пальцы, чтобы TCP Link не отвалился.beasty4ever
02.04.2023 22:36+1А зачем если есть netcat. https://habr.com/ru/articles/657613/
Цепляетесь по udp и получаете такой же cli. Вопрос не в самих инструментах а в их необходимости.
aabzel Автор
02.04.2023 22:36-1Представляете есть процессоры в которых нет uart
приведите, пожалуйста, пример конкретного микроконтроллера
beasty4ever
02.04.2023 22:36+1Tms320c5509 как пример c55 серии от texas instruments.
aabzel Автор
02.04.2023 22:36-4Представляете есть процессоры в которых нет uart
UART можно и программно реализовать на GPIO и аппаратном Timer(е).
beasty4ever
02.04.2023 22:36+1А зачем. Жрать такты и энергопотребление на постоянное переключение контекста в прерывани, на dsp который делает 2 умножения с накоплением за один такт и имеет цикл for с нулевым служебными издержками. Как я и написал в своём комментарии у вас очень узкий взгляд на embedded разработку. Расширяйте области пременения, а не фокусируйтесь на конкретных инструментах. А уж тем более не навязывайти их всем через определение мидла и синьера.
beasty4ever
02.04.2023 22:36+1А процессор я вам привёл конкретный. Вы же мне показали более новую серию и там uart есть.
aabzel Автор
02.04.2023 22:36-3А процессор я вам привёл конкретный. Вы же мне показали более новую серию и там uart есть.
Вы вообще санкционку какую-то в пример приводите. Для Tms320c5509 даже спеку не скачать. Не говоря уже про покупку.
beasty4ever
02.04.2023 22:36+2На али по 243 руб. А так весь texas instruments щас санкционка, но когда это кого-то останавливало( proxy в помощь).
progchip666
02.04.2023 22:36+1Али надо с большой осторожностью сегодня использовать, много перемарка попадается недавно на это нарвался. Купил уникальный Операционник, а вместо него какая то хрень, совместимая правда по ножкам. Ушло куча времени чтобы в этом разобраться, а теперь два месяца на следующую доставку...
aabzel Автор
02.04.2023 22:36-4Вы так усердно впихиваете всем uart и cli,
Как по мне дак, CLI это просто здравый смысл. Предлагаю обсуждать эту тему в тематическом посте https://habr.com/ru/post/694408/.
А так я как и все выступаю за всё хорошее и против всего плохого
https://docs.google.com/spreadsheets/d/1qJkZe0bK5FluFbsKUX_SbwP80gBz8sORl143gHCy02A/edit#gid=0
progchip666
02.04.2023 22:36Я бы сказал больше - UART практически бесполезен в силу своей крайней трмознутости для поиска действительно серьёзных и трудноуловимых ошибок связанных с проблемами ограничения производительности микроконтроллера. Когда для оптимизации скорости выполнения приходится выходить за рамки HAL и стандартных библиотек, когда недопустимы колбеки оптимизировать код прерывываний и вручную делать обработку не всех ошибок подряд, а только тех, которые реально могут встретиться в данном приложении...
Для меня признак синьора заключается именно в этом - глубокое знание и понимание архитектуры микроконтроллера на котором ты работаешь и способность выжать из него максимум производительности.
Для остального в общем то много ума не надо в сегодняшних условиях. А описываемые автором проблемы действительно могут возникнуть безконтрольным применением разношёрстных и непроверенных толком библиотек. Уж если применяешь что то левое, особенно из опенсоурса следует потрудиться проанализировать исходники, лично я неоднократно нарывался на крайне неприятные ошибки в подобных продуктах.
aabzel Автор
02.04.2023 22:36-1Я бы сказал больше - UART практически бесполезен в силу своей крайней трмознутости для поиска действительно серьёзных и трудноуловимых ошибок связанных с проблемами ограничения производительности микроконтроллера.
UART это одно. Тут речь идет не про водопад из логов как делают как раз Jun(ы).
UART CLI это совсем другое. CLI в режиме IDLE вообще ничего не печатает в UART и проц не нагружает от слова совсем, а только отвечает на запросы.
Рекомендую вам ознакомиться с topic(ом) https://habr.com/ru/post/694408/progchip666
02.04.2023 22:36+1Спасибо, посмотрю. Но кажется вы тут в меньшинстве, хотя это не значит что вы не правы. Возможно не всем дано понять настоящего гения, обогнавшего время...
aabzel Автор
02.04.2023 22:36Но кажется вы тут в меньшинстве, хотя это не значит что вы не правы. Возможно не всем дано понять настоящего гения, обогнавшего время...
В Европейских Embedded конторах UART-Shell, и всё что тут в категории Middle Senior для отладки firmware используют повсеместно уже лет как 35.
Наоборот мы в РФ сильно отстаем от "пригожей Европы" в плане технологий. Поэтому в своих текстах я как раз пишу для русскоязычных инженеров, то, что в ЕС уже давно есть, так как я работал в одной европейской конторое в одном проекте.Сейчас ситуация такова, что если какой-то русский ведущий инженер-программист микроконтроллеров I категории с 25 лет опыта окажется в Европе, то там его уровень будет соответствовать категории Junior.
jogick
02.04.2023 22:36+5Белиберда какая-то.
Буквально с первых строк навыков и далее по тексту стоял вопрос - ЗАЧЕМ??? ЗАЧЕМ писать СВОЮ RTOS, если не стоит задача написать свою RTOS. Некоторые навыки, которые я требую от начинающих относятся к мидлу. ПОЧЕМУ сеньёр или мидл должны писать свой загрузчик? У меня полно знакомых работающих в различных отраслях, на их совести большое количество сложных железок железок, но они ни разу не писали загрузчик. Они понимают как он работает, как его написать, но ни разу этого не делали - просто не было необходимости. Что не так с отладкой? Ведь её же не так просто туда включили, ни для джунов. Чем UART, которого может не быть или не быть свободного, лучше отладчика. На софтовый UART может просто не быть выводов. У меня на рабочем проекте stm32f405rg выбран в ноль по выводам, а более крупный ставить нельзя. И как? Почему мышью пользоваться плохо? У меня Logitech M560, с нефиксированным скроллом, так вот ей листать код удобнее, чем клавой.
В общем, странная статья. Молодым, неокрепшим умам только засрать всё можно
aabzel Автор
02.04.2023 22:36-2Что не так с отладкой? Чем UART лучше отладчика?
ответы тут https://habr.com/ru/post/694408/
jogick
02.04.2023 22:36+2Я знаю, что можно делать с UART при отладке и не только, но подавать её как нечто особенное и при этом писать, что серьёзные программисты её не используют - такое себе... И минусить комментарий с критикой, тоже не лучше. :-)
aabzel Автор
02.04.2023 22:36-2Я знаю, что можно делать с UART при отладке и не только, но подавать её как нечто особенное и при этом писать, что серьёзные программисты её не используют - такое себе
Вы точно не прочитали текст. Серьезные программисты как раз используют UART-CLI. Посмотрите проект FlipperZero, NanoVNA V2, ublox ODIN.
aabzel Автор
02.04.2023 22:36-1которого(UART) может не быть или не быть свободного ...На софтовый UART может просто не быть выводов. И как?
Ethenet на lapTop тоже один и тем не менее по нему куча протоколов циркулируют. Так же и с CLI. CLI можно добавить как отдельный протокол на том же UART интерфейсе, что и Modbus гоняет.
jogick
02.04.2023 22:36+2А если все UART'ы на внутренних железках?... И пять ЗАЧЕМ городить синтетические отмазы?
aabzel Автор
02.04.2023 22:36-3А если все UART'ы на внутренних железках?
Если ваши схемотехники не вывели "на улицу" ни одного UART или RS232/RS485, то порекомендуйте им вот эту методичку
jogick
02.04.2023 22:36Нет UART'а. Ничего больше нет, ни одного свободного вывода, на улицу смотрит только I2C, и он занять общением с управляющей программой.
aabzel Автор
02.04.2023 22:36-3Нет UART'а. Ничего больше нет, ни одного свободного вывода, на улицу смотрит только I2C, и он занять общением с управляющей программой.
Значит плохо проработана аппаратная архитектура. Заставлять программистов отлаживаться вслепую без UART это диверсия со стороны схемотехников.
jogick
02.04.2023 22:36+3Процессор с большим количеством выводов поставить НЕЛЬЗЯ, габариты не позволяют, и этот большой, надо искать пути уменьшения. BGA - тоже НЕЖЕЛАТЕЛЬНО.
aabzel Автор
02.04.2023 22:36-4Пришлите мне схемотехнику этого вашего чудо-прибора, где все пины заняты. Я постараюсь найти возможность вклинить туда CLI.
Vadimatorikda
02.04.2023 22:36+4Есть ряд устройств, где в целом вывести UART нельзя) Авионика та же (в рамках РФ ГОСТ-ов). Спасибо, что хоть JTAG выводят) Ну и да. Есть устройства с микроконтроллерами без UART. Он там и не нужен). Те же контроллеры питания (DC-DC, только умные, под задачу, если хотите)
aabzel Автор
02.04.2023 22:36-1на улицу смотрит только I2C, и он занять общением с управляющей программой.
I2C это топология общая шина.
Значит можно посадить на шину I2C еще одну аппаратную slave ноду. У вас же там уже не 127 устройств висит.
Ноду переходник I2C-UART, а в основной прошивке, где I2C master, реализовать CLI stream в эту отладочную I2C ноду.
Вот и получится отладка прибора через CLI.
aabzel Автор
02.04.2023 22:36-1ЗАЧЕМ писать СВОЮ RTOS
Вы дочитали текст, сер?
Про разработку отдельной RTOS там ни слова.
jogick
02.04.2023 22:36+1Возможно неверно понял вот этот кусок
Senior спокойно пишет прошивки с RTOS(ами): RTEMS, Zephyr RTOS, TI-RTOS,
FreeRTOS. Причем он может поднять RTOS на любом MCU любого вендора с
чистого листа, а не взяв примеры из интернета.Чем плохо взять ИЗ ИНТЕРНЕТА готовую RTOS от производителя, для целевого камня?
aabzel Автор
02.04.2023 22:36Чем плохо взять ИЗ ИНТЕРНЕТА готовую RTOS от производителя, для целевого камня?
Чтобы было понимание откуда у RTOS "ноги растут".
jogick
02.04.2023 22:36+1Так для этого можно походить по коду шаблона и по коду RTOS. Второе, при наличии свободного времени
aabzel Автор
02.04.2023 22:36-2Пошаговая отладка и точка останова нарушает тайминги. UART-CLI - нет.
jogick
02.04.2023 22:36Бывают флаги останова счётчиков тайминга, при стопе по отладке. А если внешняя программа не переживает перебоев в связи, то надо гнать программиста
beasty4ever
02.04.2023 22:36+2Иногда останавливать программу вообще нильзя. Пример жёсткий реалтайм при вращении движка. С другой стороны и uart+cli туда не стоит лучше ethernet(пропускная способность + дифпары для помехоустойчивости).
aabzel Автор
02.04.2023 22:36-3Иногда останавливать программу вообще нильзя. Пример жёсткий реалтайм при вращении движка
Вот то-то! Поэтому вся эта пошаговая JTAG отладка тут гроша ломаного не стоит, а UART CLI рулит
aabzel Автор
02.04.2023 22:36-3лучше ethernet(пропускная способность + дифпары для помехоустойчивости).
у ethernet куча зависимостей: GPIO, MDIO, MII, PHY(c регистрами), MAC, LwIP стек, потом Application протоколы на вершине.
Вся эта пирамида зависимостей сама по себе с ходу так просто не заработает.
Еthernet надо отлаживать чем-то более простым и надежным. То есть через UART-CLI.beasty4ever
02.04.2023 22:36-1Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса. Запустили отладочный интерфейс с jtag, а дальше запускаем неостанавливаемое приложение и собираем логи.
aabzel Автор
02.04.2023 22:36-1Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса.
ответ тут https://habr.com/ru/post/681280/
beasty4ever
02.04.2023 22:36+2Я читал все ваши статьи, с чем то согласен с чем то нет ибо имею другой опыт в embedded области связанный в основном с реалтаймом. Вас же я призываю не зацикливаться на opensource и uart с cli а смотреть шире на применение как интерфейсов для отладки так и различных сред ide.
aabzel Автор
02.04.2023 22:36-1Среды IDE хороши для ручной сборки. Для мелкой серии, когда сборок мало(3штук max).
Если же надо масштабироваться, если надо инициировать автосборки, то makefile лучше чем IDE.
iig
02.04.2023 22:36+1Не знаю как оно у Truъ IDE, но игрушечный ардуиновский билдер можно запускать из под Jenkins ;)
progchip666
02.04.2023 22:36Просто сняли тему с моего языка! Недавно с таким сталкивался в приложении для подсчёта фотонов. Жёсткий реалтайм, нетрадиционное использование нескольких таймеров во взаимосвязанных процессах и "зависон" из-за "гонок". Какой тут UART блин, когда всё просто намертво повисает!
Ну а для поиска простых ошибок гораздо проще использовать обычный отладчик, чем UART. Пяти - шести точек установки хватает в подавляющем большинстве случаев.
randomsimplenumber
02.04.2023 22:36+2Без цветовой дифференциации штанов в обществе никак не обойтись;) Как там в древности было: ученик, подмастерье, мастер;)
aabzel Автор
02.04.2023 22:36-3Просто это надо чтобы понимать какие задачи кому имеет смысл назначать. Только и всего.
progchip666
02.04.2023 22:36+2Не завидую я подданным этого синьора. Так и хочется добавить помидора...
dltex
02.04.2023 22:36"Junior плохо знает английский язык и поэтому пишу транслитом в комментариях" - автор спалился.
Valle
Синьеры как я, стоят в белом пальто красивые и все знают, а остальные ничего не знают и не умеют, все понял.