Комментарии 81
Для их процессов кода как будто бы не существует. О коде не говорят. Код не изучают, не анализируют. Интерес представляет только физический прприборВ
Вот это прям в точку. По СРПП софт для устройства появляется магическим образом на этапе РКД. В ночь с четверга на пятницу. И никого не волнует, что целевое устройство в этот момент существует только на бумаге! Что реальная трудоёмкость разработки изделия сейчас может на 80% быть в том самом софте. Что чтобы написать нормальный софт надо получать обратную связь от пользователя годами.
Значит, пишите ТЗ и расшифровку трудоёмкости с учётом специфики разработки. По тем же стандартам СРПП на этапе РКД можно проводить макетирование. И даже на этапе эскизного проекта, если он есть. Изготовили макет и отрабатывайте на нём софт и схемотехнику.
Да, в реальном мире не всегда получается именно так. Но стремиться и настаивать на этом нужно. Чаще всего получается.
Низкий поклон вам за статью. Как человек, закончивший универ с квалификацией инженера-электроника, успевший поработать в 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 на каждом углу, далеко не каждая программа на Си, которая компилируется и работает, является правильно написанной программой на Си, и это ни что иное как заряженное ружье, которое может выстрелить в непредсказуемый момент.
Тут стоит добавить, что нередко работа в таких проектах влечет за собой подписание формы секретности со всеми возможными последствиями.Вы вот очень много пишете (в комментах в основном) о том, как у нас тут всё плохо. Вы сами лично что-то подписывали хоть раз? Или вам об этом только рассказывали? Как вы думаете, там совсем нет ITAR-related работ?
Плюс менеджмент… в подобных местах сильно оставляет желать лучшего.Имя, сестра, имя!
Вы сами лично что-то подписывали хоть раз?
Хватило мозгов не подписывать. В свое время, собеседуясь в разные питерские конторы, сразу заранее уточнял этот вопрос - в одном месте сказали про вторую форму допуска, в некоторых других про то что может быть третья и начинали классический проезд по ушам на тему "она ни к чему вообще не обязывает, паспорт сдавать не надо, выезжать можешь спокойно, это так, для галочки". На вопрос "Учитывая происходящее последние N лет обострение маразма на госуровне, какие гарантии что в какой-то момент это 'ни к чему не обязывает' резко не изменится задним числом?" разумного ответа дать никто не смог, и в итоге пришлось отклонять офферы.
После какого-то момента я вообще перестал по совокупности причин рассматривать отечественные конторы как место для работы, благо в СПб тогда были и филиалы международных компаний, тоже работающих в области embedded, типа тех же LGE и Моторолы/Нокии, с очень неплохими условиями и интересными проектами.
А что про менеджмент - о некоторых фирмах выводы можно сделать ещё на собеседовании, с некоторыми отечественными НПФ/НПО/КБ приходилось пересекаться в работе, а в некоторых подобных заведениях работают/работали однокурсники и экс-коллеги. Поэтому рассказы о положении дел были из первых рук, так сказать.
какие гарантии… разумного ответа дать никто не смогА на что вы рассчитывали, задавая такой вопрос?
Ни на что особо. В том-то и главная проблема, что единственным реальным ответом на этот вопрос является "Никакие". Что для очень многих людей автоматически перемножает на ноль все что обсуждалось перед этим.
А на что вы рассчитывали, задавая такой вопрос?
На ответ типа "у нас есть позиция, на которой не требуется подписания никаких форм".
Да нет никаких подписок при разработке на контроллерах под военку. Даже на "взрослых" системах их нет.
Подписывают те, кто знакомится с условиями/требованиями изделия. Дальше идёт стандартное выделение функционала, деление на задачи и подзадачи. В результате, конечный исполнитель даже не знает что делает в глобальном смысле. Тут и делегировать на сторонние организации можно без проблем.
Подход древний, как сама инженерия.
Кроме микроконтроллеров С уже практичеfские никому не нужен.
Разработчики Nginx, PostgreSQL, JVM, ядра Linux и многого другого смотрят на вас очень особенным взглядом.
Вы описали существование не программиста микроконтроллеров, а эникея, человека-оркестра, к которому, зачастую, и отношение соответствующее. Печально, конечно, что озвученные вами вещи существуют, но мне представляется, что такой бардак присутствует не только у нас. Он много где. Вспомните историю 737 MAX хотя бы.
Поспорить можно практически с любым вашим утверждением. От проводов до скукоты программирования. Да, в эмбеде нет формошлепства (ну почти) и ML только-только поднимает голову. Но в целом, если общая задача интересна, то почему бы и нет. Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного. С одной стороны, можно написать простейший ПИД и успокоиться. А с другой, можно реализовать какой-нибудь нечеткий регулятор (регулятор, кстати, может быть по положению, току, моменту, да чему угодно, к чему применима ТАУ), если система позволяет. И на его отладку и доведение до ума может уйти существенное количество интересно проведенного времени.
Тем, кто всё же осилил прочитать этот поток мыслей автора (каюсь, я не с первого раза сумел): люди, знайте, есть в России такие компании, где всё хорошо с разработкой. Где первый запуск устройства делают программист и схемотехник совместно, где целостность сигналов не пустой звук, а непропаи ищут специально обученные люди, где программист активно переиспользует свою же кодовую базу и где проекты не заключаются исключительно в преобразовании одного интерфейса в другой. Не много, но есть.
есть в России такие компании, где всё хорошо с разработкой
А можно список? (не троллю, правда интересно)
Хорошо хорошо, если всё не так, и "вывсёврёти" - то предлагаю ответить на несколько простых вопросов.
Есть ли в эмбед-разработке менеджер пакетов и общий репозиторий? Вы конечно можете начать меня убеждать, что это "никому не нужно" - но вряд ли это получится )
Есть ли должность "инженер-программист" для эмбед разработки, куда можно пройти без знания схемотехники и не умея пользоваться осциллографом? Если да - то куда именно. Если нет - то это прямое опровержение ваших слов о том что "это не программисты а эникейщики"
Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного.
Отличный пример. Зачем ЕЩЁ раз решать задачу, которую до тебя решили уже "сто тысяч милионов" раз? Поведений двигателя и и способов его управления гораздо меньше, чем http запросов. Но тем не менее, в каждом языке есть библиотека, которая отправляет такие запросы, но эмбедщики за столько лет не удосужились поделиться своими шедеврами с другими. Это высшая форма жадности или отсутствие банальной организации кода?
есть в России такие компании, где всё хорошо с разработкой
Отлично, назовите компанию и прибор, где можно проникнуться величием отечественной разработки. ) Может быть.... Банальный частотник для двигателя? Или своя система управления ЧПУ станком?
Что ж вы сразу с козырей-то заходите :) Можно было для начала спросить, сколько компаний из "хороших" прошли бы хотя бы на 11/12 тест Джоуэла (и классический и новый), и в каких из них сотрудникам официально разрешено приходить на работу каждый день не к 8 или к 9, а во сколько удобно :)
Вот например почти чпу, только с несколькими фиксированными циклограммами под конкретные задачи.
Вот еще например агрегатор мониторинга оборудования написанный на С для mega2560. Все встраиваемые модули на нане или есп8266
Возможно, purelogic.
Настройка регулятора, что базовый мультиконтурник на пид, что какие-то более продвинутые, это работа не программиста, а инженера систем управления. У программистов, как правило, просто нет должной квалификации. А когда все делает человек-оркестр, то и регуляторы выглядят как курсовик по ТАУ, и качество кода вызывает вопросы.
>Я по молодости думал, что это наша отечественная специфика, но нет - говнокод в embedded - явление, увы, интернациональное.
конечно интернациональное, но imho далеко не embedded specific, зависит скорее от стандартов проекта, компании и пр (или отсутствия таковых), но embedded systems имеют особенность, ими интересно заниматься там где делают новое hw, а не копируют чужое, соответственно опыт в разных странах сильно отличается, про важность работ над embedded sw, говорить много не требуется, большая часть сети держится на таких системах, interconnect так близко к 100%, где был написан код хорошо известно, можно ли назвать его типа говнокод, думаю что нет, хотя конечно немного есть и этого,но как правило в части ui (видеть приходилось), насколько сложное там sw - достаточно сложное, у большого router процессоров до нескольких сотен, количество сообщений между ними зашкаливает, и т.д., далее embedded для сетей это типа верхушка айсберга, все что плавает, летает и ездит управляется embedded systems, соответственно там где это производится отношение и к технологии, и к программистам сильно отличается от описанного в статье, про уникальные системы реального времени вообще разговор особый, ввиду их важности и сложности разработки, примерно так, как обычно imho
… и надо будет вкуривать очередную схемотехнику на 30-60 страниц. А схемотехники даже блок-схему не нарисуют, сразу дают в лучшем случае Э3 а в обычном случае и вовсе принесут плату без доков и скажут, что надо ее оживить.
Очень жизненно)
В программировании мк на ассемблере есть особый кайф, например когда считаешь такты при общении по протоколу 1-wire
Я таки чувствую некоторую обиду не найдя в списке опросника классики в виде 8051.
По статье - всё правда, хотя меня это затронуло в своё время не так сильно, как побочная задача при разработке достаточно сложных устройств на FPGA. Но память о EZ-USB™ неизгладима и спустя пару десятилетий.
Единственное за что я могу сказать спасибо embedded, так это за осознание того, насколько полным может быть контроль над устройством при использовании Asm-а. Это осознание очень пригодилось позже, когда возникла необходимость по максимуму оптимизировать некоторые критические места уже совсем другого кода работающего с SSE/AVX.
Это ладно, почему 8049 нет? Мне после него 8051 таким сложным казался...
Да в этом списке нет также и PIC. Кроме того, лично у меня, вот прямо сейчас в работе три простых проекта на PIC12F675, Atmega64M1 и xmc4700. А в опроснике нет возможности выбора всех трех семейств. Плюс ни в тексте статьи, ни в опросах не упомянуты такие IDE, как Atmel(Microchip) Studio и MPLAB-X. Вот конкретно я в них работаю...
Хотя за статью спасибо.
а plain С это 89, 99, 2011 и всё
C17 и C2X такие:
У РФ нет даже своего текстового редактора.
Facepalm. Вам так нужен национальный текстовый редактор? Он сможет обскакать Emacs, Vim, Sublime, vscode, в которые вкидывались сотни человеко-часов и про которые я честно говоря даже не знаю их национальную принадлежность?
Всеми любимый текстовый редактор VS Code от Microsoft.
Как будто vscode индустриальный стандарт)) Я так понимаю это просто странно сформулированная мысль "Среди эмбедщиков больше перекос от IDE к редакторам, чем в прикладном программировании".
В целом, жалобам верю, но вы имхо попали в "пузырь" с неудачным типом работодателя. Отсюда и все эти гаражи и ноутбуки на коленях. Российские компании, разрабатывающие под МК, это весьма характерный типаж.
"Навыки программирования на С очень слабо конвертируются" - слишком пессимистично. Дело же не в знании непосредственно Си, к сишке у разработчиков встраиваемых систем прилагаются знания модели памяти в C, работы сисколов, бинарников, ассемблера, отладки, вы ужаснётесь если узнаете насколько прикладники этого всего не умеют.
C17 это не принципиально новый стандарт, а уточненный C11.
C2x еще не вышел, про него рано говорить.
Реальность такова, что если новый сотрудник в российской Embedded компании не пользуется VS Code от Microsoft, то его будут тиранить угнетать изводить коллеги (peer(ы)) пока новый сотрудник не установит этот 500MByte(ный) в RAM VS Code и не научится пользоваться VS Code потому, что все остальные там уже давно пользуются VS Code.
Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров. Хлам на столах с горочкой.
Хлам не на столах, а в голове. Только и занимаюсь тем, что программирую микроконтроллеры. Отличное, стильное, высокотехнологичное и удобное окружение. Работать удобно и приятно.
И вообще статья оставляет какое-то гнетущее безысходное впечатление — до прочтения статьи был уверен, что программирование микроконтроллеров это самое интересное и увлекательное дело на свете.
Сколько программирую МК и что я, что моё окружение, всегда использовали Форт. А также просто знакомые "коллеги" по программированию МК, что российские, что зарубежные так же предпочитают его использовать. С и уже тем более С++ где-то далеко.
Йоды джедаев магистра речи тайна раскрыта — на Форте просто старый программер он есть
Forth, конечно, хорош - но вот скопи-пастить более менее серьезные библиотеки неоткуда.
Все сами, девочки.
Уважуха! Видно человека, начинавшего примерно в одно со мной время, и говорящего знакомые слова :-)
Но интересно, какова у Вас предметная область? Далеко не большинство FORTH сейчас используют, конечно. И далеко не все имеет (экономический) смысл на FORTH'е сейчас писать. Попробуйте Zigbee или LoRaWAN устройство, например, реализовать...
Да и программы простые.
В условиях перехода на отечественные микросхемы, у нас происходит уже много лет следующая ситуация. Например, нужен вычислительный модуль. Что он должен делать? Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей. Смотрим, из чего такое можно сделать на отечественной базе да ещё с пятой-девятой приёмкой. И окажется, что ничего такого особо и нет («Эльбрус» чем-то не подходит, уже забыл чем именно). Зато есть продукция миландра типа 1986ВЕ1Т или 1986ВЕ92. Ну и, например, убожество типа 1867ВЦ6Ф есть. Вот набор этих штук и будет заменять собой компьютер. И программа простой не будет, не ждите. :) Это не переходник. Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом. То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.
Вы забыли ещё про НИИЭТ К1921ВК01(028/035)Т. Потом есть ещё Элвис.
Блин. Если бы не возраст 50+ - это классная задача. Систематизировать, программировать, устранять баги и прочее.
Я прямо вижу пачку статей и диссеров.
"Разработка планы интерфейса для снижения внешних воздействий", когда на любую плату навешиваешь защещенные от статического электричества и наводок повторители интефейса и эта плата универсальна.
Учебник "Систематизация процессов программирования контроллеров" - кстати, если разобраться с монетизацией - можно сделать альманах статей Хаброжителей.
Сайт "Пополняемая библиотека программных блоков"
По необходимости приходилось программировать под PLC Twincat от фирмы Beckhoff. В принципе, штука весьма продвинутая, есть и своя IDE, основана на Visual Studio, и свой ооп-язык ST (очень напоминающий Паскаль).
Это, конечно, не полноценный bare metal, основная боль была в другом и скорее решалась обратная проблема - надо было расширить функционал, написанный бывшим явистом в довольно странном стиле. И речь шла скорее об удалении ООП из кода, где оно было абсолютно не к месту.
Делал красно-черное дерево для СКУД :D - база ключей в еепром 24C, оперативки не требуется много.
В целом - все так, как описано. На удаленке 10 лет, если бы была конкурентная зарплата, то и из Таиланда +- можно было бы в целом. Но если бы да кабы...
Из Таиланда сейчас как раз проще за конкурентоспособную зарплату с микроконтроллерами возиться. Платят прилично люди из "недружественных стран", в РФ фиг заказчик сейчас что сможет переслать. И раньше-то было не всегда просто, честные люди честно писали, что посылают, например, медицинскую технику, когда посылали прототип какого-нибудь пульсоксиметра. И таможня радостно взводилась, и FedEx отправлял все обратно, и посылали снова, но уже как "выставочные образцы" чего-нибудь безобидного. И месяц уходит в никуда на все на это...
Прикольная статья. Тем, что первую треть я, читая, возмущался и негодовал описываемой безнадеге. А далее, вспоминая своё, очень плавно осознал что, на самом деле все так и есть :)
В целом, я со всем согласен и такой порядок вещей меня более чем устраивает. Ничто меня так не расслабляет как трассировка печатных плат, моделирование в SOLIDWORKS и программирование МК. Да и отладка электроники не сказать что раздражает. Одна беда - говорят, что в фирмах за такую работу денег платят мало, таксистом можно больше заработать. Но тут всегда можно поднабраться опыта, посмотреть чего людям не хватает и попробовать запустить свой проект.
Кстати, а чем плох С? Тем, что позволяет выстрелить себе в ногу? Ну так, может, тут стреляющий в ногу сам виноват? И динамическая память ладно, данные разных размеров бывают, но наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
Время программиста стоит слишком дорого, чтобы тратить его на уборку мусора.
А вот этот парадокс всегда выглядел для меня очень странным. Люди других профессий за гораздо меньшие деньги делают гораздо больше полезных дел ошибаясь при этом гораздо реже. Да, понятно, что нищая страна и конкуренция с иностранными работодателями, но все же...
Люди других профессий за гораздо меньшие деньги делают гораздо больше полезных дел
Тут уже на Хабре этот философский вопрос обсуждали не раз и не два. TLDR: это не программистам платят слишком много, это людям других профессий платят слишком мало. Причины, как верно подмечено, связаны с балансом спроса/предложения и с открытостью/изолированностью рынка труда.
Ну так, может, тут стреляющий в ногу сам виноват?
Вы так говорите, как будто в ногу стреляют намеренно и осознанно. Как раз основная проблема в том, что в Си выстрелы в ногу могут происходить совершенно неожиданно и внеочевидных местах.
но наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
Так за дело же считают. Во всех сколь-менее сложных и широко используемых программах на Си в разное время находили ошибки в работе с памятью, в лучше случае приводившие к DoS, в худшем - к дырам в безопасности. Можно, конечно, рассуждать, что ядро Linux пишут идиоты, GCC пишут идиоты, Apache пишут идиоты, Libc пишут идиоты, PostgreSQL пишут идиоты - но тогда встает вопрос, а кто не идиот-то?
Для человека невозможно сходу писать код без багов. Просто невозможно. Товарищи из блога PVS-Studio не дадут соврать. Если кто-то из программистов уверен, что уж он-то точно всегда пишет код без багов, то либо он Чак Норрис, либо он просто еще не писал ничего на самом деле сложного, либо у него синдром Даннинга-Крюгера и он просто ещё многое не осознал.
Поэтому если есть возможность снизить количество вероятных ошибок и последствия от них небольшой ценой, во многих случаях логично этой возможностью пользоваться. Заодно и временные-трудовые ресурсы программиста можно потратить на что-нибудь более полезное.
Изначальный посыл верен. Но такой подход сильно развращает, приводит к раздолбайству, пофигизму и тормозному говнокоду. Ошибки при этом, как правило, никуда особо не деваются, просто совершаются в других местах из-за снижения общей дисциплины.
приводит к раздолбайству, пофигизму и тормозному говнокоду.
Ну, перечитайте еще раз эту статью, комментарии к ней, и ссылки из комментариев: в embedded нет никаких сборщиков мусора, как правило хардкорный чистый Си, а говнокод, раздолбайства и пофигизма при разработке ПО тоже более чем достаточно. Так что не от этого зависит.
Хотя, как я уже говорил, сегодня все чаще и чаще звучат разговоры о применении Rust в embedded. Когда сам язык на уровне концепций и компилятора противодействует некоторому говнокоду и классическим ошибкам, при этом не создавая лишнего оверхеда - это самое то для встраиваемых систем.
Ошибки при этом, как правило, никуда особо не деваются, просто совершаются в других местах из-за снижения общей дисциплины.
Вполне возможно, но ошибки тоже могут быть очень разные. Ошибки в бизнес-логике обычно хорошо воспроизводимы, могут быть отловлены при тестировании, и т.д. Ошибки в управлении памятью (или, например, в многопоточности) могут не проявлять себя очень долгое время при любых тестах, воспроизводиться только при определенном положении звезд на небе, и при этом быть гораздо более дорогими в плане нанесенного ущерба (например, remote code execution или arbitrary memory read).
Недостаток С:
1) В С преобразование типов делается скобками ().
Невозможно утилитой grep найти все места, где есть преобразование типов.
"Я водитель. Вчера добывали нефть из скважины , что бы сделать бензин и заправить машину. А сегодня делали из нефти резину, а то стёрлась уже. - Так вы водитель? Или нефтяник, химик? Или автослесарь?" У меня немалый опыт, поэтому подтверждаю. Во многих организациях практикуют такой подход. Он сложился (вероятно) исторически, когда зарождались микроконтроллеры и программистом становились электронщики. Я и сам когда-то перематывал трансформаторы, пилил напильником корпуса для приборов и т.д. Я считаю такой подход непрофессиональным. Для чего вообще разделение труда? Если программист идет на поводу у работодателя, возникает такая картина. Поэтому, моё мнение, припаять что то, есть монтажница! Посмотреть осциллографом, электронщик. Проверить на объекте, инженер по внедрению. А программист микроконтроллеров, сидит на стуле и пишет программу! Как максимум, подключает программатор к плате.
Проверить на объекте, инженер по внедрению. А программист микроконтроллеров, сидит на стуле и пишет программу
Ха, если бы все было так просто. Иногда приходит от заказчика заказ: нужно, чтобы ваше изделие интегрировалось вот с этой железкой, которая стоит у нас. Вперёд, интегрируйся. Заказчик эту железку тебе не даст, она у него уже работаете и самому нужна. В офис тебе эту железку начальство не купит, она или весит под тонну, или вообще очень редкое и труднодоступное изделие, или стоит больше чем весь бюджет проекта, да и куда ее потом девать. В итоге ты пишешь программу по той спецификации протокола, что тебе дал производитель этой железки, а когда "инженер по внедрению" подключает все как надо, то ничего не работает. Потому что в спецификации были ошибки (например, она относится к другой аппаратной ревизии или к другой версии ПО), или там забыли упомянуть что-то весьма важное (а других спецификаций не было и нет), и вот уже ты сам, программист, сидишь на объекте в цеху, монитором порта слушаешь шину данных, периодически модифицируя свою программу и смотря что происходит.
И ещё. Я не называл бы (например) STM32 с частотой 200 МГц и "чудовищным" по размеру ОЗУ микроконтроллером. По этому, С++ в микроконтроллере не место (моё мнение), а вот в Гигаконтроллерах, возможно да.
У C++ основной принцип you don't pay for what you don't use. Вполне можно ограничиться определенным подмножеством фич языка, которые работают в compile-time, и таким образом при правильном подходе получить разные приятные удобства и полезные проверки на этапе компиляции без раздувания бинарника и избыточного потребления ресурсов.
Прошивки довольно простые программы. В них как правило нет никакого процессинга над данными. Всё сводится к тому, что надо GPIO мигнуть, кнопку прочитать, испустить PWM сигнал и прерывания по перепадам напряжений отловить. В микроконтроллерах нет нужды даже в алгоритмах сортировки.
Только не рассказывайте об этом ребятам, которые пишут прошивки для электропривода с векторным управлением; ребятам, которые занимаются анализом сигналов на DSP; ребятам, которые разрабатывают интерфейсы для нелинейных датчиков; ребятам, которые занимаются сетевыми устройствами итд итп. Не стоит транслировать свой, не очень релевантный, опыт на всю отрасль программирования МК.
Тоже самое с решениями для VOIP, и прочих сетевых устройств, уровень сложности там большой, без git будет сложно.
На госпредприятиях, да, вполне возможно, что описанная автором ситуация действительно есть.
Всё что я делал в русской электронике 10лет подряд это переходники с одного интерфейса на другой интерфейс. Маршрутизаторы, модемы, телематика, СКУД(ы), аудиосистемы. Переходники. Переходники. Переходники.
Тогда и любой браузер можно назвать переходником между сетью и монитором, а видеопроигрыватель — переходник между диском и монитором.
Странно что в статье обойден такой немаловажный вопрос как "про деньги". ИМХО, все связанное с железками в нашей стране, очень плохо оплачивается..
Вот, например, сколько лет нужно с начала карьеры, чтобы дойти до планок в 100, 200, 300к?
если брать разработчика, то в-до-февральской эре планка в 100 - это чуть ли не джун (ну реальнее джун за 70, через годик-полтора - 100), 200 - мидл с опытом в 5+ лет.. 300 - это крепкий мидл - сеньор.. Сейчас, правда, все стало хуже.. не вижу вакансий для сеньеоров с предложением выше 300к, ранее было "от"...
О получке, всем известно что она неприлично маленькая: но погрОмист может перекваифицироватся в "формошлёпство" за 2..3Х денег зачем он ест ембеддед-кактус и страдает, он же уже в айти ему ненужно никуда входить ? Что это за особенная форма религиозного страдания, кто эти мученики, и за что они рубятся ?
кто эти мученики
Вот тут товарищ немного раскрыл ответ на этот вопрос:
Помножаем на диспропорцию зарплат и получаем что? Правильно - или джунов (много, но не на долго) или фанатов (редко, и очень сложно переманиваемых - ибо страшно бросить то, что годами оттачивал и браться за новое, понимая всю степень ответственности) или ленивых ежей, с которыми пока не пнешь - не полетит (довольно частый вариант).
вникать в спеки каждой микросхемы (~1k...5k страниц) на печатной платы.
вы ужаснётесь если узнаете насколько прикладники этого всего не умеют.
Я точно, как прочитал, ужаснулся. Не знал, что всё проще на самом деле и из за этого не устраивался работать по специальности. Но...
такие коренные познания нужны и прикладникам, я считаю. Иначе их место (в головах людей) будут занимать околошизоидные представления.
Задачи могут поставить так: “подружить микроконтроллер и айфон”, “оживить плату”, “подружить платы”
Вот это как раз такие случаи.
Прочитал все от корки до корки...........Я люблю программировать AVR ки на языке BASCOM AVR. Для моих целей и задач вполне подходит и я им доволен. Можно написать и программу для управления электродвигателем, голосовым выключателем света в комнате, делительной головкой или поворотным столом фрезерного станка. А можно и программу управления испарителем вакуумной установки.
Статья выглядит как очередное откровение от "прозревшего" представителя поколения любителей смузи. В целом уже с первого абзаца понятно, что человек сам в программировании в общем не знает примерно ничего. Одной вот этой вот цитаты достаточно:
Навыки программирования на С очень слабо конвертируются.
Пофигу, что половина модных\молодёжных\современных языков используют похожий синтаксис и похожие концепции. Пофигу, что поняв С, разобраться с большинством других "процедурных" языков проблем не составит, т.к. уже появляется представление о том как всё работает на уровне железа. И объектно-ориентированный стиль при желании понять не сложно, т.к. это по сути переход от конкретики к абстракции, который всегда проще чем переход от одной абстракции к другой.
Ну и далее перлы один за одним. В духе "так работаю я, значит так работают все".
Всё что я делал в русской электронике 10 лет подряд это... Переходники. Переходники. Переходники.
Забавно чо уж. Послушать бы как эту же профессию этот человек опишет через десять лет (если, конечно, не сменит специальность).
Отдельно крякнул вот с этого:
Программы для МК простые
...
Всеми любимый текстовый редактор VS Code от Microsoft.
Это просто ноукомментс
Конкретно в вопросе "конвертируемости" автор как раз, судя по всему, хорошо понимает, о чем говорит. Простой пример: если человек, желая перейти из embedded в какую-нибудь другую сферу разработки, откроет российский hh или международные linkedIn/glassdoor, то проанализировав вакансии, очень быстро обнаружит, что чистый Си вне embedded нужен от силы в паре процентов от предлагаемых проектов - и число таких предложений в десятки и даже в сотни раз меньше тех, где требуется знания и опыт других языков. "Представление о том, как все работает на уровне железа", конечно, хорошо, но поможет не сильно - в том же обычном бэкенде/фронтенде о сисколлах, регистрах, кэш-линиях, аллокаторах и прочем знает в лучшем случае один разработчик из ста, и это ничуть не мешает остальным делать свою работу и получать за нее деньги (хорошо это или плохо - вопрос отдельный, но это факт) - используемый уровень абстракций гораздо выше, и просто нет нужды спускаться так низко. "Похожий синтаксис" это вообще смешно, синтаксис языка можно изучить за пару дней, это обычная самая меньшая из проблем при переходе на новый язык. То же самое про ООП, как уже тут говорилось, одна из самых частых и опасных ошибок сишников - подумать что "синтаксис у языков похожий, а принципы ООП я понимаю" и переходя на C++ начинать писать на "Си с классами", что приводит это обычно к говнокоду и очень печальным последствиям.
Ну и далее перлы один за одним. В духе "так работаю я, значит так работают все".
"Значит так работают все" у него и не звучало. Другой вопрос, если ткнуть в рандомную контору на рынке, на что больше вероятность наткнуться - на то, о чем говорит автор, или на то, о чем говорите вы. Опыт многих людей подсказывает, что распределение вероятностей тут будет явно не в пользу второго :(
Вы в самом деле хотите стать программистом микроконтроллеров?