Comments 31
Предупреждение в J-Link EDU вроде как должно выскакивать раз в сутки, по факту оно вылезает перед каждой операцией, бесит ужасно. Так поневоле начнешь использовать китайские клоны, благо v9 для моих хобби вполне достаточно.
Они дирут непомерные деньги за свои копеечные железки. Не буду же я, работая инжинером, тратить свою месячную ЗП на такую железку. Работодатели тоже не психи и оплачивать несколько штук $ за платку себестоимостью в пару баксов не будут. Так что если не хотят что бы их ломали пусть назначают адекватную цену.
J-Link не является жизненно необходимым, они вправе ставить любую цену на свои устройства. Дорогие? Так вы ещё Lauterbach не покупали.
J-Link это рудимент начала нулевых, когда JTAG-отладчики были роскошью, и даже программаторы стоили ощутимых денег. Помню когда Atmel выпустила свой ломучий и глючный Dragon за 90$ - народ раскупал моментально и радовался, ибо это было в 5 раз дешевле чем профессиональный отладочный набор. А через пару лет ST начала раздавать STM32 платы с бесплатным STLink, и ICE стало чем-то само собой разумеющимся.
Нужен ли J-Link в 2022? Сейчас есть куча открытых отладчиков на FT2232, включая фирменные (Digilent), которые и быстрые (20-30 МГц), и поддерживают кучу МК, и прекрасно скриптуются. Возможно для каких-то продвинутых возможностей отладки встроенных ОСРВ, или лютой экзотики J-Link и нужен. Но на популярных семействах МК вполне реально вести полноценную коммерческую разработку используя только открытые софт и железо.
Ну вот я сейчас работаю с последними чипами от nordic. Они там тестно работают с сигером. Их ide ни че кроме J-link не поддерживает.
Мы перешли от IDE до VScode/vim + Make + gdb. И вижу всё больше инженеров, отказывающихся от фирменных ide в пользу подобной связки.
Мейнстримные IDE это в большинстве случаев ухудшенный эклипс. Вещи типа Code Composer Studio или STMCubeMX вообще за гранью мыслимого и немыслимого, пользоваться ими невозможно.
Платные Iar или Keil очень отсталые по меркам современных программистов, негибкие, управление репозиторием или системы сборки очень слабые. (Признаю, не следил за ними лет 6 - может что-то и поменялось).
Из осей доступны Windows, реже Debian и почти никогда MacOS - а Макбуки вполне популярны среди программистов.
Связка из текстового редактора, системы сборки и отладчика универсальна. Программист может её настроить согласно своим вкусам и потребностям. Она легко скриптуется и встраивается в CI/CD (пробовали может встроить проект на Кейле в CI?).
Я понимаю что выбор среды это во многом дело вкуса и личного опыта человека. Электронщик который программирует склонен выбрать Iar ибо там уже всё настроено. А вот программист, который начинает приключение с МК очень быстро приходит в ужас от инструментария разработки и ищет более продвинутые инструменты.
А как вы считаете сколько времени займет разобраться с их компилятором, набором библиотек, sdk , структурой проекта? И написать удобные рабочие скрипты и конфиги для работы в VS-code. Что бы работало автоматическое создание проекта, конфигурирование zephyr, дебаг итд итп (мне самому VS-code нравится, пишу на нем под stm, esp)
По моей оценке на это можно убить не один месяц. И это само по себе приличных оьбемов проект. И работодатель/заказчик/клиент/начальник платить за это не готовы. Они хотят быстрый видимый результат. Поэтому приходится брать и работать с тем что есть.
Это вопрос, ответ на который знаете только вы. Только у вас есть требования и сроки для ваших проектов.
По факту у меня только один вопрос - вам реально надо создавать несколько новых проектов в день? По мне Unix-way вполне живой. У нас (как правило) нет безумного количества файлов и возможностей банального gmake вполне достаточно для сборки скелета проекта. А дальше "мясо" нарастает по мере реализации. GCC (а местами CLang, и даже так любимый "не embedded разработчиками" Rust) вполне вписываются в такую схему. В любом случае время на создание проекта сильно меньше, чем время на его реализацию.
А вопрос IDE при наличии возможности сказать "gmake firmware" уже вторичен. Любой вариант - от vim до "взрослой" Visual Studio или XCode.
Единственная проблема - это когда часть кода идет в объектниках. Да не просто в объектниках, а в объектниках под какой-то конкретный компилятор. Но опять же - это личная ответственность разработчика. Я с таким стараюсь не связываться (и пока получается).
Впрочем, есть "суровый энтерпрайз" и там несколько другие правила. Типа старого компилятора, который гарантированно с точностью до байта воспроизводит релизную прошивку... Те "погремушки", безусловно, имеют свои особенности.
Хм. Подход который вы предлагаете конечно возможен для hello world или помигать светодиодом. Но вот в случае с nordic подобный подход мало реален. Дело в том что там используеться их sdk и zephyr. Внутри это, я так понимаю это выглядит так: есть два больших конфигурационных файла , 1й это настройки zephyr , в нем описывается какие возможности и библиотеки вам нужны, 2й файл описывает переферию конроллера ( чем то напоминает подход STMcube, где вы в графическом редакторе настраиваете нужную вам переферию, привязываете к нужным ножкам, дальше нажимаете кнопку и куб генерит вам кучу кода для инициализации всего этого. Но у нордика все это сложнее и запутаннее, вместо графического редактора текстовый конфиг, и с ходу даже не совсем понятно куда идет результат и где в итоге код инициализации)
На основе этих конфигов ide создает/пересоздает даже не проект а "решение" состоящее из нескольких десятков проектов, каждый проект компелиться в отдельный обектник и потом все это собирается в прошивку. Причем часть кода может быть С а часть С++ , в зависимости от конфига и компиляторы для разных кусков могут быть похоже разные.
Как вы понимаете что бы повторить всю эту логику на сторонней ide надо досканально разобраться со всей этой логикой, при чем может выяснится что все или часть этого не документирована, и повторить все это можно только методом ревирсинжинеринга)))
И того получается что с вашим подходом можно убить месяцы на то что в их ide уйдет пять минут.
Конечно классно было бы написать все это для VS-code но это отдельный большой проект. Чем то похожим занимается PlatformIO, не знаю сколько народу его делает, но делают они это годами, и у них там до сих пор тьма диких вопиющих ошибок. Эти ошибки они не успевают, я так понимаю исправлять. Год назад нашел у них критическую ошибку (из за нее работать с проф программатором, дебажить с ESP32 не возможно, прошивка в контроллер попадает битая) . При чем я полностью понял причину ошибки и исправил ее у себя. Об этом написал им на форуме, но спустя год ошибка так и не исправлена)))
Я вас уверяю - мои проекты сильно шире, чем помигать светодиодом. Впрочем... закон качалки гласит - всегда есть тот, кто твоим весом только разминается. В моих итоговый Makefile'ах несколько сотен файлов, но 99% когда в них написаны мной, а не сгенерированы кодегенераторами. И уверяю вас - при условии что в проекте код написан автором это вполне рабочий вариант независимо от размера проекта.
Исходя строго из вашего описанию, я бы наверняка не стал использовать такое в своих проектах. Не люблю зависеть от кода, который не понимаю или, не могу повторить в разумные сроки (что по сути равнозначно). Максимум это какие-то специфические (закрытые) прошивки для второго ядра, которые надо однократно загрузить и запустить. Для меня это принципиальный вопрос. Можно название чипа для более предметного разговора?
Чип nrf9160 это gsm модем ( для iot сети), gps приемник и неплохой микроконтроллер на одном кристалле. Кроме того заявлено супернизкое энергопотребление. Но я так понял что конкретный чип не важен , фишка нордика это чип какой-то связи+ мк в одной микросхеме.
Для реализации многопоточности они используют не rtos а zephyr ( если вы не в курсе то zephyr это то же что rtos но кроме многопоточности там в составе еще куча библиотек для работы с сетью , железом, итд. Т.е. по сути можно сказать полноценная операционка для мк) Там есть куча тяжеловесных вещей типа реализации http/https протоколов. Как вы понимаете писать с нуля все это можно годами поэтому не вижу алтернативы кроме как использовать предложенные ими решения.
Идеология zephyr несколько странная( возможно для меня из за отсутствия опыта) , это не просто набор библиотек которые можно подключать инклудом. Это как я уже писал громадный конфиг файл в котором указывается какие возможности вам нужны, и как я понял, на основе этого конфига zephyr уже создает проект , генерит makefile, , подставлет нужные исходники, использует те или иные компиляторы.
Возможно мне не хватает опыта, но я даже не совсем уверен что есть легальная документированная возможность проделать все эти этапы в ручную не используя ide
Zephyr прекрасно работает с консольными системами сборки. Сам не применял - у нас другие потребности, но краем уха видел весьма навороченную консольную систему разработки от Antmicro. Единственное что мы используем из IDE это конфигуратор CubeMX. В нём необходимо сгенерировать файлы инициализации периферии и библиотек и добавить в проект. К счастью, куб поддерживает генерацию проекта под Makefile. Больше о нём ничего хорошего сказать не могу.
По времени: конечно надо потратить пару дней на настройку системы, но потом оно экономит месяцы. Думаю мы уже отбили затраченное время хотя бы на времени запуска тормозного CubeIDE (около минуты на современном ПК).
В больших проектах конфигурация собственно железа, ОСРВ и периферии это проценты от общего времени разработки. Куда больше времени тратится на собственно "бизнес-логику" прибора или приложения. Поэтому есть смысл оптимизировать разработку именно бизнес-логики.
Любой проект должен быть сбалансированным. При чем чем больше проект, тем важнее этот баланс поддерживать. Безусловно бизнес-логика она на виду, она наиболее пластичная часть. Но реализовывать ее на непрочном фундаменте так себе идея. Надо или иметь ресурсы для латания в нем дыр, которые вскроются в процессе реализации той самой бизнес-логики, или вставлять костыли, которые теперь гордо именуют "тех долгом", и которые с некоторой концентрации начинаю очень больно бить. Ну, или строить свой фундамент даже если это затратно.
Одно из основных зол это попытка сделать сложный проект экстремально простыми методами. Впрочем, обратное (простой проект крайне сложным методом) тоже встречается. А ответственность здесь так или иначе на руководителе разработчиков. По сути только от него зависит и принятое решение, и итоговая судьба проекта. А то, что заказчик всегда хочет ходовой винт авианосца за три копейки (и готов смириться с тем, что он будет непокрашен) - так это не новость.
Чип nrf9160 это gsm модем ( для iot сети), gps приемник и неплохой микроконтроллер на одном кристалле.
Понял. Да, эта одна из тех штук, для программирования который системщик не нужен. Это в том или ином виде заменяют генераторы. Последнее время довольно часто встречается. Наверное, это даже правильно. Если, конечно, вынести за скобки вопрос о том, будет ли IoT считаться критической инфраструктурой и, в связи с этим вопрос о качестве кода от Nordic. Что, к слову производитель говорит? Как всегда as-is без любых явных или неявных гарантий?
Впрочем, это уже мои тараканы... Пока мне удается не ввязываться в подобные проекты. Хотя бы по тому, что представить себе объем квалификационного тестирования такой штуки (а только оно будет являться хть какой-то гарантией того, что в "дикой природе" с ней все будет хорошо) - крайне сложно. Впрочем, да - встречается и такое. Но что вы хотите - жесткая завязка на одного вендора она не только благо. Выбор, безусловно, за заказчиком (и его разработчиками). Но мне казалось, что после продолжающейся истории с ST Microelectronics какие-то выводы были сделаны...
Так что опять к исходному посылу - выбор пути строго за вами. Как и оценка трудоемкости. И возможности ее размена на "черные ящики" готового кода. В любом случае подходов может быть больше, чем один.
Мое мнение, подход делать все с нуля, это не подход. Превращать задачу которую может сделать один человек за пару месяцев используя "черные ящики" в задачу на год для коллектива разработчиков это крайне не правильное решение. Особенно если речь не идет о управление космческим кораблем или ядерным реактором, где бюджеты и сроки возможно раздувать в сотни раз. Да, обычно все эти sdk изабилуют глюками и ошибками, но время на их поиск и исправление все равно меньше чем написание с нуля.
Я за свою жизнь практически 50 на 50 занимался чистым программированием ( не связаным с железками) и embedded. Почему то среди embedded инжинеров этот подход с нуля очень распространен, но в среде обычных прогеров с таким подходом долго не продержаться)))
Вам повезло если вашему работодателью важен процесс а не результат, но это большая редкость. Кроме того подобные работодатели как правило мало платят.
Так что с моей точки зрения, современный подход это обязательное использование по возможности готовых решений.
Вам повезло если вашему работодателью важен процесс а не результат, но это большая редкость.
Любому работадателю важен результат, а не процесс. Другое дело, что некоторым достаточно любого результата - сделал, продал, забыл. А некоторым важна долгосрочная поддержка (особенно если железка лишь часть большой информационной системы, призванной работать много лет и, при необходимости расти вместе с потребностями покупателя). Увы, вы правы - такие редкость.
Но я предпочитаю работать с ними, а не менять работу каждые три года (а то и чаще). Личное дело каждого копать вглубь или вширь. Про оплату... Да, как правило здесь она ниже. Но это вечный вопрос баланса. Меньше, но всегда и с планомерным ростом больше инфляции или много но временами с просадками едва не до нуля. Да и в долгосрочном плане все несколько по разному выглядит. Как в плане денег, так и в плане знаний, умений (и даже репутации).
Впрочем, даже здесь продуктовый цикл три года. За это время железка успевает быть сформулированнной, спроектированнной, поставленной на серийное производство. И еще три года производиться пока выполняется следующая итерация. Из тех, которые проектировал я, в работе те, что сделаны в 2010-2013-х годах. Их гарантийный срок в 8 лет закончен, но они продолжают трудиться. И, при необходимости, получают обновления. Правда конкретно эти уже получают только исправления ошибок, а не новый функционал - но это больше политика и экономика, чем техника.
Последнее что хочу, наверное добавить.
С нуля можно делать только несложные проекты. Какую ни будь простенькую сигналку можно хоть на асме с нуля написать ( когда то я занимался подобными вещами) Но сейчас есть много задач где надо использовать работу со сложными протоколами, криптографией, сетями, сжатыми видео и аудио данными, ИИ или хотя бы компьютерным зрением. Все это с нуля написать невозможно ( в адекватные сроки и с адекватными затратами) поэтому в таких задачах без громозких фреймвоков и ide не обойтись.
Да, тема сильно сложнее. Она сродни браузерам у прикладников. Те тоже кричат что создать его сегодня и с нуля практически невозможно. Во всяком случае за разумные деньги и в разумные сроки.
Это именно та причина, по которой я и говорю что системное программирование потихоньку вымирает (ну, может не вымирает - но сильно перерождается). Те вещи, которые воспринимались как сами собой разумеющиеся и требующие крайне ответственного подхода ранее вдруг становятся второстепенными. Дошло до того, что люди умеющие напрямую открыть файл устройства и сделать IOCTL в UNIX уже называют себя системщиками. Люди, горда именуемы себя системными программистами, не пишут ни к один регистр периферии и вообще никак напрямую не контактируют с железом, а крайне серьезные инфраструктурные проекты содержат код качество которого под большим вопросом (но его очень много, и за его переработку страшно даже браться).
При этом в соседних темах всячески гнобят схемотехников за "одноразовые вещи". А там происходит примерно то же самое. "С нуля можно делать только несложные проекты. Какую ни будь простенькую пищалку...". Или "нет ничего сложного в источнике постоянного тока - берем типовую схему из мануала, ставим на плату как наши габариты требуют и всего делов-то". Там, правда пока все не так страшно, но уже похоже.
Ну что тут скажешь. Живем с этим. Эволюция. Только время покажет будет ли это новым витком или очередным "эволюционным тупиком". Я принимаю то, что вы пишите. Но продолжаю считать что это не единственный путь. Он совершенно точно хорош для прототипа. Быстро и наглядно. Для остального... Боюсь это за гранью моего понимания. История знает некоторое количество примеров, когда прототипы оказавшись первыми на рынке его завоевывали. Но есть и обратные - когда слишком рано выведенный на рынок прототип породил индустрию, но сам умер.
Nordic выпустил свой плагин для VScode. Весьма годный, даже видео запили как его ставить и пользоваться. Там и настройки и отладка и все что нужно для работы.
Даже когда этого плагина не было, за пару дней можно было собрать структуру проекта со всем необходимым руками (я так делал, так как VScode на мой неискушенный взгляд на голову выше и приятнее в использовании многих альтернатив).
Макбук + CLion + J-Link - очень удобная связка, IDE от SEGGER пробовал поставить - выглядит ппц и как ей вооще пользоваться - не понятно, что-то из 90-х годов, кривой и стремный блокнот-переросток. Iar или Keil - туда же.
J-Link по настоящему даёт хорошую отдачу когда его используют в конфигурации Pro или Ultra и совместно с коммерческими средами типа IAR Embedded Workbench или SystemView.
Они дирут непомерные деньги за свои копеечные железки
Нет, это вы разрабатываете копеечные железки, для которых жылинк избыточен. Для компаний, производящих десятки тысяч плат в год, эти пару тысяч — капля в море, и если раработчики могут аргументированно пояснить, почему им нужен ИМЕННО ЭТОТ инструмент — у них будет и жылинк, и альтиум, и лицензии на их ИДЕ.
Я тоже, когда покупал смд-установщик за 5к — думал, что сильно оверпрайс — себестоимость не больше 200...300, но деваться было некуда, надо было собирать платы. Но он мне за 5 лет вчистую окупился минимум 3...4 раза. Заработал и я, заработали и его изготовители. Так же и с этим жылинком. Он не для того, чтобы вам осенними вечерами кодить ёлочную моргалку на F030P4 — пользуйтесь семихостингом…
Они дирут непомерные деньги за свои копеечные железки.
Софт ничего не стоит? Причем это хороший софт, а не типичное для нынешнего времени индусское говно.
Вообще это должен работодатель оплачивать, а не "инжинер". Для хобби можно брать J-Link EDU, он существенно дешевле стоит и вполне подходит для любительских задач. Если денег совсем нет, а что-то поделать хочется - есть другие отладчики, сильно дешевле.
У J-Link BASE/PLUS/PRO главная фишка это коммерческая поддержка, если она вам не нужна - зачем за нее платить?
а бесплатный софт устраивает и вас и работодателей же?
Ясно кого надо благодарить. Благо есть выход, откат софта до 7,56 и прошивка EDU. Как сделать сами найдете. Займитесь делом, не мешайте другим работать.
Уязвимости в системе лицензирования J-Link, или Почему так важно исследовать безопасность устройств