Comments 409
Для их процессов кода как будто бы не существует. О коде не говорят. Код не изучают, не анализируют. Интерес представляет только физический прприборВ
Вот это прям в точку. По СРПП софт для устройства появляется магическим образом на этапе РКД. В ночь с четверга на пятницу. И никого не волнует, что целевое устройство в этот момент существует только на бумаге! Что реальная трудоёмкость разработки изделия сейчас может на 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...
Я так понял что язык G, это нотация создания проектов в LabVIEW. Так?
Мы в универе делали математические модели в LabVIEW поверх Windows. Было очень досадно что в LabVIEW отсутствовал Sroll и Zoom схемы и приходилось компоновать схему так, чтобы она помещалась на одном экране.
Разве можно на LabVIEW синтезировать бинарь для RealTime программы под конкретный MCU?
НУ ВСЁ, РАЗ ДАЖЕ В СПЭЙСИКС ЭТО ПРИМЕНЯЮТ, СТАЛО БЫТЬ ЭТО КРУТО
Да. Потому что, к сожалению, РФ не может повторить практически ничего из того, что уже давно сделали SpaceX.
То что у нас воруют напропалую, никак не связано с практиками работы в SpaceX.
И заметьте, я нигде не писал, что там вообще ничего дельного не делают. Я лишь хочу сказать, что не всё, что используют в больших компаниях является крутой и перспективной технологией.
В РФ проблема еще в том, что нынешние русские инженеры-электроники очень-очень слабые как и система образования, что их клепает.
Наберите на YouTube отзывы на военную рацию Азарт. Она работает только на дальность 30 метров, а стоит 300k RUR. Из-за отказов рации Азарт на фронте в Украине погибли сотни бойцов. Причем рация Азарт это не единственный провал российской электроники. Парад могут продолжить ё-мобиль, йотафон, Сухой SuperJet100, Фобос Грунт.
Не согласен.
Электронщики у нас есть и сильные в том числе. Чтобы они делали всё нормально им, видите ли надо платить и создавать условия труда. А у нас до сих пор в массовом сознании уродов-управленцев (никого не хочу обидеть, но факт есть факт, основная масса топ-менеджемента у нас именно уроды) закрепился образ инженера который должен работать по 12 часов за еду. Оно и понятно, зачем платить нормальным инженерам, если можно заказать разработку у макак из Китая, или например у студентов за копейки, а остальное разворовать.
Далее - про йотафон вы просто глупость пишете, это вполне конкурентный продукт был (за исключением камеры, наверное, но тоже можно подискутировать). Два года назад, хотя он уже не производился, он буквально был самым оптимальным по параметрам в своём классе (я про диагональ), вот только его уже было не купить...
То что весь этот проект тупо забросили закрыв с убытком - вопрос всё туда же к нашему "гениальному" топ-менеджемнту. Эти скоты не могут нормальное производство организовать, ведь даже то что могли организовать у нас по тому же йотафону - делали заграницей. В целом довольно ожидаемо что его закрыли.
По Сухому не согласен в корне. То что его сделали - это они вообще большие молодцы. И он вполне нормальный, летает, не падает (тьфу-тьфу). Были прецеденты, конечно, но там, в основном, вопросы не к самому самолёту. Двигатели французские ставить на него было не очень дальновидно конечно, но по другому он бы вообще хрен знает когда в серию пошёл, т.к. наши движки на него были готовы много позже чем он летать начал. Есть у него проблемы с электроникой, конечно, я слышал неоднократно жалобы техников, но в целом подобное во многих самолётах встречается. Проблемы в конце-концов исправят, если не свернут работы по нему. Да и вообще с этим самолётом большая часть проблем как и везде, из-за тупости управленцев и повального воровства на самых верхах, а вовсе не из-за квалификации кадров. Да и вы не забывайте, что это первый самолёт такого класса за много лет пошедший в серию... до этого же у нас вообще буквально всё на металолом растаскивали лет 20, само собой на пустом месте что-то сделать было не тривиально. Тут больше вопрос в том чтоб на SSJ100 всё тут же и не закончилось. Если будут развивать, всё будет нормально.
С ёмобилем там вообще история отдельная, тут тоже мимо. Про рацию сказать ничё не могу, не знаю.
Вот TG группа в которой отмечены фейлы инженеров
https://t.me/petep_prinsiple
которые можно обнаружить в обыденной жизни.
РФ на первое месте.
Оно и понятно, зачем платить нормальным инженерам, если можно заказать разработку у макак из Китая, или например у студентов за копейки, а остальное разворовать.
Российские компании не хотят нанимать опытных программистов-микроконтроллеров. Опытные знают себе цену и у них свой почерк. Российские компании больше предпочитают нанимать вчерашних студентиков. Происходит это по двум причинам:
1—Экономия на зарплате. Вчерашнего студента легко унизить на собеседовании и склонить работать на зарплату в 25к-42к RUR в мес.
2—Научить юнца под себя. Зачастую научить малыша своим плохим практикам. Зачастую вчерашние ВУЗ(овцы) ещё не знают о таком понятии как технологии промышленной разработки ПО, поэтому в их голову можно вложить любое убеждение даже самое абсурдное, например, что передавать код проекта в *.zip архиве по почте, и сборка из-под IDE это вообще норма жизни, и тому подобное.
Эти скоты не могут нормальное производство организовать, ведь даже то что могли организовать у нас по тому же йотафону - делали заграницей. В целом довольно ожидаемо что его закрыли.
Даже если российская компания вдруг задумывает сделать примерно современное электронное устройство с BGA корпусами, PCB антеннами, то как правило это заканчивается тем, что схемотехник(и) сталкиваются с технологическими проблемами, первая ревизия плат вообще не работает.
Например из-за неправильного выбора пинов на микроконтроллере (схемотехнические ошибки), компоненты припаяны не той ориентацией, припаяны не те кварцы и в итоге экземпляры электронных плат даже не доходят до стола программиста-микроконтроллеров.
Уровень современной российской схемотехнической школы сейчас настолько низок, что о программировании и говорить порой даже не приходится. На предприятиях кроме готовых отладочных плат от вендора зачастую просто нечего программировать.
Только, внимание, четвёртая-пятая ревизия российских PCB обычно лишена детских болезней. Пятая!
Да, вот так, господа...
А что, в России ещё что-то осталось?
Боги, какой ад.
Да Вы, уважаемый, @vvzvlad сами так считали 5 лет назад
https://habr.com/ru/articles/433504/comments/#comment_19532476
очень хорошо написано. С юмором , иронией :) Спасибо.
в среднем 3е из 5ти
На этом месте завис. Упорно читалось "третье из пяти".
Прекрасный повод вспомнить Горчева, спасибо, автор, ты попал в его стиль!
И как же всё-таки приятно, что я когда-то стал тем, кто называется "инженер-электроник", сиречь "embedded-разработчик", а не "программист микроконтроллеров" )
А что по статье — ну видимо автору не повезло и этот путь не для него. Как программист микроконтроллеров (но не только их) с некоторым стажем и опытом работы как на «госзаказ», так и на «коммерцию», могу сказать, что описанное слабо соответствует действительности. Опыт в процессе работы приобретается интересный, приходит понимание как устроена как вычислительная техника на разных уровнях, так и отдельные ее части (датчики, связь и т.п.), в программировании тоже приходится решать интересные задачи связанные с ограниченными ресурсами и/или временем, частенько с погружением в математику. В общем я ни разу не пожалел об этом.
Автор явный программист малых embedded систем и говорит в основном за свою область, но есть еще средние и большие встраиваемые системы.
Автомобильные ECU я бы назвал средними системами, а не малыми, как утверждает автор
Авионику я бы назвал большими системами. В станкостроении есть малые и большие системы. Большую систему можно встретить даже в офисном печатающем центре. По видимому автор не занимался реверсом, иначе бы знал насколько еще 20 лет назад были огромными программы для мобильников Nokia или для фото-принтеров Canon, на таких мощных RTOS как Nucleus Plus и ITRON. С тех пор они стали еще монструозней.
Про то что код никто не смотрит, тоже искажение реальности. Аудит кода аккредитованными организациями - обязательный этап при получении разрешения на эксплуатацию систем с заданными требованиями к безопасности.
Утверждение о простоте программ вытекает, по видимому, из специфического опыта автора с малыми системами. Но уже в средних системах, он может встретить софт баз данных, файловых систем, GUI/HMI, сетевых протоколов, где все упомянутые им алгоритмы сортировки, поиска и фильтрации используются в полную силу. И это еще не упоминая всеобщего наступления Neural Network
Опять же код теперь не пишут только на C или С++. И малые системы и огромные ответственные системы разрабатывают прямо в графической нотации Stateflow и Simulink. На хабре куча статей про это. Есть и другие мощные графические среды.
Словом быть сейчас embedded-ом, это все равно что богом. Бил Гейтс начал свой бизнес с малых систем, в те времена не отличимых от embedded систем, Стив Джобс с компаньонами - аналогично. На процессорах Zilog делались и домашние компьютеры и станки для литья изделий из пластмассы.
Будучи embedded-ом вы единственный, кто может создать свой полностью независимый продукт от начала и до конца, от идеи до вещи. Вы не зависите от магазинов приложений, не зависите от программных платформ типа Android, которые вам могут отменить, не зависите от моды.
embedded-ы по прежнему могут взлететь легче всех прочих, причем почти в одиночку. Вспомним успех Arduino или вот Flipper Zero
>Автомобильные ECU я бы назвал средними системами ...
Ню-Ню, успехов в разработке ECU Euro 5-6.
Из массмаркета ничего сложнее уже нет, не было и думаю не будет, из-за восхода "электричек", которые в массе своей проще на порядок.
Ну а так - а что в современных блоках ECU euro6 написано на С и вручную? ;)
200 строчек проверки хеш суммы загрузчика для гипервизорного цпу? ;)
Так 4-х уровневая модель разработки блоков ( девелопмент элементрной базы->разраяботка проторипированной железки с софтом->аппликаторы->автозавод) вообще не дает доступа к коду на последних 2-х этапах ....
И малые системы и огромные ответственные системы разрабатывают прямо в графической нотации Stateflow и Simulink. На хабре куча статей про это. Есть и другие мощные графические среды.
В Российском рынке электроники есть одна любопытная закономерность.
Чем более ответственный проект и разработка тем, как не странно, проще туда устроиться на работу программистом микроконтроллеров.
Мой самый простой job offer, ( где я, к слову, накосячил во всём, опоздал на 45 минут, ничего не решил на тестовом задании), я получил в компанию, которая разрабатывает авионику для российского пассажирского авиалайнера MC-21. А самое-самое трудное собеседование в моей жизни, где меня гоняли по всему MIT(шному) курсу Computer Science было в компанию, которая разрабатывает электронную папироску для вэйперов.
Также было очень легко получить предложение работы в компанию, которая разрабатывает активные фазированные решетки для российских ударных дронов. И одновременно неимоверно сложно получить job offer в российскую компанию, которая делает офисную поилку с газировкой.
Кто-нибудь может объяснить мне, что, собственно, происходит в российской электронике?!
Неужели в США всё тоже так? Или там инженеры ВПК это техно-элита.
Всё просто — желающих работать над коммерческими проектами намного больше. Основные причины:
- Далеко не каждый российский программист хочет участвовать в создании российского оружия, учитывая то, для чего оно сейчас применяется. Основное назначение разработки собственной российской авиации, даже пассажирской — тоже военное.
- Любому программисту важно поддерживать востребованность своих навыков на рынке труда. А в сфере с госзаказами идёт тотальный переход на российские микроконтроллеры, которые вне этой сферы нигде не востребованы, а через пару лет могут быть вообще забыты.
- Над чем в коммерческом проекте работает один человек, над тем в военном проекте должно работать трое — чтобы они контролировали друг друга. Причём эти трое часто лично не знакомы. Соответственно ниже эффективность, ниже зарплаты, но при этом ниже и ответственность каждого, соответственно ниже и требования. Ведь та же электронная сигарета может взорваться и искалечить или даже убить человека — это серьёзная ответственность. Хотя, конечно, возлагать её на ПО и программистов неправильно, но так бывает.
- Над коммерческими проектами часто можно работать удалённо, даже программисту микроконтроллеров. Особенно такими, как электронная сигарета. Это особенно актуально сейчас, когда множество программистов вынуждены были спешно уехать из России из-за своих убеждений, но многие из них предпочитают работать с российскими компаниями. Но и вообще, возможность работать из Таиланда зимой многого стоит.
- Военные проекты очень часто предполагают допуск к секретам, который влечёт за собой ограничение свободы передвижения. Даже если на начальном уровне этого нет, с карьерным ростом это появляется.
Далеко не каждый российский программист хочет участвовать в создании российского оружия, учитывая то, для чего оно сейчас применяется. Основное назначение разработки собственной российской авиации, даже пассажирской — тоже военное.
Ситуация осложнятся ещё и тем, что для программистов-микроконтроллеров из военных НИИ не дают отсрочку от военной мобилизации.
Дело в том, что военные НИИ и их подрядчики не числятся как IT компании. Чтобы быть IT компанией, по закону РФ надо чтобы стоимость ПО составляла что-то более 45% от стоимости всего продукта. Одновременно с этим продукты класса military hardware это как правило далеко за 50% стоимость микросхем (купленных к слову у Xilinx, Analog Devices, Texas Instruments, STm), потом стоимость разработки топологии PCB, стоимость производства PCB, стоимость фрезеровки металлического корпуса для PCB.
В итоге услуги программиста микроконтроллеров в военных НИИ на фоне общего количества оплаченных работ становятся не особо заметными.
Поэтому у программистов микроконтроллеров из военных НИИ есть реальный шанс оказаться в окопе с пластмассовой каской, БУ бронежилетом рядом с надувным ЗРК.
Над чем в коммерческом проекте работает один человек, над тем в военном проекте должно работать трое — чтобы они контролировали друг друга. Причём эти трое часто лично не знакомы. Соответственно ниже эффективность, ниже зарплаты, но при этом ниже и ответственность каждого, соответственно ниже и требования.
Тут я видел как раз наоборот. В одном российском военном НИИ один программист микроконтроллеров называл Си функции для ECU в танках именами литературных персонажей и никто его не отдёргивал от такого художества и всё попадало в релиз.
Любому программисту важно поддерживать востребованность своих навыков на рынке труда. А в сфере с госзаказами идёт тотальный переход на российские микроконтроллеры, которые вне этой сферы нигде не востребованы, а через пару лет могут быть вообще забыты
В российских микроконтроллерах от Миландр и НИИЭТ стоит всё тот же ARM-Cortex-M3. То же ядро в STM32, CC2642, NRF.
Над чем в коммерческом проекте работает один человек
Программисты MCU в России не умеют работать в команде. Да это факт... Три раза был свидетелем, как программисту МК предлагали напарника, помощника, а тот говорил:
Ой не надо. Он мне в спину дышать будет. Он мне тут всю экосистему в программе поменяет....
и т п
А по факту проблема в том, что без TDD (Test Driven Development) совместная разработка реально не работает. Вот и получается, что есть только два выхода - делать все по одиночке или делать вместе, но по TDD. Только до осознания пользы TDD в embedded России пилить и пилить ещё лет 40-50. Вот и остается всё делать по одиночке в кактус-solo режиме.
Три раза был свидетелем, как программисту МК предлагали напарника, помощника, а тот говорил:
А программисту напарник вовсе не нужен. Взаимодействие с другим программистом - это дополнительные сложности, всегда. А то, что результат получается медленнее - это не забота программиста. Программист в результате не заинтересован чисто объективно: ему деньги за процесс труда плятят, а не за результат. Реально, заинтересованные лица тут - владельцы бизнеса и их представители - менеджеры.
А по факту проблема в том, что без TDD (Test Driven Development) совместная разработка реально не работает
Как это: везде - работает, а при программировании микроконтроллеров - нет? Что это такая специфика именно для микроконтроллеров? В своей области я что-то такого не замечал, что без TDD никак. Вполне программировал совместно ещё в те времена, когда о TDD и слыхом не слыхали. Правда, не для микроконтроллеров, а для десктопов, на Delphi.
Неужели для микроконтроллеров нельзя найти способ организации разработки подешевле? Не знаю, как там у вас в микроконтроллерах, а я тут вот развликаюсь написанием чисто самодельной библиотеки (Middleware для ASP.NET Core) в соответствии с наилучшими практиками: могу себе позволить, потому что надо мной погонщик с кнутом не стоит. Так вот для этой библиотеки полное покрытие тестами (xUnit+Moq+VS 2022) - это примерно раза в два больше кода, чем в самой библиотеке. Причем, это - с максимальным выносом общего для тестов кода в общие классы и методы тестового проекта. Я понимаю, конечно, что код библиотеки - он не простой, там куча асинхронщины и параллельщины, которую как раз и проверять надо, а тестов - наоборот простой: там копипасты с мелкими правками много. Но даже если кода требуется не в три, а в два раза больше - это IMHO дорого, слишком.
А в реальной разработке для микроконтроллеров и без TDD явно есть чего улучшать. Вон, вчера сын принес с работы историю про смежников-эмбедщиков. Он сам не эбедщик вообще-то, но с их изделиями ему приходится работать, и плотно. Суть истории: смежники сделали для них железку, и она в целом работает стабильно, но тут доработки потребовались. А с этим оказалось сложно, потому что смежники начали чинить то, что не сломалось - добавили (чисто в прошивку в новую) какую-то не особо нужнуую фичу (вроде как, со слов - запись логов в флеш-память). После чего железка через полсуток работы стала виснуть. Казалось бы, нет ничего проще - вернтуься к стабильной версии и танцевать от нее - ан нет: исходники стабильной версии продолбаны. Потому что CVS/SVN/Git/Mercurial смежники ниасилили. А вы говорите - TDD!
Потому что CVS/SVN/Git/Mercurial смежники ниасилили
Это потому что у программистов микроконтроллеров обычно начальник схемотехник. Мой бывший начальник-схемотехник вообще запрещал пользоваться системами контроля версий. Любыми. Вот его аргументация:
SVN/GIT не нужен так как у нас только один программист-микроконтроллеров.
Неужели для микроконтроллеров нельзя найти способ организации разработки подешевле?
Можно. Свои фантазии на эту тему я написал тут.
DevOps для производства Firmware
https://habr.com/ru/articles/656449/
Если коротко, то надо завести репозиторий, поверх него запустить сервер сборки Jenkins, сборку делать самописными скриптами make, HIL стенд, планерки по 5-7 мин каждый день.
не зависите от программных платформ типа Android .... не зависите от моды.
От Android не зависим - это правда.
Зато зависим от Zephyr Project, который навязывает моду использовать в программировании микроконтроллеров такие хипстерские вещи как DeviceTree, West, Yaml и прочие бантики, которые кроме Zephyr особо не нужны больше нигде в микроконтроллерах.
Будучи embedded-ом вы единственный, кто может создать свой полностью независимый продукт от начала и до конца, от идеи до вещи.
Это скорее справедливо для GameDev и то только в случае инди-разработчика.
--------------------
Embedder в одиночку максимум может либо топологию платы страссировать, либо прошивку написать для покупной отладочной электронной платы. То есть уже надо 2 спеца: схемотехник + программист.
А до готового продукта еще путь в тысячу миль.
Надо корпус (ищи пром дизайнера), производство (ищи завод + технолога), выход на рынок (ищи маркетолога).
+ Надо снять видеоролик для привлечения инвестиций (kickstarter, CroudSupply) (ищи режиcсера, оператора, продюсера и артистов).
+ надо еще прошивку обновлять через телефон (ищи Andriod и iOS разработчика).
Вот уже 11 человек набралось.
Hi-Tech по этому и называют Hi-Tech потому, что нигде больше нет такого количества этапов и набора инструментов и калейдоскопа узких специалистов как в Hi-Tech(е).
Embedder часто по образованию схемотехник, так что он может разработать плату и прошивку к ней от начала до конца. Прошивку можно обновлять с чего угодно через USB, если реализовать в устройстве USB Mass Storage с автоматической установкой прошивки при её загрузке через него. Видеоролик делается сторонней организацией, это разовая инвестиция, и можно найти не очень дорогие вварианты. С производством всё так, но производство небольшой партии некоторые разработчики с бизнес-способностями могут и сами организовать, а дальше уже можно привлечь инвестиции, и нанять специалистов.
Embedder часто по образованию схемотехник, так что он может разработать плату и прошивку к ней от начала до конца.
Когда схемотехник пишет прошивку, то без слёз на это смотреть невозможно.
Вот доказательство https://habr.com/ru/articles/555498/
Будучи embedded-ом вы единственный, кто может создать свой полностью независимый продукт от начала и до конца, от идеи до вещи.
У меня есть "независимые" знакомые в российском автопроме. Им американцы отказались продавать компилятор GHS для чипа от Samsung.
Сидят документацию читают уже полтора года. В уме фантазируют как их код будет исполняться.
Вспомним успех Arduino или вот Flipper Zero
Не знаю как в Arduino но вот fLIPPER zERO паразитировали на том, что при найме в качестве тестовых задач всегда задавали задачи из своего продакшена (backlog(а)). И получили много готового кода , схемотехники и чертежей конструктива просто на халяву.
Я репозитарий флипера смотрел. Там нет ничего интересного от слова совсем.
Типичные проекты образовательного начального уровня. Как там флипер взлетел на фоне Arduino для меня загадка.
Скорее всего он был сторонним проектом какой-то другой финансируемой темы.
Трудности описанные вами для разработки и выпуска продукта весьма условны.
Т.е. они могут быть трудностями, а могут и не быть.
Про Zephyr правильно написали. На linkedin его агреcсивно толкают. Прям как тут флипер раскручивали. На самом деле довольно малоюзабельный проект. Сродни mbed или freertos. У всех них одна беда - они все мучают эти давно вымученные lwip и fatfs как ядро своего middleware. Но на фоне открывающегося Azure RTOS с его midleware они слабы.
они все мучают эти давно вымученные lwip и fatfs как ядро своего middleware.
Что не так с FatFs? Пару раз использовал FatFs, очень понравилось. LwIP тоже понравился.
С самой fatfs все нормально. Сам использовал когда-то. И lwip использовал. Примитивны, конечно, но то что обещают - делают.
Но вот делать проекты из таких несвязанных никак между собой кусков, с разными стилями, разрозненной документацией, без поддержки плагинами в отладчиках я считаю малоперспективно. Arduino их переплюнет.
Про AVL деревья сложно возразить, а вот B-Tree во внешнем NAND, над файловой системой NAND, довольно полезен. Даже был единственным возможным решением для POS-терминала с большой базой товаров.
вот B-Tree во внешнем NAND, над файловой системой NAND, довольно полезен.
B-Tree это (Binary search tree) BST? https://habr.com/ru/articles/732442/
мой опыт 8-14 лет назад в embedded совпадает в целом с видением автора
ну и господи, какая же была ламповая конференция по МК на телесиське)
Основной язык программирования это С
Это выдается как недостаток? Непонятно чем вам так не угодил С, но даже если так, при решении задач можно и нужно использовать все возможные инструменты в зависимости от их эффективности. Например, для предварительных расчетов многочисленных таблиц (фильтры, кодирование, некоторые алгоритмы и т.п.) можно использовать python или что-то еще по вкусу. Ищите возможности.
В России программисты МК в основном работают в компаниях, которые делают госзаказ на военную технику
Это неправда. Коммерческих разработок тоже полно, просто наверное вам не повезло их найти, а может вы прошли мимо таких вакансий. Но даже если вы видите вокруг только госзаказ, всегда можно посмотреть на иностранных заказчиков, уж там работы по контроллерам еще больше.
Программисты МК в принципе не пишут больших программ. Размер проекта ограничен несколькими сотнями килобайт памяти Nor Flash(а).
Это смотря как считать. Сама прошивка для контроллера может занимать всего несколько килобайт, но код который ее обслуживает (и частично генерирует) — сотни мегабайт. Пример из практики: прошивка была 64К, весь проект — около 100Мб чисто исходников, причем скриптов там было сильно больше, чем кода на С/С++ (я уж молчу про всякие тесты и внешние зависимости/библиотеки и т.п.). И это была только одна прошивка, а их было в проекте пара десятков для разных модификаций железа.
Если вы программист МК, то скорее всего вы будете по уши в электронных платах. Вам придется не сколько программировать сколько исправлять разнородные аппаратные баги. Железо часто подводит.
Это отчасти так, хотя это и нельзя назвать «второстепенной работой», ведь вы делаете продукт в целом, а не только софт. Поиск компромиссов с «железячниками» — это само по себе интересное занятие помогающее глубже понять как и почему там все устроено. Тут каждому свое, мне было интересно находить баги даже в современных x86 и общаться с производителем по факту этого.
Даже не мечтайте про удалёнку из Тайланда
Все зависит от договоренности с работодателем и ваших желаний. Мелкие устройства можно брать на дом, если договориться, например. У меня опыт удаленки как раз так и начался, еще в доковидные времена.
Любое электронное устройство, которое вы будете делать скорее всего можно будет назвать одним словом: переходник.
Не повезло вам. У меня по опыту переходников было может 10-15% (обычно это всякое тестовое оборудование), остальные были вполне себе независимые вещи или с достаточной самостоятельностью, чтобы делать что-то большее, чем перекладывание байтов из одного места в другое.
Программирование микроконтроллеров это на 80-70% электротехника и только на 20-30% программирование.
Это уж что вам больше нравится и как вы себя позиционируете на работе. Даже если вы в одном лице и схемотехник и программист, то соотношение слишком перекошенное у вас. По опыту платы диагностировать приходилось конечно, но это все равно больше про программирование, чем про электротехнику. Тесты всякие, программирование КПА это все же больше про программирование тоже. Может у вас схемотехника в штате не было просто?
Для программирования микроконтроллеров надо очень хорошо ориентироваться в множестве официальных документов.
Я вам больше скажу, вообще для программирования как и для любой другой профессиональной деятельности надо уметь читать большое количество документов. При чем тут именно контроллеры — неясно.
Если у вас есть выбор и вы хотите программировать на разных языках и быть в теме классической программной теории, если вам 20..24 и вы решаете как орешки олимпиадные задачи с LeetCode и хотите использовать в работе современные и классические алгоритмы и структуры данных, то программирование MK вам едва ли подойдет.
Не согласен. Все вышеперечисленное я лично (и мои коллеги в разных компаниях тоже) делал для контроллеров. Я бы даже сказал, что разнообразие задач здесь огромное, да еще есть поправки на предельную эффективность — вот где пригодятся все знания по математике и алгоритмике. В общем, просто хочу сказать, что ищите возможности для развития, а интересная работа есть и среди контроллеров.
Это выдается как недостаток? Непонятно чем вам так не угодил С, но даже если так, при решении задач можно и нужно использовать все возможные инструменты в зависимости от их эффективности.
В Си есть вещи, которые раздражают:
--Нет 10 битного знакового типа данных,
--нет защиты пространства имен,
--нет типа данных int24_t, int13_t и прочее
--неудобное преобразование типов скобками неудобно grep(ать),
--нет встроенных в язык абстрактных типов данных,
--абсолютно ненужный оператор >, когда уже есть оператор < и можно использовать его поменяв местами операнды и прочее.
Мелкие устройства можно брать на дом, если договориться, например.
И программировать под шум перфоратора соседа сверху, и сбоку.
Может у вас схемотехника в штате не было просто?
Есть, чтобы он что-то починил программисту приходится объяснить схемотехнику всё максимально подробно и понятно, что именно на PCB не так, вплоть до того что именно отпаять, а что заменить.
И поиском реальной причины неисправности занимается как раз программист микроконтроллеров, так как программист понимает и схемотехнику и софт.
В то время как схемотехник понимает только схемотехнику, а о софте знать ничего не желает.
Тут каждому свое, мне было интересно находить баги даже в современных x86 и общаться с производителем по факту этого.
Как вам такой баг в программировании микроконтроллеров?
При включенном переходнике USB-CAN автомобиль не заводится. Стартер работает, но зажигания (вспышек в цилиндрах) не происходит. Разобрали половину впускного коллектора. Три часа искали причину поломки. Оказывается в OBD-II разъем попал кусок фольги от папиросок, которые замкнули три крайних пина.
Поймете одну вещь...
В программировании микроконтроллеров баг может быть вообще даже не в коде! И даже не в железе!
А просто где угодно, как вот тут.
В этом случае багов, похоже, несколько - в архитектуре системы, и в схеме подключения диагностического разъёма. Неработоспособность CAN не должна приводить к неработоспособности двигателя, а любые механические повреждения диагностического разъёма не должны приводить к неработоспособности системной CAN.
В программировании микроконтроллеров аппаратные баги просто поражают своей тупостью.
Вот например, плохая была идея насадить этот WSON ASIC на эту универсальную макетку.
Прозвонил DMMом. 5й 6й 7й 8ой пины коротко замкнуты.
Видимо 9й контакт теплоотвода наполз на 5й 6й 7й 8ой пины.
Причем программист-микроконтроллеров два дня искал ошибку в коде драйвера SPI.
Вот так....
Теперь надо сдувать чип.
программист-микроконтроллеров обязан уметь работать с тестером и осциллографом, тогда вот такие аппаратные баги не будут на 2 дня выводить из строя программиста. элементарные вещи: убедись что нет КЗ, убедись что сигнал имеет тот уровень, которые ты выставил и так далее. да можно не знать всех тонкостей работы электроники и проектировать аналоговые фильтры на рассыпухе, но элементарные вещи уметь обязательно. не для схемотехников же придуманы логические анализаторы и прочее.
Классная статья. Ещё в России по-настоящему не любят людей которые пишут как всё а действительности плохо, ещё год назад мой комментарий о том что в 60-х годах ЦК похерила отечественную разработку микропроцессоров, решив скопировать IBM System/360 вместо того чтобы развивать свой конвейер несчадно заминусили. Зато сегодня то же самое несчадно плюсуют. Пока гром не грянет мужик не перекрестится. И что же есть у нас шанс нагнать 60 лет отставания? На счёт кодовой базы - очень верная и глубочайшая мысль. Это относится не только к C но и к C++. Кстати вы забыли ещё одну область где нужно С это параллельное программирование на GPU, разные физические симуляции, кустика, рендер
Ну, производство бывает разное.
Мы вот иногда и Asm вспоминаем, и такое бывает.
не все микроконтроллеры без багов.
тут уже всякого написали, поэтому я вкратце свои 5 копеек занесу.
У автора такой опыт. Я в России в embedded работал в коммерческих проектах, и у меня совсем другой опыт. Например большие проекты с смешанным с/с++, со сборками, CI/CD, тестами.
Я получал по ушам за попытки взять в руки паяльник, потому что "тебя как программиста наняли".
Так же я пробегал в стартапах, там тоже по другому.
Вишенкой на торте - на коммерческих проектах всегда предлагали "нормальную" зп по сравнению с инженерами-электронищиками. Уходил в 2019 со 120 в Петербурге (в команде были те, кто получал больше).
Сейчас продолжаю, но уже за пределами России, и тут тоже видение автора сильно отличается от моего.
Но у каждого свой опыт. Надо писать свой пост видимо.
как написал выше - смотря с чем сравнивать. С бэкендерами/фронтендерами да, в целом самую высокую зп у ембеддеда в 2019 я видел 180.
Про различия много написать не получится, потому как я тут сижу в одной фирме уже три года и под NDA, так в ближайшее время рассказать особо будет нельзя, только общие фразы.
У программистов PLC ещё хуже как по мне. Мало того, что практически все перечисленные проблемы те же, так еще и ниша очень узкая, языки вообще нормальным людям неведомые и нигде больше не применимые, а зарплаты совсем уж грусть нагоняют.
Если код у автора написан так же, как и опросник, то - ой.
Почему можно выбрать только один вариант?
Гм, ну, знаете, бывает всякое. Для простых приборов - простые прошивки. Для сложных - сложные. сложность необязательно в алгоритмах работы, попросту инфраструктурная сложность может быть велика. Так что это вот "МК просто программировать" - скорее личный опыт, чем система.
триггер Шмидта
А вот это просто позор какой-то для электронщика... Отто Шмитт.
Работа программиста MK происходит как правило в гаражных или около гаражных условиях. Провода. Высокое напряжение. Много какого-то металлолома возле компьютеров.
На сам процесс программирование уходит 10...20% времени. В основном приходится что-то ремонтить, разбираться с проводами. Выяснять что куда подключено, проверять осциллографом наличие электрических сигналов, проходить по чек-листу.
Можно запросто неосторожно сжечь оборудование из-за неправильно подключенного заземления. Вы обязательно узнаете как пахнут искры. Можно потратить весь день на подключение лампочки или чтения состояния зашумленной кнопки. Копаться в разъемах.
Чтобы отлаживать код его надо исполнять. Если в коде баг и нет возможности исполнить код, то баг не исправить.То, что вы пишете, больше похоже на промышленную автоматику, программирование под ПЛК. Вот это, действительно, в первую очередь — геморрой и приключения. Программирование — во вторую.
Немного контекста: на жизнь зарабатываю в «кровавом энтерпрайзе» на .NET, в свободное время пишу код для хобби проектов на этом самом «Си с классами». Понятно, что для себя можно писать как угодно, но если в embedded-сообществе сложились представления о том что такое хорошо и что такое плохо, глупо было бы не спросить.
«Си с классами» плох потому как «Си»? Да, каюсь, когда мне нужно отформатировать вывод, то часто использую старый добрый ssprintf. Начинать в 2 килобайтах памяти Ардуины пляски с операторами << как завещал дедушка Страуструп не поднимается рука.
«Си с классами» плох потому как «с классами»? Действительно, вот написал я контроллер блинкерного табло, сделал красивый класс с минимальным публичным интерфейсом, спрятал детали реализации в приватные методы, при этом внутри он выдаёт сигналы на конкретные пины. Если создать второй экземпляр того же класса, то будут конфликты с железом, так что абстракция у меня ложная. Но классы же мы любим не только за это, например, глянув на подорожавшие Arduino Nano, я быстро добавил возможность запускать код и на 8266, вынеся всю общую логику в базовый класс и переопределив лишь пару методов отвечающих за управление пинами и коммуникацию по I2C.
Так почему же у «Си с классами» такая дурная слава?
Дурная слава у людей, его использующих :-) И пытающихся выдать код на нем за полноценный C++.
А так IOKit эппловский (т.е. считай, что и почти все kexts/драйвера) на нем написан, хотя люди из Apple вроде утверждали, что это оказалось плохой идеей. Когда по уму и к месту применен - IMHO все ОК.
Я бы начал с Steve McConnell, Code Complete/Стив Макконнелл,"Совершенный код". Не то, чтобы она была именно про Си, хотя, на глазок, половина примеров там на нем. И не то, чтобы она была исключительно про организацию кода (хотя глава или раздел с подобным названием там вроде есть). Но она как раз родом из начала 90-х, первое издание 1993, кажется. Про современный C++ он при всем желании еще не мог написать :-)
Видимо программисты МК не относятся к ленивым программистам. Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Вот почему бы один раз не сесть и не написать фреймворкВ «свободное» время, бесплатно и на благо сообщества? ;)
Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Кодогенерация для stm32 есть, скелет с инициализацией переферии накидает.
А до остального - чего мелочиться, может сразу генератор документации? На входе скан ТЗ, на выходе эл. схемы, прошивки, спецификации, герберы печатных плат :))
Я собирал MCU сборки, где код генераторами, которые из базы данных CAN пакетов (*.dbc файлы) генерировали C-функции парcеров пакетов.
Ну... видимо исключения подтверждают правило.
У нас устройства на микроконтроллерах (Cortex M3, M4, M7), более миллиона экземпляров устройств "в полях", пара десятков моделей плюс модификации. В эксплуатации три поколения аппаратных платформ, три поколения программных платформ (частично пересекаются в разных комбинациях). 80% кода - общие для всех моделей. Коллективное владение кодом, юнит тесты, ночные сборки, ревью кода, agile-подходы к разработке.
95% кода микроконтроллеров - на C, немного С++ и есть ещё кое-какая экзотика. Со стороны ПК и облака естественно, используются другие языки и технологии.
Да, работаю в РФ, секретности нет, график гибкий, в офис допустимо ездить от одного до пяти раз в неделю.
Но учитывая провокационную форму статьи, называть компанию не хочу.
Но вполне допускаю, что во многих российских компаниях всё происходит именно так, как описал автор.
А интерфейс командной строки поверх UART в ваших устройствах заложен?
В Линуксовых есть serial console для отладочного uboot и несколько сценариев использования SSH.
В чисто микроконтроллерных командной строки нет ни в каком виде. Там либо FreeRTOS, либо bare metal и лишних ресурсов нет, т. к. ввиду значительных тиражей имеет смысл заниматься оптимизацией ради экономии пары десятков центов за счёт более дешёвой модификации микроконтроллера.
ARM банит пользователей из РФ
Всегда поражало как люди, знающие все вот это, потом приходят на должность андроид разработчика и не могут сверстать вьюху так, чтобы она не вернулась из дизайн-ревью десять раз подряд. Т.е. фундаментальные знания - мое почтение, но на верхнем уровне разработка вообще не клеится.
За 2 года в этой сфере увидел, что везде может быть по разному.
Существуют типичные совковые предприятия, где всё примерно устроено как описано в статье. Основные признаки такого предприятия:
Работают в большинстве деды, очень мало молодежи.
Древнее оборудование, компы допотопные стоят с виндой хп.
Начальнику +60 лет, схемотехник, ничего не знает о программировании, испытывает трудности в обычном использовании ПК.
Низкие ЗП
Полностью сидит на выполнении гос.заказов
Дефицит хороших специалистов, с программистами вообще полный напряг.
Но и попадались новые компании, их очень мало, но они существуют. Там всё по другому:
Все сотрудники молодые, не выше 40 лет.
Уровень проектов значительно выше
Адекватный уровень ЗП, не такой как в айти, но все же
Ориентированы на свободный рынок, продукцию продают за рубеж
Цивильный офис, новое оборудование
Нет никакого дефицита кадров, работают опытные специалисты
Переиспользование кода эта боль. Я в своё время нагородил целый транслятор кода с Дельфи на си, который транслировал по разному на разные контроллеры PIC. Ну ясно он поглючивал, как любая такая поделка. Но зато позволял кое-что протестировать в среде Дельфи и даже писать с классами.
Обзор mikroPascal PRO for ARM от MikroElektronika Программирование ARM на Pascal
У прямой компиляции есть недостаток, что разработчику оного надо развивать компилятор в ногу с компилятором на Си. А при трансляторе в случае улучшения компилятора Си , повышение производительность программы будет "из коробки". Ну и плюс моя поделка была Open Source :-)
А так конечно, да , то, что вы по ссылке даёте, это уже хороший и серьёзный проект. Я правда не пользовался , но слышал хорошие о нём отзывы.
Типичная ситуация в программировании микроконтроллеров.
Отвалившаяся вилка застряла в гнезде.
И тут вам никакие знания программирования не помогут, чтобы починить изделие и продолжить работу.
Можно задавать в качестве вопроса для собеседования при приеме на работу на должность "программист микроконтроллеров".
Как вытащить отломанную вилку.
Один из правильных вариантов ответа - "Отдать на опытное производство для ремонта". Потому что время программиста стоит дороже, чем время ремонтника. Но какой вариант самый правильный - зависит от множества факторов - есть ли опытное производство, как далеко оно расположено, насколько оно загружено, кому еще можно отдать изделие на ремонт. У нас, например, сеньоры обычно ремонтировали в таких случаях сами, потому что у них под рукой паяльник и прочие инструменты, они из схемотехников, и хотят, чтобы поменьше народу узнали о таком фэйле как сломанная вилка. А некоторые джуны относили на производство, потому что не имели уверенных навыков пайки и паяльника.
Иногда программист МК даже ничего и не пишет сам вообще. Важно уже не сколько уметь программировать, сколько уметь тестировать и собирать, улучшать из готового кода из интернета.
Помимо кодовой базы Linux много готовых сорцов можно извлечь из Zephyr Project.
Это CLI, BSP, драйверы разных чипов.
Но надо быть готовым, что образ будет собираться по часу.
Компилирую ядро на домашнем компе за несколько минут, что я делаю не так?
Самое тупое в профессии программист микроконтроллеров это написать и отладить драйвер для модуля у которого очередной самый снобский в природе шаг между пинами например 1,4мм.
Программирование начинается с закупки химии для лазерно-утюжной технологии для производства очередной печатной платы-переходника
https://habr.com/ru/post/451314/
Каждый собирает артефакты по-своему. Первый никогда ничего не знал кроме IDE IAR, второй точно такой же только в IDE Keil, третий собирает через GCC+Eclipse, пятый в GCC+Make+OpenOCD, шестой в GCC+СMake+ST-LINK_gdbserver, седьмой GCC+Ninjia+VSCode, восьмой ничего не знает кроме AtilocStudio, девятый программирует в STMCubeIDE, десятый в Code Comрoser Studio. В общем полная анархия.
А одинадцатый возьмет Haskell и Ivory Language вместо С/С++, и Shake вместо Make или CMake, вообще ужас!
Тут речь идет про программирование микроконтроллеров. В выборе языка приходится ориентироваться на HAL вендора чипа. А вендор дает C.
Поэтому МК продолжают прогать на С.
А вот в выборе компилятора и системы сборок, полная анархия. Jun(ы) сидят в разныз IDE. Middle(ы) собирают из разных скриптов.
А выбор общего текстового редактора это вообще почва для конфликтов.
Даже если Вы будучи программистом MCU и научитесь чему-то особенному, то это скорее всего нигде не пригодится.
В России традиционно электронику делают очень-очень топорными способами: без сборки из скриптов, без модульных тестов, без серверов сборки, без кодо генерации, без HIL стендов. Просто тупо пилят функционал и бюджет.
Если Вы будете учиться, то уже через 2 года Вы будите overqualified.
Вот Вам яркий пример.
Буквально из жизни. Выучили Вы, например, тот же CMake (отличный инструмент), приходите работать в военное НИИ АФАР радары программировать для дронов, а там до Вас дедушка прошивки собирал из-под IDE 15 лет подряд. И что?
Вы будете CMake скрипты писать для 1500 файлов из распакованного архива? Нет конечно же! Более того, да Вас за такое уволят еще на испытательном сроке!
Вывод
В России лояльность важнее мастерства!
Если сравнивать программирование микроконтроллеров с web программированием, то это как водитель вертолета и шофёр пассажирского авиалайнера. У WEB программистов существенно более мощная вычислительная техника (сервера, DeskTop(ы)), их продукт обслуживает миллионы людей. Их как пилотов Boeing 737 окружает слава и внимание.
У программистов - MCU наоборот слабенькие процессоры. Программа для микроконтроллера служит, как правило, только одному единственному человеку (например прошивка для кардиостимулятора). В обществе и СМИ программисты микроконтроллеров абсолютно незаметны.
Зато программисты MCU ближе к контролю real-time процессов. Подобно тому как вертолетчики могут приземляться и взлетать вертикально, а пилоты Boeing 737 - нет.
Тестирование электронных плат кастрюлей
В одном НПЦ я был свидетелем одного очень эпичного способа тестировать PCB.
Вот так это выглядит...
Полностью собирают электронную плату, накрывают её большой металлической кастрюлей вверх дном, подают питание на электронную плату что лежит под кастрюлей.
++В случае, когда изделие нормальное - ничего не происходит.
--В случае, когда изделие бракованное внутри кастрюли раздается глухой хлопок и звонкий стук компонентов о стенки кастрюли. Иногда даже кастрюля подпрыгивает. А по её периметру на мгновение вспыхивает желтое кольцо. После снятия кастрюли выходит облачко дыма.
Вот так в России тестируют электронные платы.
В российских НИИ программистов и схемотехников периодически заставляют писать подробные научные работы по каким-то ноу-хау в софте или железе, что есть в изделии. Аля-патент. Это весьма утомительно из-за обилия формул, схем, графиков и таблиц. Писать такие тексты приходится по выходным, по вечерам и в гос. праздники, так как есть и основные задачи в будни. По сути ты описываешь, то, что сам сделал за полгода на 7-10 страницах.
Потом эту монографию публикуют в каком-н российском журнале при местном институте.
Самое подлое в этом процессе то, что там на первом месте оказывается фамилии начальника НИИ, начальника отдела и начальника лаборатории. А твоя фамилия в авторах либо в самом конце, либо вообще выброшена!
При этом поезд в списке указанных авторов к тексту никакого отношения, естественно как и к работе, не имели. Они текст даже не читали!
Это эдакие намёк тебе: "Знай своё место, собака!"
Вы в Самом Деле Хотите Стать Программистом Микроконтроллеров?