Комментарии 406
Для их процессов кода как будто бы не существует. О коде не говорят. Код не изучают, не анализируют. Интерес представляет только физический прприборВ
Вот это прям в точку. По СРПП софт для устройства появляется магическим образом на этапе РКД. В ночь с четверга на пятницу. И никого не волнует, что целевое устройство в этот момент существует только на бумаге! Что реальная трудоёмкость разработки изделия сейчас может на 80% быть в том самом софте. Что чтобы написать нормальный софт надо получать обратную связь от пользователя годами.
Тут стоит добавить, что нередко работа в таких проектах влечет за собой подписание формы секретности со всеми возможными последствиями.Вы вот очень много пишете (в комментах в основном) о том, как у нас тут всё плохо. Вы сами лично что-то подписывали хоть раз? Или вам об этом только рассказывали? Как вы думаете, там совсем нет ITAR-related работ?
Плюс менеджмент… в подобных местах сильно оставляет желать лучшего.Имя, сестра, имя!
какие гарантии… разумного ответа дать никто не смогА на что вы рассчитывали, задавая такой вопрос?
Жду не дождусь, когда секретка таки спадёт, ещё полгода осталось. Дальше что?
И про менеджмент — полностью подтверждаю.
Шаг 1. «Вторая форма нужна, чтобы бла-бла-бла, реально ты к секретам не полезешь, а без ознакомления с секретами, сама по себе, эта форма ничего не значит» (и это на самом деле так)
Шаг 2, через несколько месяцев: «а на вот почитай документ». И пошли тикать пять лет.
ВСЁ. По молодости либо неопытности таким образом залететь — проще простого.
Так что у разработчика НЕТ в реальной военке вариантов избежать хотя бы третьей формы. Ну, кроме варианта «вообще не работать на вояк»
Вы пытаетесь увести дискуссию от исходной точки.Нет, я всего лишь утверждаю, что если у вас был выбор идти на работу с формой допуска или не идти, то факт того, что вы туда пошли — это исключительно ваше решение.
Вы начали отвечать на этот мой комментарий. Где я в нём оспариваю
что в военке без третьей, а то и второй формы работать разработчиком нельзя? Не занимайтесь приписыванием и додумыванием (тоже демагогия, ага), пожалуйста.
Если вы при устройстве на работу не
Современный тётушки из российских отделов кадров абсолютно не понимают, что такое профессия "программист-микроконтроллерв". Поэтому на ваше резюме на hh.ru будут регулярно откликаться левые HRы.
Они будут на полном серьёзе приглашать тебя на роль 1C-программист в бухгалтерию, linux-kernel программиста, чертёжника печатных плат, C#-программиста, преподавателя информатики в ПТУ, инженера КИПиА в ЖКХ, программиста станков с ЧПУ и прочее.
Отклики будут от всего, что только угодно, только не на программирование микроконтроллеров. Поэтому только ты сам сможешь понять какая вакансия тебе реально соответствует.
После «а на вот почитай документ» ничего тикать не начинает. Срок 5 лет отсчитывают после последней официально зарегистрированной даты взятия документа в БСТД.
Интересно, какое именно "блабла" вам вешали, рассказывая о необходимости второй формы, что вы прямо так доверчиво решили ее оформить.
Из опыта скажу - вторую форму с удовольствием оформляют, например потому что это, например, может быть плюс 40% к окладу, которые призваны компенсировать неудобства пользователя.
Третья форма - около плюс 20% к окладу и практически никаких выездных ограничений, и даже загран не сдается в отдел кадров. Сама по себе третья форма это фигня, которая выдается любому студенту и реально ни к чему особо не обязывает, буквально для ДСП.
Допустим у нас не брали без формы в том числе, что таких людей даже посадить негде, т.к. помещения аттестованы и на три этажа была буквально одна одноместная каморка, куда формально вписывали всех "недопущенных", в том числе командированных, гостей и т.д.
Я на эту тему даже анекдот придумал:
Программист-микроконтроллеров Ашок подходит к Начальнику и говорит:
—Мне для написания прошивки нужна схемотехника PCB
Начальник говорит:
—Ашок, решай задачу с минимальным погружением.
Прошло 2 недели. Начальник подходит к Ашоку и спрашивает:
—Ашок, почему ты в последнее время работаешь только по 4 часа в день вместо 8ми?
Ашок отвечает:
—Я решаю задачи с минимальным погружением, как вы и велели
Да нет никаких подписок при разработке на контроллерах под военку. Даже на "взрослых" системах их нет.
Подписывают те, кто знакомится с условиями/требованиями изделия. Дальше идёт стандартное выделение функционала, деление на задачи и подзадачи. В результате, конечный исполнитель даже не знает что делает в глобальном смысле. Тут и делегировать на сторонние организации можно без проблем.
Подход древний, как сама инженерия.
У нас в организации одно время на всех "причастных" оформляли секретность. А потом ввели доплату "за секретность", и через некоторое время руководство решило, что большей части сотрудников никакого допуска и не надо и прекрасно работается и без него...
Я спросил: почему работодатели на собеседованиях прямо говорят о необходимости третьей формы?Именно. По-моему вполне адекватный ответ на ваш изначальный вопрос, зачем при трудоустройстве некоторые компании хотят, чтобы вы подписали согласие на третью форму. Где тут было
Вы ответили: потому что по долгу службы возможно придется работать с определенными документами, для которых ее необходимо иметь.
ничего подписывать не нужно и не придется, а в следующем комментарии говорите что оказывается может быть нужно и придется?
Вы в предыдущем комментарии говорили, что ничего подписывать не нужно и не придется, а в следующем комментарии говорите что оказывается может быть нужно и придется.Как-то не бьется с
«ничего подписывать не придется» написал другой комментатор, а вы под его комментарием выразили согласие со сказаннымТ.е. вы занимаетесь приписыванием, если уж вы собрались ловить меня на логических ошибках.
Касательно моего комментария на комментарий Yurik79 о дроблении работы. У меня была третья форма, поэтому я из первых рук знаю что это такое. Несколько раз. Ничего ужасного в этом не было (только не надо из этого раздувать, что я автоматически согласен с политикой партии и всем прочим, что происходит в стране). Паспорт никто не забирал, на границе меня никто ни о чем никогда не спрашивал. В реальных работах, в которых я участвовал, где были закрытые параметры, делали так, как описано в комментарии Yurik79. Это мой личный опыт.
У тебя есть орган и "потенциально", ты насильник... Из старой "шутки".
Предупредили или заставили?
"Предупредили". Что если вдруг, будет карьерный рост и из простого эникейщика, перейдёшь в разряд человека, имеющего право решать артихектуру или участвовать в обсуджении архитектуры, ты"вдруг" не узнал что надо сделать выбор.
"Предупреждают" где-то о внеурочной работе или командировках. "Предупреждают" о прохождении квалификационных испытаний. "Предупреждают" о переезде в другую локацию.
"Предупреждают" - это не обязательство.
Ты принимаешь во внимание и дальнейшее от тебя зависит. Не хочешь форму допуска 3(по сути ни к чему не обязывает, а 2 не дадут просто так с улицы и она излишня разрабам), можешь отказаться отполучения и остаёшься на прежнем уровне задач "вот тебе условие А, должно быть Б, через преобразование С". С допуском, можешь понимать почему А и Б, и С, и возможно исправить ошибку архитектурную при этом.
Нет расстрелов, нет ограничений на передвижения, нет проверок до 7 колена... "Меньше читайте советских газет" вобщем. Стандартно, очевидно, что аж плакать хочется.
Дают простой условие… согласиться и подписать, иначе работать на этой должности не выйдет… множит на ноль все то, что обсуждалось на собеседовании до этогоИдти работать в компанию, где потенциально может быть форма секретности и первым вопросом не спросить, нужно ли будет её оформлять, ну это нужно быть очень-очень одаренным человеком.
разработать железку - вот это настоящая сложность и искусство доступное не многим, а программу написать - вообще фигня, даже обезьяна на коленке справится
Из за этого подхода много интересных компьютеров из 80 загнулось. Когда разработчики железа именно так и постулировали, что мол главное это характеристики электроники, а софт пользователи сами себе без проблем напишут. Что привело к доминированию на рынке стандарта ibm-pc, по сути единственного стандарта, который не забивал на проблему обратной совместимости нового железа со старым софтом.
Такие легенды, как commodore, spectrum, bbc micro, amiga загнулись в первую очередь из за подхода - для новых версий железа понапишут новый софт с нуля. А неблагодарные пользователи отказались покупать новые компьютеры, на которых не запускались старые программы и игры.
В программировании микроконтроллеров нет людей легенд, как это присутствует в GameDev(Джон Кармак), Mobile(Ян Борисович Кум), Compilers(Джеймс Гослинг), DeskTop( Ричардом Броди) или Web(Марк Цукерберг).
В Embedded отсутствуют признанные авторитеты в разработке и знаменитости в этой, с позволения сказать, "индустрии".
Как следствие, нет примеров и ориентиров того как надо. Нет историй успеха.
Тщеславным людям в Embedded разработке делать абсолютно нечего.
Как правило каждый попал в эту профессию случайно. Учился на инженера-электроника на приборостроительном факультете в своем региональном политехе. На 4м курсе пошёл работать по специальности, а его на работе программировать заставили.
Через 6 месяцев подписал форму допуска и стал абсолютно серым телом.
Потом вся оставшаяся жизнь протекает по схеме: сделал проект, получили премию, съездил в Анапу.
На большее рассчитывать и не приходится.
Как это в Embedded нет авторитетов? А Ричард Барри, Адам Дункельс, Рольф Зеггер, пожелавший остаться анонимным Elm-ChaN?
Ричард Барри- автор FreeRTOS,
Адам Дункельс- автор lwIP,uIP
Elm-ChaN - автор FatFS
Однако Рольф Зеггер - это кто?
Рольф Зеггер - это основатель Segger, которая разработала embOS, STemWin и многое другое.
Ещё одна RTOS. Впервые слышу про такую embOS.
Подозреваю что разные RTOS нужны для обнуления зарплатных ожиданий Senior программистов микроконтроллеров.
Приходит человек на работу говорит что
--Я 12 лет работал с FreeRTOS. Знаю её насквозь.
А ему отвечают
--А мы работаем с RTEMS. Соглашайся на ставку Junior(а)
Так как количество RTOSов просто зашкаливает.
Azure RTOS , CHibi, Contiki, DSP/BIOS, Embox , FreeRTOS, Keil RTX, Nucleus RTOS, NuttX, OpenRTOS, QNX, RTEMS, RTEMS 5, SafeRTOS, SYS/BIOS, TI-RTOS, TI-RTOS7, Tizen, TNKernel, TynyOS, vxWorks, Zephyr, embOS.
То эту карусель можно проворачивать ещё очень-очень долго.
хреновый тогда сеньор, ибо сеггер это ещё и J-Link, наиболее часто встречаемый в последнее время программатор-отладчик, который умеет как в ARM, так и в RISC-V.
ибо сеггер это ещё и J-Link, наиболее часто встречаемый в последнее время программатор-отладчик,
Этот глюченный J-Link только с 10й попытки пошаговую отладку запускает
https://habr.com/ru/articles/682498/
В то время как OpenOCD безотказный как автомат Калашникова
https://habr.com/ru/articles/792590/
Этот глюченный J-Link только с 10й попытки пошаговую отладку запускает
сколько лет с ним работаю, проблема возникла только один раз с китайским клоном, в котором слетела прошивка. в остальных случаях проблем не возникло ни разу. Правда я с эклипсом особо не работаю, не понравилось на заре танцы с бубном устраивать для его настройки так сильно, что до сих пор и не пользуюсь. Но это чисто вкусовщина, на мой взгляд эти фломастеры не вкусные.
зато для производство получилось сделать несколько простых скриптов, которые через J-Link автоматически шьют прошивку, серийные номера и калибровочные данные в память. можно ли это сделать другими средствами? наверно можно. Но будет ли проще?
В то время как OpenOCD безотказный как автомат Калашникова
Он может выводить RTT поток с микроконтроллера? это режим трассировки причем двунаправленный, аналог SWO и semihosting, только немного быстрее. J-Link умеет.
Правда я с эклипсом особо не работаю
В каком текстовом редакторе Вы тогда пишите исходный код?
Раз уж спросили, отвечу: я использую IDE, Segger Embedded Studio (SES) - так как для Nordic у них свободная лицензия, а последнее время я работаю только с ними. Есть как плюсы, так и минусы. Главный плюс - оно работает из коробки. Опять же, из него запускается Ozone весьма интересный, хоть и специфичный отладчик-профилировщик.
Пробовал Visual Studio с плагином VisualGDB (для зефира, в целом весьма удобно, так как смог прикрутить запуск RTT логгера, что позволило видеть логи сразу в консоле студии), в планах попробовать освоить Visual Studio Code.
Пару раз файлы открывались в Qt Creator, когда надо было строчно поправить по результатам тестов и отдать на повторный прогон устройство.
часто заготовки классов пишу в Notepad++ просто потому что привык к нему.
По итогу могу подтвердить что, все фломастеры разные как на цвет, так и на вкус. Где-то удобно сделано автодополнение кода, где-то подсветка лучше, а где-то есть "странный" статический анализатор кода, который может выдать сообщение "данный код не используется в файлах. Есть вызов функции в файлах ... "
Разве это имеет большое значение в чем писать код сейчас или чем его собирать? Писать в текстовом редакторе и руками вызывать make ? Можно, но для чего, если придумали более удобный инструмент?
Разве это имеет большое значение в чем писать код сейчас или чем его собирать?
В чем писать не имеет.
А вот чем собирать - да имеет. Причем очень существенное значение.
Пояснение тут
Почему важно собирать код из скриптов
https://habr.com/ru/articles/723054/
Почему важно собирать код из скриптов
Это только ваше мнение и я с ним имею право быть не согласным. Я согласен что скрипты в сборке полезны и более того, без них часто бывает сложно, но ведь скрипты умеют вызывать наверно все IDE как перед компиляций, так и после. Что в принципе я и использую. У меня есть несколько batch файлов, которые делают разные полезные вещи (например, формируют файл для "обновления по воздуху", правильно его именуют, помещают в правильную директорию на сервере и рядом бонусом кладут файл с описанием изменений). Были даже bash-скрипты которые тянули из гита описание тэгов и формировали историю версий.
И мне кажется, вы смешиваете сущности. Есть скрипты окружения (формирование номера версии, перекладывание результатов сборки куда-либо), а есть система сборки (компиляция + линковка). Для общего понимания наверно да, надо уметь собирать с помощью своего скрипта, но в большинстве случае: зачем? Какое преимущество это дает? Если Вася собирает проект в IDE, получает ровно тот же самый hex файл прошивки и тратит на него меньше времени, то зачем руководителю платить Пете, который умеет собирать из makefile, но тратит на весь процесс больше времени? Если при этом Васе ещё и IDE помогает в отладке, то почему бы и не купить ему лицензию, ведь это сэкономит много времени.
Я думаю есть отрасль, где существуют требования по использованию именно makefile (или его аналогов). Но это же не повод обобщать на всех и на все?
Для общего понимания наверно да, надо уметь собирать с помощью своего скрипта, но в большинстве случае: зачем? Какое преимущество это дает? Если Вася собирает проект в IDE, получает ровно тот же самый hex файл прошивки и тратит на него меньше времени, то зачем руководителю платить Пете, который умеет собирать из makefile, но тратит на весь процесс больше времени? Если при этом Васе ещё и IDE помогает в отладке, то почему бы и не купить ему лицензию, ведь это сэкономит много времени.
Сборка из-под IDE наоборот как раз тормозит ход работы. Как правило те кто собирают из под IDE у них одна сборка-франкенштейн. Там все настройки мышкой.
Одновременно с этим
Скрипты (Make Cmake) это самый гибкий способ управлять модульностью кодовой базы. Новые сборки легко добавляются.
Можно буквально одной строчкой в скриптах сборки добавлять или исключать один конкретный программный компонент (десятки файлов) из десятков сборок. Вместе с макросами и путями для него.. В случае же сборки из-под IDE вам бы пришлось вручную мышкой щелкать в GUIне или редактировать .xml для каждой сборки.
+Скрипты сборки лучше подходят для DevOps.
При этом не открывая скрипт сборки не узнаешь, какой модуль идет в сборку, а какой нет. Дерево проекта в этом плане имеет хотя бы подсветку активных файлов, которые попадают в данную сборку.
Можно буквально одной строчкой в скриптах сборки добавлять или исключать один конкретный программный компонент (десятки файлов)
Клик ПКМ в выпадающем меню выбрать "исключить из сборки". При необходимости повторить для нескольких конфигураций.
я не ставлю цель убедить вас в неправильности использования скриптов сборки, пишите и собирайте как вам удобно. вы же упорно ставите цель убедить меня в том, что я неправильно работаю.
p.s. ещё и джуниором обозвали)
При этом не открывая скрипт сборки не узнаешь, какой модуль идет в сборку, а какой нет.
Для этого прямо из этих же скриптов можно сделать вот такой генератор документации.
Генерация зависимостей внутри программы
https://habr.com/ru/articles/765424/
Клик ПКМ в выпадающем меню выбрать "исключить из сборки". При необходимости повторить для нескольких конфигураций.
Уже проходили. А пути-то в IDE так и останутся прописаны в настройках проекта. И одноименные .h будут конфликтовать.
За 12 лет в профессии в разных компаниях и разных городах у меня сформировалась вот такая картина
Градация Навыков в Embedded Программировании
https://habr.com/ru/articles/725156/
При этом не открывая скрипт сборки не узнаешь, какой модуль идет в сборку, а какой нет.
Можно набрать в коде модуля
#error check_compile
и если будет ошибка, значит модуль собирается
Если Вася собирает проект в IDE
значит он Junior разработчик. Middle(ы)+ собирают скриптами.
В этом плане embedded-мир сильно отстает от "большого IT" - те через подобное прошли еще 20-30 лет назад, успешно преодолели подобные болезни роста и разработали огромное количество рекомендаций, принципов и инструментов, как нужно делать сложные информационные системы чтобы получилось хорошо.
А что такого придумали в большом IT для преодоления проблем роста проектов? Что бы почитать про это?
Кроме микроконтроллеров С уже практичеfские никому не нужен.
Разработчики Nginx, PostgreSQL, JVM, ядра Linux и многого другого смотрят на вас очень особенным взглядом.
Да тут вся статья примерно того же уровня как и это возвышенное умозаключение.
Насчёт остального не скажу, а вот код постгреса я в своё время вынуждено читал по работе. И это пиздец, за такой говнокод нужно руки отрывать.
JVM написан на плюсах,
Какая именно? Но, скорее, с небольшой примесью плюсов. Там ведь тоже скоро тридцать лет истории.
Можете взглянуть на исходники OpenJDK, которые из нее выросли. Так себе C++, прямо скажем. Даже по тогдашним меркам.
Ну, во-первых, Вы на все 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. И такого там большинство.
Разработчики ядра Linux смотрят на вас очень особенным взглядом.
Linux kernel программисты очень скептически относятся к тем, кто пришел в Linux kernel из программирования микроконтроллеров.
Фактические Linux разработчики даже не считают программистов-микроконтроллеров программистами как таковыми. Называют их User(ы) GUI(нёвых)-IDE(шек).
Во первых все кто пришел в Linux из микроконтроллеров это 90% Window (ятники). Это первая причина отсутствия обшей почвы под ногами.
Потом средства отладки в Linux и MCU совершенно разные, разные системы сборки, разный способ передачи конфигов в программы, разный исходный набор документации, разные традиции оформления кода. Всё разное!
Только Си язык одинаковый.
Поэтому закрепиться в коллективе Linux программистов программисту-микроконтроллеров получится не с первой, и даже не со второй попытки.
Вы описали существование не программиста микроконтроллеров, а эникея, человека-оркестра, к которому, зачастую, и отношение соответствующее. Печально, конечно, что озвученные вами вещи существуют, но мне представляется, что такой бардак присутствует не только у нас. Он много где. Вспомните историю 737 MAX хотя бы.
Поспорить можно практически с любым вашим утверждением. От проводов до скукоты программирования. Да, в эмбеде нет формошлепства (ну почти) и ML только-только поднимает голову. Но в целом, если общая задача интересна, то почему бы и нет. Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного. С одной стороны, можно написать простейший ПИД и успокоиться. А с другой, можно реализовать какой-нибудь нечеткий регулятор (регулятор, кстати, может быть по положению, току, моменту, да чему угодно, к чему применима ТАУ), если система позволяет. И на его отладку и доведение до ума может уйти существенное количество интересно проведенного времени.
Тем, кто всё же осилил прочитать этот поток мыслей автора (каюсь, я не с первого раза сумел): люди, знайте, есть в России такие компании, где всё хорошо с разработкой. Где первый запуск устройства делают программист и схемотехник совместно, где целостность сигналов не пустой звук, а непропаи ищут специально обученные люди, где программист активно переиспользует свою же кодовую базу и где проекты не заключаются исключительно в преобразовании одного интерфейса в другой. Не много, но есть.
есть в России такие компании, где всё хорошо с разработкой
А можно список? (не троллю, правда интересно)
Например, wirenboard
ЗАО НВП Болид
Не знаю, откуда минусы, судя по открытой информации вполне успешное предприятие, одних налогов за 2020 год больше миллиарда уплатили...
И даже у АО Тесла тоже не только фанаты есть.
Видел их офис в ЗелАО. Типичный тренажерный зал-гараж с бардаком. 2 комнаты 3x3 метра и там 8 инженеров. Освещение через щель под потолком. Зачем-то поставили аквариум в котором плавают мертвые рыбки.
ЗелАО - это Зеленоград? Судя по официальному сайту, там вроде нет офиса...
Основной офис и автоматизированная производственная линия находятся в г. Королев на территории ЦНИИМАШ, где трудятся порядка 200 человек. В Зеленограде филиал, ничего не могу сказать, не когда там не был.
Но как мне кажется бардак на рабочем месте это вина хозяина рабочего мест, а не компании. Я коробки из под пиццы наблюдал и на столах в OZON, на 42 этаже небоскрёба. Неряхи есть везде.
не является верным утверждениемЯ сужу только по своей области работы и предполагаю, что в рыночных условиях все должны действовать примерно одинаково (за исключением неких выбросов, разумеется). Кто первый отладил процесс, показал заказчику, что его железка реально работает, того и тапки. Не берем в расчет коррупцию и прочие если.
Просто не верно утверждать, что во всех коллективах эмбеддеров царит бардак и хаос.
Вот иллюстрация, которой можно охарактеризовать код прошивки типичного российского программиста микроконтроллеров. Бомбардировщик К-7.
Хорошо хорошо, если всё не так, и "вывсёврёти" - то предлагаю ответить на несколько простых вопросов.
Есть ли в эмбед-разработке менеджер пакетов и общий репозиторий? Вы конечно можете начать меня убеждать, что это "никому не нужно" - но вряд ли это получится )
Есть ли должность "инженер-программист" для эмбед разработки, куда можно пройти без знания схемотехники и не умея пользоваться осциллографом? Если да - то куда именно. Если нет - то это прямое опровержение ваших слов о том что "это не программисты а эникейщики"
Взять хотя бы управление двигателем, любым. От коллекторного до бесколлекторного.
Отличный пример. Зачем ЕЩЁ раз решать задачу, которую до тебя решили уже "сто тысяч милионов" раз? Поведений двигателя и и способов его управления гораздо меньше, чем http запросов. Но тем не менее, в каждом языке есть библиотека, которая отправляет такие запросы, но эмбедщики за столько лет не удосужились поделиться своими шедеврами с другими. Это высшая форма жадности или отсутствие банальной организации кода?
есть в России такие компании, где всё хорошо с разработкой
Отлично, назовите компанию и прибор, где можно проникнуться величием отечественной разработки. ) Может быть.... Банальный частотник для двигателя? Или своя система управления ЧПУ станком?
Уже много лет прихожу на работу во сколько удобно. Выполняю работу. Того же прошу от своих коллег. В итоге работоспособные продукты, довольные заказчики и акционеры предприятия.
у нас в компании можно приходить во сколько удобно. Или дома работать можно (забрал железку домой и ковыряй)
Вот например почти чпу, только с несколькими фиксированными циклограммами под конкретные задачи.
Вот еще например агрегатор мониторинга оборудования написанный на С для mega2560. Все встраиваемые модули на нане или есп8266
Возможно, purelogic.
Я горжусь всем спектром продукции от ЗАО НВП Болид произведённым в Росси.
вывсёврётиНе передергивайте, пожалуйста. Я всего лишь написал, что с каждым утверждением автора можно поспорить.
менеджер пакетов и общий репозиторийОтвечу вопросом на вопрос: для какой платформы какого производителя чипов? Вы же понимаете (по крайней мере я надеюсь на это), что уровни абстракций слегка разные? У вас может быть ноутбук от десятка вендоров, собранный из запчастей сотни производителей. Но при этом его глобальная архитектура будет одинаковая, хотя и реализована она будет физически разными транзисторами внутри разных микросхем. А поверх всего этого нагромождения железа крутится некая единая в смысле своего внутреннего устройства операционная система, под работу с которой вы уже и имеете всяческие репозитории, менеджеры пакетов и прочий блэкджек. Ваше утверждение про репозитории, это всё равно, что сказать: а давайте у всех будет один микроконтроллер и только на нём мы будем что-то делать. Вы вообще в курсе, что есть такая штука как драйвера под конкретное железо (самые что ни на есть низкоуровневые, пишущие непосредственно в регистры физической микросхемы, для которой написаны), которые и позволяют вам в общем случае (при написании ПО верхнего уровня) не задумываться, видюха от NVIDIA у вас внутре стоит или от AMD (да и то со всеми этими современными ML приходится задумываться, а какое конкретно железо стоит внутри)?
Так что в такой постановке ваш вопрос не корректен.
Есть ли должность «инженер-программист» для эмбед разработкиЕсть где? В компаниях? Есть. Если бы у меня и моих коллег на прошлой работе было бы свободное время для обучения такого джуна, я бы с удовольствием его нанял. Собственно, я такое делал с разработчиками железа. Разумеется, быть программистом-эмбеддером и не понимать, что происходит в железке малореально, поскольку от кода такого разработчика зачастую зависит правильное физическое функционирование устройства, поскольку предусмотреть аппаратные защиты от кривого кода на все случаи жизни не всегда возможно\целесообразно.
которую до тебя решилиВот опять. Различных платформ десятки, если не сотни. В каждом конкретном случае есть свои особенности. По питанию, потреблению. Особенности объекта управления (двигателей вообще-то тоже много всяких разных с разными параметрами и свойствами, от микроваттных до мегаваттных). И что, под них делать некую «единую» библиотеку? Впрочем, некоторые производители микроконтроллеров имеют «библиотеки», разработанные под те или иные семейства микроконтроллеров, реализующие различные «управляторы». Качество зачастую страдает, но где оно не страдает?
эмбедщики за столько лет не удосужились поделиться своими шедеврами с другимиЕсли вы чего-то не видели, это не значит, что этого не существует.
Отлично, назовите компанию и прибор, где можно проникнуться величием отечественной разработки.Как вы себе представляете процесс пенетрации в величие? Может вам еще исходный код показать, сиречь, дать ключи от квартиры где деньги лежат? :) К сожалению, всё что я знаю лично, не стоит озвучивать в интернете, товарищ майор не будет рад. Так что можете смело называть меня диванным аналитиком, что поделать.
Вы про разделение HAL и непосредственно логики рабочей задачи слышали?А что в моём комментарии заставляет вас думать, что нет? Отсутствие единой ардуины для всех микроконтроллеров? Как вы себе представляете единую реализацию, например, векторного управления бесколлекторным двигателем для кардинально разных архитектур, с разной битностью и наличием или отсутствием FPU (впрочем, как и любых других аппаратных блоков, которые, порой сильно влияют на общую производительность всего алгоритма)? Нет, можно, разумеется, такое написать. Но зачем? Не будет ли максимально адаптированная под конкретную архитектуру реализация намного более продуктивной, чем луковичный монстр, завернутый в тонну обёрток? Всё же, надо делать поправку на область применения и ограниченные ресурсы. Иначе мы придем к тому, что в каждом чайнике, для того, чтобы сделать приятную подсветку нагревающейся водички будет стоять четвертая малина. Зато да, зато код будет универсальный, репозитории с менеджерами будут и вот это вот всё.
Не надо тут ложной дихотомии про четвертую малину.Что, простите?
Ну вот есть, например, github.com/search?o=desc&q=modbus&s=stars&type=Repositories Вам от этого сильно легче стало? Чтобы эмбеддеру было удобно, нужна ровно одна среда разработки (IDE, называйте как хотите), в которой будут писать все под всё. Наверное, раз такой единой (кто сказал эклипс? гусары, молчать!) среды нет, значит нет и рентабельной потребности в ней. Либо проблема еще глубже, чем кажется на первый взгляд.
отсутствие удобных инструментов и подходов… вместо очередного изобретения велосипедов… отличительная особенность embedded-тусовки… лично он-то точно сейчас сядет и напишет свою свою собственную реализацию как надоДа где оно, где это чертово отсутствие? Удобные инструменты есть? Есть, причем они развиваются. Подходы есть? Есть. Если этими подходами и инструментами какой-то Вася пользоваться не хочет, это не означает, что все остальные Васи такие же. Вы меня обвиняете в ложной дихотомии, а сами безосновательно постоянно скатываетесь в необоснованные обобщения. При этом в этом же топике уже приводили историю с ораклом и говнокодом. Но нет, это ведь другое.
Система управления ЧПУ станком NC-210 подойдет?
за «своё» выдают чужое,Вам, видимо, не знаком термин «адаптация». Это нормальный процесс и бизнес, пользующийся этим, совершенно не обязан лично перед вами отчитываться, что они адаптировали, а что разработали сами с нуля. Это нормальное явление в современном мире. Или вы думаете, что те же ноутбуки производит только условный леново и асус и нет OEM производителей, готовых слегка кастомизировать свою платформу под ваши задачи и наклеить на неё ваш шильдик?
Не недо приписывать собеседнику свои выдумки.Этим как раз всю дискуссию вы занимаетесь.
по документам все чистоЯ не собираюсь спорить, что нечестное выдавливание с рынка конкурентов под видом импортозамещения это хорошо. Нет, это, безусловно, плохо. Есть такая штука как 719-е постановление. И да, это проблема, что оно написано как написано и перекрасив корпус можно выиграть тендер, а с другой стороны потерять финансирование разработки. Значит не надо ориентироваться только на госзаказ. Это вообще такая себе палка о двух концах. Вроде как стабильные деньги, а попробуй сделай что-то не так или не в срок, так прилетит, что потом можно и не встать.
Менеджера пакетов - это прям вот чтоб для всего на свете и под разные МК и для общения с разными микрухами разных производителей?
У нас например есть всякие заготовки к часто используемым микрухам (например, какие-нить флешки) и бутлоадеры, да и мигалка светодиодами с кучей настроек... правда, так совпало, что репозиторий создал я, и некоторые товарищи сразу присоединились потому что это просто давно назревало. И да, какие-то готовые решения приходится выдёргивать из старых архивов =)
И кстати, не только С использую. У меня ещё прилично времени уходит на питоний код (как правило, для стендов, ну и всяких утилит).
Да, приходится пользоваться осциллографом и микроамперметром. Значит я ещё и эникейщик... И алгоритмист. И интегратор. Хм.
А как вы считаете, что бы в эмбед-разработке появился менеджер пакетов и общий репозиторий - надо ждать его появления или есть ещё какие-то варианты?) Мне просто интересно, что должно произойти, что бы он появился. Это вообще реально? Его ведь не может создать человек, работающий на предприятии и пишущий код для предприятия. Или может?
Общий GIT репозиторий для всех программистов МК был бы хорошим делом.
Просто репозиторий без работающего поверх него Jenkins(а) и юнит тестов это мусорное ведро.
Чтобы появился такой репозиторий нужна коммерческая организация, которая будет поддерживать репу валидной. Т.е поддерживать на плаву сборки и тесты. Добавлять популярные драйверы чипов, программные компоненты. Проводить аналитику.
Там должны быть штатные программисты. Каждый пользователь репозитория должен будет платить ежемесячные взносы.
За подписку программист получит доступ в чтению и записи репы, что ускорит его разработки, где бы он не работал.
Программисты микроконтроллеров, как правило, никогда не числятся как штатные программисты.
В большинстве российских организациях у вас, как программиста MK в трудовой книжке будет написано обыкновенно “инженер”.
Компании PФ, которые делают электронику и нуждаются в System Software даже официально не состоят в реестре IT компаний.
Поэтому программистом вы будете считать себя только сами и никому не сможете доказать, что вы программист, если программируете MCUшки.
Программисты микроконтроллеров, как правило, никогда не числятся как штатные программисты.
В большинстве российских организациях у вас, как программиста MK в трудовой книжке будет написано обыкновенно “и“инженер”.
Глянул в трудовой (записи 20 летней давности, контора: "...одно из крупнейших российских предприятий в области разработки и изготовления систем управления и радиоэлектронной аппаратуры..."): техник минус программист потом (после получения диплома) инженер минус программист.
Настройка регулятора, что базовый мультиконтурник на пид, что какие-то более продвинутые, это работа не программиста, а инженера систем управления. У программистов, как правило, просто нет должной квалификации. А когда все делает человек-оркестр, то и регуляторы выглядят как курсовик по ТАУ, и качество кода вызывает вопросы.
Мы в универе на лабе настраивали PID регулятор методом Цинглера-Николсена.
https://en.wikipedia.org/wiki/Ziegler–Nichols_method
Метод Зиглера-Никольса. Предложен чуть не в 50-х ли годах 20 века. Имеет несколько вариаций и улучшений. Вот только этот метод применим, ну, скажем так, "не всегда". Иногда систему нельзя раскачивать, а иногда нельзя и раскачать. При этом - модель в матлабе и система в железе - немного разные вещи. Помехи, шум АЦП, всё это усложняет задачу поиска точек перехода через ноль и отсечения ложных переходов. Короче - для автонастройки грелки или сливного бачка - норм. А когда начинаются реально сложные вещи, с инерцией, трением, прочими нелинейностями - выясняется, что метод не применим.
Я не уверен, что понимаю, о каких физических принципах вы говорите. Регулятор это некоторое математическое преобразование входных сигналов в выходные. Для его реализации, программисту не сильно нужно понимать, из каких принципов были получены итоговые формулы. И уж точно не обязательно уметь получать их самому.
не сильно нужно понимать, из каких принципов были получены итоговые формулыТ.е. это не программист, а кодер? За него кто-то рисует алгоритм, составляет формулы, которые тот просто переводит с условной бумаги в машиночитаемый язык. Так?
А насколько глубоко вы понимаете те формулы, которыми пользуетесь?Зависит от конкретной области. Что-то мне представляется понятным чуть лучше, что-то чуть хуже. А что-то вообще темный лес. Но я ж не программист, я с этого когда-то начинал, потом ушел полностью в железо о чем не жалею ни разу. Просто постоянно взаимодействую с программистами и вижу, как и что они делают (или пытаются).
не помнит какую-нибудь теорию мерыИ это не делает им чести. С другой стороны, количество знаний, необходимых для решения конкретной задачи конкретным инструментом зачастую весьма мало и ограничено.
Но я же о другом, я же говорю о конкретной реализации чего-то. Как можно написать регулятор, если тебе не известны особенности архитектуры микроконтроллера, особенности периферии, особенности объекта управления? Будет какой-то сферический регулятор, который кто-то (как там комментатор выше его назвал, инженер систем управления?) будет вынужден приспосабливать к реальному железу, сиречь, менять коэффициенты, настраивать ограничения.
А насколько глубоко вы понимаете те формулы, которыми пользуетесь?
А всегда ли это надо — понимать на глубоком уровне?
А то вот мне вспоминается физик и электротехник по фамилии Хэвисайд, живший примерно полтора века назад. Он тогда для решения дифференциальных уравнений изобрел некое символическое исчисление, основанное на интегральных преобразованиях. Причем интегралы в этих преобразованиях, с точки зрения тогдашней математики, могли просто не существовать — но исчисление при этом работало как надо, вопреки глубокому пониманию, точнее — невозможности такового.
Потом, конечно, математики придумали, как эти свои интегралы и все такое прочее определить получше, но это было уже решение проблем математиков: инженерам оно для работы не требовалось.
Где первый запуск устройства делают программист и схемотехник совместно
В разработке приборов на микроконтроллерах постоянная конфронтация между программистами и схемотехниками.
В провалах схемотехники обвиняют программистов, a программисты - схемотехников.
Какую бы хорошую прошивку Вы не написали, схемотехники непременно назовут её "галимой прошивкой". И как бы ни старался схемотехник его электронную плату программисты назовут "мертворожденная PCB"
Это просто классика жанра и норма жизни к которой уже все привыкли.
люди, знайте, есть в России такие компании, где всё хорошо с разработкой.
Вы описали существование не программиста микроконтроллеров, а эникея, человека-оркестра, к которому, зачастую, и отношение соответствующее. Печально, конечно, что озвученные вами вещи существуют, но мне представляется, что такой бардак присутствует не только у нас.
У германцев есть великолепная культовая народная песня. Называется Was wollen wir trinken. Помимо великолепной музыки там есть три показательных куплета.
1 как мы выпиваем вместе,
2 как мы работаем вместе
3 как мы воюем вместе.
А у нынешних русских программистов всё с точностью до наоборот.
Русские работают по одиночке, воюют по одиночке и по одиночке пьянствуют.
>Я по молодости думал, что это наша отечественная специфика, но нет - говнокод в embedded - явление, увы, интернациональное.
конечно интернациональное, но imho далеко не embedded specific, зависит скорее от стандартов проекта, компании и пр (или отсутствия таковых), но embedded systems имеют особенность, ими интересно заниматься там где делают новое hw, а не копируют чужое, соответственно опыт в разных странах сильно отличается, про важность работ над embedded sw, говорить много не требуется, большая часть сети держится на таких системах, interconnect так близко к 100%, где был написан код хорошо известно, можно ли назвать его типа говнокод, думаю что нет, хотя конечно немного есть и этого,но как правило в части ui (видеть приходилось), насколько сложное там sw - достаточно сложное, у большого router процессоров до нескольких сотен, количество сообщений между ними зашкаливает, и т.д., далее embedded для сетей это типа верхушка айсберга, все что плавает, летает и ездит управляется embedded systems, соответственно там где это производится отношение и к технологии, и к программистам сильно отличается от описанного в статье, про уникальные системы реального времени вообще разговор особый, ввиду их важности и сложности разработки, примерно так, как обычно imho
… и надо будет вкуривать очередную схемотехнику на 30-60 страниц. А схемотехники даже блок-схему не нарисуют, сразу дают в лучшем случае Э3 а в обычном случае и вовсе принесут плату без доков и скажут, что надо ее оживить.
Очень жизненно)
В программировании мк на ассемблере есть особый кайф, например когда считаешь такты при общении по протоколу 1-wire
не надо считать такты 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.
C17 и C2X такие:
Учитывая, что даже C11 на практике используется в исчезающе малых количествах — вполне справедливая на практике точка зрения.
Вам так нужен национальный текстовый редактор?
Национальный текстовый редактор нужен, чтобы была гарантия, что исходные коды российских компаний не утекают через TCP сокет в здание с пятью углами.
Дело не только в том, что ПО песочницы и брандмауэра точно так же неверифицируемо на практике, но и в том, что если если существует легитимыный канал обмена информацией для редактора, то по нему, вообще говоря, можно передавать любую информацию, пользуясь методами стеганографии.
В общем, приходим к общеизвестному (AFAIK) выводу: обеспечение безопасности — это процесс, а не однократная настройка.
Ну, а дальше все зависит, конечно, от модели угроз. Я лично для себя, например, поскольку в мою личную модель угроз не входит угроза утечки информации в NSA или ФСБ/СВР, особо по жизни ничем таким не заморачиваюсь.
Этот «легитимный канал обмена» в лучшем случае будет идти только до git-сервера
Т.е. появляются ещё компоненты, надежность которых тоже надо обеспечивать. Ну и атаки на цепь поставки ПО становятся возможны.
Короче, ещё раз повторяю: обеспечение бескомпромисной безопасности — это, в общем случае, процесс, сложный и дорогой.
Нужен ли он в этом конкретном случае — я это сказать не готов, потому что соответсвующая модель угроз мне неизвестна. Потому думаю, что обсуждение надо завершить: на потенциальную опасность простых решений на «свободном» ПО я уже указал, а оценить ее прямо для конкретного для конкретного случая с ходу не могу, а необходимый для этого углубленный анализ не считаю своей задачей.
Навыки программирования на С очень слабо конвертируются
В программировании MCU сложна не только внешняя миграция в другие профессии, но также сложна и внутренняя миграция на другие микроконтроллеры.
--Те кто разобрался с AVR запутается в STM32.
--Те кто отлично программируют STM32 скорее всего не смогут сделать то же самое на nRF5340.
--Техасские микроконтроллеры СС26x2 это вообще отдельная вселенная со своей собственной экосистемой разработки.
--Китайские ESP32 потребуют от вас выучить систему сборки ninja.
--Разработка под PowerPC SPC58NN потребует от вас доскональное знание make.
--Разработчикам nRF5340 придется отказаться от всего и забыть все, что они знали ранее и освоить компиляцию через деревья устройств (Device Tree).
Каждый вендор микроконтроллеров (Atmel, ST, Миландр,НИИЭТ,TI,Atmel,Infineon Technologies,Microchip,Nordic Semoconductor,Renesas,Silicon Laboratories) предлагает свой ни на что не похожий ToolСhain и свою систему сборки со множествами костылей.
Программистам микроконтроллеров при переходе на другого производителя микроконтроллеров приходится фактически заново учиться ходить.
В программировании микроконтроллеров даже Senior может стать Junior(ом) в один день.
В программировании МК трудна также миграция на другие проекты так как там везде взяты за основу разные RTOS(ы).
Если вы senior в FreeRTOS с 10 годами опыта за плечами, то при переходе на TiRTOS вы мгновенно превратитесь в Junior(а).
Если вы senior в TiRTOS с 15 годами опыта за плечами, то при переходе на RTOS Zephyr вы мгновенно снова превратитесь в Junior(а).
Поэтому в программировании микроконтроллеров Senior может на следующий день стать Junior(ом) и это обычное явление.
В профессии программист MK развитие и экспертиза обнуляется каждые 2-3 года.
Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров. Хлам на столах с горочкой.
Хлам не на столах, а в голове. Только и занимаюсь тем, что программирую микроконтроллеры. Отличное, стильное, высокотехнологичное и удобное окружение. Работать удобно и приятно.
И вообще статья оставляет какое-то гнетущее безысходное впечатление — до прочтения статьи был уверен, что программирование микроконтроллеров это самое интересное и увлекательное дело на свете.
до прочтения статьи был уверен, что программирование микроконтроллеров это самое интересное и увлекательное дело на светеИ что, неужто эта статья пошатнула Вашу уверенность? )
Вспомнил еще шестой плюс работы программирования микроконтроллеров.
Если Вы программист-микроконтроллеров, то у Вас будет большой выбор в том какое себе завести хобби. У вас будет достаточно знаний умений и навыков (ЗУНов) чтобы сделать свой радио управляемый самолётик, умный дом, CNC станок на балконе и прочее в этом же роде.
У вас не будет вопроса как провести выходные, отпуск или гос. праздники.
Родственники и знакомые будут вас называть Кулибиным, Ползуновым или Левшой.
Хобби будет, пожалуй, единственной радостью в вашей жизни.
Сколько программирую МК и что я, что моё окружение, всегда использовали Форт. А также просто знакомые "коллеги" по программированию МК, что российские, что зарубежные так же предпочитают его использовать. С и уже тем более С++ где-то далеко.
Йоды джедаев магистра речи тайна раскрыта — на Форте просто старый программер он есть
Forth, конечно, хорош - но вот скопи-пастить более менее серьезные библиотеки неоткуда.
Все сами, девочки.
Уважуха! Видно человека, начинавшего примерно в одно со мной время, и говорящего знакомые слова :-)
Но интересно, какова у Вас предметная область? Далеко не большинство FORTH сейчас используют, конечно. И далеко не все имеет (экономический) смысл на FORTH'е сейчас писать. Попробуйте Zigbee или LoRaWAN устройство, например, реализовать...
Да и программы простые.
В условиях перехода на отечественные микросхемы, у нас происходит уже много лет следующая ситуация. Например, нужен вычислительный модуль. Что он должен делать? Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей. Смотрим, из чего такое можно сделать на отечественной базе да ещё с пятой-девятой приёмкой. И окажется, что ничего такого особо и нет («Эльбрус» чем-то не подходит, уже забыл чем именно). Зато есть продукция миландра типа 1986ВЕ1Т или 1986ВЕ92. Ну и, например, убожество типа 1867ВЦ6Ф есть. Вот набор этих штук и будет заменять собой компьютер. И программа простой не будет, не ждите. :) Это не переходник. Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом. То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.
Вы забыли ещё про НИИЭТ К1921ВК01(028/035)Т. Потом есть ещё Элвис.
А что можно, всё такого же уровня. А заменить надо по сути ПК. Вот и извращаемся.
НИИЭТ как раз можно. У них военная приёмка
Есть 2 версии. Одна в пластиковом корпусе, другая металлокерамика - https://niiet.ru/product-category/chips/microcont/risc-32-bit/
Без 'К' как раз металлокерамика
Тогда Байкал, если у них есть металлокерамика.
То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.
Примеры "наших реалий" можно? А то недавно ковырял "забугорную железку", так там на удивление:
Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом.
Т.е. куча "убогих" МК висящих на шине типа arinc/1533, каждая что то считает и чем то управляет.
Ну и, например, убожество типа 1867ВЦ6Ф есть.
Это ж tms320c3x, вполне нормальный камень. Собсно на нем вполне себе реализуется:
Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей.
Примеры «наших реалий» можно?
Не понял вопроса. Я работаю в ВПК (корабли, космос и РВСН).
А то недавно ковырял «забугорную железку», так там на удивление:
Ну, у нас вот так просто не получилось в силу специфики технического задания. И автоматика с графом переходов такая, что без пол-литры разобраться очень непросто.
Это ж tms320c3x, вполне нормальный камень.
Это — привет из 80-х. А в подарок древний компилятор С с 40 битными типами данных (да, char — 40 бит) и своей собственной системой хранения float и double. И достаточно низкая частота.
Собсно на нем вполне себе реализуется:
Всегда интересовало, как можно подобное утверждать, не зная специфики задачи? :) Когда у вас частота обработки десятки Гц и матрицы 28x28 это уже не так просто реализуется. Поэтому у нас в системе четыре процессора, объединённых двухпортовым ОЗУ.
Всегда интересовало, как можно подобное утверждать, не зная специфики задачи? :)
Ну собственно об этом и речь. Что то вполне реализуется на "привете из 80-х".
40 битными типами данных (да, char — 40 бит) и своей собственной системой хранения float и double.
Насколько помню 40 бит - внутреннее представление числа с ПЗ (32-мантисса, 8-порядок, формат отличается от IEEE754), но разрядность ШД - 32 бита и при сохранении/чтении в/из ОЗУ 40 бит конвертируются в 32 (мантисса обстригается до 24). Про 40 битный чар - не знаю (до си не добрался, кодил это чудо на асме), но что то мне подсказывает что с такой организацией памяти это не так.
Что то вполне реализуется на «привете из 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.
Вся таблица вот такая:
Пардон, наврал. Не 40 бит, а 32. 40 — это long double.
Во, вот это уже похоже на правду.
Когда у вас частота обработки десятки Гц и матрицы 28x28 это уже не так просто реализуется.
Перемножение матриц типа float/double 28х28 при их размещении во внутреннем ОЗУ и функции размещенной во внутреннем ПЗУ займет примерно 1мс (для тактовой 20 МГц), если на асм-е наваять соответствующую функцию (умножение с накоплением+повтор 28 раз). Если множить типы long double то производительность упадет в разы, так как требуется двойная загрузка каждого множителя, если long long double (48 бит на мантиссу) то все станет еще печальнее, т.к. там добавятся потери на вызов библиотечной функции арифметики расширенной точности. Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
Во внешнем подключённом ОЗУ (1 Мб) они лежат, если не память не подводит. Тип у них float. Да, все операции делаются на Си (делал бы на С++, но компилятора-то нет).
Во внешнем подключённом ОЗУ (1 Мб) они лежат, если не память не подводит.
Из внутреннего в два раза быстрее читается/пишется.
Да, все операции делаются на Си (делал бы на С++, но компилятора-то нет).
А причем тут плюсы? Код писаный что на плюсах, что на Си врятли выдаст на выходе специфичные инструкции, которые могут выполнятся параллельно (MPYF3 || ADDF3). Для реализации подобных вещей пригоден только асм, благо писать на нем немного - несколько библиотечных функций.
Из внутреннего в два раза быстрее читается/пишется.
Работает и ладно. :)
А причем тут плюсы?
А плюсы тут при том, что программа вообще на этих самых плюсах была бы не в пример лучше организована, чем на голом С 87-го года. Специфических инструкций я от них, разумеется, не жду. Но большим плюсом было бы само наличие компилятора с плюсами. А его нет и никто делать не будет.
Работает и ладно. :)
Ага, только чего ж Вы жалуетесь на низкое быстродействие? По мне погромист МК как раз и занимается тем что выжимает из железяки максимум.
А плюсы тут при том, что программа вообще на этих самых плюсах была бы не в пример лучше организована, чем на голом С 87-го года.
Это уже вкусовщина. Мне вот лично больше нравится Си :)
Ага, только чего ж Вы жалуетесь на низкое быстродействие? По мне погромист МК как раз и занимается тем что выжимает из железяки максимум.
Выжимать максимум имеет смысл, когда вы буквально на грани. Но если у вас от грани далеко, то хоть выжимай, хоть не выжимай, результата вы не достигнете.
Но если у вас от грани далеко, то хоть выжимай, хоть не выжимай, результата вы не достигнете.
Если я правильно понимаю то нужная производительность достигнута применением 4-х МК, и при этом главный пожиратель процессорного времени - работа с матрицами 28х28, которую можно ускорить минимум в два раза.
Т.е. "выжав из камня все" число МК можно сократить вдвое, и вместо двух "двухядреных" поставить один двухядреный, а это вполне себе достижимая такая грань и смысл, глядишь и межпроцессорная логика взаимодействия упростится.
Но из вот этого:
Работает и ладно. :)
Напрашивается нерадостный вывод о том что сделано в стиле "и так сойдет", даже не задумываясь об оптимизации. А че тут мучаться, дайте мне 1.5ГГц х 4 ядер и 4ГБ вот тогда точно заработает.
Напрашивается нерадостный вывод о том что сделано в стиле «и так сойдет», даже не задумываясь об оптимизации.
Не стоит просто так нарушать принцип KISS. В данном случае извращения с ассемблером начинать рано. Ещё есть запас в имеющейся системе (а вот запас 50% должен быть всегда, когда всё может поменяться в процессе разработки изделия).
Да и не факт, что в два раза увеличится бустродействие.
При размещении матриц во внутреннем озу - должно увеличится, к нему доступ дважды за такт.
Компилятор, конечно, древний, но вряд ли код простых циклов умножений и сложений сделал неоптимальным (кстати, компилятор асмовский код создаёт как промежуточный и его можно посмотреть.).
Нужны еще исходники, а так мало ли как чего написано. Шмат сгенереного кода перемножения матриц на асме я бы глянул с удовольствием :)
а вот запас 50% должен быть всегда, когда всё может поменяться в процессе разработки изделия
Нафига? 20-30%, не больше. Иначе получается что второй двухпроцессорный летает пассажиром.
Плюсом алгоритмика и математика после выхода на опытные образцы существенно уже не меняется, и куда девать этот "запас" в половину мощности?
Нафига? 20-30%, не больше. Иначе получается что второй двухпроцессорный летает пассажиром.
Потому что задача такая… неопределённая. :) Эти модели лет по 30 разрабатывают и дополняют.
Плюсом алгоритмика и математика после выхода на опытные образцы существенно уже не меняется, и куда девать этот «запас» в половину мощности?
Вот как раз после опытных и меняется. Начинается литера О и её доработки по результатам. Разработки ведутся десятилетиями. А вот потом… раз и полетела. :)
Стало интересно, а зачем вам обращение матрицы?
> Когда у вас частота обработки десятки Гц
это довольно типично, мало кто знает что у первой серьезной системы на Q7 рабочий цикл был 17 сек, большое количество усилий было потрачено, чтобы в него уложиться, первые сборки требовали раза в три больше времени для рабочего цикла, хотя все критическое было на ассемблере
там дофига математики
Всегда есть вариант спаять математику на операционниках 140УД1 по справочнику Горошкова :)
А можно взять керамическую подложку и запилить гибридный модуль с плёночной пассивкой и бескорпусными ОУ. И вот тебе "вычислительный модуль", который любой Эльбрус сделает как стоячего :) Правда, и считает приблизительно....
Блин. Если бы не возраст 50+ - это классная задача. Систематизировать, программировать, устранять баги и прочее.
Я прямо вижу пачку статей и диссеров.
"Разработка планы интерфейса для снижения внешних воздействий", когда на любую плату навешиваешь защещенные от статического электричества и наводок повторители интефейса и эта плата универсальна.
Учебник "Систематизация процессов программирования контроллеров" - кстати, если разобраться с монетизацией - можно сделать альманах статей Хаброжителей.
Сайт "Пополняемая библиотека программных блоков"
Еще в программировании микроконтроллеров часто мешает дребезг контактов.
Особенно в высокочастотных интерфейсах как I2S, SPI, A2B, PDM, SWD.
Можно неделю искать ошибку в коде, когда как на самом деле пластмасска перемычки упиралась в разъём под не тем микро углом и шип железки банально касался контакта каждый второй-третий бит в clock(е).
По необходимости приходилось программировать под PLC Twincat от фирмы Beckhoff. В принципе, штука весьма продвинутая, есть и своя IDE, основана на Visual Studio, и свой ооп-язык ST (очень напоминающий Паскаль).
Это, конечно, не полноценный bare metal, основная боль была в другом и скорее решалась обратная проблема - надо было расширить функционал, написанный бывшим явистом в довольно странном стиле. И речь шла скорее об удалении ООП из кода, где оно было абсолютно не к месту.
Делал красно-черное дерево для СКУД :D - база ключей в еепром 24C, оперативки не требуется много.
В целом - все так, как описано. На удаленке 10 лет, если бы была конкурентная зарплата, то и из Таиланда +- можно было бы в целом. Но если бы да кабы...
Из Таиланда сейчас как раз проще за конкурентоспособную зарплату с микроконтроллерами возиться. Платят прилично люди из "недружественных стран", в РФ фиг заказчик сейчас что сможет переслать. И раньше-то было не всегда просто, честные люди честно писали, что посылают, например, медицинскую технику, когда посылали прототип какого-нибудь пульсоксиметра. И таможня радостно взводилась, и FedEx отправлял все обратно, и посылали снова, но уже как "выставочные образцы" чего-нибудь безобидного. И месяц уходит в никуда на все на это...
когда посылали прототип какого-нибудь пульсоксиметра. И таможня радостно взводилась, и FedEx отправлял все обратно, и посылали снова, но уже как "выставочные образцы" чего-нибудь безобидного. И месяц уходит в никуда на все на это...
Прототипы это вообще больная тема.
В программировании MCU с Вас будут спрашивать за функционал прошивки. Однако для разработки и отладки функционала прошивки нужен прототип. Схемотехники будут отказываться делать для Вас прототип под предлогом, что они не хотят покупать примочки для прототипа. В фэнтези-мире схемотехников клей, гвозди и синяя изолента - это лучшее решение всех задач.
Поэтому вам как программисту МК также придется заниматься конструированием прототипов самому. Это черчение конструктива прототипа, договоры с производством конструктива, покупка крепежа. Кто хоть раз делал прототипы, тот знает, что тут много нюансов. И на это будет уходить много времени.
Как следствие на разработку функционала будет оставаться мало времени.
Да нет, прототип схемотехники сделают - надо же им свои косяки исправить перед запуском в серию. Но они норовят отдать вам его только за день до срока готовности изделия, в аккурат чтобы вы успели их косяки найти. И если вы упустили этот момент при планировании - вам реально придётся лепить макет самостоятельно.
Прикольная статья. Тем, что первую треть я, читая, возмущался и негодовал описываемой безнадеге. А далее, вспоминая своё, очень плавно осознал что, на самом деле все так и есть :)
В целом, я со всем согласен и такой порядок вещей меня более чем устраивает. Ничто меня так не расслабляет как трассировка печатных плат, моделирование в SOLIDWORKS и программирование МК. Да и отладка электроники не сказать что раздражает. Одна беда - говорят, что в фирмах за такую работу денег платят мало, таксистом можно больше заработать. Но тут всегда можно поднабраться опыта, посмотреть чего людям не хватает и попробовать запустить свой проект.
Кстати, а чем плох С? Тем, что позволяет выстрелить себе в ногу? Ну так, может, тут стреляющий в ногу сам виноват? И динамическая память ладно, данные разных размеров бывают, но наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
наличие сборщика мусора разве не означает, что программиста заранее считают идиотом, не способным убрать за собой?
Время программиста стоит слишком дорого, чтобы тратить его на уборку мусора.
Изначальный посыл верен. Но такой подход сильно развращает, приводит к раздолбайству, пофигизму и тормозному говнокоду. Ошибки при этом, как правило, никуда особо не деваются, просто совершаются в других местах из-за снижения общей дисциплины.
Embedded говнокода не прощает. Некоторую неоптимальность - да, но говнокод начинает плохо работать сразу и заставляет себя исправлять.
А сборщик мусора, запускающийся при определённом положении звёзд на небе не менее непредсказуем, чем ошибки работы с памятью. Да и кто знает, как поведёт себя сам сборщик мусора и нет ли в нём скрытых ошибок.
Да и кто знает, как поведёт себя сам сборщик мусора и нет ли в нём скрытых ошибок.
Да и кто знает, как поведёт себя сам компилятор и нет ли в нём скрытых ошибок.
Да и кто знает, как поведёт себя сам процессор и нет ли в нём скрытых ошибок.
Да и кто знает, как поведут себя сам конденсаторы и нет ли в них скрытых ошибок.
Недостаток С:
1) В С преобразование типов делается скобками ().
Невозможно утилитой grep найти все места, где есть преобразование типов.
Кстати, а чем плох С?
нет 24-битного типа данных uint24_t, int24_t, а чипы с такими регистрами есть.
И вообще не хватает знаковых типов данных произвольной разрядности. например int7_t int13_t и т.п
Это всего лишь значит что авторы платформы поленились написать stdint.h с правильными типами к своему компилятору. stdint.h - не часть языка С.
А аппаратно подсистема памяти и процессор микроконтроллера способны работать с такими типами данных?!
Переопределения операций Вам не хватает явно, а не типов.
Есть битовые поля. А произвольная разрядность - это зачем вообще?
Да и отладка электроники не сказать что раздражает. Одна беда - говорят, что в фирмах за такую работу денег платят мало, таксистом можно больше заработать.
Чтобы компенсировать маленькую зарплату вам будут говорить: "да, зарплата у тебя маленькая, зато твою работу покажут Президенту!" Или "Этот прибор проедет на параде по Красной Площади!". Это будет, пожалуй, основной и единственный бонус, предмет гордости и бальзам на душу тебе как программисту-микроконтроллеров.
"Я водитель. Вчера добывали нефть из скважины , что бы сделать бензин и заправить машину. А сегодня делали из нефти резину, а то стёрлась уже. - Так вы водитель? Или нефтяник, химик? Или автослесарь?" У меня немалый опыт, поэтому подтверждаю. Во многих организациях практикуют такой подход. Он сложился (вероятно) исторически, когда зарождались микроконтроллеры и программистом становились электронщики. Я и сам когда-то перематывал трансформаторы, пилил напильником корпуса для приборов и т.д. Я считаю такой подход непрофессиональным. Для чего вообще разделение труда? Если программист идет на поводу у работодателя, возникает такая картина. Поэтому, моё мнение, припаять что то, есть монтажница! Посмотреть осциллографом, электронщик. Проверить на объекте, инженер по внедрению. А программист микроконтроллеров, сидит на стуле и пишет программу! Как максимум, подключает программатор к плате.
может, еще и лампочки специальный человек меняет?
Программирование микроконтроллеров это даже не профессия
Программирование микроконтроллеров это зачастую даже не отдельная профессия. В вакансиях часто пишут что нужен программист DeskTop, там куча требований типа С++, QT, Linux Kernel, и в самом конце в обязанностях приписка программирование микроконтроллеров.
Или вакансия инженер-схемотехник. В требованиях трассировка печатных плат в Altium Designer, черчение корпусов блоков, а конце приписка программирование микроконтроллеров.
Также программирование микроконтроллеров можно встретить в требованиях к FPGA разработчика: Verilog, Vivado, Qvartus и в конце программирование микроконтроллеров.
Современный российские НИИ ну никак не хотят признавать программирование микроконтроллеров в отдельную специальность.
Если вы устроитесь только программировать микроконтроллеры, то Вас оформят максимум на треть или четверть ставки.
И ещё. Я не называл бы (например) STM32 с частотой 200 МГц и "чудовищным" по размеру ОЗУ микроконтроллером. По этому, С++ в микроконтроллере не место (моё мнение), а вот в Гигаконтроллерах, возможно да.
Прошивки довольно простые программы. В них как правило нет никакого процессинга над данными. Всё сводится к тому, что надо GPIO мигнуть, кнопку прочитать, испустить PWM сигнал и прерывания по перепадам напряжений отловить. В микроконтроллерах нет нужды даже в алгоритмах сортировки.
Только не рассказывайте об этом ребятам, которые пишут прошивки для электропривода с векторным управлением; ребятам, которые занимаются анализом сигналов на DSP; ребятам, которые разрабатывают интерфейсы для нелинейных датчиков; ребятам, которые занимаются сетевыми устройствами итд итп. Не стоит транслировать свой, не очень релевантный, опыт на всю отрасль программирования МК.
Тоже самое с решениями для VOIP, и прочих сетевых устройств, уровень сложности там большой, без git будет сложно.
На госпредприятиях, да, вполне возможно, что описанная автором ситуация действительно есть.
Всё что я делал в русской электронике 10лет подряд это переходники с одного интерфейса на другой интерфейс. Маршрутизаторы, модемы, телематика, СКУД(ы), аудиосистемы. Переходники. Переходники. Переходники.
Тогда и любой браузер можно назвать переходником между сетью и монитором, а видеопроигрыватель — переходник между диском и монитором.
к примеру embox, у нас разрабатывают без git и юнит-тестов
Да, конечно, Embox изначально на системе контроля версий, просто не реально вести коллективную разработку без этого. И, да, сложность на МК уже слишком высокая и не позволяет вести разработку без этого. Как минимум решение будет не воспроизводимо и не поддерживаемо.
По unit-тестам у нас достаточно быстро появилась острая необходимость в них. А потом и интеграционные тесты и CI. Без этого уже никак нельзя в современном мире.
Странно что в статье обойден такой немаловажный вопрос как "про деньги". ИМХО, все связанное с железками в нашей стране, очень плохо оплачивается..
Вот, например, сколько лет нужно с начала карьеры, чтобы дойти до планок в 100, 200, 300к?
если брать разработчика, то в-до-февральской эре планка в 100 - это чуть ли не джун (ну реальнее джун за 70, через годик-полтора - 100), 200 - мидл с опытом в 5+ лет.. 300 - это крепкий мидл - сеньор.. Сейчас, правда, все стало хуже.. не вижу вакансий для сеньеоров с предложением выше 300к, ранее было "от"...
О получке, всем известно что она неприлично маленькая: но погрОмист может перекваифицироватся в "формошлёпство" за 2..3Х денег зачем он ест ембеддед-кактус и страдает, он же уже в айти ему ненужно никуда входить ? Что это за особенная форма религиозного страдания, кто эти мученики, и за что они рубятся ?
вникать в спеки каждой микросхемы (~1k...5k страниц) на печатной платы.
Преувеличение если и есть, то небольшое - Reference manual на STM32H745 - 3528 страниц, на STM32MP157 (в котором тоже есть микроконтроллер) - 4062 страницы. Если добавить сюда объем Datasheet - выходит приблизительно как в статье. И вникать во все это приходится.
И ещё про самую главную часть документации надо не забыть — про еррату
Часто перед тем, как задействовать часть интерфейсов, нужно сначала их выбрать. Это делается на этапе выбора микроконтроллера и проектирования схемы, и делает это программист, потому что схемотехники недостаточно хорошо знают особенности микроконтроллеров. И вот тут приходится читать про гораздо больше видов интерфейсов, чем будет применяться в итоговом коде - потому что часто одну и ту же задачу можно решить большим числом существенно разных способов, как с применением внешней обвязки, так и без. Часто на этом этапе нужно минимизировать количество внешней обвязки МК, и вычислительную нагрузку, и здесь нужно довольно хорошо понимать работу периферии, которая может быть использована.
на этапе выбора микроконтроллера и проектирования схемы, и делает это программист, потому что схемотехники недостаточно хорошо знают особенности микроконтроллеровЧуть живот не надорвал от смеха, извините. Я не знаю с кем вы работаете, но у нас мягко говоря немного не так. Решение выбирает схемотехник, активно советуясь с программистом, как ему было бы удобнее программировать железку. Плох тот схемотехник, который разрабатывает что-то микроконтроллерное и при этом не понимает, как оно внутри работает.
Чтобы быть уверенным в правильности выбора микроконтроллера, в общем случае схемотехнику нужно прочесть тот самый Reference manual на 2..3 тысячи страниц, и уверенно понять его. А, возможно, и несколько, если нужно еще определиться и с семейством МК. Пока мне не приходилось работать ни с одним схемотехником (который не был бы при этом одновременно и программистом), который сделал бы это - все схемотехники ограничивались чтением Datasheet. Действительно, выбор МК - это зона ответственности схемотехников, но сложность современных МК не позволяет им делать это без помощи программистов, если речь не идёт об устройствах, имеющих только те интерфейсы, которые хорошо стандартизированы, и аппаратно реализованы в микроконтроллере.
вы ужаснётесь если узнаете насколько прикладники этого всего не умеют.
Я точно, как прочитал, ужаснулся. Не знал, что всё проще на самом деле и из за этого не устраивался работать по специальности. Но...
такие коренные познания нужны и прикладникам, я считаю. Иначе их место (в головах людей) будут занимать околошизоидные представления.
Задачи могут поставить так: “подружить микроконтроллер и айфон”, “оживить плату”, “подружить платы”
Вот это как раз такие случаи.
Прочитал все от корки до корки...........Я люблю программировать AVR ки на языке BASCOM AVR. Для моих целей и задач вполне подходит и я им доволен. Можно написать и программу для управления электродвигателем, голосовым выключателем света в комнате, делительной головкой или поворотным столом фрезерного станка. А можно и программу управления испарителем вакуумной установки.
Статья выглядит как очередное откровение от "прозревшего" представителя поколения любителей смузи. В целом уже с первого абзаца понятно, что человек сам в программировании в общем не знает примерно ничего. Одной вот этой вот цитаты достаточно:
Навыки программирования на С очень слабо конвертируются.
Пофигу, что половина модных\молодёжных\современных языков используют похожий синтаксис и похожие концепции. Пофигу, что поняв С, разобраться с большинством других "процедурных" языков проблем не составит, т.к. уже появляется представление о том как всё работает на уровне железа. И объектно-ориентированный стиль при желании понять не сложно, т.к. это по сути переход от конкретики к абстракции, который всегда проще чем переход от одной абстракции к другой.
Ну и далее перлы один за одним. В духе "так работаю я, значит так работают все".
Всё что я делал в русской электронике 10 лет подряд это... Переходники. Переходники. Переходники.
Забавно чо уж. Послушать бы как эту же профессию этот человек опишет через десять лет (если, конечно, не сменит специальность).
Отдельно крякнул вот с этого:
Программы для МК простые
...
Всеми любимый текстовый редактор VS Code от Microsoft.
Это просто ноукомментс
> проанализировав вакансии, очень быстро обнаружит, что чистый Си вне embedded нужен от силы в паре процентов от предлагаемых проектов
кроме языка есть еще предметная область, imho по нынешним временам в серьезных компаниях смотрят именно на это, типа если писать в своем резюме про языки С, Rust, С++ и пр. то это лучше последней строкой, вместе с образованием, по крайней мере так делают, видеть хороших резюме пришлось достаточно много, лично для меня годится практически любой язык высокого уровня (включая ada и jovial) кроме lisp, про assembler конечно все иначе
смысл моих комментариев это дополнить, то что Вы написали, например один из Ваших первых комментариев ("... успевший поработать в embedded, а потом перешедший в прикладное...") вполне понятно, в первом приближении это совет держаться от embedded подальше, что соответствует духу статьи, и вероятно соответствует реальности РФ, но для тех кто предположим приложив силы окажется в US, перспективы будут другие, и если человек использует свои возможности, то искать работу будет не через упомянутые сайты, а например просто позвонив своим знакомым, так что мы говорим немного о разном, через упомянутые сайты видны далеко не все вакансии, недавно смотрел что делается в компаниях которые меня интересуют, там требования другие, при прохождении интервью действительно могут спросить про языки, инструментарий и пр. что является вероятно самой легкой частью, помню со мной такое было один раз, чтобы не тянуть собаку за хвост, просто написал фрагмент текста, и показал как именно он будет компилироваться, этого хватило, основные вопросы к профессионалу всегда связаны с тем что он сделал в прошлом, потому как люди решают насколько полезным человек может быть для проекта прямо сейчас, с этим у меня тоже проблем пока не было
ps
точности ради, ниже principal в us работать не приходилось, поэтому вероятно можно переформулировать так, начиная с principal предметная область это главное
но для тех кто предположим приложив силы окажется в US, перспективы будут другие
Невозможность Профессиональной Эмиграции
В профессии программист микроконтроллеров насколько бы упорно и усердно не работать, то всё равно не светит профессиональная миграция в развитые страны: США, Австралию, Англию, Новую-Зеландию и т.п.
Дело в том что российская, с позволения сказать, школа программирования микроконтроллеров настолько, мягко говоря, самобытная, что западные коллеги (начиная с восточной Европы и Балкан) просто не понимают и не признают инженеров-электроников из РФ как Embedded/Firmware программистов.
Там другие стандарты, другие методы работы. По-другому устроено делопроизводство. Там всё по-другому. Они не видели российских микроконтроллеров, российских электронных товаров и считают, что в России никто ничего в этой теме не умеет. Сколько бы российского опыта ни было 5, 10, 15 лет. Всё одно. Вероятно лучше с этим сидеть дома.
Даже гипотетически оказавшись в западной компании, с российским образованием и российским микроконтроллерным опытом человек едва ли сможет решить там хотя-бы одну задачу.
Западу как цивилизации проще, привычнее, удобнее и понятнее нанять программиста-индуса или программиста-иранца, чем российского Кулибина или Ползунова.
одна из самых частых и опасных ошибок сишников - подумать что "синтаксис
у языков похожий, а принципы ООП я понимаю" и переходя на C++ начинать
писать на "Си с классами"
Поэтому, переходя с си на плюсы не пишите на "си с классами", пишите на "си без классов". Не повторяйте чужих ошибок.
Пофигу, что половина модных\молодёжных\современных языков используют похожий синтаксис и похожие концепции.
О каких концепциях речь? Условия и циклы?
Psychosynthesis, а что вам не нравится в текстовом редакторе VS Code от Microsoft?
Почему большинство(см. голосование) пользуется именно VS Code от Microsoft?
Ну, для начала мне не нравится, что он после установки почему-то отжирает почти полгига места на диске, при том что это, по сути, текстовый редактор. Не знаю как сейчас, но когда я последний раз его ставил, мне пришлось ещё накинуть в систему какую-то там версию .Net просто потому что она очень нужна была этой печатной машинке. Мне также не нравится, что этот текстовый редактор независимо от того что я думаю на сей счет, со всех сил пытается быть IDE, даже там где это совершенно не нужно.
Но больше всего меня раздражает, что при всём желании этого текстонабирателя быть полноценной IDE, для того чтобы в нём были все необходимые IDE функции, в любом случае придётся ставить плагины, разумеется сторонние. А после установки плагинов оно начинает гораздо чаще глючить и медленно работать...
Почему большинство(см. голосование) пользуется именно VS Code от Microsoft?
Ну, во первых, опрос позволяет выбрать несколько вариантов. Во вторых, каким образом у вас 40% стало "большинством"? Я уж молчу о том что тут выборка всего 500 человек, да ещё в опросе зачем-то выделены такие чисто нёрдские окаменелости как Vim...
Вы в Самом Деле Хотите Стать Программистом Микроконтроллеров?