uni

Вложенная отладка. Отладчик GDB исполняет python-скрипт, который тестирует прошивку, подключённую через J-Link. На картинке - отладка самого python-скрипта во время его работы. Здесь, кстати, есть ошибка в регулярке. Неправильно задана для hex-значения. Разыменование THUMB инструкции тоже неверное (в комментарии). Полезные ссылки: 1. How to attach VSCode debugger to Python application already running in Windows terminal?

Модульное тестирование для малых встраиваемых систем

Дизасма я пока не встречал, пока использую самостоятельное формирование lss файла (исходники+асм) и смотрю там, что мне нужно. Остальное есть в таком виде как на картинке. Надо отметить, что сами авторы рекомендуют использовать VS Code как один из вариантов отладки проектов на основе исходников Ardupilot. Правда, они используют другой плагин (cppdbg), а у меня показан cortex-debug. Полезные ссылки: 1. Debugging with GDB using VSCode

Попробовал тут напрямую отладку через USB J-Link в WSL - работает. Нужно обновить Wiki Segger'а, где пока написано, что WSL не полностью поддерживает работу по USB и предлагается обходной костыль. На картинке отладка загрузчика Ardupilot'а для STM32F103 в WSL. Полезные ссылки: 1. Connect USB devices

Не знал про podman. Поставил, запустил, прикольно. Пока только тестовые контейнеры. Поиграюсь какое-то время, попробую что-нить "боевое", наберусь опыта и запишу новый ролик по горячим следам. П.С. Кому интересно, j-link через usbipd в WSL тоже работает. Попробовал отлаживать Ardupilot через VS Code (cortex-debug). pyocd также определяет отладчик.

Это не так. К примеру, мне для сборки исходников Ardupilot в Windows одним из рекомендованных разработчиками способов нужно использовать cygwin, где запускать python скрипт waf (их сборочная система). Так вот этот самый python, который там нужен для сборки в cygwin, оставляет процессы windows в подвешенном состоянии при вызове внешних утилит. Что приводит к использованию танцев с бубном. Это известная проблема в интернетах и её решения я так и не нашёл. Второй рекомендованный разработчиками способ - это использование WSL. Ну и третий - выкинуть Windows.

Дойдём и до контейнеров, всё сразу не успеваю. У меня ещё более старое видео есть по сборке Ardupilot в WSL, но я тогда не знал, что можно USB расшаривать, поэтому в ролике сомневался в практической полезности подхода. Сборка Ardupilot в WSL (Windows 11 + Ubuntu): Попробую отладку Ardupilot через VS Code (cortex-debug) в Windows через WSL (Ubuntu-22.04), используя J-Link. Да, можно и виртуалку использовать, но это и так все знают как делать. Там в WSL можно и Ozone от Segger запускать, но как это всё вместе выглядеть будет не знаю. Мне нравится "прозрачная" доступность Ubuntu через WSL. Я пока не могу полностью перейти на Linux, может быть, используя WSL, постепенно перекочую. Жаль просто терять десятилетия опыта мучений с Windows. Ведь "выкинуть" всё придётся.

Использование WSL для сборки и отладки STM32 проектов Окружение разработки: Windows 11, WSL, VS Code, CMake, ARM GCC. https://www.youtube.com/watch?v=g4k4OOwf58M

Обзор нескольких примеров использования библиотеки Mcucpp для AVR. Окружение разработки: Windows 11, scoop, VS Code, CMake, AVR GCC 10.1/12.1, Proteus 8.15 SP1. Уровень: для начинающих и продолжающих пользоваться Arduino платами, основанными на AVR. Обзор репозитория с CMake демо проектами для AVR. Часть 2. Библиотека Mcucpp https://www.youtube.com/watch?v=auUEUNs8-Ew

Для VS Code понятие "дополнительный инструментарий" слишком широкое. Я бы сузил обсуждение до связки VS Code и gcc/gdb, т.е. сборки при помощи gcc и отладки через gdb, как было упомянуто первоначально. Отладка python-скриптов в VS Code поэтому не относится к этой теме. В этом смысле можно было бы объединиться с темой: Там тоже используется VS Code и тоже сборка идёт при помощи компилятора GCC (avr-gcc). Но я выделил её отдельно, чтобы не смешивать avr и arm архитектуры.

🙂 каждому свои фломастеры, я пользуюсь всеми. О присвятой Кирхгоф, моя техническая реклама связки VS Code + STM32 cmake:

У меня до 3-х экземпляров открыто одновременно бывает. Разных проектов. Обычно я работаю с двумя проектами одновременно и открываю их в разных экземплярах VS Code. База данных для конкретного проекта хранится обычно локально вместе с ним, вы указываете место хранения в настройках к конкретному проекту. Поэтому проблем с одновременной работой у меня не было. VS Code постоянно асинхронно чем-то занимается, к примеру, подсветка кода зависит от наличия файлов в проекте. Некоторые проекты при сборке формируют файлы, которые будут собирать и в процессе сборки можно видеть как меняется подсветка по мере парсинга появляющихся файлов. Всё происходит автоматически. Не нужно как в CubeIDE, к примеру, делать принудительно переиндексацию проекта, когда что-то недоподсветилось как должно. У VS Code более стабильная раскраска. Я сталкивался с проблемой при попытке расширить VS Code на два монитора. Само окно не расширяется в автомате на два 4К монитора. Это можно сделать вручную, изменив размеры, но это неудобно. Открыть один проект (папку) из двух экземпляров не получится, так как программа автоматически активирует уже запущенный экземпляр. Можно перенести вкладку из редактора на второй монитор. Она переносится, но теряется "связь" по подсветке, то есть нарушается работа редактора кода. Это известная проблема, её обсуждают и думается когда-нить порешают.

Не смотрите в эту тему. Вам для здоровья полезнее. Я далее буду игнорировать все такие реплики, так как мне интересно здесь обсуждение только конкретного инструмента. В исходниках сборочного окружения Ardupilot повсеместно применяется python. Он используется waf и просто как набор скриптов. Что касается встраиваемых систем, то могу ещё упомянуть библиотеку modm, где также используется python. В VS Code, как среде разработки, python поддерживается и очень удобно между делом править скрипты и непосредственно проект. Такое иногда приходится делать из-за особенностей сборки Ardupilot через Cygwin. Я пояснял это в своём видеоролике по сборке Ardupilot'а таким образом для полётника CUAV-X7. Также python скрипты используются в Chibios для парсинга datasheet'ов STM32 для автоматического портирования кода под другие мк. Есть видео, где об этом рассказывается, но всё руки не доходят посмотреть и перенять для себя, пока не освоил. VS Code не PyCharm, но от него это пока и не требуется. Это современная модульная среда разработки. Там есть больше чем нужно функционала редактора для встраиваемых систем и он конечно функциональней Keil, IAR или Eclipse. К примеру, насколько я помню, ни одна из этих сред не умеет подхватывать doxygen комментарии для объектов кода налету. Некоторые другие среды умеют (Clion, например). Это очень удобно, когда тебе сразу доступно описание кода во всплывающей подсказке. Для кого того это свистоперделки, но я так не считаю и пользуюсь всеми доступными удобствами. Это особенно полезно при обзоре таких проектов как Ardupilot. Навигация по коду в VS Code просто замечательная, когда нужно найти все концы. Я недавно так нашёл и исправил ошибку в Ardupilot проекте, просто воспользовавшись удобствами навигации при локализации места в коде. Может ролик сниму, аналогичный авторским, как навигировать в большом проекте при поиске ошибок. Они в своём ролике также демонстрировали не просто отладку, а локализацию проблемы.

Трудно уследить что оно позволяет или не позволяет, так как доучиться им пользоваться трудно. Плагины обновляются чуть ли не каждый день, а сама среда по нескольку раз в месяц. Из приятного - поддержка профилей в сети. Если есть привязка к github, то можно иметь единый профиль на всех своих машинах. При переходе с одной машины на другую VS Code восстанавливает свою конфигурацию из сети. Очень удобно. Я не понял что бы это означало. Несколькие "себя" - это как? Какое именно из моих сообщений? Особенности в работе есть, да. Как можно было заметить, я работаю на двух вертикальных 4К мониторах и кое-чего не хватает - нельзя удобно развернуть VS Code на два таких монитора. Окна два разместить можно или вкладки, но теряется подсветка, если эти окна от одного экземпляра программы. Это трудно словами объяснить и это конечно неудобно при такой работе. Про комбинированную отладку я написал, потому что попробовал её в работе и мне понравилось. У меня как раз проекты есть с резервированными мк. И Ardupilot'ом я тоже занимаюсь, нынче это востребовано, а хочется иметь одну среду для всего. Ну и Chibios, Waf, python и тп - какое-то разнообразие.

Вы додумали за меня, а делать этого не надо. Лучше спросить: а в чём отлаживали omap-l138 конкретно? Я бы написал, что в CCS. И эта тема касается VS Code. Лепить сюда свои домыслы, что бы с ними сражаться - это бессмысленное здесь времяпрепровождение. Я и так знаю как отлаживать код во всех других IDE. Мне это не интересно здесь обсуждать. К примеру, сейчас я отлаживаю связку проектов Ardupilot и AP_Periph. Если вы посмотрите на репозиторий обоих проектов, то не увидите там проектных файлов от какой-либо известной IDE. Вот так осуществляют отладку участники проекта (выложено 4 месяца назад на официальном канале проекта): В прикреплённых файлах - то, как это делаю я, используя VS Code (Windows). Можно использовать Ozone (параллельно всё то же отлаживаю и в Ozone, но не пишу тут об этом), может быть можно как-то Eclipse прикрутить, но об этом можно рассказать в другой теме.