Comments 98
Синьеры как я, стоят в белом пальто красивые и все знают, а остальные ничего не знают и не умеют, все понял.
Я удивлен, что в этой статье запретили сеньору использовать что-то кроме Vim, не канон.
Одновременно с этим у Junior(а), как правило, чувствительность мышки настроена в режим кометы. Если двинуть мышку относительно коврика на 1мм, то курсор на мониторе улетает в соседнюю комнату!
Всегда замечал эту закономерность именно у Jun(ов).
Один Junior как-то мне жаловался, что у него за день руки затекают.
Это как раз потому, что Junior не двигает руками из-за максимальной чувствительности своего курсора.
Он умеет написать хороший загрузчик с шифрованием и аутентификацией.
Т.е. мидл компетентнее сенйора, а джун это сын директора пристроенный.
Миддл какой то не жмбедер, а девопс. непонятно почему вообще мидл и сеньор этим должны заниматься. Они же ембеддеры а не девопсы, у них и развиты должны быть эмбеддерские навыки лучше всего. Например, по требования разработать архитектуру многопоточного приложения для микроконтроллера, разбить проект на небольшие задачи, раздатьзадачи джуниорам, проводить ревью кода и т. д. и т. п.
В целом все какие то кодеры идевопсы, а не embedded программисты.
А кто анализ сичтемных требований проводит? Требования к ПО пишет? архитектуру приложения рисует? Фреймворки в конце концов?
Думаю, сеньор вообще может код не писать 😀
Миддл какой то не жмбедер, а девопс. непонятно почему вообще мидл и сеньор этим должны заниматься. Они же ембеддеры а не девопсы, у них и развиты должны быть эмбеддерские навыки лучше всего.
В российских организациях, которые занимаются разработкой электроники нет и не было такой статьи расходов как DevOps инженер.
Есть только инженер-конструктор, инженер-схемотехник и инженер-программист. Как вы думаете кто же из троих будет заниматься DevOps(ом)?
Вы очень сильно привязались к opensource продуктам, и почему то ранжируете всех по умению работать с ними хотя как вам намекнули выше это devops, а не embedded. Как по мне так ранжирование должно идти по наличию опыта работы с разными задачами и платформам. А судя по вашим постам у вас очень узкий взгляд на embedded через окошко opensource и stm. При этом у вас пропущен такой пласт как dsp процессоры со своими специализированными средами(привет texas instruments, analogdevices, миландр, элвис, модуль-м). Способность собрать код на C с опциями - O3 или - Os и ассемблерными вставками или интринсиками, а так же знание арифметики с фиксированной точкой. Умение писать код под cpld и fpga не как профи конечно, но иметь соответствующий опыт и понимание как он работает чтобы помочь плисоводу с отладкой. Знание цифровой и аналоговой обработки сигналов.
Фреймворки в конце концов?
В Embedded программировании нет такого понятия как Frame Work.
Когда Junior(у) надо найти конкретную функцию, то он открывает встроенный в IDE поиск и набирает ключевое слово.
Вот же мерзавец. Поиск для поиска использует.
Junior не умеет пользоваться системами контроля версий как SVN или GIT. А когда надо передать сорцы другому разработчику, то Junior скопает всё на USB-флешку, весь SDK c объектниками гигабайт на 16+
Это уже вопрос не к джуну, а к организации. Почему сеньоры-помидоры не удосужились наладить прозрачный процесс онбординга и сходу пояснить джуну правила игры? Наверное, были заняты написанием статей о цветовой диффиренциации штанов. Джун в принципе дурит ровно настолько, насколько позволяют правила. Грамотные практики онбординга, девопса, тестирования, код-ревью и статанализа снижают джуновскую дурь до минимума. Если у вас их нет, то как бы на себя пеняйте.
Вот же мерзавец. Поиск для поиска использует.
Может в Microsoft Word поиск через Ctrl+F и оправдан.
А вот в исходниках следует искать утилитой grep.
https://habr.com/ru/post/229501/
Там речь про IDE. Зачем мне переключаться в консоль, если IDE сделает ровно то же самое?
Зачем мне переключаться в консоль, если IDE сделает ровно то же самое?
grep позволяет делать вложенные поиски поверх результата предыдущего поиска.
grep -rni gpio_set | grep "\.h:" | grep -i stm32
IDE такое даже не снилось .
Если проводить аналогию, то поиск IDE это РСЗО "Катюша", а grep это HIMARS
grep позволяет
А откуда следует, что мне необходимо делать вложенные поиски? 8 лет в отрасли, ступенчатым грепом только по логам ищу. Для поиска по коду ни разу не было нужды.
8 лет в отрасли, ступенчатым грепом только по логам ищу. Для поиска по коду ни разу не было нужды.
значит у вас пока ещё слишком маленькая кодовая база в репозитории.
Вот когда перевалит за 3 миллиона строк кода так и пригодится grep
А что не так с миллионами строк? В grep насколько секретный алгоритм, что в IDE его до сих пор не портировали? В чем удобство переключений между окном с grep и окном с IDE?
в output(е) grep за счет ступенчатого поиска меньше информационного шума (или вообще его нет) от ложных срабатываний поиска+ регулярные выражения можно применять.
А если учесть что 95% программистов МК работаю с 2мя мониторами, то переключение между окнами не составляет вообще никакого труда
регулярные выражения можно применять
Назовите IDE, где нельзя применять регулярные выражения ;)
Ступенчатый поиск, конечно же, полезен иногда. Если не знаешь что ищешь ;) А в программном коде IDE разбирается лучше сторонней утилиты.
IDE не поможет Вам найти нужные файлы в консольном выводе git status для формирования коммитов
хорошим фильтром послужит только grep
Ступенчатый поиск, конечно же, полезен иногда. Если не знаешь что ищешь
Когда ты работаешь с чужим горе-Legacy, то ты всегда не знаешь что ищешь. Есть только 2 или 3 ключевых слова.
И тут ступенчатый grep это самая подходящая технология.
Ступенчатый grep находит даже уголку в стоге сена.
del
Если embedded Junior(а) спросить какая у него сейчас система сборки в компиляции прошивки, то он не поймёт о чем идёт речь.
Скорее всего ответит IAR, Keil или Cube-IDE.
Программист должен понимать какой путь проходят сорцы от написания до исполнения.
Jun часто не понимает код в Legacy.
Но это даже не проблема.
Проблема в том, что Jun не может сформулировать как письменно, так и устно, что именно он не понимает в legacy.
Он собирает код сразу двумя-тремя компиляторами: GCC, Clang, GHS и т.п..
Есть подозрение что код надерган из разных исходников, их как-то склеили вместе и они как-то работают ;)
Это прикольно, троллить Keil с IAR-ом, но топить за GHS , которые написали такую "замечательную" статью - https://www.ghs.com/FreeSoftware.html
Это что, не первоапрельская статья? Авто не пошутил, да? Нет, сначало было прям смешно...
Junior относится к коду как ребёнок к пластилину. Он лепит и приговаривает: "A ладно, и так сойдет". Middle относится к коду как писатель к прозе. Всё грамотно. Мысль передана, но можно было и по другому сделать. Senior относится к коду как конструктор к чертежу. В его коде нет ничего лишнего. Всё написано по строгим и обоснованным правилам.
Middle практически не использует пошаговую отладку. Разве, что для запуска и отладки UART. Далее он ориентируется на интерфейс командной строки и модульные тесты, которые он добавил в сборку и вызвал из командной строки поверх UART. https://habr.com/ru/post/694408/
Вы так усердно впихиваете всем uart и cli, но отладка в принципе возможна через любой интерфейс процессора. Представляете есть процессоры в которых нет uart, да и байта там тоже нет(texas instruments серия c54 и c55) но они способны работать в embedded области и даже не смотря на отсутствие байта крутить ethernet стек на внешнем Mac или rndis через встроенный usb. И вместо uart+ cli будет rndis+wireshark.
но они способны работать в embedded области и даже не смотря на отсутствие байта крутить ethernet стек на внешнем Mac или rndis через встроенный usb.
Ну и норм. Запускайте CLI поверх TCP на порту номер 60100.
затем можно подключатся к устройство утилитой hercules
https://www.hw-group.com/software/hercules-setup-utility
и отлаживаться, скрестив пальцы, чтобы TCP Link не отвалился.
Представляете есть процессоры в которых нет uart
приведите, пожалуйста, пример конкретного микроконтроллера
Tms320c5509 как пример c55 серии от texas instruments.
Представляете есть процессоры в которых нет uart
UART можно и программно реализовать на GPIO и аппаратном Timer(е).
А зачем. Жрать такты и энергопотребление на постоянное переключение контекста в прерывани, на dsp который делает 2 умножения с накоплением за один такт и имеет цикл for с нулевым служебными издержками. Как я и написал в своём комментарии у вас очень узкий взгляд на embedded разработку. Расширяйте области пременения, а не фокусируйтесь на конкретных инструментах. А уж тем более не навязывайти их всем через определение мидла и синьера.
А процессор я вам привёл конкретный. Вы же мне показали более новую серию и там uart есть.
А процессор я вам привёл конкретный. Вы же мне показали более новую серию и там uart есть.
Вы вообще санкционку какую-то в пример приводите. Для Tms320c5509 даже спеку не скачать. Не говоря уже про покупку.
Вы так усердно впихиваете всем uart и cli,
Как по мне дак, CLI это просто здравый смысл. Предлагаю обсуждать эту тему в тематическом посте https://habr.com/ru/post/694408/.
А так я как и все выступаю за всё хорошее и против всего плохого
https://docs.google.com/spreadsheets/d/1qJkZe0bK5FluFbsKUX_SbwP80gBz8sORl143gHCy02A/edit#gid=0
Я бы сказал больше - UART практически бесполезен в силу своей крайней трмознутости для поиска действительно серьёзных и трудноуловимых ошибок связанных с проблемами ограничения производительности микроконтроллера. Когда для оптимизации скорости выполнения приходится выходить за рамки HAL и стандартных библиотек, когда недопустимы колбеки оптимизировать код прерывываний и вручную делать обработку не всех ошибок подряд, а только тех, которые реально могут встретиться в данном приложении...
Для меня признак синьора заключается именно в этом - глубокое знание и понимание архитектуры микроконтроллера на котором ты работаешь и способность выжать из него максимум производительности.
Для остального в общем то много ума не надо в сегодняшних условиях. А описываемые автором проблемы действительно могут возникнуть безконтрольным применением разношёрстных и непроверенных толком библиотек. Уж если применяешь что то левое, особенно из опенсоурса следует потрудиться проанализировать исходники, лично я неоднократно нарывался на крайне неприятные ошибки в подобных продуктах.
Я бы сказал больше - UART практически бесполезен в силу своей крайней трмознутости для поиска действительно серьёзных и трудноуловимых ошибок связанных с проблемами ограничения производительности микроконтроллера.
UART это одно. Тут речь идет не про водопад из логов как делают как раз Jun(ы).
UART CLI это совсем другое. CLI в режиме IDLE вообще ничего не печатает в UART и проц не нагружает от слова совсем, а только отвечает на запросы.
Рекомендую вам ознакомиться с topic(ом) https://habr.com/ru/post/694408/
Спасибо, посмотрю. Но кажется вы тут в меньшинстве, хотя это не значит что вы не правы. Возможно не всем дано понять настоящего гения, обогнавшего время...
Но кажется вы тут в меньшинстве, хотя это не значит что вы не правы. Возможно не всем дано понять настоящего гения, обогнавшего время...
В Европейских Embedded конторах UART-Shell, и всё что тут в категории Middle Senior для отладки firmware используют повсеместно уже лет как 35.
Наоборот мы в РФ сильно отстаем от "пригожей Европы" в плане технологий. Поэтому в своих текстах я как раз пишу для русскоязычных инженеров, то, что в ЕС уже давно есть, так как я работал в одной европейской конторое в одном проекте.
Сейчас ситуация такова, что если какой-то русский ведущий инженер-программист микроконтроллеров I категории с 25 лет опыта окажется в Европе, то там его уровень будет соответствовать категории Junior.
Дело в том, что программирование - это всего лишь инструмент. Своего рода отвертка. Настоящую же ценность представляют именно предметные знания.
Программист МК без экспертизы в какой-либо предметной области это однозначно Juniour.
Белиберда какая-то.
Буквально с первых строк навыков и далее по тексту стоял вопрос - ЗАЧЕМ??? ЗАЧЕМ писать СВОЮ RTOS, если не стоит задача написать свою RTOS. Некоторые навыки, которые я требую от начинающих относятся к мидлу. ПОЧЕМУ сеньёр или мидл должны писать свой загрузчик? У меня полно знакомых работающих в различных отраслях, на их совести большое количество сложных железок железок, но они ни разу не писали загрузчик. Они понимают как он работает, как его написать, но ни разу этого не делали - просто не было необходимости. Что не так с отладкой? Ведь её же не так просто туда включили, ни для джунов. Чем UART, которого может не быть или не быть свободного, лучше отладчика. На софтовый UART может просто не быть выводов. У меня на рабочем проекте stm32f405rg выбран в ноль по выводам, а более крупный ставить нельзя. И как? Почему мышью пользоваться плохо? У меня Logitech M560, с нефиксированным скроллом, так вот ей листать код удобнее, чем клавой.
В общем, странная статья. Молодым, неокрепшим умам только засрать всё можно
Что не так с отладкой? Чем UART лучше отладчика?
ответы тут https://habr.com/ru/post/694408/
Я знаю, что можно делать с UART при отладке и не только, но подавать её как нечто особенное и при этом писать, что серьёзные программисты её не используют - такое себе... И минусить комментарий с критикой, тоже не лучше. :-)
Я знаю, что можно делать с UART при отладке и не только, но подавать её как нечто особенное и при этом писать, что серьёзные программисты её не используют - такое себе
Вы точно не прочитали текст. Серьезные программисты как раз используют UART-CLI. Посмотрите проект FlipperZero, NanoVNA V2, ublox ODIN.
которого(UART) может не быть или не быть свободного ...На софтовый UART может просто не быть выводов. И как?
Ethenet на lapTop тоже один и тем не менее по нему куча протоколов циркулируют. Так же и с CLI. CLI можно добавить как отдельный протокол на том же UART интерфейсе, что и Modbus гоняет.
А если все UART'ы на внутренних железках?... И пять ЗАЧЕМ городить синтетические отмазы?
А если все UART'ы на внутренних железках?
Если ваши схемотехники не вывели "на улицу" ни одного UART или RS232/RS485, то порекомендуйте им вот эту методичку
Нет UART'а. Ничего больше нет, ни одного свободного вывода, на улицу смотрит только I2C, и он занять общением с управляющей программой.
Нет UART'а. Ничего больше нет, ни одного свободного вывода, на улицу смотрит только I2C, и он занять общением с управляющей программой.
Значит плохо проработана аппаратная архитектура. Заставлять программистов отлаживаться вслепую без UART это диверсия со стороны схемотехников.
Процессор с большим количеством выводов поставить НЕЛЬЗЯ, габариты не позволяют, и этот большой, надо искать пути уменьшения. BGA - тоже НЕЖЕЛАТЕЛЬНО.
Пришлите мне схемотехнику этого вашего чудо-прибора, где все пины заняты. Я постараюсь найти возможность вклинить туда CLI.
Коммерческая тайна ни о чём ни говорит? Не? Или это ничего не значит?
Есть ряд устройств, где в целом вывести UART нельзя) Авионика та же (в рамках РФ ГОСТ-ов). Спасибо, что хоть JTAG выводят) Ну и да. Есть устройства с микроконтроллерами без UART. Он там и не нужен). Те же контроллеры питания (DC-DC, только умные, под задачу, если хотите)
на улицу смотрит только I2C, и он занять общением с управляющей программой.
I2C это топология общая шина.
Значит можно посадить на шину I2C еще одну аппаратную slave ноду. У вас же там уже не 127 устройств висит.
Ноду переходник I2C-UART, а в основной прошивке, где I2C master, реализовать CLI stream в эту отладочную I2C ноду.
Вот и получится отладка прибора через CLI.
ЗАЧЕМ писать СВОЮ RTOS
Вы дочитали текст, сер?
Про разработку отдельной RTOS там ни слова.
Возможно неверно понял вот этот кусок
Senior спокойно пишет прошивки с RTOS(ами): RTEMS, Zephyr RTOS, TI-RTOS,
FreeRTOS. Причем он может поднять RTOS на любом MCU любого вендора с
чистого листа, а не взяв примеры из интернета.
Чем плохо взять ИЗ ИНТЕРНЕТА готовую RTOS от производителя, для целевого камня?
Чем плохо взять ИЗ ИНТЕРНЕТА готовую RTOS от производителя, для целевого камня?
Чтобы было понимание откуда у RTOS "ноги растут".
Так для этого можно походить по коду шаблона и по коду RTOS. Второе, при наличии свободного времени
Пошаговая отладка и точка останова нарушает тайминги. UART-CLI - нет.
Бывают флаги останова счётчиков тайминга, при стопе по отладке. А если внешняя программа не переживает перебоев в связи, то надо гнать программиста
Иногда останавливать программу вообще нильзя. Пример жёсткий реалтайм при вращении движка. С другой стороны и uart+cli туда не стоит лучше ethernet(пропускная способность + дифпары для помехоустойчивости).
Иногда останавливать программу вообще нильзя. Пример жёсткий реалтайм при вращении движка
Вот то-то! Поэтому вся эта пошаговая JTAG отладка тут гроша ломаного не стоит, а UART CLI рулит
лучше ethernet(пропускная способность + дифпары для помехоустойчивости).
у ethernet куча зависимостей: GPIO, MDIO, MII, PHY(c регистрами), MAC, LwIP стек, потом Application протоколы на вершине.
Вся эта пирамида зависимостей сама по себе с ходу так просто не заработает.
Еthernet надо отлаживать чем-то более простым и надежным. То есть через UART-CLI.
Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса. Запустили отладочный интерфейс с jtag, а дальше запускаем неостанавливаемое приложение и собираем логи.
Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса.
ответ тут https://habr.com/ru/post/681280/
Просто сняли тему с моего языка! Недавно с таким сталкивался в приложении для подсчёта фотонов. Жёсткий реалтайм, нетрадиционное использование нескольких таймеров во взаимосвязанных процессах и "зависон" из-за "гонок". Какой тут UART блин, когда всё просто намертво повисает!
Ну а для поиска простых ошибок гораздо проще использовать обычный отладчик, чем UART. Пяти - шести точек установки хватает в подавляющем большинстве случаев.
Без цветовой дифференциации штанов в обществе никак не обойтись;) Как там в древности было: ученик, подмастерье, мастер;)
Не завидую я подданным этого синьора. Так и хочется добавить помидора...
"Junior плохо знает английский язык и поэтому пишу транслитом в комментариях" - автор спалился.
Очень часто у Junior(a) на плате один микроконтроллер (например STM32F413ZGJ6), а собирает проект он для другого микроконтроллера (STM32F207VG). Программа не зависает только из-за обратной совместимости между ARM Coretx-M3 и ARM Coretx-M4.
Junior обычно не понимает make файлов.
Для Junior(а) содержимое Makefile(ла) - это как китайские иероглифы для средневекового североамериканского индейца.
Junior(y) крайне не комфортно жить даже от того, что *.mk файл просто лежит рядом с его *.с/*.h файлами в одной папочке на жестком диске.
Junior от этого не ест, ночи не спит, лоб у него от makefile(ов) трещит...
Когда embedded школьнику хочется открыть диспетчер задач, то школьник отчаянно нажимает разные комбинации тех четырех кнопок, что под монитором внизу справа.
Embedded Junior обычно не знает такого понятия как абстрактные структуры данных (ADT).
Поэтому Junior не понимает разницы между циклическим буфером и очередью (FIFO). А она есть!
собирает код сразу двумя-тремя компиляторами: GCC, TCC, Clang, GHS
А если кто-то собирает прошивки с помощью GHC, то он кто? =)
GHC - это Glasgow Haskell Compiler . Как я понял. В Haskell я не эксперт.
Пока ничего не могу сказать конкретно.
Программировать микроконтроллеры на Haskell это не общепринятая технология работы с MCU. Haskell на MCU экзотика. Выглядит как опасная тропа.
Обычно MCU программируют на Assembler, Си, С++, иногда Rust очень редко на Pascal.
В чём выигрыш программирования микроконтроллеров Haskell ? При программировании на Cи выигрыш в том что любой производитель MCU бесплатно дает полный MCAL написанный на Си как и примеры проектов. Для Haskell такой поддержки никто не дает.
В случае Haskell тут Вам приходится рассчитывать только на себя и на сообщество Haskell разработчиков для MCU. Не знаю уж какого размера это сообщество.
Придется самому писать MCAL, FatFs, LwIP, RTOS и прочее программные компоненты для построения прошивок.
Отчего бы Вам тут на habr не написать методичку настройки ToolChain(а) для программирования MCU на Haskell ?
Типа вот такой
https://habr.com/ru/articles/792590/
Выглядит как опасная тропа
Наоборот, безопасная! https://www.researchgate.net/publication/329505354_Ivory_safe_and_performant_Haskell
Градация Навыков в Embedded Программировании