В этом тексте я напишу о буднях программиста МК в РФ.
Что вообще пишут программисты МК и на чем?
Основной язык программирования это С. Языку С уже более 50 лет. Язык С потихоньку сдает свои позиции. Кроме микроконтроллеров С уже практически никому не нужен. Навыки программирования на С очень слабо конвертируются. В свое время, видимо, на С написали компилятор для С++ и нужда в С для desktop как таковая отпала. Есть конечно DeskTop проекты написанные на С: Git, JVM, MySQL, Nginx, PostgreSQL, TaranTool, WallArm, однако вероятность, что в этих проектах можно работать из РФ да еще и с опытом из электроники мала. A сам язык С остался для сборки артефактов для микроконтроллеров с экстремально малыми ресурсами (для automotive ECU, SIM карт, IoT). Хотя и сейчас большинство компаний в Евросоюзе уже давно как и микроконтроллерные сборки собирают на С++ 17 и выше. Вероятно, что язык программирования С для МК вскоре и вовсе войдет в историю.
Справедливости ради стоит упомянуть, что С используют для создания модулей ядра Linux. Как вариант можно пойти работать туда. Но надо быть готовым, что образ будет собираться по часу. В Linux проектах ещё больше бюрократии и секретности, чем в проектах на МК. И С кода в Linux пишут меньше. Часто Linux программисты даже никогда не видели схемотехнику своего одноплатника SBC и datasheet(а) на SoC (так как это секрет компании). Программисты работают в абстрактных условиях. Редактируют дерево устройств, путешествуют по файловой системе, пишут скрипты на Bash и Python, исправляют баги в JavaScript(е) Web GUI и выносят ведрами баги из кода User Space процессов, перекраивают дерево устройств *.dts, добавляют драйверы чипов в загрузчик U-Boot и пишут очень много документации и инструкций (Doc Food(а)).
Еще программистам MК приходится обсчитывать аналоговые цепи и вычислять какие-то сложные 8-этажные формулы и строить графики. Для этого практикуют бесплатный интерпретатор Python.
Главным образом программисты МК составляют Board Support Package, пишут драйверы для новых умных периферийных чипов c управлением по интерфейсам I2C/SPI/MDIO/1Wire/UART/SMBus/PMBus, пишут загрузчики, портируют RTOS(ы) на разные процессорные ядра, пишут код-генераторы, скрипты сборки, составляют модульные тесты, изредка производят рефакторинг, часто чинят ошибки в Legacy коде, изредка что-то изменяют в коде Assembler(а), который запускается до вызова функции main().
Иногда программист МК даже ничего и не пишет сам вообще. Важно уже не сколько уметь программировать, сколько уметь тестировать и собирать, улучшать из готового кода из интернета. Какие-то исходники можно взять из github или ядра Linux. Там есть код на многие темы. Драйверы для множества чипов. Важно уметь верифицировать найденные сорцы и аккуратно подключить их к нужной сборке.
Где работать?
В России программисты МК в основном работают в компаниях, которые делают госзаказ на военную технику. Основной источник работы - госзаказы и ОКРЫ. Конечный программист МК как правило даже не знает, что за комплекс разрабатывается в организации. Все платы называются "вычислительный модуль". ТЗ для программиста МК под запретом. На рабочем компьютере нет доступа в сеть интернет. Утилиты можно устанавливать только через пароль руководителя отдела. Пароль для открытия диспетчера устройств, пароль, чтобы прописать путь в переменную Path, пароль на установку драйверов, пароль на удаление папок.
Традиций в профессии программист микроконтроллеров в РФ исторически не сложилось. Разработка всюду похоже на анархию. Зачастую вам придется работать даже без технического задания. Задачи могут поставить так: “подружить микроконтроллер и айфон”, “оживить плату”, “подружить платы”. Понимай как хочешь. Нет доверенной покрытой тестами кодовой базы на всю страну (аналога европейскому AUTOSAR). То есть нет тех кирпичей из которых можно было бы гарантированно собирать программное здание. Нет никакой общей культуры разработки системного ПО. Нет общей терминологию. Везде свой внутренний нецензурный фольклор.
Что разрабатывать?
Любое электронное устройство, которое вы будете делать скорее всего можно будет назвать одним словом: переходник. Типичное IoT устройство это с одной стороны, например, датчик температуры на шине I2C c другой стороны WiFi модуль. Телематика это тоже переходник: с CAN на LTE и т д. Всё что я делал в русской электронике 10 лет подряд это переходники с одного интерфейса на другой интерфейс. Маршрутизаторы, модемы, телематика, СКУД(ы), аудиосистемы, IoT. Переходники. Переходники. Переходники.
Есть некоторая специфика программирования МК в РФ. Свою оригинальную электронику в России делать отказались еще в конце 60-х. Был принят гос план копировать западные IBM(ы). В результате Россия стала полным акцептором IT технологий. Сегодня у России нет своего дешевого процессорного RISC/MIPS/PowerPC ядра, нет своего компилятора для известных ядер ARM, PowerPC, RISC -V. У РФ нет даже своего текстового редактора. Благо есть открытый софт (Linux и GCC), которым и пользуются российские компании. Страна полностью зависит от импорта микропроцессоров и ToolChain(а) для микропроцессоров. Микроконтроллеры активно покупают в Италии, Франции, США, Китае, Нидерландах, Канаде, Швейцарии. Toolchain покупают у Швеции (IAR), Германии(Keil), США(GHS).
В РФ по-настоящему передовые электронные разработки часто попросту не доживают до серийного производства банально из-за очередного эмбарго.
Россия страна санкционная. В российской организации могут запросто решиться начать разработку, которую можно реализовать только на одном единственном импортном чипе из Евросоюза. А вендор этого чипа наложит эмбарго либо сразу, либо потом и не будет присылать вам полный datasheet и сами чипы, так как РФ, по его мнению, является санкционной территорией. И в результате вы, как программист микроконтроллеров вообще ничего не сможете с этим сделать. Такая история у меня лично была уже дважды.
В США ситуация диаметрально наоборот. Там не то, что есть полный цикл IT продуктов. Там еще есть каждый IT продукт в нескольких экземплярах, т.е. от нескольких вендоров. Микропроцессоры AMD, Intel, TI, Microchip. Софт операционных систем от MAC, Windows. Компиляторы TI, GHS. Всеми любимый текстовый редактор VS Code от Microsoft.
Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров. Хлам на столах с горочкой. Вероятно, будешь работать по соседству с шумным охладительным оборудованием, так как электронные платы надо подвергать климатическим испытаниям.
Начальство программистов микроконтроллеров в трех случаях из пяти в российских компаниях это в прошлом схемотехники. О программировании они знать ничего не хотят, не любят программировать. Учиться у них программированию не выйдет.
Российские компании не хотят ничего выдумывать. Предпочитают копировать то, что уже есть на западе. Едва ли в РФ получится участвовать в какой-либо уникальной прорывной разработке на микроконтроллерах. По настоящему грандиозных проектов в РФ скорее всего просто не удастся сделать из-за эмбарго. Проекты гаджетов с Kickstarter(а) или CrowdSupply вызывают больше восхищения и трепета чем то, что пытаются делать электронные компании в РФ со своим громадным опытом.
В программировании микроконтроллеров большинство русских фирм даже не заботятся о коде как таковом вообще. Для их процессов внутри организации кода как будто бы и не существует вовсе. О коде не говорят. Код не изучают, код не анализируют. Интерес представляет только физический прибор. В большом почете схемотехники и конструкторы. А исходники можно вообще хранить в открытом доступе и это никого не волнует. Исходники микроконтроллера никого кроме 1го единственного разработчика не интересуют. В одной российской организации я видел как программист микроконтроллеров называл С функции именами литературных персонажей и это никого вообще не волновало так как кроме него с этим кодом никто не работает. А он хотел быть незаменимым. И, как правило, один человек делает прошивку для одной платы. Другой программист делает прошивку для другой платы. Каждый пишет свою бажную версию fifo, swap, циклического буфера, цифрового фильтра, загрузчика, reverse_byte, CRC8, crc16, crc24, crc32 и пр. зачастую даже без юнит тестов. Повторяемость кода достигает количества программистов в организации умноженная на 100%. Обычно это 550%...750%. Их сорцы никто не контролирует, их код не инспектируют, не тестируют, не переиспользуют. Большинство разработчиков даже юнит тестов не делают. В результате во всех микроконтроллерных проектах может быть дичайший хаос (функции по 5k строк) и этого даже никто не заметит. Это особенность российской программистской культуры ведения R&D.
Второстепенная работа
Работа программирования МК тесно связана с электронными платами. Если вы программист МК, то скорее всего вы будете по уши в электронных платах. Вам придется не сколько программировать, сколько исправлять разнородные аппаратные баги. Железо часто подводит. Вот пара примеров.
Программатор не видит target. Собрали стенд, положили SWD длиной 90 см и нет Link(а) с MCU. Когда кабель 12 см, то link есть. Потом статическое электричество будет постоянно портить вам жизнь, разные разъёмы будут не контачить и прочее. Аппаратные проблемы будут еще до запуска кода.
Например плата работает под отладчиком, а при пересбросе питания не стартует прошивка. На другой плате это не проявляется. И эта ситуация потребует неделю на выяснение и устранение причины. И так для каждого нового чипа и ToolChain(а). Свежие электронные платы с производства не любят работать. Предпочитают сразу сгорать. На программирование после починки плат остается мало времени.
На сам процесс программирования уходит 10...20% времени. В основном приходится что-то ремонтить, разбираться с проводами. Выяснять, что куда подключено, проверять осциллографом наличие электрических сигналов, проходить по чек-листу. Не успеешь разобраться с одной платой, как тебе принесут еще две платы и надо будет вкуривать очередную схемотехнику на 30-60 страниц. А схемотехники даже блок-схему не нарисуют, сразу дают в лучшем случае электрическую принципиальную схему (Э3) в виде фотографии *.JPG, а в обычном случае и вовсе принесут плату без доков и скажут, что надо оживить плату.
Можно запросто неосторожно сжечь оборудование из-за неправильно подключенного заземления. Вы обязательно узнаете как пахнут искры. Можно потратить весь день на подключение лампочки или чтения состояния зашумленной кнопки. Копаться в разъемах. Лампочки тебя будут ослеплять, моторы задевать, бетта-лучи облучать.
Чтобы отлаживать код, его надо исполнять. Если в коде баг и нет возможности исполнить код, то баг не исправить. Это как найти в лесу отдельно лежащую человеческую ногу, то не ясно что это и зачем. Понятно только когда эта нога видна в действии. Аналогично в понимании причины багов. Надо запускать код. А накладные расходы на запуск и исполнения микроконтроллерного кода при разработке на MCU в составе комплекса порой огромные.
Мало ресурсов
Программисты МК в принципе не пишут больших программ. Размер проекта ограничен несколькими сотнями килобайт памяти Nor Flash(а). Обычно 320KByte на всё. Вас будет преследовать постоянная нехватка Flash памяти. Особенно при разработке загрузчиков. Невозможность сделать полноценный загрузчик по всем интерфейсам. С RAM ситуация еще хуже. Вам повезет, если размер RAM будет в 4 раза меньше чем Flash(а). А частоты микроконтроллеров не превышают 200MHz, так как смысл МК это низкое энергопотребление.
Даже не мечтайте про удалёнку из Тайланда
Чтобы в принципе делать embedded software нужен физический доступ к оборудованию. Проверка сигналов осциллографом, подключение логического анализатора к I2S, измерение DMM(ом), работа с микроскопом для проверки, что микросхемы правильно припаяны. Анализ перегрева платы тепловизором. Это основное отличие программирования микроконтроллеров от, например, web программирования. Едва ли вообще можно эффективно работать в роли embedded удаленно. Это как удаленно красить стены или строить дом. Это профессия производственная и тут нужно физические первостепенное воздействие на прототип или изделие.
Образовательный BackGround
Самым полезным background-ом для профессии программист микроконтроллеров я бы назвал профессию разнорабочий. Программирование микроконтроллеров это на 80-70% электротехника и только на 20-30% программирование. Надо будет делать прототипы и ремонтировать сгоревшие платы. Вытравливать электронные платы методом ЛУТ (лазерно-утюжная технология). Выяснять, почему электронные платы с производства не включаются. Предстоит делать закупки примочек, метаться по радиорынку, работать курьером, прокладывать проводку, чертить 2D и 3D детали, трассировать печатные платы, паять под микроскопом, измерять электрические сигналы, выпиливать, клеить, шкурить, сверлить, фрезеровать, крутить разные отвертки, настраивать 3D принтер, пылесосить, ездить на автомобиле с ноутбуком на коленях и многое чего еще. Делать реверс инжиниринг западных товаров. Вам повезет, если вы вообще за неделю будете хоть что-то программировать в этой чудо профессии программист микроконтроллеров. Если вы будучи программистом МК не станете исполнять функции чернорабочего и будете проявлять принципиальность, якобы я только код пишу, то попросту будете тормозить ход работы и вас будут изживать из компании.
Да и программы для МК простые. Прочитать по ADC напряжение и что-нибудь выполнить. Все что вам понадобится из теории computer science это теория конечных автоматов, PID регуляторы, самые базовые и простецкие структуры данных как массив, FIFO(шка), циклический массив). Плюс цифровые фильтры, триггер Шмитта, AES шифрование. Пожалуй всё. Остальная теория будет вам скорее мешать, чем приносить пользу. Я ни разу не видел LIFO, двоичных деревьев AVL, красно-черных деревьев, косых деревьев в исходниках каких бы то ни было прошивок. Ни разу не видел хеш-таблиц, фильтров Блума, графов. Все это добро в большинстве своем просто не нужно в программировании МК.
Прошивки довольно простые программы. В них как правило нет никакого процессинга над данными. Всё сводится к тому, что надо GPIO мигнуть, кнопку прочитать, испустить PWM сигнал и прерывания по перепадам напряжений отловить. В микроконтроллерах нет нужды даже в алгоритмах сортировки. В сущности прошивки только прописывают константы в регистры и считывают регистры SoC(а). А это приводит к активации электрических цепочек внутри SoC(а). Со стороны вся цифровая электроника только и делает всего-навсего 4 простых действия:
1--установить на проводе 0V
2--установить на проводе 3.3V
3--считать с провода 0V
4--считать с провода 3.3V
Вот и всё. Easy!
Программы для МК в основном нужны там, где надо быстро сигналы обрабатывать. Для управления любыми двигателями (спинеры), для считывания датчиков физических величин. В таких вещах не должно быть никакой осечки и неожиданного поведения. Во встраиваемых системах не будет всех передовых технологий как MMU, Cache, динамического выделения памяти. Так как они не дают гарантии на время отклика. Есть правила MISRA, которые запрещают много интересного, например, динамическую память. Нет динамической памяти, а значит нет и абстрактных структур данных. Нет сортировки слиянием, быстрой сортировки. Ресурсов так мало, что быстрее отправить данные на сервер и расcчитать там чем рассчитывать что-то на MCU. Разработчик MCU обычно за год делают проект и переключаются на другой. В микроконтроллерном программировании всё очень топорно устроено. Как правило на один проект сажают одного человека. Командной работы нет. Поэтому такими программистами МК работают как правило только ортодоксальные интроверты.
В программировании МК не происходит ничего особенного. Как правило такие программы принимают пакеты из интерфейсов и что-то прописывают в интерфейсы или читают датчики и передают показания в интерфейсы. Принимают прошивку и прописывают ее в Flash память.
В программировании МК как такового программирования-то мало. В основном задачи вида прочитать SPI датчик и переслать значение в провода. Получить из проводов команду и включить лампочку. Получить из проводов массив и прописать его в энергонезависимую память и т.п.
Много работы с бумажками
Для программирования микроконтроллеров надо очень хорошо ориентироваться в множестве официальных документов. Вникать в спецификацию компилятора (~1k страниц), стандарт языка С (~700-1k страниц), спецификацию процессорного ядра (~300 страниц), обязательно ознакомиться с перечнем ошибок проектирования кристалла (~20 страниц), вникать в спеки каждой микросхемы (~50...5k страниц) на печатной плате. Искать куда идут провода(~1-100 страниц). Придется как юрист очень много пылиться в чтении официальных документов.
Чего вообще хорошего в профессии программист микроконтроллеров?
Плюс этой работы в том, что тут всё конкретно и завязано на физические величины. Всё можно измерить. Есть полный контроль за устройством. Никакого недоверенного кода. Никакой OS, которая вдруг начнет обновлять антивирус на МК нет. Всё можно оцифровать, любую физическую величину перевести в цифру. Всё упирается на физику и законы физики. Никто не будет спорить с законами физики. Софт произрастает от схемотехники. Схемотехника произрастает из физики. Достаточно посмотреть на схему устройства и уже становится понятно, что это и какое для неё должно быть firmware. Товар сразу видно, его можно потрогать, показать, покрутить. В этой профессии создают настоящие материальные ценности. Язык Си по сравнению с другими языками простой как ножик. Одни только функции и переменные. Самый древний язык из тех что всё еще используются ~50 лет. Тут не будет никаких программных делегатов из C#, сборщиков мусора, исключений и виртуальных машин.
Вывод.
В целом профессия разработчика МК такая как я тут написал. Мало программирования и много проводов. Если у вас есть выбор и вы хотите программировать на разных языках и быть в теме классической программной теории, если вам 20..24 и вы решаете как орешки олимпиадные задачи с LeetCode и хотите использовать в работе современные и классические алгоритмы и структуры данных, то программирование MK вам едва ли подойдет. Тут просто не нужно ничего кроме FIFO и конечных автоматов. Займитесь лучше Back-End(ом), Front-End(ом), Web(ом), нейросетями, GPU, мобильными приложениями, базами данных. С++ и то более живо развивается. Появились стандарты 11, 14, 17, 20, а plain С это 89, 99, 2011 и кажется всё. По моим наблюдениям за 10 лет в среднем трое из пяти кто начинал с программирования MK спустя 3 года переметнулись в другие программирования или совсем в другое. Программирование МК это для тех кто готов закатать рукава, замарать руки и регулярно выходить из зоны комфорта.
Если же вы всё же по каким-то причинам хотите программировать MCU(шки), то старайтесь угодить в компанию, где делают модульное тестирование сорцов, собирают из Make файлов, есть командная работа (3+ вкладчика), практикуется пере использование кодовой базы, где фигурирует такое слово как AUTOSAR, есть планерки, инспекция программ, автосборки. И крайне важно, чтобы в компании отсутствовала секретность на схемотехнику, datasheet(ы) и техническое задание. Там хотя бы будет выше вероятность сделать что-то по-настоящему ценное.
В общем делайте правильный выбор.
Комментарии (256)
F0iL
29.05.2022 00:21+31Низкий поклон вам за статью. Как человек, закончивший универ с квалификацией инженера-электроника, успевший поработать в embedded, а потом перешедший в прикладное программирование, но периодически снова возвращающийся к железкам, то есть прочувствовавший все это на своей шкуре, но имеющий возможность посмотреть со стороны и сравнить, подпишусь под каждым словом.
Навыки программирования на С очень слабо конвертируются.
Одна из самых частых и опасных ошибок сишников - подумать что "синтаксис у языков похожий, а принципы ООП я понимаю" и переходя на C++ начинать писать на "Си с классами". Приводит это обычно к очень печальным последствиям.
Хотя и сейчас большинство компаний в ЕС уже микроконтроллерные сборки собирают на С++ 17.
В Нюрнберге в июне будет Embedded World 2022 (кто-нибудь из хабравчан планирует туда, интересно?), и в программе выставки-конференции я неожиданно обнаружил выступление про Rust. Так что не все ещё в мире потеряно :)
В России программисты МК в основном работают в компаниях, которые делают госзаказ на военную технику. Основной источник работы - госзаказы и ОКРЫ.
Тут стоит добавить, что нередко работа в таких проектах влечет за собой подписание формы секретности со всеми возможными последствиями. Плюс менеджмент (организация процессов и отношение руководства к сотрудникам) в подобных местах сильно оставляет желать лучшего.
Нет никакой общей культуры разработки системного ПО.
...в 3 случаях из 5ти в российских компаниях это в прошлом схемотехники. О программировании они знать ничего не хотят. Учится у них программированию не выйдет.
Каждый пишет свою бажную версию fifo, swap, циклического буфера, цифрового фильтра, загрузчика, reverse_byte_order, CRC8, crc16, crc24, crc32 и пр. зачастую даже без юнит тестов.
В программировании микроконтроллеров большинство русских фирм даже не заботятся о коде как таковом вообще.... Его сорцы никто не контролирует и его код не инспектируют не тестируют не пере используют. Большинство разработчиков даже юнит тестов не делают. В результате во всех проектах может быть дичайший хаос и этого даже никто не заметит.
Это для меня вообще больная тема. Не иначе как пару дней назад я как раз написал тут на Хабре комментарий, процитирую полностью, ибо прям в точку:
Я по молодости думал, что это наша отечественная специфика, но нет - говнокод в embedded - явление, увы, интернациональное. И если там где Embedded Linux там еще обычно все не так плохо, то чем ниже уровнем (особенно под bare metal или под крохотные rtos), тем страшнее. Об этом
не раз уже говорили здесь на хабре (в первой половине одной нашумевшей статьи, например, да и еще много где в комментариях).
Объяснения этому можно найти разные. Долгое время специфика embedded состояла в том, что сам по себе функционал у железок был весьма ограничен и прямолинеен (несколько основных функций), время не жизни, а точнее развития продукта не слишком большое (сделали изделие и клепаем много лет, ну или спустя N лет выйдет новая железка), а ресурсы очень ограничены (нужно экономить каждый байт и каждый такт, иначе трындец). В подобных условиях о читаемости и архитектуре никто, понятное дело, думать не будет.
Времена поменялись, железо сделало огромный скачок (STM32 имеющий в десятки раз больше мегагерц и килобайт чем ATmega8, стоит меньше центов чем та своё время), а вот функционал стал наоборот более сложным и разнообразным, и нередко сильно разрастается со временем.
В этом плане embedded-мир сильно отстает от "большого IT" - те через подобное прошли еще 20-30 лет назад, успешно преодолели подобные болезни роста и разработали огромное количество рекомендаций, принципов и инструментов, как нужно делать сложные информационные системы чтобы получилось хорошо. Многие (понятно дело, что не все, но многие) из них отлично применимы и с пользой впишутся и в embedded-мир - вот только нередко embedded-разработчики не то что не хотят к ним приглядеться и оценить, какую выгоду им это даст, чтобы разработка была более эффективной, а их программы были более надежны и гибкие - а отвергают все "чужое" даже не глядя (например, с пеной у рта доказывая что "DevOps в эмбеддед невозможен").
Возможно здесь дело в известном снобизме ("мы тут реальные дела делаем, каждый опкод нашего процессора наизусть знаем, а вы без своего сборщика мусора ничего написать вообще не можете"), помноженном на банальную денежную зависть (веб-формошлеп в банке может получать в 2-3 раза больше эмбеддера на производстве), что влияет на восприятие, а может в чем-то другом.
На Quora.com, помнится, кто-то спросил, мол, эмбеддеры, почему у вас часто бывает такой говнокод? Ответ, набравший больше всего голосов, звучал как "Я вообще по образованию electrical engineer и меня всему этому не учили". И тут я прям завис. Многие "высокоуровневые программисты" тоже самоучки без образования - и то, что я описал выше, они освоили самостоятельно. А тут "меня этому не учили" и всё. Мне этого не понять. Возможно корни действительно растут из того, что многие эмбеддеры пришли в программирование со стороны железок, и мнение что "разработать железку - вот это настоящая сложность и искусство доступное не многим, а программу написать - вообще фигня, даже обезьяна на коленке справится" действительно распространено с соответствующими последствиями.В ответ от своего собеседника, тоже embedded-разработчика, я получил комментарий тоже полный жизненной боли, цитировать не буду, можете прочесть его по ссылке.
Есть правила MISRA, которые запрещают много интересного, например, динамическую память
Насколько я помню, в свежих вариантах MISRA нет запрета на динамическую память как таковую, есть запрет только на выделение памяти через классические malloc/free. То есть какие-нибудь pool allocators вполне себе допустимы, и более того, из-за предсказуемого времени выделения блока и отсутствия фрагментации они в embedded вполне себе уместны.
Язык Си по сравнению с другими языками простой как нож.
Опасное заблуждение. С точки зрения имеющихся примитивов и концепций языка - да, он простой. А вот с точки зрения неочевидных подводных камней - у него их море, возьмите хотя бы тот же алиасинг для примера. Из-за undefined behaviour на каждом углу, далеко не каждая программа на Си, которая компилируется и работает, является правильно написанной программой на Си, и это ни что иное как заряженное ружье, которое может выстрелить в непредсказуемый момент.
Karlson_rwa
29.05.2022 00:49+1Тут стоит добавить, что нередко работа в таких проектах влечет за собой подписание формы секретности со всеми возможными последствиями.
Вы вот очень много пишете (в комментах в основном) о том, как у нас тут всё плохо. Вы сами лично что-то подписывали хоть раз? Или вам об этом только рассказывали? Как вы думаете, там совсем нет ITAR-related работ?Плюс менеджмент… в подобных местах сильно оставляет желать лучшего.
Имя, сестра, имя!F0iL
29.05.2022 01:02+27Вы сами лично что-то подписывали хоть раз?
Хватило мозгов не подписывать. В свое время, собеседуясь в разные питерские конторы, сразу заранее уточнял этот вопрос - в одном месте сказали про вторую форму допуска, в некоторых других про то что может быть третья и начинали классический проезд по ушам на тему "она ни к чему вообще не обязывает, паспорт сдавать не надо, выезжать можешь спокойно, это так, для галочки". На вопрос "Учитывая происходящее последние N лет обострение маразма на госуровне, какие гарантии что в какой-то момент это 'ни к чему не обязывает' резко не изменится задним числом?" разумного ответа дать никто не смог, и в итоге пришлось отклонять офферы.
После какого-то момента я вообще перестал по совокупности причин рассматривать отечественные конторы как место для работы, благо в СПб тогда были и филиалы международных компаний, тоже работающих в области embedded, типа тех же LGE и Моторолы/Нокии, с очень неплохими условиями и интересными проектами.
А что про менеджмент - о некоторых фирмах выводы можно сделать ещё на собеседовании, с некоторыми отечественными НПФ/НПО/КБ приходилось пересекаться в работе, а в некоторых подобных заведениях работают/работали однокурсники и экс-коллеги. Поэтому рассказы о положении дел были из первых рук, так сказать.
Karlson_rwa
29.05.2022 01:11+3Спасибо, примерно так я и думал.
какие гарантии… разумного ответа дать никто не смог
А на что вы рассчитывали, задавая такой вопрос?F0iL
29.05.2022 01:37+10Ни на что особо. В том-то и главная проблема, что единственным реальным ответом на этот вопрос является "Никакие". Что для очень многих людей автоматически перемножает на ноль все что обсуждалось перед этим.
Karlson_rwa
29.05.2022 01:54+1Понятно. Ну каждому своё. Я вот сколько раз смотрел по всяким забугорным компаниям интересные мне предложения о работе. В половине случаев было чудесное ITAR controlled (или related, формулировки слега разные бывают), citizen и прочие атрибуты.
SergeyMax
29.05.2022 10:07+12А на что вы рассчитывали, задавая такой вопрос?
На ответ типа "у нас есть позиция, на которой не требуется подписания никаких форм".
Hlad
30.05.2022 11:22+1Я подписывал.
Жду не дождусь, когда секретка таки спадёт, ещё полгода осталось. Дальше что?
И про менеджмент — полностью подтверждаю.Karlson_rwa
30.05.2022 12:27+1Вторую? Чего там с третьей ждать-то?
Hlad
30.05.2022 12:36Да, вторую. Пять лет с момента последнего приобщения к секретам родины ждать надо :(
Karlson_rwa
30.05.2022 12:52Вас заставили это сделать что ли? Или вы не знали, что подписываете?
Hlad
30.05.2022 13:01+3Поясняю, как это происходит в реальности.
Шаг 1. «Вторая форма нужна, чтобы бла-бла-бла, реально ты к секретам не полезешь, а без ознакомления с секретами, сама по себе, эта форма ничего не значит» (и это на самом деле так)
Шаг 2, через несколько месяцев: «а на вот почитай документ». И пошли тикать пять лет.
ВСЁ. По молодости либо неопытности таким образом залететь — проще простого.Karlson_rwa
30.05.2022 13:04+2Значит вы ССЗБ, уж извините. Может вы и валютную ипотеку тоже не глядя подписали бы? Или еще какой кредит с мелким шрифтом. По-моему вполне очевидно, что если на вас оформляют вторую форму, то рано или поздно это ружье выстрелит. Не надо оправдывать собственную недальновидность молодостью и неопытностью.
Hlad
30.05.2022 13:07+4«Быть бедным, старым и больным — плохо, постарайтесь быть молодым, здоровым и богатым. У меня это получается, значит и у любого получится». Ну-ну.
Karlson_rwa
30.05.2022 13:11+2Неподходящая аналогия. Если вы при устройстве на работу не в состоянии осознать последствий подписываемых бумаг, значит в этом виноваты исключительно вы. Если работодатель при этом ввёл вас в заблуждение, разумеется, не делает ему чести. Но своя голова тоже должна быть.
Hlad
30.05.2022 13:18Окей, вернёмся к исходной точке. Если бы я не подписал эту вторую форму, то меня бы тупо не взяли на работу. А когда я начал сомневаться — уговаривали так, как описано выше.
Так что у разработчика НЕТ в реальной военке вариантов избежать хотя бы третьей формы. Ну, кроме варианта «вообще не работать на вояк»
Karlson_rwa
30.05.2022 14:13-2А у вас не было выбора с работой? Либо на военку либо в никуда? Вас кто-то насильно туда просил устроиться работать?
Hlad
30.05.2022 14:33+3Вы пытаетесь увести дискуссию от исходной точки. Напомню, изначальный тезис, который вы пытаетесь оспорить — что в военке без третьей, а то и второй формы работать разработчиком нельзя. Теперь вы пытаетесь соскочить на «вас никто в эту военку не гонит». Это принято относить к приёмам демагогии так то.
Karlson_rwa
30.05.2022 14:43Вы пытаетесь увести дискуссию от исходной точки.
Нет, я всего лишь утверждаю, что если у вас был выбор идти на работу с формой допуска или не идти, то факт того, что вы туда пошли — это исключительно ваше решение.
Вы начали отвечать на этот мой комментарий. Где я в нём оспариваючто в военке без третьей, а то и второй формы работать разработчиком нельзя
? Не занимайтесь приписыванием и додумыванием (тоже демагогия, ага), пожалуйста.
comandante_teresa
31.05.2022 11:49+2После «а на вот почитай документ» ничего тикать не начинает. Срок 5 лет отсчитывают после последней официально зарегистрированной даты взятия документа в БСТД.
comandante_teresa
31.05.2022 12:18+1Интересно, какое именно "блабла" вам вешали, рассказывая о необходимости второй формы, что вы прямо так доверчиво решили ее оформить.
Из опыта скажу - вторую форму с удовольствием оформляют, например потому что это, например, может быть плюс 40% к окладу, которые призваны компенсировать неудобства пользователя.
Третья форма - около плюс 20% к окладу и практически никаких выездных ограничений, и даже загран не сдается в отдел кадров. Сама по себе третья форма это фигня, которая выдается любому студенту и реально ни к чему особо не обязывает, буквально для ДСП.
Допустим у нас не брали без формы в том числе, что таких людей даже посадить негде, т.к. помещения аттестованы и на три этажа была буквально одна одноместная каморка, куда формально вписывали всех "недопущенных", в том числе командированных, гостей и т.д.
Yurik79
29.05.2022 08:13+15Да нет никаких подписок при разработке на контроллерах под военку. Даже на "взрослых" системах их нет.
Подписывают те, кто знакомится с условиями/требованиями изделия. Дальше идёт стандартное выделение функционала, деление на задачи и подзадачи. В результате, конечный исполнитель даже не знает что делает в глобальном смысле. Тут и делегировать на сторонние организации можно без проблем.
Подход древний, как сама инженерия.
Karlson_rwa
30.05.2022 00:02Ни разу не подписавшие ничего этого не знают и не хотят понимать. Для них слова «третья форма» это как красная тряпка. Бесполезно объяснять.
Shpakov
30.05.2022 09:49+5У нас в организации одно время на всех "причастных" оформляли секретность. А потом ввели доплату "за секретность", и через некоторое время руководство решило, что большей части сотрудников никакого допуска и не надо и прекрасно работается и без него...
F0iL
30.05.2022 10:17Да нет никаких подписок при разработке на контроллерах под военку. Даже на "взрослых" системах их нет.
А зачем тогда о потенциальном требовании формы секретности предупреждают сразу на собеседовании при трудоустройстве?
Karlson_rwa
30.05.2022 12:29А вдруг вам по служебной необходимости придется знакомиться с документами ДСП? Или с чем-нибудь типа ГОСТ-РВ. Формально вы должны иметь на это право.
F0iL
30.05.2022 12:37Вы в предыдущем комментарии говорили, что ничего подписывать не нужно и не придется, а в следующем комментарии говорите что оказывается может быть нужно и придется. Вы уж там определитесь, нужно или не нужно :)
Karlson_rwa
30.05.2022 12:55Демагог демагогович, пожалуйста, приводите конкретные цитаты, когда обвиняете или очки протрите. Где я говорил, что нужно будет подписывать? Хватит извращать мои слова.
F0iL
30.05.2022 13:17Я спросил: почему работодатели на собеседованиях прямо говорят о необходимости третьей формы?
Вы ответили: потому что по долгу службы возможно придется работать с определенными документами, для которых ее необходимо иметь.
Что мы имеем из ваших слов? Третья форма нужна. И согласно законодательству, чтобы получить третью форму, необходимо подписать письменное согласие на нее. Складывая первое со вторым получаем очевидный вывод.
Karlson_rwa
30.05.2022 14:17Я спросил: почему работодатели на собеседованиях прямо говорят о необходимости третьей формы?
Именно. По-моему вполне адекватный ответ на ваш изначальный вопрос, зачем при трудоустройстве некоторые компании хотят, чтобы вы подписали согласие на третью форму. Где тут было
Вы ответили: потому что по долгу службы возможно придется работать с определенными документами, для которых ее необходимо иметь.ничего подписывать не нужно и не придется, а в следующем комментарии говорите что оказывается может быть нужно и придется
?F0iL
30.05.2022 14:47Про "ничего подписывать не придется" написал другой комментатор, а вы под его комментарием выразили согласие со сказанным.
Karlson_rwa
30.05.2022 15:01Это вроде ваши слова?
Вы в предыдущем комментарии говорили, что ничего подписывать не нужно и не придется, а в следующем комментарии говорите что оказывается может быть нужно и придется.
Как-то не бьется с«ничего подписывать не придется» написал другой комментатор, а вы под его комментарием выразили согласие со сказанным
Т.е. вы занимаетесь приписыванием, если уж вы собрались ловить меня на логических ошибках.
Касательно моего комментария на комментарий Yurik79 о дроблении работы. У меня была третья форма, поэтому я из первых рук знаю что это такое. Несколько раз. Ничего ужасного в этом не было (только не надо из этого раздувать, что я автоматически согласен с политикой партии и всем прочим, что происходит в стране). Паспорт никто не забирал, на границе меня никто ни о чем никогда не спрашивал. В реальных работах, в которых я участвовал, где были закрытые параметры, делали так, как описано в комментарии Yurik79. Это мой личный опыт.F0iL
30.05.2022 15:17Так я признаю, что я перепутал вас с другим комментатором - вопрос я задал ему, вместо него ответили вы, без аватарок и других отличительных знаков перепутать легко, извините. Что не отменяет тот факт, что тот изначальный комментарий другого пользователя вы поддержали, таким образом согласившись с ним.
Личный опыт - это конечно, хорошо, но нет никаких гарантий, что ваш личный опыт будет применим для других, особенно когда что-то внезапно поменяется.
Hlad
30.05.2022 12:38+1Более того — ряд военных ГОСТов — сов.секретны. То есть, вторую форму надо, со всеми вытекающими.
Yurik79
30.05.2022 13:56У тебя есть орган и "потенциально", ты насильник... Из старой "шутки".
Предупредили или заставили?
"Предупредили". Что если вдруг, будет карьерный рост и из простого эникейщика, перейдёшь в разряд человека, имеющего право решать артихектуру или участвовать в обсуджении архитектуры, ты"вдруг" не узнал что надо сделать выбор.
"Предупреждают" где-то о внеурочной работе или командировках. "Предупреждают" о прохождении квалификационных испытаний. "Предупреждают" о переезде в другую локацию.
"Предупреждают" - это не обязательство.
Ты принимаешь во внимание и дальнейшее от тебя зависит. Не хочешь форму допуска 3(по сути ни к чему не обязывает, а 2 не дадут просто так с улицы и она излишня разрабам), можешь отказаться отполучения и остаёшься на прежнем уровне задач "вот тебе условие А, должно быть Б, через преобразование С". С допуском, можешь понимать почему А и Б, и С, и возможно исправить ошибку архитектурную при этом.
Нет расстрелов, нет ограничений на передвижения, нет проверок до 7 колена... "Меньше читайте советских газет" вобщем. Стандартно, очевидно, что аж плакать хочется.
F0iL
30.05.2022 14:54+1Предупредили или заставили?
Эм... Вы сейчас с чем спорите вообще? Никто и не говорил про "заставляют" и прочее. Дают простой условие: для работы на этой должности нужно согласиться и подписать, иначе работать на этой должности не выйдет. И для многих людей это автоматически множит на ноль все то, что обсуждалось на собеседовании до этого и они идут в другое место. Потому что...
нет ограничений на передвижения
...как уже тут сказали - "пока нет". Опять же, на вопрос "Учитывая происходящее последние N лет обострение маразма на госуровне, какие гарантии что в какой-то момент это никаких ограничений' резко не изменится задним числом?" нет никакого реального ответа кроме как "никаких".
Karlson_rwa
30.05.2022 15:04-1Дают простой условие… согласиться и подписать, иначе работать на этой должности не выйдет… множит на ноль все то, что обсуждалось на собеседовании до этого
Идти работать в компанию, где потенциально может быть форма секретности и первым вопросом не спросить, нужно ли будет её оформлять, ну это нужно быть очень-очень одаренным человеком.F0iL
30.05.2022 15:13+1Заранее далеко не всегда понятно, может она там быть или не может. Если бы было понятно, то на собеседования туда можно сразу не идти, чтобы не тратить время :)
В описании вакансии может быть вообще ничего, что намекает на вероятность такого, и в рамках одного и того же предприятия могут быть проекты для ВПК, а могут быть чисто гражданские разработки (я лично в такой работал - мы пилили софт для гражданского применения, а в соседних отделах делались разработки для заказчиков другого рода), и т.д. Поэтому приходишь, разговариваешь, пытаешься понять, чего ждать, и если становится понятно, что вероятность есть - спрашиваешь.
Hlad
30.05.2022 11:23Третью форму вешают вообще всем, без разговора. Да, сейчас она ни к чему не обязывает. но СЕЙЧАС.
GospodinKolhoznik
29.05.2022 23:30+3разработать железку - вот это настоящая сложность и искусство доступное не многим, а программу написать - вообще фигня, даже обезьяна на коленке справится
Из за этого подхода много интересных компьютеров из 80 загнулось. Когда разработчики железа именно так и постулировали, что мол главное это характеристики электроники, а софт пользователи сами себе без проблем напишут. Что привело к доминированию на рынке стандарта ibm-pc, по сути единственного стандарта, который не забивал на проблему обратной совместимости нового железа со старым софтом.
Такие легенды, как commodore, spectrum, bbc micro, amiga загнулись в первую очередь из за подхода - для новых версий железа понапишут новый софт с нуля. А неблагодарные пользователи отказались покупать новые компьютеры, на которых не запускались старые программы и игры.
Hivemaster
29.05.2022 00:34+66Кроме микроконтроллеров С уже практичеfские никому не нужен.
Разработчики Nginx, PostgreSQL, JVM, ядра Linux и многого другого смотрят на вас очень особенным взглядом.
Psychosynthesis
29.05.2022 14:30+11Да тут вся статья примерно того же уровня как и это возвышенное умозаключение.
AnthonyMikh
29.05.2022 19:43+2Насчёт остального не скажу, а вот код постгреса я в своё время вынуждено читал по работе. И это пиздец, за такой говнокод нужно руки отрывать.
0xd34df00d
29.05.2022 23:45+3JVM написан на плюсах, а постгрес, линукс и nginx начались примерно 35, 30 и 20 лет назад соответственно, когда особых альтернатив С не было.
Конечно, с одной стороны, эти проекты актуальны и сегодня, и им нужны контрибьюторы, поэтому чистый сишник не пропадёт. С другой — об актуальности сей для новых проектов это не особо много говорит.
hobogene
30.05.2022 01:19+2JVM написан на плюсах,
Какая именно? Но, скорее, с небольшой примесью плюсов. Там ведь тоже скоро тридцать лет истории.
0xd34df00d
30.05.2022 02:27+2Оригинальная сановская HotSpot, насколько я знаю.
hobogene
30.05.2022 02:32+1Можете взглянуть на исходники OpenJDK, которые из нее выросли. Так себе C++, прямо скажем. Даже по тогдашним меркам.
0xd34df00d
30.05.2022 02:56+1Оно? Если да, то 75% джавы, 13.5% плюсов, 7.4% сей. И то, судя по первым нескольким страницам поиска сишных файлов, это в основном либо какие-то наркоманские тесты, либо интеграция с сишными API ОС.
hobogene
30.05.2022 10:39Ну, во-первых, Вы на все JDK скопом смотрите, и 75 процентов Джавы обесценивают несколько нашу дискуссию. Сама JVM примерно тут:
https://github.com/openjdk/jdk/tree/master/src/hotspotВ качестве иллюстрации моей идеи можно глянуть, например, сюда:
https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_perf_windows.cpp
Формально плюсовый код. Но переполнен typedef struct и передачей в функции указателей на что-нибудь в тех местах, где в плюсах ожидалась бы ссылка. И пара классов в конце дописана в довольно архаичном стиле. Ну и все такое. Т.е. был сишный код, ну, потихоньку времена менялись, побрызгали сверху плюсами для запаха... Это не "написано на плюсах" IMHO. И такого там большинство.
Karlson_rwa
29.05.2022 00:43+36А вы всё же можете озвучить названия компаний, пусть завуалированные, где вам «посчастливилось» трудиться и в которых вы настолько искалечили (другое слово тут не подходит, на мой взгляд) свою психику?
Вы описали существование не программиста микроконтроллеров, а эникея, человека-оркестра, к которому, зачастую, и отношение соответствующее. Печально, конечно, что озвученные вами вещи существуют, но мне представляется, что такой бардак присутствует не только у нас. Он много где. Вспомните историю 737 MAX хотя бы.
Поспорить можно практически с любым вашим утверждением. От проводов до скукоты программирования. Да, в эмбеде нет формошлепства (ну почти) и ML только-только поднимает голову. Но в целом, если общая задача интересна, то почему бы и нет. Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного. С одной стороны, можно написать простейший ПИД и успокоиться. А с другой, можно реализовать какой-нибудь нечеткий регулятор (регулятор, кстати, может быть по положению, току, моменту, да чему угодно, к чему применима ТАУ), если система позволяет. И на его отладку и доведение до ума может уйти существенное количество интересно проведенного времени.
Тем, кто всё же осилил прочитать этот поток мыслей автора (каюсь, я не с первого раза сумел): люди, знайте, есть в России такие компании, где всё хорошо с разработкой. Где первый запуск устройства делают программист и схемотехник совместно, где целостность сигналов не пустой звук, а непропаи ищут специально обученные люди, где программист активно переиспользует свою же кодовую базу и где проекты не заключаются исключительно в преобразовании одного интерфейса в другой. Не много, но есть.
atd
29.05.2022 09:49+9есть в России такие компании, где всё хорошо с разработкой
А можно список? (не троллю, правда интересно)
Karlson_rwa
29.05.2022 23:16+2Мне представляется, что, например, в таких компаниях как WayRay, Yadro и им подобных всё как раз хорошо. Потому что без нормальных отлаженных процессов невозможно выпускать конкурентоспособный продукт.
0xd34df00d
29.05.2022 23:50Слышали ли вы что-нибудь про процессы в Оракле?
Karlson_rwa
29.05.2022 23:56+1Будете рассказывать, как у них там всё плохо? Охотно поверю. Просто не верно утверждать, что во всех коллективах эмбеддеров царит бардак и хаос.
0xd34df00d
29.05.2022 23:59+1Рассказывать не буду, сошлюсь на это. Можно, конечно, сказать, что это тоже нормальные процессы.
Просто не верно утверждать, что во всех коллективах эмбеддеров царит бардак и хаос.
Конечно. Но
без нормальных отлаженных процессов невозможно выпускать конкурентоспособный продукт
не является верным утверждением (и я мог бы показать другие примеры, кроме оракла, да не хочу рассказывать, где я успел поработать). Впрочем, оно не является прямым следствием из хаоса у всех эмбеддеров, так что с точки зрения матлога всё нормально.
Karlson_rwa
30.05.2022 00:05не является верным утверждением
Я сужу только по своей области работы и предполагаю, что в рыночных условиях все должны действовать примерно одинаково (за исключением неких выбросов, разумеется). Кто первый отладил процесс, показал заказчику, что его железка реально работает, того и тапки. Не берем в расчет коррупцию и прочие если.
order227
30.05.2022 01:27-1Во многих больших компаниях с процессами все отлично. Проблема автора, что он видимо поработал в компаниях уровня ООО Рога и Копыта, вот и все. 90% тезисов в статье банальная неправда и субъективщина, основанная на опыте одного человека.
hobogene
30.05.2022 01:50+5Больше похоже на НИИ Химических Удобрений и Ядохимикатов, чем на "Рога и копыта". Картинка-то весьма узнаваемая, но, конечно, далеко не везде так.
dimaaannn
29.05.2022 13:42+8Хорошо хорошо, если всё не так, и "вывсёврёти" - то предлагаю ответить на несколько простых вопросов.
Есть ли в эмбед-разработке менеджер пакетов и общий репозиторий? Вы конечно можете начать меня убеждать, что это "никому не нужно" - но вряд ли это получится )
Есть ли должность "инженер-программист" для эмбед разработки, куда можно пройти без знания схемотехники и не умея пользоваться осциллографом? Если да - то куда именно. Если нет - то это прямое опровержение ваших слов о том что "это не программисты а эникейщики"
Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного.
Отличный пример. Зачем ЕЩЁ раз решать задачу, которую до тебя решили уже "сто тысяч милионов" раз? Поведений двигателя и и способов его управления гораздо меньше, чем http запросов. Но тем не менее, в каждом языке есть библиотека, которая отправляет такие запросы, но эмбедщики за столько лет не удосужились поделиться своими шедеврами с другими. Это высшая форма жадности или отсутствие банальной организации кода?
есть в России такие компании, где всё хорошо с разработкой
Отлично, назовите компанию и прибор, где можно проникнуться величием отечественной разработки. ) Может быть.... Банальный частотник для двигателя? Или своя система управления ЧПУ станком?
F0iL
29.05.2022 14:16+3Что ж вы сразу с козырей-то заходите :) Можно было для начала спросить, сколько компаний из "хороших" прошли бы хотя бы на 11/12 тест Джоуэла (и классический и новый), и в каких из них сотрудникам официально разрешено приходить на работу каждый день не к 8 или к 9, а во сколько удобно :)
Karlson_rwa
29.05.2022 23:50К эмбеду (не ко всему, конечно), тест Джоуэла не совсем применим, на мой взгляд. Это очередное натягивание совы на глобус. А уж про гибкую разработку я много чего могу рассказать за рюмкой чая.
Уже много лет прихожу на работу во сколько удобно. Выполняю работу. Того же прошу от своих коллег. В итоге работоспособные продукты, довольные заказчики и акционеры предприятия.F0iL
30.05.2022 00:25+2К эмбеду (не ко всему, конечно), тест Джоуэла не совсем применим, на мой взгляд.
Гораздо больше применим и нужен, чем многим кажется.
solderman
29.05.2022 15:15+3Вот например почти чпу, только с несколькими фиксированными циклограммами под конкретные задачи.
Вот еще например агрегатор мониторинга оборудования написанный на С для mega2560. Все встраиваемые модули на нане или есп8266
Karlson_rwa
29.05.2022 23:43+1вывсёврёти
Не передергивайте, пожалуйста. Я всего лишь написал, что с каждым утверждением автора можно поспорить.менеджер пакетов и общий репозиторий
Отвечу вопросом на вопрос: для какой платформы какого производителя чипов? Вы же понимаете (по крайней мере я надеюсь на это), что уровни абстракций слегка разные? У вас может быть ноутбук от десятка вендоров, собранный из запчастей сотни производителей. Но при этом его глобальная архитектура будет одинаковая, хотя и реализована она будет физически разными транзисторами внутри разных микросхем. А поверх всего этого нагромождения железа крутится некая единая в смысле своего внутреннего устройства операционная система, под работу с которой вы уже и имеете всяческие репозитории, менеджеры пакетов и прочий блэкджек. Ваше утверждение про репозитории, это всё равно, что сказать: а давайте у всех будет один микроконтроллер и только на нём мы будем что-то делать. Вы вообще в курсе, что есть такая штука как драйвера под конкретное железо (самые что ни на есть низкоуровневые, пишущие непосредственно в регистры физической микросхемы, для которой написаны), которые и позволяют вам в общем случае (при написании ПО верхнего уровня) не задумываться, видюха от NVIDIA у вас внутре стоит или от AMD (да и то со всеми этими современными ML приходится задумываться, а какое конкретно железо стоит внутри)?
Так что в такой постановке ваш вопрос не корректен.Есть ли должность «инженер-программист» для эмбед разработки
Есть где? В компаниях? Есть. Если бы у меня и моих коллег на прошлой работе было бы свободное время для обучения такого джуна, я бы с удовольствием его нанял. Собственно, я такое делал с разработчиками железа. Разумеется, быть программистом-эмбеддером и не понимать, что происходит в железке малореально, поскольку от кода такого разработчика зачастую зависит правильное физическое функционирование устройства, поскольку предусмотреть аппаратные защиты от кривого кода на все случаи жизни не всегда возможно\целесообразно.которую до тебя решили
Вот опять. Различных платформ десятки, если не сотни. В каждом конкретном случае есть свои особенности. По питанию, потреблению. Особенности объекта управления (двигателей вообще-то тоже много всяких разных с разными параметрами и свойствами, от микроваттных до мегаваттных). И что, под них делать некую «единую» библиотеку? Впрочем, некоторые производители микроконтроллеров имеют «библиотеки», разработанные под те или иные семейства микроконтроллеров, реализующие различные «управляторы». Качество зачастую страдает, но где оно не страдает?эмбедщики за столько лет не удосужились поделиться своими шедеврами с другими
Если вы чего-то не видели, это не значит, что этого не существует.Отлично, назовите компанию и прибор, где можно проникнуться величием отечественной разработки.
Как вы себе представляете процесс пенетрации в величие? Может вам еще исходный код показать, сиречь, дать ключи от квартиры где деньги лежат? :) К сожалению, всё что я знаю лично, не стоит озвучивать в интернете, товарищ майор не будет рад. Так что можете смело называть меня диванным аналитиком, что поделать.F0iL
30.05.2022 00:31+2для какой платформы какого производителя чипов?
Вы про разделение HAL и непосредственно логики рабочей задачи слышали? Очень многие из упомянутых выше и в статье вещей (всякие FSM, реализации протоколов, общих алгоритмов управления, и т.д.) от используемой платформы и конкретного микроконтроллера не зависят и зависеть вообще не должны. А если даже по какой-то причине зависят, то это никак не мешает иметь для них общий пакетный репозиторий - размещать в нем пакеты сделанные под разные и под определенные платформы, использовать флаги при компиляции, и т.д.
Karlson_rwa
30.05.2022 00:52Вы про разделение HAL и непосредственно логики рабочей задачи слышали?
А что в моём комментарии заставляет вас думать, что нет? Отсутствие единой ардуины для всех микроконтроллеров? Как вы себе представляете единую реализацию, например, векторного управления бесколлекторным двигателем для кардинально разных архитектур, с разной битностью и наличием или отсутствием FPU (впрочем, как и любых других аппаратных блоков, которые, порой сильно влияют на общую производительность всего алгоритма)? Нет, можно, разумеется, такое написать. Но зачем? Не будет ли максимально адаптированная под конкретную архитектуру реализация намного более продуктивной, чем луковичный монстр, завернутый в тонну обёрток? Всё же, надо делать поправку на область применения и ограниченные ресурсы. Иначе мы придем к тому, что в каждом чайнике, для того, чтобы сделать приятную подсветку нагревающейся водички будет стоять четвертая малина. Зато да, зато код будет универсальный, репозитории с менеджерами будут и вот это вот всё.F0iL
30.05.2022 01:09+2Не надо тут ложной дихотомии про четвертую малину.
Во-первых идея репозиториев и переиспользования кода вовсе не противоречит максимальной адаптации под конкретную платформу. Если испольщуется у нас эта платформа - берём реализацию под нее, используется другая - берём другую. Если нет кокнретно той, что надо - берём то что есть, перепиливакм под свои нужды, оптимизируем, делимся с другими.
А во-вторых, что гораздо важнее, далеко не все функциональные блоки требуют глубокие оптимизации под конкретные железки. Что много лет назад, что до сих пор, чуть ли не в каждом третьем embedded-проекте разработчики пишут свою кривую, глючную и не полностью соответствующую стандарту реализацию какого-нибудь банального модбаса, никаких особых оптимизаций и привязок к железу там вообще не требуется, и "сделаем свое" обуславливается именно отсутствием удобных способов подтянуть готовую имплементации вкупе с классическим NIH синдромом. Именно об этом и говорил комментатор выше.
Karlson_rwa
30.05.2022 02:24Не надо тут ложной дихотомии про четвертую малину.
Что, простите?
Ну вот есть, например, github.com/search?o=desc&q=modbus&s=stars&type=Repositories Вам от этого сильно легче стало? Чтобы эмбеддеру было удобно, нужна ровно одна среда разработки (IDE, называйте как хотите), в которой будут писать все под всё. Наверное, раз такой единой (кто сказал эклипс? гусары, молчать!) среды нет, значит нет и рентабельной потребности в ней. Либо проблема еще глубже, чем кажется на первый взгляд.F0iL
30.05.2022 10:09-1Что, простите?
То :) У вас в комментарии была в прямом смысле ложная дихотомия: либо отсутствие удобных инструментов и подходов в разработке, либо четвертая малина в каждом чайнике. Это не так.
нужна ровно одна среда разработки (IDE, называйте как хотите), в которой будут писать все под всё.
Зачем ровно одна? Больше инструментов хороших и разных, чтобы удобно было каждому.
А если вы клоните к завязке IDE на пакетный менеджер, то она вовсе не нужна. При правильном подходе пакетный менеджер вообще не должен зависеть от IDE. Всё это уже давно придумано и обкатано.Вам от этого сильно легче стало?
Мне станет сильно легче, когда люди начнут этим пользоваться вместо очередного изобретения велосипедов, хотя бы для того кода, который не требует хардкорных оптимизаций и не завязан на конкретное железо. Вот именно отличительная особенность embedded-тусовки - что там каждый второй Васян уверен, что всякие там библиотеки, которые до него запилили, допилили проверили и использовали уже тысячи людей - ну их нафиг, в них разбираться надо, и наверное в них баги еще, а уж вот лично он-то точно сейчас сядет и напишет свою свою собственную реализацию как надо. Приводит это обычно к печальным результатам (а когда Васян берется за криптографию, так еще и к опасным).
Karlson_rwa
30.05.2022 13:00-2отсутствие удобных инструментов и подходов… вместо очередного изобретения велосипедов… отличительная особенность embedded-тусовки… лично он-то точно сейчас сядет и напишет свою свою собственную реализацию как надо
Да где оно, где это чертово отсутствие? Удобные инструменты есть? Есть, причем они развиваются. Подходы есть? Есть. Если этими подходами и инструментами какой-то Вася пользоваться не хочет, это не означает, что все остальные Васи такие же. Вы меня обвиняете в ложной дихотомии, а сами безосновательно постоянно скатываетесь в необоснованные обобщения. При этом в этом же топике уже приводили историю с ораклом и говнокодом. Но нет, это ведь другое.F0iL
30.05.2022 15:07-1Если этими подходами и инструментами какой-то Вася пользоваться не хочет, это не означает, что все остальные Васи такие же.
Где я делал такие обобщения, покажите? Я написал не "все остальные", а "каждый второй" - разницу видите? Эта оценка субьективная и эмпирическая, от вашей она может отличаться, но это то, что я видел и вижу своими глазами. И тут встает самый главный вопрос, если ткнуть в рандомные конторы в отрасли, на кого больше будет вероятность там наткнуться - на Вась или на не-Вась.
При этом в этом же топике уже приводили историю с ораклом и говнокодом
Что вы этой историей хотите сказать, можете развернуть мысль? Что говнокод может быть везде? С этим никто не спорит. Более того, чем более проект старый и чем больше в нем наросло легаси, тем больше в нем может быть говнокода - а учитывая, что Оракл ведет свою историю еще из 80-х годов, то подобное не удивительно. История с Ораклом, кстати, наоборот демонстрирует то, что благодаря применению правильных практик (у них там миллионы автоматизированных тестов) даже проект состоящий целиком и полностью из говнокода не развалился в тартарары, а успешно развивается десятки лет и удерживает свою рыночную долю.
order227
30.05.2022 01:30+2назовите компанию и прибор
Колонка и серверы Яндекса… Колонка и девайсы СберТеха… Серверы Yadro… можно продолжать очень долго, благо с дизайном и RnD в РФ все очень неплохо.F0iL
30.05.2022 10:15-5Колонка и девайсы СберТеха
Вы наверное имели в виду SberDevices. Правда, про них недавно выяснилось, что это китайцы с переклеенными шильдиками.
order227
30.05.2022 11:20На счет лампочек ничего сказать не могу, но box и колонка это их собственный дизайн и вполне достойный. Может вы скажите, что серверы ядра и колонка яндекса тоже с переклеенными шильдиками?
Обожаю менталитет СНГ, все превращающий вговно«плач ярославны»: когда никто ничего не делает — плохо, когда компании что-то делают свое и конкурентное — все равно плохо. Жду следующий опус мол «а компоненты то не отечественные, резисторы сделать не можем»…F0iL
30.05.2022 11:25-2Может вы скажите, что серверы ядра и колонка яндекса тоже с переклеенными шильдиками?
Зачем? Про серверы и колонку яндекса мне достоверно неизвестно, поэтому я про них такого и не говорю.
плач ярославны
Плач может быть просто так, а может быть и по делу. Первый нужно игнорировать, ко второму прислушиваться.
Когда никто ничего не делает — плохо, когда компании что-то делают свое и конкурентное — все равно плохо.
Когда делают что-то свое и конкурентное - это офигенно, это действительно повод для радости и восхищения. Увы, это происходит не настолько часто, насколько хочется.
А нередко за "своё" выдают чужое, причем глядя при этом кристально честными глазами. И это гораздо хуже. Я в работе на такое насмотрелся уже, и не раз, это для меня тоже больная тема. Потому что самое плохое здесь - от такого как раз страдают те, кто действительно пытаются делать что-то своё.Жду следующий опус мол «а компоненты то не отечественные, резисторы сделать не можем»…
Не недо приписывать собеседнику свои выдумки.
Karlson_rwa
30.05.2022 13:09-1за «своё» выдают чужое,
Вам, видимо, не знаком термин «адаптация». Это нормальный процесс и бизнес, пользующийся этим, совершенно не обязан лично перед вами отчитываться, что они адаптировали, а что разработали сами с нуля. Это нормальное явление в современном мире. Или вы думаете, что те же ноутбуки производит только условный леново и асус и нет OEM производителей, готовых слегка кастомизировать свою платформу под ваши задачи и наклеить на неё ваш шильдик?Не недо приписывать собеседнику свои выдумки.
Этим как раз всю дискуссию вы занимаетесь.F0iL
30.05.2022 15:04Речь о том, что не надо выдавать OEM за "наши разработки", понимаете?
Во-первых, это вводит в заблуждение сторонних наблюдателей и создает у них искаженную картину того, как на самом деле обстоят дела в отрасли.
Во-вторых, что гораздо более важно, от такой подмены страдают именно те, кто действительно пытается что-то сам разрабатывать и производить.Я неспроста привел в пример выше историю с перекрашенными Сименсовскими контроллерами, потому что я сам как раз в те годы работал в АСУТП и подобные истории наблюдал своими глазами.
Берется курс на импортозамещение, и заказчиками начинает отдаваться приоритет отечественной продукции. Одни компании берут, и начинают разрабатывать что-то на самом деле своё - свою схемотехнику, свои прошивки, свои десктопный софт. Да, поначалу у них получается далеко не идеально (невозможно за пару лет достичь того мастерства и опыта, который другие оттачивали десятками лет), и не всегда дешево (из-за маленьких партий, например). А потом приходят такие вот "оемщики", выдают перекрашеный сименс под видом "отечественного продукта" (хотя от отечественного там только название и перевод инструкции), по документам все чисто, и естественно, клиент отдает предпочтение привычному и проверенному, таким образом оставляя тех, кто на самом деле разрабатывает и развивает что-то сам, без заказов и без денег на дальнейшие разработки.
Karlson_rwa
30.05.2022 15:21Вы прикопались к сберовским лампочкам, которые оказались китайскими. Сбер где-то вещал про импортозамещение лампочек? Может я плохо смотрел, но именно воплей про импортозамещение не припоминаю. Сбер — вполне себе коммерческая структура, которая может заявлять что угодно про что угодно в рамках текущего законодательства. Так многие делают.
по документам все чисто
Я не собираюсь спорить, что нечестное выдавливание с рынка конкурентов под видом импортозамещения это хорошо. Нет, это, безусловно, плохо. Есть такая штука как 719-е постановление. И да, это проблема, что оно написано как написано и перекрасив корпус можно выиграть тендер, а с другой стороны потерять финансирование разработки. Значит не надо ориентироваться только на госзаказ. Это вообще такая себе палка о двух концах. Вроде как стабильные деньги, а попробуй сделай что-то не так или не в срок, так прилетит, что потом можно и не встать.
Arastas
29.05.2022 14:18+8Настройка регулятора, что базовый мультиконтурник на пид, что какие-то более продвинутые, это работа не программиста, а инженера систем управления. У программистов, как правило, просто нет должной квалификации. А когда все делает человек-оркестр, то и регуляторы выглядят как курсовик по ТАУ, и качество кода вызывает вопросы.
Karlson_rwa
29.05.2022 23:51Зависит от размера компании на мой взгляд. Как по-вашему программист реализует регулятор, если не будет понимать физических принципов, которые за ним стоят?
aabzel Автор
30.05.2022 00:06Мы в универе на лабе настраивали PID регулятор методом Цинглера-Николсена.
https://en.wikipedia.org/wiki/Ziegler–Nichols_methodKarlson_rwa
30.05.2022 00:09+2Поздравляю вас с этим достижением! Это стандартный эмпирический метод. Со своими ограничениями. И настроить регулятор по методике вовсе не означает «написать код, физически его реализующий на конкретной платформе». Слегка ортогональные понятия.
gorbln
30.05.2022 00:47+2Метод Зиглера-Никольса. Предложен чуть не в 50-х ли годах 20 века. Имеет несколько вариаций и улучшений. Вот только этот метод применим, ну, скажем так, "не всегда". Иногда систему нельзя раскачивать, а иногда нельзя и раскачать. При этом - модель в матлабе и система в железе - немного разные вещи. Помехи, шум АЦП, всё это усложняет задачу поиска точек перехода через ноль и отсечения ложных переходов. Короче - для автонастройки грелки или сливного бачка - норм. А когда начинаются реально сложные вещи, с инерцией, трением, прочими нелинейностями - выясняется, что метод не применим.
Arastas
30.05.2022 01:13+1Я не уверен, что понимаю, о каких физических принципах вы говорите. Регулятор это некоторое математическое преобразование входных сигналов в выходные. Для его реализации, программисту не сильно нужно понимать, из каких принципов были получены итоговые формулы. И уж точно не обязательно уметь получать их самому.
Karlson_rwa
30.05.2022 02:02+1не сильно нужно понимать, из каких принципов были получены итоговые формулы
Т.е. это не программист, а кодер? За него кто-то рисует алгоритм, составляет формулы, которые тот просто переводит с условной бумаги в машиночитаемый язык. Так?0xd34df00d
30.05.2022 02:30+2А насколько глубоко вы понимаете те формулы, которыми пользуетесь?
Я почти уверен, что большинство датасайентистов не помнит какую-нибудь теорию меры. А ведь теория меры — это не то что не конец, а даже не середина кроличьей норы.
Karlson_rwa
30.05.2022 02:51А насколько глубоко вы понимаете те формулы, которыми пользуетесь?
Зависит от конкретной области. Что-то мне представляется понятным чуть лучше, что-то чуть хуже. А что-то вообще темный лес. Но я ж не программист, я с этого когда-то начинал, потом ушел полностью в железо о чем не жалею ни разу. Просто постоянно взаимодействую с программистами и вижу, как и что они делают (или пытаются).не помнит какую-нибудь теорию меры
И это не делает им чести. С другой стороны, количество знаний, необходимых для решения конкретной задачи конкретным инструментом зачастую весьма мало и ограничено.
Но я же о другом, я же говорю о конкретной реализации чего-то. Как можно написать регулятор, если тебе не известны особенности архитектуры микроконтроллера, особенности периферии, особенности объекта управления? Будет какой-то сферический регулятор, который кто-то (как там комментатор выше его назвал, инженер систем управления?) будет вынужден приспосабливать к реальному железу, сиречь, менять коэффициенты, настраивать ограничения.
mvv-rus
30.05.2022 06:12А насколько глубоко вы понимаете те формулы, которыми пользуетесь?
А всегда ли это надо — понимать на глубоком уровне?
А то вот мне вспоминается физик и электротехник по фамилии Хэвисайд, живший примерно полтора века назад. Он тогда для решения дифференциальных уравнений изобрел некое символическое исчисление, основанное на интегральных преобразованиях. Причем интегралы в этих преобразованиях, с точки зрения тогдашней математики, могли просто не существовать — но исчисление при этом работало как надо, вопреки глубокому пониманию, точнее — невозможности такового.
Потом, конечно, математики придумали, как эти свои интегралы и все такое прочее определить получше, но это было уже решение проблем математиков: инженерам оно для работы не требовалось.0xd34df00d
30.05.2022 09:52+1Так я про то и говорю, что не факт, что надо.
Понимающий теорию меры чувак, скорее всего, не знает основания математики в смысле матлога. Датасайентист, скорее всего, не особо знает теорию меры. […] Эмбеддщик, кодящий какую-то формулу, скорее всего, не особо знает, какие из участвующих функций должны иметь какие свойства, чтобы все нужные теоремы выполнялись.
victor_1212
29.05.2022 01:11>Я по молодости думал, что это наша отечественная специфика, но нет - говнокод в embedded - явление, увы, интернациональное.
конечно интернациональное, но imho далеко не embedded specific, зависит скорее от стандартов проекта, компании и пр (или отсутствия таковых), но embedded systems имеют особенность, ими интересно заниматься там где делают новое hw, а не копируют чужое, соответственно опыт в разных странах сильно отличается, про важность работ над embedded sw, говорить много не требуется, большая часть сети держится на таких системах, interconnect так близко к 100%, где был написан код хорошо известно, можно ли назвать его типа говнокод, думаю что нет, хотя конечно немного есть и этого,но как правило в части ui (видеть приходилось), насколько сложное там sw - достаточно сложное, у большого router процессоров до нескольких сотен, количество сообщений между ними зашкаливает, и т.д., далее embedded для сетей это типа верхушка айсберга, все что плавает, летает и ездит управляется embedded systems, соответственно там где это производится отношение и к технологии, и к программистам сильно отличается от описанного в статье, про уникальные системы реального времени вообще разговор особый, ввиду их важности и сложности разработки, примерно так, как обычно imho
Ivanii
29.05.2022 11:28+2Был удивлен когда первые разы видел куски схемотехники и иногда платы на дип компонентах перетащенные в новые устройства из 20+ лет разработок крупными европейскими производителями.
victor_1212
29.05.2022 16:38>перетащенные в новые устройства из 20+ лет разработок
своих или чужих?
если это reference design обычное дело, многие в китае только так и делают
AlexanderS
29.05.2022 02:40+3… и надо будет вкуривать очередную схемотехнику на 30-60 страниц. А схемотехники даже блок-схему не нарисуют, сразу дают в лучшем случае Э3 а в обычном случае и вовсе принесут плату без доков и скажут, что надо ее оживить.
Очень жизненно)
Pavel_nobranch
29.05.2022 04:26+6В программировании мк на ассемблере есть особый кайф, например когда считаешь такты при общении по протоколу 1-wire
vau
29.05.2022 10:09+9не надо считать такты 1-wire на ассемблере. надо делать автоподстройку скорости обмена под емкость линии. девайсы разные, количество девайсов на линии может быть разное, тип линии и ее электрические параметры тоже. на одной скорости работает очень узкий класс решений.
Pavel_nobranch
30.05.2022 05:05+3Не точно выразился. Кайф от того что каждый такт имеет значение, кайф от битовых операций.
Maks027
30.05.2022 01:57Да, кайф. Вот только никто этим и не занимаемся для устройств которые должны пойти в производство. В реальности нужно прочитать документацию для мк и настроить регистры встроенного интерфейса который справится с этим намного лучше и не будет занимать драгоценные циклы процессора.
Как и в большинстве интересных задач, они уже были решены, и решены хорошо, так что они остаются только как хобби
Pavel_nobranch
30.05.2022 05:08+1Да хобби. Делал на atmega 8 сигнализацию на машину себе, а открывание двери сделал таблеткой от домофона от своего подьезда. Просто захотелось)
old_bear
29.05.2022 04:50+9Я таки чувствую некоторую обиду не найдя в списке опросника классики в виде 8051.
По статье - всё правда, хотя меня это затронуло в своё время не так сильно, как побочная задача при разработке достаточно сложных устройств на FPGA. Но память о EZ-USB™ неизгладима и спустя пару десятилетий.
Единственное за что я могу сказать спасибо embedded, так это за осознание того, насколько полным может быть контроль над устройством при использовании Asm-а. Это осознание очень пригодилось позже, когда возникла необходимость по максимуму оптимизировать некоторые критические места уже совсем другого кода работающего с SSE/AVX.
Albert2009ru
29.05.2022 12:46+7Да в этом списке нет также и PIC. Кроме того, лично у меня, вот прямо сейчас в работе три простых проекта на PIC12F675, Atmega64M1 и xmc4700. А в опроснике нет возможности выбора всех трех семейств. Плюс ни в тексте статьи, ни в опросах не упомянуты такие IDE, как Atmel(Microchip) Studio и MPLAB-X. Вот конкретно я в них работаю...
Хотя за статью спасибо.
Cheater
29.05.2022 05:05+21а plain С это 89, 99, 2011 и всё
C17 и C2X такие:
У РФ нет даже своего текстового редактора.
Facepalm. Вам так нужен национальный текстовый редактор? Он сможет обскакать Emacs, Vim, Sublime, vscode, в которые вкидывались сотни человеко-часов и про которые я честно говоря даже не знаю их национальную принадлежность?
Всеми любимый текстовый редактор VS Code от Microsoft.
Как будто vscode индустриальный стандарт)) Я так понимаю это просто странно сформулированная мысль "Среди эмбедщиков больше перекос от IDE к редакторам, чем в прикладном программировании".
В целом, жалобам верю, но вы имхо попали в "пузырь" с неудачным типом работодателя. Отсюда и все эти гаражи и ноутбуки на коленях. Российские компании, разрабатывающие под МК, это весьма характерный типаж.
"Навыки программирования на С очень слабо конвертируются" - слишком пессимистично. Дело же не в знании непосредственно Си, к сишке у разработчиков встраиваемых систем прилагаются знания модели памяти в C, работы сисколов, бинарников, ассемблера, отладки, вы ужаснётесь если узнаете насколько прикладники этого всего не умеют.
aabzel Автор
29.05.2022 13:51-1Реальность такова, что если новый сотрудник в российской Embedded компании не пользуется VS Code от Microsoft, то его будут тиранить угнетать изводить коллеги (peer(ы)) пока новый сотрудник не установит этот 500MByte(ный) в RAM VS Code и не научится пользоваться VS Code потому, что все остальные там уже давно пользуются VS Code.
Karlson_rwa
29.05.2022 23:59+3Такова реальность преломленная только через призму конкретно вас. Вам самому не надоело обобщать всё и вся? Вы поработали в нескольких компаниях, увидели одинаковый бардак и почему-то решили, что так везде. А это далеко не везде. Говорю с точки зрения своей призмы.
JerleShannara
30.05.2022 02:37+2Нигде не видел, чтобы за «Я ваше электронское поделие для МК не юзаю» гнобили, а поработал много где именно вот с этими самыми МК (от 8051 до aarch64). Зато в срачах IAR vs Keil vs Eclipse довольно много участия принял.
AnthonyMikh
29.05.2022 20:01C17 и C2X такие:
Учитывая, что даже C11 на практике используется в исчезающе малых количествах — вполне справедливая на практике точка зрения.
smart_alex
29.05.2022 07:18+44Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров. Хлам на столах с горочкой.
Хлам не на столах, а в голове. Только и занимаюсь тем, что программирую микроконтроллеры. Отличное, стильное, высокотехнологичное и удобное окружение. Работать удобно и приятно.
И вообще статья оставляет какое-то гнетущее безысходное впечатление — до прочтения статьи был уверен, что программирование микроконтроллеров это самое интересное и увлекательное дело на свете.
Serge78rus
29.05.2022 13:34+3до прочтения статьи был уверен, что программирование микроконтроллеров это самое интересное и увлекательное дело на свете
И что, неужто эта статья пошатнула Вашу уверенность? )
TsarS
29.05.2022 13:40+6Мне вот вообще стало интересно программирование микроконтроллеров после этой статьи.
smart_alex
29.05.2022 13:55+4Нет конечно, просто с удивлением узнал, что у народа такие напряги с этим делом :)
pfr46
29.05.2022 07:45+2Сколько программирую МК и что я, что моё окружение, всегда использовали Форт. А также просто знакомые "коллеги" по программированию МК, что российские, что зарубежные так же предпочитают его использовать. С и уже тем более С++ где-то далеко.
DustyZebra
29.05.2022 09:29+3Йоды джедаев магистра речи тайна раскрыта — на Форте просто старый программер он есть
Forth, конечно, хорош - но вот скопи-пастить более менее серьезные библиотеки неоткуда.
Все сами, девочки.pfr46
29.05.2022 10:15+3Это его фича. Из-за возможности расширять сколь угодно язык средствами самого языка - под каждую специфическую "железку" на нём пишут свой язык под этот МК. Очень удобно, продуктивно и минимум ресурсов.
DustyZebra
29.05.2022 10:40+2Да я смутно помню :) Когда-то свой кросс-компилятор писал на ДВК для 8080. И форт-ориентированный экранный редактор для ДВК-2 - аж 3 килобайта потребовалось :) , если склероз не изменяет.
hobogene
29.05.2022 10:19+3Уважуха! Видно человека, начинавшего примерно в одно со мной время, и говорящего знакомые слова :-)
Но интересно, какова у Вас предметная область? Далеко не большинство FORTH сейчас используют, конечно. И далеко не все имеет (экономический) смысл на FORTH'е сейчас писать. Попробуйте Zigbee или LoRaWAN устройство, например, реализовать...
da-nie
29.05.2022 08:45+7Да и программы простые.
В условиях перехода на отечественные микросхемы, у нас происходит уже много лет следующая ситуация. Например, нужен вычислительный модуль. Что он должен делать? Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей. Смотрим, из чего такое можно сделать на отечественной базе да ещё с пятой-девятой приёмкой. И окажется, что ничего такого особо и нет («Эльбрус» чем-то не подходит, уже забыл чем именно). Зато есть продукция миландра типа 1986ВЕ1Т или 1986ВЕ92. Ну и, например, убожество типа 1867ВЦ6Ф есть. Вот набор этих штук и будет заменять собой компьютер. И программа простой не будет, не ждите. :) Это не переходник. Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом. То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.nordligeulv
29.05.2022 13:33+2Вы забыли ещё про НИИЭТ К1921ВК01(028/035)Т. Потом есть ещё Элвис.
da-nie
29.05.2022 14:18+1У меня военка. :) Мне такое нельзя.
А что можно, всё такого же уровня. А заменить надо по сути ПК. Вот и извращаемся.nordligeulv
29.05.2022 14:20+1НИИЭТ как раз можно. У них военная приёмка
da-nie
29.05.2022 14:30+2Вот К1921ВК01 — нельзя. У него буква К намекает, что это не военная приёмка. Корпус пластиковый тоже об этом свидетельствует.
nordligeulv
29.05.2022 14:32+3Есть 2 версии. Одна в пластиковом корпусе, другая металлокерамика - https://niiet.ru/product-category/chips/microcont/risc-32-bit/
Без 'К' как раз металлокерамика
da-nie
29.05.2022 14:34+2Эти можно. Но суть так же — используем МК вместо компьютера.
nordligeulv
29.05.2022 16:11+1Тогда Байкал, если у них есть металлокерамика.
da-nie
29.05.2022 17:13+2Было бы интересно посмотреть, что уже кто собрал на Байкале (кроме анонсированных «Таволга» и маршрутизаторов). Тут есть ещё проблемка. К такому процессору память желательна и ОС. А динамическую память отечественную приличного объёма я не встречал (думаю, её не производят). Вот и получится в лучшем случае Байкал+16 Мб ОЗУ (статического :) ). :)
FGV
29.05.2022 17:21+2То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.
Примеры "наших реалий" можно? А то недавно ковырял "забугорную железку", так там на удивление:
Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом.
Т.е. куча "убогих" МК висящих на шине типа arinc/1533, каждая что то считает и чем то управляет.
Ну и, например, убожество типа 1867ВЦ6Ф есть.
Это ж tms320c3x, вполне нормальный камень. Собсно на нем вполне себе реализуется:
Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей.
da-nie
29.05.2022 17:36+1Примеры «наших реалий» можно?
Не понял вопроса. Я работаю в ВПК (корабли, космос и РВСН).А то недавно ковырял «забугорную железку», так там на удивление:
Ну, у нас вот так просто не получилось в силу специфики технического задания. И автоматика с графом переходов такая, что без пол-литры разобраться очень непросто.Это ж tms320c3x, вполне нормальный камень.
Это — привет из 80-х. А в подарок древний компилятор С с 40 битными типами данных (да, char — 40 бит) и своей собственной системой хранения float и double. И достаточно низкая частота.Собсно на нем вполне себе реализуется:
Всегда интересовало, как можно подобное утверждать, не зная специфики задачи? :) Когда у вас частота обработки десятки Гц и матрицы 28x28 это уже не так просто реализуется. Поэтому у нас в системе четыре процессора, объединённых двухпортовым ОЗУ.FGV
29.05.2022 18:18Всегда интересовало, как можно подобное утверждать, не зная специфики задачи? :)
Ну собственно об этом и речь. Что то вполне реализуется на "привете из 80-х".
40 битными типами данных (да, char — 40 бит) и своей собственной системой хранения float и double.
Насколько помню 40 бит - внутреннее представление числа с ПЗ (32-мантисса, 8-порядок, формат отличается от IEEE754), но разрядность ШД - 32 бита и при сохранении/чтении в/из ОЗУ 40 бит конвертируются в 32 (мантисса обстригается до 24). Про 40 битный чар - не знаю (до си не добрался, кодил это чудо на асме), но что то мне подсказывает что с такой организацией памяти это не так.
da-nie
29.05.2022 18:44+1Что то вполне реализуется на «привете из 80-х».
Что-то всегда реализуется. Но что-то и нет. :)Про 40 битный чар — не знаю
Пардон, наврал. Не 40 бит, а 32. 40 — это long double.Data sizes char, short, int, long, float, and double are 32 bits.
Data size long
double is 40 bits. This allows all types of data to take full advantage of the
TMS320C3x/C4x integer and floating-point arithmetic capabilities. For more
information, refer to Section 3.2 on page 3-4
Вот тут описано на странице файла 101.
Вся таблица вот такая:
FGV
29.05.2022 19:26Пардон, наврал. Не 40 бит, а 32. 40 — это long double.
Во, вот это уже похоже на правду.
Когда у вас частота обработки десятки Гц и матрицы 28x28 это уже не так просто реализуется.
Перемножение матриц типа float/double 28х28 при их размещении во внутреннем ОЗУ и функции размещенной во внутреннем ПЗУ займет примерно 1мс (для тактовой 20 МГц), если на асм-е наваять соответствующую функцию (умножение с накоплением+повтор 28 раз). Если множить типы long double то производительность упадет в разы, так как требуется двойная загрузка каждого множителя, если long long double (48 бит на мантиссу) то все станет еще печальнее, т.к. там добавятся потери на вызов библиотечной функции арифметики расширенной точности. Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
da-nie
29.05.2022 19:39А там не только перемножения. Там ещё вычисление обратной матрицы и тому подобная фигня. И такой фигни в матмоделях много.
Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
Во внешнем подключённом ОЗУ (1 Мб) они лежат, если не память не подводит. Тип у них float. Да, все операции делаются на Си (делал бы на С++, но компилятора-то нет).FGV
29.05.2022 19:57Во внешнем подключённом ОЗУ (1 Мб) они лежат, если не память не подводит.
Из внутреннего в два раза быстрее читается/пишется.
Да, все операции делаются на Си (делал бы на С++, но компилятора-то нет).
А причем тут плюсы? Код писаный что на плюсах, что на Си врятли выдаст на выходе специфичные инструкции, которые могут выполнятся параллельно (MPYF3 || ADDF3). Для реализации подобных вещей пригоден только асм, благо писать на нем немного - несколько библиотечных функций.
da-nie
29.05.2022 20:09Из внутреннего в два раза быстрее читается/пишется.
Работает и ладно. :)А причем тут плюсы?
А плюсы тут при том, что программа вообще на этих самых плюсах была бы не в пример лучше организована, чем на голом С 87-го года. Специфических инструкций я от них, разумеется, не жду. Но большим плюсом было бы само наличие компилятора с плюсами. А его нет и никто делать не будет.FGV
29.05.2022 20:26Работает и ладно. :)
Ага, только чего ж Вы жалуетесь на низкое быстродействие? По мне погромист МК как раз и занимается тем что выжимает из железяки максимум.
А плюсы тут при том, что программа вообще на этих самых плюсах была бы не в пример лучше организована, чем на голом С 87-го года.
Это уже вкусовщина. Мне вот лично больше нравится Си :)
da-nie
29.05.2022 21:14Ага, только чего ж Вы жалуетесь на низкое быстродействие? По мне погромист МК как раз и занимается тем что выжимает из железяки максимум.
Выжимать максимум имеет смысл, когда вы буквально на грани. Но если у вас от грани далеко, то хоть выжимай, хоть не выжимай, результата вы не достигнете.
FGV
30.05.2022 04:32Но если у вас от грани далеко, то хоть выжимай, хоть не выжимай, результата вы не достигнете.
Если я правильно понимаю то нужная производительность достигнута применением 4-х МК, и при этом главный пожиратель процессорного времени - работа с матрицами 28х28, которую можно ускорить минимум в два раза.
Т.е. "выжав из камня все" число МК можно сократить вдвое, и вместо двух "двухядреных" поставить один двухядреный, а это вполне себе достижимая такая грань и смысл, глядишь и межпроцессорная логика взаимодействия упростится.
Но из вот этого:
Работает и ладно. :)
Напрашивается нерадостный вывод о том что сделано в стиле "и так сойдет", даже не задумываясь об оптимизации. А че тут мучаться, дайте мне 1.5ГГц х 4 ядер и 4ГБ вот тогда точно заработает.
da-nie
30.05.2022 06:32Это так не работает. Модули коррекции ошибок — штука такая, что исходная модель может быть изменена и откорректирвана десятки раз. Да и не факт, что в два раза увеличится бустродействие. Компилятор, конечно, древний, но вряд ли код простых циклов умножений и сложений сделал неоптимальным (кстати, компилятор асмовский код создаёт как промежуточный и его можно посмотреть.).
Напрашивается нерадостный вывод о том что сделано в стиле «и так сойдет», даже не задумываясь об оптимизации.
Не стоит просто так нарушать принцип KISS. В данном случае извращения с ассемблером начинать рано. Ещё есть запас в имеющейся системе (а вот запас 50% должен быть всегда, когда всё может поменяться в процессе разработки изделия).
FGV
30.05.2022 08:06Да и не факт, что в два раза увеличится бустродействие.
При размещении матриц во внутреннем озу - должно увеличится, к нему доступ дважды за такт.
Компилятор, конечно, древний, но вряд ли код простых циклов умножений и сложений сделал неоптимальным (кстати, компилятор асмовский код создаёт как промежуточный и его можно посмотреть.).
Нужны еще исходники, а так мало ли как чего написано. Шмат сгенереного кода перемножения матриц на асме я бы глянул с удовольствием :)
а вот запас 50% должен быть всегда, когда всё может поменяться в процессе разработки изделия
Нафига? 20-30%, не больше. Иначе получается что второй двухпроцессорный летает пассажиром.
Плюсом алгоритмика и математика после выхода на опытные образцы существенно уже не меняется, и куда девать этот "запас" в половину мощности?
da-nie
30.05.2022 17:22Нафига? 20-30%, не больше. Иначе получается что второй двухпроцессорный летает пассажиром.
Потому что задача такая… неопределённая. :) Эти модели лет по 30 разрабатывают и дополняют.Плюсом алгоритмика и математика после выхода на опытные образцы существенно уже не меняется, и куда девать этот «запас» в половину мощности?
Вот как раз после опытных и меняется. Начинается литера О и её доработки по результатам. Разработки ведутся десятилетиями. А вот потом… раз и полетела. :)
victor_1212
29.05.2022 18:31> Когда у вас частота обработки десятки Гц
это довольно типично, мало кто знает что у первой серьезной системы на Q7 рабочий цикл был 17 сек, большое количество усилий было потрачено, чтобы в него уложиться, первые сборки требовали раза в три больше времени для рабочего цикла, хотя все критическое было на ассемблере
Wan-Derer
30.05.2022 09:20+1там дофига математики
Всегда есть вариант спаять математику на операционниках 140УД1 по справочнику Горошкова :)
А можно взять керамическую подложку и запилить гибридный модуль с плёночной пассивкой и бескорпусными ОУ. И вот тебе "вычислительный модуль", который любой Эльбрус сделает как стоячего :) Правда, и считает приблизительно....
fndrey357
29.05.2022 08:51+4Блин. Если бы не возраст 50+ - это классная задача. Систематизировать, программировать, устранять баги и прочее.
Я прямо вижу пачку статей и диссеров.
"Разработка планы интерфейса для снижения внешних воздействий", когда на любую плату навешиваешь защещенные от статического электричества и наводок повторители интефейса и эта плата универсальна.
Учебник "Систематизация процессов программирования контроллеров" - кстати, если разобраться с монетизацией - можно сделать альманах статей Хаброжителей.
Сайт "Пополняемая библиотека программных блоков"
Racheengel
29.05.2022 10:00+1По необходимости приходилось программировать под PLC Twincat от фирмы Beckhoff. В принципе, штука весьма продвинутая, есть и своя IDE, основана на Visual Studio, и свой ооп-язык ST (очень напоминающий Паскаль).
Это, конечно, не полноценный bare metal, основная боль была в другом и скорее решалась обратная проблема - надо было расширить функционал, написанный бывшим явистом в довольно странном стиле. И речь шла скорее об удалении ООП из кода, где оно было абсолютно не к месту.
hexus7
29.05.2022 10:07+2Делал красно-черное дерево для СКУД :D - база ключей в еепром 24C, оперативки не требуется много.
В целом - все так, как описано. На удаленке 10 лет, если бы была конкурентная зарплата, то и из Таиланда +- можно было бы в целом. Но если бы да кабы...
hobogene
29.05.2022 10:28+6Из Таиланда сейчас как раз проще за конкурентоспособную зарплату с микроконтроллерами возиться. Платят прилично люди из "недружественных стран", в РФ фиг заказчик сейчас что сможет переслать. И раньше-то было не всегда просто, честные люди честно писали, что посылают, например, медицинскую технику, когда посылали прототип какого-нибудь пульсоксиметра. И таможня радостно взводилась, и FedEx отправлял все обратно, и посылали снова, но уже как "выставочные образцы" чего-нибудь безобидного. И месяц уходит в никуда на все на это...
peacemakerv
29.05.2022 10:20+5Прикольная статья. Тем, что первую треть я, читая, возмущался и негодовал описываемой безнадеге. А далее, вспоминая своё, очень плавно осознал что, на самом деле все так и есть :)
PKav
29.05.2022 10:33+3В целом, я со всем согласен и такой порядок вещей меня более чем устраивает. Ничто меня так не расслабляет как трассировка печатных плат, моделирование в SOLIDWORKS и программирование МК. Да и отладка электроники не сказать что раздражает. Одна беда - говорят, что в фирмах за такую работу денег платят мало, таксистом можно больше заработать. Но тут всегда можно поднабраться опыта, посмотреть чего людям не хватает и попробовать запустить свой проект.
Кстати, а чем плох С? Тем, что позволяет выстрелить себе в ногу? Ну так, может, тут стреляющий в ногу сам виноват? И динамическая память ладно, данные разных размеров бывают, но наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
randomsimplenumber
29.05.2022 10:40+5наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
Время программиста стоит слишком дорого, чтобы тратить его на уборку мусора.
PKav
29.05.2022 12:22+2А вот этот парадокс всегда выглядел для меня очень странным. Люди других профессий за гораздо меньшие деньги делают гораздо больше полезных дел ошибаясь при этом гораздо реже. Да, понятно, что нищая страна и конкуренция с иностранными работодателями, но все же...
F0iL
29.05.2022 12:27+4Люди других профессий за гораздо меньшие деньги делают гораздо больше полезных дел
Тут уже на Хабре этот философский вопрос обсуждали не раз и не два. TLDR: это не программистам платят слишком много, это людям других профессий платят слишком мало. Причины, как верно подмечено, связаны с балансом спроса/предложения и с открытостью/изолированностью рынка труда.
F0iL
29.05.2022 11:08+11Ну так, может, тут стреляющий в ногу сам виноват?
Вы так говорите, как будто в ногу стреляют намеренно и осознанно. Как раз основная проблема в том, что в Си выстрелы в ногу могут происходить совершенно неожиданно и внеочевидных местах.
но наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
Так за дело же считают. Во всех сколь-менее сложных и широко используемых программах на Си в разное время находили ошибки в работе с памятью, в лучше случае приводившие к DoS, в худшем - к дырам в безопасности. Можно, конечно, рассуждать, что ядро Linux пишут идиоты, GCC пишут идиоты, Apache пишут идиоты, Libc пишут идиоты, PostgreSQL пишут идиоты - но тогда встает вопрос, а кто не идиот-то?
Для человека невозможно сходу писать код без багов. Просто невозможно. Товарищи из блога PVS-Studio не дадут соврать. Если кто-то из программистов уверен, что уж он-то точно всегда пишет код без багов, то либо он Чак Норрис, либо он просто еще не писал ничего на самом деле сложного, либо у него синдром Даннинга-Крюгера и он просто ещё многое не осознал.
Поэтому если есть возможность снизить количество вероятных ошибок и последствия от них небольшой ценой, во многих случаях логично этой возможностью пользоваться. Заодно и временные-трудовые ресурсы программиста можно потратить на что-нибудь более полезное.
PKav
29.05.2022 12:26+2Изначальный посыл верен. Но такой подход сильно развращает, приводит к раздолбайству, пофигизму и тормозному говнокоду. Ошибки при этом, как правило, никуда особо не деваются, просто совершаются в других местах из-за снижения общей дисциплины.
F0iL
29.05.2022 12:35+5приводит к раздолбайству, пофигизму и тормозному говнокоду.
Ну, перечитайте еще раз эту статью, комментарии к ней, и ссылки из комментариев: в embedded нет никаких сборщиков мусора, как правило хардкорный чистый Си, а говнокод, раздолбайства и пофигизма при разработке ПО тоже более чем достаточно. Так что не от этого зависит.
Хотя, как я уже говорил, сегодня все чаще и чаще звучат разговоры о применении Rust в embedded. Когда сам язык на уровне концепций и компилятора противодействует некоторому говнокоду и классическим ошибкам, при этом не создавая лишнего оверхеда - это самое то для встраиваемых систем.
Ошибки при этом, как правило, никуда особо не деваются, просто совершаются в других местах из-за снижения общей дисциплины.
Вполне возможно, но ошибки тоже могут быть очень разные. Ошибки в бизнес-логике обычно хорошо воспроизводимы, могут быть отловлены при тестировании, и т.д. Ошибки в управлении памятью (или, например, в многопоточности) могут не проявлять себя очень долгое время при любых тестах, воспроизводиться только при определенном положении звезд на небе, и при этом быть гораздо более дорогими в плане нанесенного ущерба (например, remote code execution или arbitrary memory read).
PKav
29.05.2022 19:28Embedded говнокода не прощает. Некоторую неоптимальность - да, но говнокод начинает плохо работать сразу и заставляет себя исправлять.
А сборщик мусора, запускающийся при определённом положении звёзд на небе не менее непредсказуем, чем ошибки работы с памятью. Да и кто знает, как поведёт себя сам сборщик мусора и нет ли в нём скрытых ошибок.
AnthonyMikh
29.05.2022 20:06+4Да и кто знает, как поведёт себя сам сборщик мусора и нет ли в нём скрытых ошибок.
Да и кто знает, как поведёт себя сам компилятор и нет ли в нём скрытых ошибок.
Да и кто знает, как поведёт себя сам процессор и нет ли в нём скрытых ошибок.
Да и кто знает, как поведут себя сам конденсаторы и нет ли в них скрытых ошибок.
F0iL
30.05.2022 00:33Прошу прощения, ошибочно ткнул минус из-за тормозов браузера на телефоне. Должен был быть плюс.
KvanTTT
31.05.2022 03:23Ага, тут вон в соседнем топике обсуждаются космические частицы, которые могут менять биты в произвольном месте.
F0iL
29.05.2022 20:36+2Embedded говнокода не прощает. Некоторую неоптимальность - да, но говнокод начинает плохо работать сразу и заставляет себя исправлять.
Ох. Вы сейчас серьезно? Я боюсь вы кажется не совсем представляете, о чем говорите.
Во-первых, один пример я уже привел выше: программа на Си, в которой есть undefined behavior. Учитывая заботливо раскиданные грабли, допустить UB в коде на Си легче легкого даже для опытного и сосредоточенного разработчика (спросите @0xd34df00d, он вам всякого расскажет). С точки зрения стандарта языка и компилятора, такой код будет не то что говнокодом, а вообще не будет является кодом на языке Си. При этом компилятор вам об этом не скажет (по стандарту, опять же, имеет полное право). И в итоге программа может работать совершенно корректно. Годами работать корректно, без ошибок. А при определенном положении звезд на небе упасть или выдать неверный результат. Или даже еще веселее - компилятор выдаст вас абсолютно правильный и верный машинный код в бинаре, именно такой, какой ожидает получить программист. А спустя какое-то время, стоит поменять один флаг у компилятора, пересобраться под другую платформу, или даже просто добавить где-то несколькими строками выше новую переменную или безобидную операцию - как что-то пойдет не так.
И так вот, кода с UB я в embedded лично наблюдал ничуть не меньше, чем вне embedded, а может даже больше. А ответ у тех, кто написал этот код, как правило, один и тот же - "ну а че, работает же..."Во-вторых, говнокод - это совсем не обязательно код с багами, вовсе нет. Говнокод - это в том числе сложночитаемый, сложноподдерживаемый и сложнорасширяемый код - плохо написанный и плохо спроектированный. Например, когда в коде нет нормального логического разделения на слои и функциональные блоки, а все напихано в одно место в какой-нибудь божественный модуль, компоненты прибиты гвозядями друг к другу, когда покрытие тестами нулевое (да и по изложенным выше причинам их писать для такой архитектуры вообще невозможно), данные и состояния лежат в глобальном конктексте и манипулируются кем попало и когда попало, или наоборот, разные части программы лезут напрямую друг к другу в кишки и что-то там изменяют во внутренних структурах, и другие антипаттерны т.д. В embedded такое встречается на каждом углу, там говнокод цветет и пахнет, об этом очень хорошо написал тут на Хабре один товарищ, а еще к той статье очень хорошие комментарии, где люди рассказывают о том, какой говнокод они своими глазами видели в embedded-проектах. Во всех этих случаях программа может не содержать ошибок. Программа может работать корретно. Но вот поддерживать и развивать ее будет очень больно и опасно.
А сборщик мусора, запускающийся при определённом положении звёзд на небе не менее непредсказуем, чем ошибки работы с памятью.
Верно, поэтому в системах реального времени сборщики мусора не используют. Но реальное время - это все-таки очень небольшой пласт современной разработки ПО.
Да и кто знает, как поведёт себя сам сборщик мусора и нет ли в нём скрытых ошибок.
Ошибки могут быть везде. Но практика показала, что вероятность ошибок в сборщике мусора, который тщательно тестируется при разработки, который используется в тысячах проектов и таким образом тестируется в бою, и который уже многократно проверен и отлажен годами, все-таки гораздо ниже, чем вероятность ошибок в новом коде от какого-нибудь Васи. За прошедший десяток лет было море нашумевших CVE в сишных проектах (ядро Linux, Libc, а в OpenSSL даже несколько раз) из-за ошибок работы с памятью, а вот о каких-то громких и скандальных дырах в софте класса RCE, связанных с багами сборщика мусора, почему-то не слышно :)
0xd34df00d
29.05.2022 23:57+1А сборщик мусора, запускающийся при определённом положении звёзд на небе не менее непредсказуем, чем ошибки работы с памятью.
Только последствия от этого сильно разные. В подавляющем большинстве приложений (если учитывать не только эмбеддед) сборка мусора — совсем не проблема.
aabzel Автор
29.05.2022 14:43+2Недостаток С:
1) В С преобразование типов делается скобками ().
Невозможно утилитой grep найти все места, где есть преобразование типов.
aabzel Автор
29.05.2022 17:45Кстати, а чем плох С?
нет 24-битного типа данных uint24_t, int24_t, а чипы с такими регистрами есть.
И вообще не хватает знаковых типов данных произвольной разрядности. например int7_t int13_t и т.пrandomsimplenumber
29.05.2022 18:32+1Это всего лишь значит что авторы платформы поленились написать stdint.h с правильными типами к своему компилятору. stdint.h - не часть языка С.
vau
29.05.2022 22:33stdint.h - не часть языка С? Смотрю в стандарт ISO/IEC 9899 и вижу раздел 7.18 посвященный stdint.h. Кстати упоминание uint24_t в нем тоже имеется
randomsimplenumber
30.05.2022 13:05+1Няп, это часть реализации языка С под конкретную платформу. В 64 битном Linux grep ничего подобного uint_24 не нашел. Ожидаемо.
Ivanii
29.05.2022 18:43А аппаратно подсистема памяти и процессор микроконтроллера способны работать с такими типами данных?!
PKav
29.05.2022 19:16+1Есть битовые поля. А произвольная разрядность - это зачем вообще?
aabzel Автор
29.05.2022 19:24А произвольная разрядность - это зачем вообще?
Существуют периферийные SPI микросхемы у которых карта регистров такова, что там заложены знаковые целые числа разрядностью по 4 бит, 7 бит, 13 бит и их надо правильно переводить в int32_t или double.
PKav
29.05.2022 19:40+1Вот для этого и есть битовые поля. Хотя, по старинке через битовый сдвиг всё тоже прекрасно переводится и не особо теряет в понятности.
randomsimplenumber
29.05.2022 20:01+2надо правильно переводить в int32_t или double.
Допустим. И в чем проблема то? Если математика у ALU всё равно 32 разрядная - чем вам поможет uint_7t?
JackKatch
29.05.2022 10:48+7"Я водитель. Вчера добывали нефть из скважины , что бы сделать бензин и заправить машину. А сегодня делали из нефти резину, а то стёрлась уже. - Так вы водитель? Или нефтяник, химик? Или автослесарь?" У меня немалый опыт, поэтому подтверждаю. Во многих организациях практикуют такой подход. Он сложился (вероятно) исторически, когда зарождались микроконтроллеры и программистом становились электронщики. Я и сам когда-то перематывал трансформаторы, пилил напильником корпуса для приборов и т.д. Я считаю такой подход непрофессиональным. Для чего вообще разделение труда? Если программист идет на поводу у работодателя, возникает такая картина. Поэтому, моё мнение, припаять что то, есть монтажница! Посмотреть осциллографом, электронщик. Проверить на объекте, инженер по внедрению. А программист микроконтроллеров, сидит на стуле и пишет программу! Как максимум, подключает программатор к плате.
F0iL
29.05.2022 11:32+9Проверить на объекте, инженер по внедрению. А программист микроконтроллеров, сидит на стуле и пишет программу
Ха, если бы все было так просто. Иногда приходит от заказчика заказ: нужно, чтобы ваше изделие интегрировалось вот с этой железкой, которая стоит у нас. Вперёд, интегрируйся. Заказчик эту железку тебе не даст, она у него уже работаете и самому нужна. В офис тебе эту железку начальство не купит, она или весит под тонну, или вообще очень редкое и труднодоступное изделие, или стоит больше чем весь бюджет проекта, да и куда ее потом девать. В итоге ты пишешь программу по той спецификации протокола, что тебе дал производитель этой железки, а когда "инженер по внедрению" подключает все как надо, то ничего не работает. Потому что в спецификации были ошибки (например, она относится к другой аппаратной ревизии или к другой версии ПО), или там забыли упомянуть что-то весьма важное (а других спецификаций не было и нет), и вот уже ты сам, программист, сидишь на объекте в цеху, монитором порта слушаешь шину данных, периодически модифицируя свою программу и смотря что происходит.
JackKatch
29.05.2022 10:52-4И ещё. Я не называл бы (например) STM32 с частотой 200 МГц и "чудовищным" по размеру ОЗУ микроконтроллером. По этому, С++ в микроконтроллере не место (моё мнение), а вот в Гигаконтроллерах, возможно да.
F0iL
29.05.2022 11:16+9У C++ основной принцип you don't pay for what you don't use. Вполне можно ограничиться определенным подмножеством фич языка, которые работают в compile-time, и таким образом при правильном подходе получить разные приятные удобства и полезные проверки на этапе компиляции без раздувания бинарника и избыточного потребления ресурсов.
Z55
29.05.2022 11:16+25Прошивки довольно простые программы. В них как правило нет никакого процессинга над данными. Всё сводится к тому, что надо GPIO мигнуть, кнопку прочитать, испустить PWM сигнал и прерывания по перепадам напряжений отловить. В микроконтроллерах нет нужды даже в алгоритмах сортировки.
Только не рассказывайте об этом ребятам, которые пишут прошивки для электропривода с векторным управлением; ребятам, которые занимаются анализом сигналов на DSP; ребятам, которые разрабатывают интерфейсы для нелинейных датчиков; ребятам, которые занимаются сетевыми устройствами итд итп. Не стоит транслировать свой, не очень релевантный, опыт на всю отрасль программирования МК.
iliasam
29.05.2022 11:57+3Не думаю, что, к примеру embox, у нас разрабатывают без git и юнит-тестов. abondarev расскажите?
Тоже самое с решениями для VOIP, и прочих сетевых устройств, уровень сложности там большой, без git будет сложно.
На госпредприятиях, да, вполне возможно, что описанная автором ситуация действительно есть.Всё что я делал в русской электронике 10лет подряд это переходники с одного интерфейса на другой интерфейс. Маршрутизаторы, модемы, телематика, СКУД(ы), аудиосистемы. Переходники. Переходники. Переходники.
Тогда и любой браузер можно назвать переходником между сетью и монитором, а видеопроигрыватель — переходник между диском и монитором.
abondarev
30.05.2022 17:13+1к примеру embox, у нас разрабатывают без git и юнит-тестов
Да, конечно, Embox изначально на системе контроля версий, просто не реально вести коллективную разработку без этого. И, да, сложность на МК уже слишком высокая и не позволяет вести разработку без этого. Как минимум решение будет не воспроизводимо и не поддерживаемо.
По unit-тестам у нас достаточно быстро появилась острая необходимость в них. А потом и интеграционные тесты и CI. Без этого уже никак нельзя в современном мире.
sergeyns
29.05.2022 12:26+4Странно что в статье обойден такой немаловажный вопрос как "про деньги". ИМХО, все связанное с железками в нашей стране, очень плохо оплачивается..
Вот, например, сколько лет нужно с начала карьеры, чтобы дойти до планок в 100, 200, 300к?
если брать разработчика, то в-до-февральской эре планка в 100 - это чуть ли не джун (ну реальнее джун за 70, через годик-полтора - 100), 200 - мидл с опытом в 5+ лет.. 300 - это крепкий мидл - сеньор.. Сейчас, правда, все стало хуже.. не вижу вакансий для сеньеоров с предложением выше 300к, ранее было "от"...
PKav
30.05.2022 08:53+1Скорее всего, сейчас у обычных программистов зарплаты просядут до уровня embedded, т. к. теперь не получится нормально перевести деньги из другой страны и тогда уже все будут бедными.
wAgo
29.05.2022 12:35+4О получке, всем известно что она неприлично маленькая: но погрОмист может перекваифицироватся в "формошлёпство" за 2..3Х денег зачем он ест ембеддед-кактус и страдает, он же уже в айти ему ненужно никуда входить ? Что это за особенная форма религиозного страдания, кто эти мученики, и за что они рубятся ?
F0iL
29.05.2022 12:40+4кто эти мученики
Вот тут товарищ немного раскрыл ответ на этот вопрос:
Помножаем на диспропорцию зарплат и получаем что? Правильно - или джунов (много, но не на долго) или фанатов (редко, и очень сложно переманиваемых - ибо страшно бросить то, что годами оттачивал и браться за новое, понимая всю степень ответственности) или ленивых ежей, с которыми пока не пнешь - не полетит (довольно частый вариант).
Mike-M
29.05.2022 13:14+6Впервые встречаю статью, в которой обилие ошибок правописания соседствует с обилием преувеличений. Например:
вникать в спеки каждой микросхемы (~1k...5k страниц) на печатной платы.
Sun-ami
29.05.2022 14:19+7Преувеличение если и есть, то небольшое - Reference manual на STM32H745 - 3528 страниц, на STM32MP157 (в котором тоже есть микроконтроллер) - 4062 страницы. Если добавить сюда объем Datasheet - выходит приблизительно как в статье. И вникать во все это приходится.
Mike-M
29.05.2022 15:15+4Я про другое: автор статьи почему-то считает, что печатные платы состоят исключительно из «крупнокалиберных» микроконтроллеров. В этом и есть суть преувеличения.
Karlson_rwa
29.05.2022 23:06+2Надо ну очень сильно постараться, чтобы даже в простеньком микроконтроллере задействовать все ресурсы и интерфейсы, чтобы была необходимость читать и вникать в тысячи страниц руководств.
Sun-ami
30.05.2022 11:22Часто перед тем, как задействовать часть интерфейсов, нужно сначала их выбрать. Это делается на этапе выбора микроконтроллера и проектирования схемы, и делает это программист, потому что схемотехники недостаточно хорошо знают особенности микроконтроллеров. И вот тут приходится читать про гораздо больше видов интерфейсов, чем будет применяться в итоговом коде - потому что часто одну и ту же задачу можно решить большим числом существенно разных способов, как с применением внешней обвязки, так и без. Часто на этом этапе нужно минимизировать количество внешней обвязки МК, и вычислительную нагрузку, и здесь нужно довольно хорошо понимать работу периферии, которая может быть использована.
Karlson_rwa
30.05.2022 14:21на этапе выбора микроконтроллера и проектирования схемы, и делает это программист, потому что схемотехники недостаточно хорошо знают особенности микроконтроллеров
Чуть живот не надорвал от смеха, извините. Я не знаю с кем вы работаете, но у нас мягко говоря немного не так. Решение выбирает схемотехник, активно советуясь с программистом, как ему было бы удобнее программировать железку. Плох тот схемотехник, который разрабатывает что-то микроконтроллерное и при этом не понимает, как оно внутри работает.Sun-ami
30.05.2022 15:12Чтобы быть уверенным в правильности выбора микроконтроллера, в общем случае схемотехнику нужно прочесть тот самый Reference manual на 2..3 тысячи страниц, и уверенно понять его. А, возможно, и несколько, если нужно еще определиться и с семейством МК. Пока мне не приходилось работать ни с одним схемотехником (который не был бы при этом одновременно и программистом), который сделал бы это - все схемотехники ограничивались чтением Datasheet. Действительно, выбор МК - это зона ответственности схемотехников, но сложность современных МК не позволяет им делать это без помощи программистов, если речь не идёт об устройствах, имеющих только те интерфейсы, которые хорошо стандартизированы, и аппаратно реализованы в микроконтроллере.
hard2018
29.05.2022 13:54вы ужаснётесь если узнаете насколько прикладники этого всего не умеют.
Я точно, как прочитал, ужаснулся. Не знал, что всё проще на самом деле и из за этого не устраивался работать по специальности. Но...
такие коренные познания нужны и прикладникам, я считаю. Иначе их место (в головах людей) будут занимать околошизоидные представления.
Задачи могут поставить так: “подружить микроконтроллер и айфон”, “оживить плату”, “подружить платы”
Вот это как раз такие случаи.
FIZIK-TECHNIK
29.05.2022 14:49+2Прочитал все от корки до корки...........Я люблю программировать AVR ки на языке BASCOM AVR. Для моих целей и задач вполне подходит и я им доволен. Можно написать и программу для управления электродвигателем, голосовым выключателем света в комнате, делительной головкой или поворотным столом фрезерного станка. А можно и программу управления испарителем вакуумной установки.
Psychosynthesis
29.05.2022 14:53+3Статья выглядит как очередное откровение от "прозревшего" представителя поколения любителей смузи. В целом уже с первого абзаца понятно, что человек сам в программировании в общем не знает примерно ничего. Одной вот этой вот цитаты достаточно:
Навыки программирования на С очень слабо конвертируются.
Пофигу, что половина модных\молодёжных\современных языков используют похожий синтаксис и похожие концепции. Пофигу, что поняв С, разобраться с большинством других "процедурных" языков проблем не составит, т.к. уже появляется представление о том как всё работает на уровне железа. И объектно-ориентированный стиль при желании понять не сложно, т.к. это по сути переход от конкретики к абстракции, который всегда проще чем переход от одной абстракции к другой.
Ну и далее перлы один за одним. В духе "так работаю я, значит так работают все".Всё что я делал в русской электронике 10 лет подряд это... Переходники. Переходники. Переходники.
Забавно чо уж. Послушать бы как эту же профессию этот человек опишет через десять лет (если, конечно, не сменит специальность).
Отдельно крякнул вот с этого:Программы для МК простые
...
Всеми любимый текстовый редактор VS Code от Microsoft.
Это просто ноукомментс
F0iL
29.05.2022 15:41+5Конкретно в вопросе "конвертируемости" автор как раз, судя по всему, хорошо понимает, о чем говорит. Простой пример: если человек, желая перейти из embedded в какую-нибудь другую сферу разработки, откроет российский hh или международные linkedIn/glassdoor, то проанализировав вакансии, очень быстро обнаружит, что чистый Си вне embedded нужен от силы в паре процентов от предлагаемых проектов - и число таких предложений в десятки и даже в сотни раз меньше тех, где требуется знания и опыт других языков. "Представление о том, как все работает на уровне железа", конечно, хорошо, но поможет не сильно - в том же обычном бэкенде/фронтенде о сисколлах, регистрах, кэш-линиях, аллокаторах и прочем знает в лучшем случае один разработчик из ста, и это ничуть не мешает остальным делать свою работу и получать за нее деньги (хорошо это или плохо - вопрос отдельный, но это факт) - используемый уровень абстракций гораздо выше, и просто нет нужды спускаться так низко. "Похожий синтаксис" это вообще смешно, синтаксис языка можно изучить за пару дней, это обычная самая меньшая из проблем при переходе на новый язык. То же самое про ООП, как уже тут говорилось, одна из самых частых и опасных ошибок сишников - подумать что "синтаксис у языков похожий, а принципы ООП я понимаю" и переходя на C++ начинать писать на "Си с классами", что приводит это обычно к говнокоду и очень печальным последствиям.
Ну и далее перлы один за одним. В духе "так работаю я, значит так работают все".
"Значит так работают все" у него и не звучало. Другой вопрос, если ткнуть в рандомную контору на рынке, на что больше вероятность наткнуться - на то, о чем говорит автор, или на то, о чем говорите вы. Опыт многих людей подсказывает, что распределение вероятностей тут будет явно не в пользу второго :(
victor_1212
29.05.2022 18:55> проанализировав вакансии, очень быстро обнаружит, что чистый Си вне embedded нужен от силы в паре процентов от предлагаемых проектов
кроме языка есть еще предметная область, imho по нынешним временам в серьезных компаниях смотрят именно на это, типа если писать в своем резюме про языки С, Rust, С++ и пр. то это лучше последней строкой, вместе с образованием, по крайней мере так делают, видеть хороших резюме пришлось достаточно много, лично для меня годится практически любой язык высокого уровня (включая ada и jovial) кроме lisp, про assembler конечно все иначе
F0iL
29.05.2022 20:08+1по нынешним временам в серьезных компаниях смотрят именно на это
Я ровно обратное наблюдаю. Открываете российский hh.ru, международные linkedin/glassdoor или сайты крупных софтверных компаний, и смотрите вакансии для разработчиков - конкретный требуемый язык/стек указывается прям с самого начала еще в заголовке вакансии (например, "Senior Java Developer" или ".Net Core Backend developer"), дальше идет список требований по опыту именно по части конкретных технологий (фреймворки, СУБД, окружение и т.д.), а про прикладную область (чем конкретно занимается компания и что конкретно должен будет разрабатывать кандидат) в лучшем случае пишут в последнем абзаце, а иногда и вообще почти не пишут, надо догадываться :) На собеседовании будет то же самое - в первую очередь и как первый этап будут разговаривать именно о конкретных языках/технологиях или попросят написать код на них.
Из того что наблюдаю вокруг, для программистов между предметными областями переключаться совершенно нормально - нередко в городе по конкретной предметной области бывает 1-2 компании, а по конкретному языку - 20-30 - соответственно в плане карьерного развития программисту просто невыгодно глубоко забуриваться и прикрепляться к предметной области, это очень сильно ограничивает для него возможности выбора нового места работы (про релокацию уж и не говорим).
victor_1212
29.05.2022 22:28смысл моих комментариев это дополнить, то что Вы написали, например один из Ваших первых комментариев ("... успевший поработать в embedded, а потом перешедший в прикладное...") вполне понятно, в первом приближении это совет держаться от embedded подальше, что соответствует духу статьи, и вероятно соответствует реальности РФ, но для тех кто предположим приложив силы окажется в US, перспективы будут другие, и если человек использует свои возможности, то искать работу будет не через упомянутые сайты, а например просто позвонив своим знакомым, так что мы говорим немного о разном, через упомянутые сайты видны далеко не все вакансии, недавно смотрел что делается в компаниях которые меня интересуют, там требования другие, при прохождении интервью действительно могут спросить про языки, инструментарий и пр. что является вероятно самой легкой частью, помню со мной такое было один раз, чтобы не тянуть собаку за хвост, просто написал фрагмент текста, и показал как именно он будет компилироваться, этого хватило, основные вопросы к профессионалу всегда связаны с тем что он сделал в прошлом, потому как люди решают насколько полезным человек может быть для проекта прямо сейчас, с этим у меня тоже проблем пока не было
ps
точности ради, ниже principal в us работать не приходилось, поэтому вероятно можно переформулировать так, начиная с principal предметная область это главное
F0iL
29.05.2022 22:38но для тех кто предположим приложив силы окажется в US,
Насчёт US не знаю, там вполне может быть как вы говорите, я был только в РФ и EU
начиная с principal предметная область это главное
Вот это вполне может быть, да. Principal уже сами особо не пишут код, а задают другим, как и что писать :)
victor_1212
30.05.2022 00:53> Principal уже сами особо не пишут код
это тоже по-разному, в моем случае пишут, и в больших количествах, чем сложнее проект тем активнее участвуют principal, именно это и интересно, хотя спецификаций тоже достаточно написано
GospodinKolhoznik
30.05.2022 00:05одна из самых частых и опасных ошибок сишников - подумать что "синтаксис
у языков похожий, а принципы ООП я понимаю" и переходя на C++ начинать
писать на "Си с классами"Поэтому, переходя с си на плюсы не пишите на "си с классами", пишите на "си без классов". Не повторяйте чужих ошибок.
Fenzales
30.05.2022 10:49+1Пофигу, что половина модных\молодёжных\современных языков используют похожий синтаксис и похожие концепции.
О каких концепциях речь? Условия и циклы?
Gudd-Head
29.05.2022 17:24+2в среднем 3е из 5ти
На этом месте завис. Упорно читалось "третье из пяти".
Mih-mih
29.05.2022 20:57+1Прекрасный повод вспомнить Горчева, спасибо, автор, ты попал в его стиль!
И как же всё-таки приятно, что я когда-то стал тем, кто называется "инженер-электроник", сиречь "embedded-разработчик", а не "программист микроконтроллеров" )
titbit
29.05.2022 21:23+9Опросы некорректные, нет возможности множественных ответов, что если я программировал под несколько платформ?
А что по статье — ну видимо автору не повезло и этот путь не для него. Как программист микроконтроллеров (но не только их) с некоторым стажем и опытом работы как на «госзаказ», так и на «коммерцию», могу сказать, что описанное слабо соответствует действительности. Опыт в процессе работы приобретается интересный, приходит понимание как устроена как вычислительная техника на разных уровнях, так и отдельные ее части (датчики, связь и т.п.), в программировании тоже приходится решать интересные задачи связанные с ограниченными ресурсами и/или временем, частенько с погружением в математику. В общем я ни разу не пожалел об этом.
Indemsys
29.05.2022 23:03+12Автор явный программист малых embedded систем и говорит в основном за свою область, но есть еще средние и большие встраиваемые системы.
Автомобильные ECU я бы назвал средними системами, а не малыми, как утверждает автор
Авионику я бы назвал большими системами. В станкостроении есть малые и большие системы. Большую систему можно встретить даже в офисном печатающем центре. По видимому автор не занимался реверсом, иначе бы знал насколько еще 20 лет назад были огромными программы для мобильников Nokia или для фото-принтеров Canon, на таких мощных RTOS как Nucleus Plus и ITRON. С тех пор они стали еще монструозней.Про то что код никто не смотрит, тоже искажение реальности. Аудит кода аккредитованными организациями - обязательный этап при получении разрешения на эксплуатацию систем с заданными требованиями к безопасности.
Утверждение о простоте программ вытекает, по видимому, из специфического опыта автора с малыми системами. Но уже в средних системах, он может встретить софт баз данных, файловых систем, GUI/HMI, сетевых протоколов, где все упомянутые им алгоритмы сортировки, поиска и фильтрации используются в полную силу. И это еще не упоминая всеобщего наступления Neural NetworkОпять же код теперь не пишут только на C или С++. И малые системы и огромные ответственные системы разрабатывают прямо в графической нотации Stateflow и Simulink. На хабре куча статей про это. Есть и другие мощные графические среды.
Словом быть сейчас embedded-ом, это все равно что богом. Бил Гейтс начал свой бизнес с малых систем, в те времена не отличимых от embedded систем, Стив Джобс с компаньонами - аналогично. На процессорах Zilog делались и домашние компьютеры и станки для литья изделий из пластмассы.
Будучи embedded-ом вы единственный, кто может создать свой полностью независимый продукт от начала и до конца, от идеи до вещи. Вы не зависите от магазинов приложений, не зависите от программных платформ типа Android, которые вам могут отменить, не зависите от моды.
embedded-ы по прежнему могут взлететь легче всех прочих, причем почти в одиночку. Вспомним успех Arduino или вот Flipper Zero
Skyline_XXX
30.05.2022 01:59+2Про AVL деревья сложно возразить, а вот B-Tree во внешнем NAND, над файловой системой NAND, довольно полезен. Даже был единственным возможным решением для POS-терминала с большой базой товаров.
smartass111
30.05.2022 02:55+3мой опыт 8-14 лет назад в embedded совпадает в целом с видением автора
ну и господи, какая же была ламповая конференция по МК на телесиське)
titbit
30.05.2022 11:24+5Вдогонку хочется прокомментировать некоторые утверждения из статьи:
Основной язык программирования это С
Это выдается как недостаток? Непонятно чем вам так не угодил С, но даже если так, при решении задач можно и нужно использовать все возможные инструменты в зависимости от их эффективности. Например, для предварительных расчетов многочисленных таблиц (фильтры, кодирование, некоторые алгоритмы и т.п.) можно использовать python или что-то еще по вкусу. Ищите возможности.В России программисты МК в основном работают в компаниях, которые делают госзаказ на военную технику
Это неправда. Коммерческих разработок тоже полно, просто наверное вам не повезло их найти, а может вы прошли мимо таких вакансий. Но даже если вы видите вокруг только госзаказ, всегда можно посмотреть на иностранных заказчиков, уж там работы по контроллерам еще больше.Программисты МК в принципе не пишут больших программ. Размер проекта ограничен несколькими сотнями килобайт памяти Nor Flash(а).
Это смотря как считать. Сама прошивка для контроллера может занимать всего несколько килобайт, но код который ее обслуживает (и частично генерирует) — сотни мегабайт. Пример из практики: прошивка была 64К, весь проект — около 100Мб чисто исходников, причем скриптов там было сильно больше, чем кода на С/С++ (я уж молчу про всякие тесты и внешние зависимости/библиотеки и т.п.). И это была только одна прошивка, а их было в проекте пара десятков для разных модификаций железа.Если вы программист МК, то скорее всего вы будете по уши в электронных платах. Вам придется не сколько программировать сколько исправлять разнородные аппаратные баги. Железо часто подводит.
Это отчасти так, хотя это и нельзя назвать «второстепенной работой», ведь вы делаете продукт в целом, а не только софт. Поиск компромиссов с «железячниками» — это само по себе интересное занятие помогающее глубже понять как и почему там все устроено. Тут каждому свое, мне было интересно находить баги даже в современных x86 и общаться с производителем по факту этого.Даже не мечтайте про удалёнку из Тайланда
Все зависит от договоренности с работодателем и ваших желаний. Мелкие устройства можно брать на дом, если договориться, например. У меня опыт удаленки как раз так и начался, еще в доковидные времена.Любое электронное устройство, которое вы будете делать скорее всего можно будет назвать одним словом: переходник.
Не повезло вам. У меня по опыту переходников было может 10-15% (обычно это всякое тестовое оборудование), остальные были вполне себе независимые вещи или с достаточной самостоятельностью, чтобы делать что-то большее, чем перекладывание байтов из одного места в другое.Программирование микроконтроллеров это на 80-70% электротехника и только на 20-30% программирование.
Это уж что вам больше нравится и как вы себя позиционируете на работе. Даже если вы в одном лице и схемотехник и программист, то соотношение слишком перекошенное у вас. По опыту платы диагностировать приходилось конечно, но это все равно больше про программирование, чем про электротехнику. Тесты всякие, программирование КПА это все же больше про программирование тоже. Может у вас схемотехника в штате не было просто?Для программирования микроконтроллеров надо очень хорошо ориентироваться в множестве официальных документов.
Я вам больше скажу, вообще для программирования как и для любой другой профессиональной деятельности надо уметь читать большое количество документов. При чем тут именно контроллеры — неясно.Если у вас есть выбор и вы хотите программировать на разных языках и быть в теме классической программной теории, если вам 20..24 и вы решаете как орешки олимпиадные задачи с LeetCode и хотите использовать в работе современные и классические алгоритмы и структуры данных, то программирование MK вам едва ли подойдет.
Не согласен. Все вышеперечисленное я лично (и мои коллеги в разных компаниях тоже) делал для контроллеров. Я бы даже сказал, что разнообразие задач здесь огромное, да еще есть поправки на предельную эффективность — вот где пригодятся все знания по математике и алгоритмике. В общем, просто хочу сказать, что ищите возможности для развития, а интересная работа есть и среди контроллеров.
cherv2
30.05.2022 12:54+1Классная статья. Ещё в России по-настоящему не любят людей которые пишут как всё а действительности плохо, ещё год назад мой комментарий о том что в 60-х годах ЦК похерила отечественную разработку микропроцессоров, решив скопировать IBM System/360 вместо того чтобы развивать свой конвейер несчадно заминусили. Зато сегодня то же самое несчадно плюсуют. Пока гром не грянет мужик не перекрестится. И что же есть у нас шанс нагнать 60 лет отставания? На счёт кодовой базы - очень верная и глубочайшая мысль. Это относится не только к C но и к C++. Кстати вы забыли ещё одну область где нужно С это параллельное программирование на GPU, разные физические симуляции, кустика, рендер
hooperer
30.05.2022 16:19+2Ну, производство бывает разное.
Мы вот иногда и Asm вспоминаем, и такое бывает.
не все микроконтроллеры без багов.
gapel
30.05.2022 16:20+4тут уже всякого написали, поэтому я вкратце свои 5 копеек занесу.
У автора такой опыт. Я в России в embedded работал в коммерческих проектах, и у меня совсем другой опыт. Например большие проекты с смешанным с/с++, со сборками, CI/CD, тестами.
Я получал по ушам за попытки взять в руки паяльник, потому что "тебя как программиста наняли".
Так же я пробегал в стартапах, там тоже по другому.
Вишенкой на торте - на коммерческих проектах всегда предлагали "нормальную" зп по сравнению с инженерами-электронищиками. Уходил в 2019 со 120 в Петербурге (в команде были те, кто получал больше).
Сейчас продолжаю, но уже за пределами России, и тут тоже видение автора сильно отличается от моего.
Но у каждого свой опыт. Надо писать свой пост видимо.
Karlson_rwa
30.05.2022 16:25+1Напишите, было бы очень интересно почитать! А то статьи с нытьем, о том как всё плохо в эмбеде уже набили оскомину.
gapel
31.05.2022 13:03+1Попробую найти ресурсы для написания.
Все в сравнении, в программировании после разработки очень даже хорошо.
F0iL
30.05.2022 16:44+3на коммерческих проектах всегда предлагали "нормальную" зп по сравнению с инженерами-электронищиками. Уходил в 2019 со 120 в Петербурге
По сравнению со всякими бэкендерами-фронтендерами для Питера прям мало :(
Сейчас продолжаю, но уже за пределами России
Кстати, было бы интересно почитать именно про различия в embedded-разработки в России и вне России. Я пока еще не набрал достаточно наблюдений, чтобы делать какие-то основательные выводы :)
gapel
31.05.2022 13:07+1как написал выше - смотря с чем сравнивать. С бэкендерами/фронтендерами да, в целом самую высокую зп у ембеддеда в 2019 я видел 180.
Про различия много написать не получится, потому как я тут сижу в одной фирме уже три года и под NDA, так в ближайшее время рассказать особо будет нельзя, только общие фразы.
Dirty_Purity
30.05.2022 23:13+2У программистов PLC ещё хуже как по мне. Мало того, что практически все перечисленные проблемы те же, так еще и ниша очень узкая, языки вообще нормальным людям неведомые и нигде больше не применимые, а зарплаты совсем уж грусть нагоняют.
EGregor_IV
31.05.2022 07:34+1Если код у автора написан так же, как и опросник, то - ой.
Почему можно выбрать только один вариант?
hhba
31.05.2022 11:27+1Гм, ну, знаете, бывает всякое. Для простых приборов - простые прошивки. Для сложных - сложные. сложность необязательно в алгоритмах работы, попросту инфраструктурная сложность может быть велика. Так что это вот "МК просто программировать" - скорее личный опыт, чем система.
триггер Шмидта
А вот это просто позор какой-то для электронщика... Отто Шмитт.
Muzzy0
31.05.2022 13:26+2Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров.
На сам процесс программирование уходит 10...20% времени. В основном приходится что-то ремонтить, разбираться с проводами. Выяснять что куда подключено, проверять осциллографом наличие электрических сигналов, проходить по чек-листу.
Можно запросто неосторожно сжечь оборудование из-за неправильно подключенного заземления. Вы обязательно узнаете как пахнут искры. Можно потратить весь день на подключение лампочки или чтения состояния зашумленной кнопки. Копаться в разъемах.
Чтобы отлаживать код его надо исполнять. Если в коде баг и нет возможности исполнить код, то баг не исправить.
То, что вы пишете, больше похоже на промышленную автоматику, программирование под ПЛК. Вот это, действительно, в первую очередь — геморрой и приключения. Программирование — во вторую.
commanderxo
31.05.2022 14:13+2А что плохого в «Си с классами»? Не троллинга ради, действительно хочу понять.
Немного контекста: на жизнь зарабатываю в «кровавом энтерпрайзе» на .NET, в свободное время пишу код для хобби проектов на этом самом «Си с классами». Понятно, что для себя можно писать как угодно, но если в embedded-сообществе сложились представления о том что такое хорошо и что такое плохо, глупо было бы не спросить.
«Си с классами» плох потому как «Си»? Да, каюсь, когда мне нужно отформатировать вывод, то часто использую старый добрый ssprintf. Начинать в 2 килобайтах памяти Ардуины пляски с операторами << как завещал дедушка Страуструп не поднимается рука.
«Си с классами» плох потому как «с классами»? Действительно, вот написал я контроллер блинкерного табло, сделал красивый класс с минимальным публичным интерфейсом, спрятал детали реализации в приватные методы, при этом внутри он выдаёт сигналы на конкретные пины. Если создать второй экземпляр того же класса, то будут конфликты с железом, так что абстракция у меня ложная. Но классы же мы любим не только за это, например, глянув на подорожавшие Arduino Nano, я быстро добавил возможность запускать код и на 8266, вынеся всю общую логику в базовый класс и переопределив лишь пару методов отвечающих за управление пинами и коммуникацию по I2C.
Так почему же у «Си с классами» такая дурная слава?hobogene
31.05.2022 14:24Дурная слава у людей, его использующих :-) И пытающихся выдать код на нем за полноценный C++.
А так IOKit эппловский (т.е. считай, что и почти все kexts/драйвера) на нем написан, хотя люди из Apple вроде утверждали, что это оказалось плохой идеей. Когда по уму и к месту применен - IMHO все ОК.F0iL
31.05.2022 19:14Всё так. Когда "Си с классами" выбирается из-за определенных ограничений (например, не допустима вообще никакая динамическая память), то с этим всё ок - как я уже говорил, в таких случаях совершенно нормально ограничиться определенным подмножеством фич языка, которые работают в compile-time, и это уже даст определенные удобства и облегчит жизнь.
А вот когда подобных ограничений и специфических требований нет, а человек пишет код так только потому что по-другому не умеет, выдавая это за "полноценный C++", то в приличных местах за такоебьют в жбанна ревью ставят needs work и отправляют читать Core Guidelines.
Krey
31.05.2022 14:36+2Видимо программисты МК не относятся к ленивым программистам. Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
FGV
31.05.2022 14:54+1Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Кодогенерация для stm32 есть, скелет с инициализацией переферии накидает.
А до остального - чего мелочиться, может сразу генератор документации? На входе скан ТЗ, на выходе эл. схемы, прошивки, спецификации, герберы печатных плат :))
aabzel Автор
31.05.2022 16:19Обычно достаточно просто собирать сборки из Make файлов.
Make файлы - это, пожалуй, самый мощный инструмент управления модульностью в разработке на С(ях).
aabzel Автор
31.05.2022 16:25Я собирал MCU сборки, где код генераторами, которые из базы данных CAN пакетов (*.dbc файлы) генерировали C-функции парcеров пакетов.
Korogodin
Вот это прям в точку. По СРПП софт для устройства появляется магическим образом на этапе РКД. В ночь с четверга на пятницу. И никого не волнует, что целевое устройство в этот момент существует только на бумаге! Что реальная трудоёмкость разработки изделия сейчас может на 80% быть в том самом софте. Что чтобы написать нормальный софт надо получать обратную связь от пользователя годами.
ptica_filin
Значит, пишите ТЗ и расшифровку трудоёмкости с учётом специфики разработки. По тем же стандартам СРПП на этапе РКД можно проводить макетирование. И даже на этапе эскизного проекта, если он есть. Изготовили макет и отрабатывайте на нём софт и схемотехнику.
Да, в реальном мире не всегда получается именно так. Но стремиться и настаивать на этом нужно. Чаще всего получается.