Visual studio code stm32 настройка
This guide will help you install and setup Visual Studio Code for programming and debugging STM32 boards.
I tested this guide under Arch Linux and Ubuntu 18.04. If you get it to work under other setups, please let me know so I will update the steps with more info.
If you were using STM32CubeIDE or SystemWorkbench before, you need to convert your projects in order for them to work. The conversion procedure is fully reversible.
Up until the time of writing this guide, it is not possible to use STM32CubeIDE and Visual Studio Code on the same project unless some configuration changes are made on CubeIDE. Besides that, it is reccomended that every person that works on a project runs the same working environment.
If you already have CubeMX installed, you can skip this step
Install stm32cubemx from the AUR. If you don't have access to the AUR or you just don't want to use it, follow the step below.
Inferior operating systems (Windows, Ubuntu, Temple OS. )
Download the .zip from here (you have to sign up to ST's website) and install the right version for your OS.
2. GNU ARM Embedded Toolchain
These are the tools needed to compile and debug the code.
Install arm-none-eabi-gcc arm-none-eabi-gdb arm-none-eabi-newlib .
Install gcc-arm-none-eabi gdb-multiarch libnewlib-arm-none-eabi .
Install the toolchain from arm's website
Install make from your package manager
Install make from this this page (updated in 2006 though. ). It should be possible to get the current version of make through WSL, but I don't have experience with it.
Open On-Chip Debugger is the software that will take care of uploading the compiled software to the STM32, and during debug, it will open the connection between the computer and the STM32.
If you are on Windows you could probably get OpenOCD installed, but I don't have idea on how to do it. Contact me if you're willing to find a way.
Install openocd from your package manager
5. Visual Studio Code
The next steps aren't really necessary to get the thing working. You could just use the a terminal and your favourite editor and you would have (almost) all the functionality of the complete setup. Visual Studio Code is just a pretty front-end.
This page contains the instructions to install the latest version of VSCode on many distributions.
Download and install the program from the official website.
This extension will take care of intellisense, syntax highlighting and more.
Install this extension in Visual Studio Code.
Same as above, but with this extension.
By default CubeMX generates projects in a format called EWARM. Unfortunately, EWARM is currently not supported by the VSCode extension, but the more generic Makefile structure is. In order to configure CubeMX to support VSCode you have to navigate to Project Manager->Project->Toolchain/IDE and set it to Makefile.
Under the Code generator tab, enable the Copy all used libraries into the project folder option. This step is needed because stm32-for-vscode doesn't support the implicit inclusion of libraries yet.
After doing that, click on GENERATE CODE ; You should see the new Makefile project structure being created.
2. Visual Studio
Using the Open folder menu in Visual Studio Code, navigate to your project's root folder and open it. Now open the command palette ( Ctrl+Shift+P or F1 ) and run Build STM32 Project . A terminal should appear and you will see gcc (hopefully) compiling your project.
After you call Build STM32 Project for the first time, stm32-for-vscode will create two custom tasks (that can be accessed by typing Ctrl+Shift+B ) to build your code and to flash it into the STM32 board.
To debug the code just press F5 inside VSCode and the debugger will start automatically. Remember to stop the debugger before flashing new code.
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS during upload
This happnes because you don't have permission to open the serial device. In order to fix this you need to add your user to the group that owns the serial interface. To get the serial interface name you can run dmesg | grep tty after plugging the STM32 in. Read the last line, you should see something like:
In this example ttyACM0 is the device name.
Now that you know the name you can get the owner by doing ls -l /dev/ttyACM0 . The output looks like this:
group indicates the group name.
Now you just need to add your user to the group by doing sudo usermod -aG group $USER , substituting group with the group name you have discovered above.
You are done. Log out of your account and log back in to apply the change.
Сегодня рассмотрим настройку удобной и красивой среды разработки для программиста микроконтроллеров с помощью набора полностью бесплатных инструментов разработки.
Все шаги проверены на виртуальной машине со свежеустановленной Ubuntu 16.04 xenial desktop x64.
Подразумевается, что у Вас уже есть исходники какого-либо проекта.
Все настройки, касающиеся конкретного железа (в моём случае это контроллер STM32F429 и девборда STM32F429DISCO), нужно подменить на свои. То же самое касается и путей.
Если готовы, то поехали
Установка curl
Установка vscode
Установка arm-none-eabi тулчейна
Установка openocd
Запуск и настройка vscode
Для запуска vscode вызвать в терминале команду code .
Заходим в раздел Extensions (Ctrl+Shift+X).
Ищем и устанавливаем следующие плагины:
- Cortex-Debug от автора marus25.
- С/С++ от Microsoft.
Открываем папку с проектом через меню File/Open Folder.
Заходим в раздел Debug (Ctrl+Shift+D).
Вверху в выпадающей строке видим текст No configurations.
Нажимаем на шестерёнку рядом с ней, выпадает меню с предложением создать конфигурацию для дебага, выбираем Cortex-Debug.
В каталоге проекта создаётся скрытая папка .vscode, в которой создаётся файл с конфигурациями дебага launch.json.
Если этот файл не открылся сам, открываем его руками: переходим в раздел Explorer (Ctrl+Shift+E) и в дереве выбираем этот файл.
Настраиваем конфигурацию для openocd:
Последние три свойства: расположение elf-файла, расположение svd-файла, путь к конфигу для openocd, — настраиваем под себя.
Сохраняем файл launch.json и снова идём в раздел Debug, там убеждаемся, что в выпадающем меню появилась наша конфигурация.
Далее возвращаемся в раздел Explorer и в каталог .vscode добавляем новый файл с именем settings.json, открываем его, пишем там следующее:
Далее добавляем в .vscode ещё один файл c_cpp_properties.json, открываем его и пишем там следующее:
По нажатию F5 можно запускать отладку (не забудьте перед этим собрать проект, чтобы elf-файл был на нужном месте).
Это даже не руководство, а небольшое описание и собственные ощущения о переходе с Keil'а на VSCode. Здесь нет рассказа от том, как настроить систему сборки, только немного о настройках самого редактора.
Небольшая заметка о том, как я решил отказаться от keil и перешел на visual studio code.
Давно я собирался это сделать, но никак не мог решиться. Больше всего в vscode привлекал удобный редактор с его плюшками, до которого keil'у, да и многим другим IDE расти и расти.
Основной проблемой было то, как настроить сборку, как выполнять загрузку и отладку. "У страха глаза велики" - это правда, на деле всё оказалось куда проще. Даже этот текст, который вы читаете, написан в vscode.
Если стало интересно - читайте дальше.
Установка VS Code и расширений
Для разработки приложений на языке Си для микроконтроллеров ARM будем использовать несколько плагинов:
Основные - это верхние три, остальные это лишь небольшие улучшения и дополнения, хотя в принципе достаточно и первых двух.
Настройка среды
Вся настройка производится в файлах json .
Файл .vscode\launch.json соделжит конфигурации запуска и отладки.
Пример моей конфигурации:
Это конфигурация для плагина Cortex-Debug, в которой указаны параметры типа ядра, путь к elf файлу, ипя конфигурации для отладки, интерфейс, тип операционной системы, тип отладчика, путь к файлу описания регистров микроконтроллера (SVD файл), его можно найти в папке с файлами поддержки семейства микроконтроллеров для STM32CubeMx, например для STM32F0 здесь
Следующий файл - .vscode\settings.json , - настройки рабочего пространства, у меня выглядят примерно так.
Указаны лишь три настройки, могут быть и другие, но эти важны для нашего проекта.
Теперь приступим к настройкам нашего проекта, а именно укажем пути к заголовочным файлам, дефайны и настройки стандарта языка, это всё нужно не для сборки проекта, а для работы системы IntelliSense. Главное быть внимательным, так как эти настройки должны быть максимально синхронны с настройками при компилировании файлов, вплоть до указания предопределенных макросов типа __GNU__ и подобных. Иначе можно получить весьма неожиданный результат, на экране будет одно, а по факту проект будет собираться уже по другом из-за вмешательства препроцессора и раскрытия макросов.
Из названия настроек всё понятно: имя конфигурации, путь к компилятору, его аргументы, пути к заголовочным файлам, опеределения макросов и указание стандарта языка. Более подробно об этих параметрах можно почитать в официальной документации.
В принципе все основные настройки готовы, осталось определелить несколько задач для сборки и загрузки прошивки в микроконтроллер. Для этого их необходимо описать в файле .vscode\tasks.json .
Первая задача Build - задача сборки, о чем намекает параметр "kind": "build" , именно её редактор будет предлагать к выбору при выборе меню Терминал -> Запустить задачу сборки. , либо при нажатии кнопок CTRL+SHIFT+B .
Команда которая будет выполняться написана в параметре command .
В первой задаче это запуск утилиты make с параметрами.
Во второй это запуск утилиты jlink для записи файла прошивки в микроконтроллер. Видно, что здесь указаны тип устройства, интерфейс и скорость соединения и скрипт прошивки. Скрипт выглядит следующим образом:
Другие команды, для чтения, очистки и сброса можно посмотреть в документации к jlink .
Ну вот и всё, Вам же осталось только написать свой код, написать Makefile и пользоваться средой.
Немного об ощущениях
- Превосходный редактор с отличным функционалом;
- Можно переходить к определнию функции по клику с нажатым CTRL ;
- куча расширений функционала редактора.
- Немного непривычная отладка: значения регистров и переменных в десятичном формате;
- Отладка без дизассемблера;
- Возможность отстрелить ногу с предопределенными компилятором макросами (то, о чем я писал выше);
- Много ручной работы по настройке проекта и системы сборки;
- GCC вместо ARM Compiler 6.
На первый взгляд кажется что минусов больше, но на самом деле удобство работы в редакторе кода компенсирует многое. А расширение функции отладки скорее всего дело будущих версий этого плагина.
Все гораздо проще. Перед подачей питания на контроллер (либо нажатием кнопки сброса) нужно BOOT0 подтянуть к VCC. Делается это соответствующей перемычкой или зажатием соответствующей кнопки. Контроллер переводится в режим DFU и его можно шить хоть через SWD, хоть через UART, хоть через USB (в F1 не поддерживается)
А можно один раз в китайском "свистке" вывести наружу сигнал сброса (нога 18 контроллера) и забыть об этих мучениях навсегда.
Не вижу смысла в подключении аппаратного ресета, когда программный нормально работает. А данный способ подъема нужен за очень редким исключением, когда забываешь первым делом включить SWD-интерфейс.
насколько я помню, можно в настройках openocd указать сброс через сам отладчик
-f ../scripts/board/st_xnucleo_f4.cfg -c "reset_config none separate" -c "init" -c "reset halt"
-c "reset_config none separate" — означает, что сброс производится через SWD без использования отдельной ножки сброса (а у меня как раз такой китайский отладчик)
Проблема в том, что самим пинам SWD программно могут быть назначены другие функции (по ошибке, как в примере, либо намеренно). В таком случае для установления связи по SWD нужно держать ядро в сбросе (тогда пины будут исполнять функцию по умолчанию - SWD). Для случая «по ошибке», как написали выше, действительно достаточно замкнуть nRST любым подручным средством. Однако для проекта с сознательно переназначаемым SWD это уже будут постоянные мучения и проще один раз допаять один провод в самом отладчике.
Плагин PlatformIO к VSCode не рассматривали? Я поставил его, а от Куба полностью отказался.
Я смотрел на PlatformIO, но решил отказаться. Очень не люблю когда на двадцать строк кода добавляется пол-мегабайта служебных файлов. И от меня прячется основная часть работы. По этой причине я в своё время отказался от AVR CodeVision, потом от AVR Studio, потом от Eclipse. Сам PlatformIO показался громоздким и избыточным. Опять же этомоё мнение и никого ни к чему не призываю.
Мне кажется, что куб прячет гораздо больше и добавляет в проект несколько мегабайт файлов. Причём я если при генерации проекта выбирал везде LL, и копировать только используемые файлы, он мне все равно в папку проекта кроме CMSIS накидывает и HAL, и main.c создаёт довольно не слабый. Может я конечно кубик готовить не умею. Я использую CMSIS, и всю инициализации пишу сам, а платформио библиотеки в проект не копирует, и вся папка проекта у меня килобайт на 60 выходит.
А компилированный проект при этом тяжелый или сравнительно лёгкий?
Кубик про запас накидывает всё необходимое
Если посмотрите Makefile, то там подключаются только те файлы исходников, которые используются, а дальше всё на совести gcc.
Мне не с чем сравнивать, я начинаю только. Сейчас разбираюсь с прерываниями. Два светодиода, две кнопки, два прерывания. Код в платформио выглядит так. Файл bin 884 байта.
Бинарник вполне компактный. Минимальный размер. Можете еще утрамбовать, но там уже придётся руками адреса прописывать, плюс в ассемблер удариться.
Спасибо за совет, но думаю мне пока рано. Первый месяц в микроконтроллеры ударился. Но может через какое-то время и до ассемблера доберусь. Адреса вручную есть смысл? Ведь все определения в CMSIS задефайнены, и вроде на размер влиять не должны. Разве что функции работы с прерываниями заменить на запись в регистры.
Не надо так увлекаться гипероптимизацией. Чаще всего если немного памяти не хватает - если нет специфических требований - проще взять контроллер постарше, благо они по пинам совместимые.
Как вы оценили минимальность? Сам вот этот видимый код выше со включённой оптимизацией оттранслируется во что-то порядка 200 байт. А остальное — раздутые startup, SystemInit и прочие чудеса, заботливо добавляемые Кубом до вызова main, о существовании которых немало начинающих и не подозревает, т.к. их код туда не ссылается.
Я тоже выкидываю из Кубовского проекта всё безбожно, меня от него интересуют только свежие библиотеки и начальная инициализация тактировки, HAL выпиливаю начисто.
Мне кажется, странно предъявлять претензий к PlatformIO по поводу разрастания проекта и тут же использовать HAL, который тоже тащит кучу всего, причем прямиком в прошивку.
Пробовали STM32CubeIDE? Или не рассматривали так как основано на eclipse? Просто всё-равно использовали CubeMX для конфигурации, а в обозначенной IDE он встроен
STM32CubeIDE я смотрел когда тот ещё был совсем маленьким и запустить проект на Eclipse было проще чем на STM32CubeIDE. К тому же тогда его не было для Linux. Сейчас для меня основным набором являются Си для микроконтроллеров (STM8, STM32 AVR) и Python для служебных утилит. Если учесть что я перемещаюсь между Window, Debian и Raspberry (да, я использую RPI 4 8 Gb как нормальную машину) то полная кросплатформенность для меня важна.
Уже пару лет как вполне хорошо с CubeID, посмотрите еще раз.
Уже пару лет как всё очень плохо с STM32CubeIDE.
Оно медленное. Оно очень плохо работает с Makefile-проектами. Оно постоянно качает гигабайты обновлений.
Вы скачали CubeIDE и решили попрограммировать. Выбираете процессор или плату и оно начинает качать библиотеки - так мегабайт по 700. Поменяли семейство? Опять качать ВСЁ. Невозможно выбрать компоненты, оно скачает весь BSP, примеры, библиотеки для фат, фриртос, аудио, сенсорных экранов и ещё 100500 компоненотов.
А через пару недель прилетает обновление и пожалуйте качать заново библиотеки для старых проектов. С STM32CubeIDE не бывает так что его просто можно запустить и начать программировать. Впрочем, у других производителей ситуация не лучше, а наверно ещё хуже. При таком качестве бесплатного софта не удивительно что IAR прямиком из 1998 года продают за большие деньги и он народу нравится.
Собственно идея написать эту статью как памятку себе любимому, ну может ещё кому пригодится пришла в голову год назад, после того как убил немало времени на это нехитрое занятие. Недавно оказалось, что проблема актуальна по сей день. Почему-то ни один из найденных вариантов сам по себе не помогает и данная статься является результатом обработки всей найденной информации. При решении вопроса, больше всего бесило - возьмите мой проект и будет вам счастье, а проекта там уже и нет. Такой подход я плохо переношу, поэтому и сам делать так не буду.
Всё ниже описанное является следствием моего личного опыта, и ни на какую истинность не претендует. Все советы рассчитаны не людей только решившихся на переход с AVR на STM32
Вопросы типа почему Linux, VSCode и прочее, думаю, освещения не требуют. Считаю, что все заинтересованные в вопросе, на эти мелочи давно нашли СВОЙ ответ. Однако отмечу, в Винде всё это тоже работает, проверено, и проекты спокойно переживают миграцию между машинами.
Этап установки VSCode опущу, этого добра настролько навалом, что даже чересчур. Скажу только, что минимально нужно поставить модули C/C++ от Microsoft (считаю, что плагин от крупного автора имеет больше шансов на долгую жизнь), Cortex-Debug от marus25 (альтернатив пока нет) и Makefile Tools от Microsoft (анализирует Makefile и сам настраивает IntelliSense, давно ждал такую штуку, было хоть сам пиши).
Самый простой способ получить заготовку проекта - собрать его в CubeMX. Процесс интуитивно понятный, сотни раз описанный в сети, поэтому отвлекаться на него не буду. Отмечу пару важных моментов.
Нужно не забыть в настройках порта разрешить отладочную шину
Очень беспонтовая ошибка. По умолчанию все выводы переводятся на вход и после первой прошивки у Вас отваливается программатор. Так как у всех начинающих программатор - китайский минимальный клон, то никакого сброса для STM32 там нет и что дальше делать не всем понятно.
Как и у меня в своё время, у большинства начинающих в распоряжении так называемая Синяя Пилюля, поэтому давайте включим выход к которому подключен светодиод (PC13).
Так как светодиод через резистор подключен к питанию, то вывод настроим в режим Open-Drain, хотя от Push-Pull хуже не будет.
Настройку тактировки мне приводить лень, пхать сюда огромную бессмысленную картинку не вижу смысла, а от уменьшенной смысла ещё меньше. К тому же CubeMX предлагает сам настроить все коэффициенты, да и для ручного режима всё более чем интуитивно понятно.
Поэтому завершаем работу с CubeMX задав имя проекта и обязательно переключив *Toolchain/IDE* на *Makefile*
После генерации проекта, в целевом каталоге получаем вот такой набор файлов.
Всё бы хорошо, но для отладки нам необходим SVD-файл, в нём информация для отладчика, необходимая для человеческого отображения регистров периферии, ядра и т.п.
Тут можно найти всю возможную документацию по процессору, но сейчас нас интересует вкладка CAD Resources. На ней находим HW Model, CAD Libraries & SVD -> System View Description. Скачиваем найденый архив. Для ленивых ссылка на страницу. В архиве найдёте несколько svd-файлов. Нас сейчас интересует - STM32F103.svd. Не долго думая кидаем его в папку с проектом.
Пришло время запустить VSCode. Лично я предпочитаю в нужном каталоге дать команду code ., а там каждому своё. Программа спросит, доверяете ли вы авторам этого каталога, придётся сказать, что доверяете. Makefile Tool проанализирует Makefile, о чём выдаст много текста в панели, и настроит IntelliSense. Ещё не так давно приходилось его настраивать вручную, не сложно, но не интересно.
Не забываем сохранить Рабочую Область.
Теперь немного дополняем Makefile - добавляем ещё одну цель prog
Небольшое пояснение. Скрипты interface/stlink-v2.cfg и target/stm32f1x.cfg позволяют openocd узнать через какой адаптер и с кем он должен работать. Сами скрипты распологаются в каталоге scripts с установленным openocd (для Винды) или в каталоге /usr/share/openocd в Linux. Приведённый пример работает для китайского клона ST-Link v2 и Синей Пилюли. Если у Вас другой программатор или камень, то необходимые файлы найдёте в тех же каталогах.
Собственно зачем нужна эта байда? Иногда нужно записать программу в процессор не запуская отладку - просто записать и посмотреть, что произойдёт. Вот за это и отвечает -c "program build/$(TARGET).elf verify exit reset
Следующим этапом я настраиваю git, но это по вкусу. Ну как настраиваю, создаю файл *.gitignore* ну и инициализацию репозиторий. Пример .gitignore
по списку поясню только каталог build - в него производится сборка проекта, поэтому чтобы не отвлекаться на него и случайно не нагадить в коммит его и игнорим. Логи любит создвать Makefile Tools, они мне тоже ни к чему.
Если очень чешутся руки, то на данном этапе уже можно в терминале VSCode дать команду `make prog`, соберётся Ваш пустой проект и запишется в процессор. Процесс сборки будет отображаться здесь же в терминале, а об успешной записи Вам сообщит openocd примерно вот так
Желающие почесали руки, продолжаем. В каталоге .vscode проекта нужно создать файл tasks.json примерно такого содержания
Собственно здесь объявляются три задачи: сборка проекта, очистка рабочего каталога и прошивка контроллера. Можно конечно и здесь расписать все команды с параметрами, раньше так и делал, но потом стало лень дублировать команды, следить что бы они были одинаковыми в Makefile и тут. Ну в общем остановился на таком варианте. Работает же.
Теперь создаём launch.json c вот таким содержимым
Страшная штука. Собственно "name" может иметь любое значение, оно влияет только на отображение. Поле "executable" должно иметь значение файла в который собирается ваша программа, с указанием пути от каталога проекта. У Вас оно своё, поэтому вместо Habr должно быть то, чему у вас равно TARGET = в Makefile. В "svdFile" прописываем svd файл нашего процессора. Если вы его положили не в корень проекта, то нужно указать путь от каталога проекта. В "configFiles" указываем те самые скрипты, которые мы добавляли в Makefile для прошивки контроллера. И последний момент "preLaunchTask": "Build" - запуск задачи сборки программы из tasks.json, что бы было чего прошивать и отлаживать.
А теперь момент без которого всё это добро не работает - необходимо сообщить программе, где лежат бинарники openocd и gdb, причём не пути к каталогам с ними, а именно сами программы. Сделать это нужно в глобальном файле settings.json, пока так стабильно работает. Так как сам этот файл слегка закопан, к тому же, в Linux и Windows находится в разных местах, то я для себя нашёл простой способ его открыть. Идём Файл -> Настройки -> Параметры, откроется вкладка с настройками. Далее Текстовый редактор -> Шрифт и ищем надпись Изменить в settings.json. В открывшийся файл нужно добавить следующие строчки
"cortex-debug.armToolchainPath" - просто путь к каталогу в котором ваш *arm-none-eabi-gcc*, вот тут просто каталог
"cortex-debug.openocdPath" - полный путь к бинарнику openocd, для винды будет заканчиваться на .exe
"cortex-debug.gdbPath" - полный путь к бинарнику gdb котрым Вы будете пользоваться
Ну и финишная прямая.
В файле main.c чуть-чуть меняем функцию main() на вот такое
Честно говоря страшнее кода придумать с ходу не смог. Хочу просто показать, что ЭТО ВСЁ может жить.
Теперь на __ASM("NOP"); ставим точку останова, переходим "Запуск и Отладка" и запускаем всё это добро, нажав на зелёный треугольничек.
В Терминале побежали надписи процесса компиляции и через пару секунд всё остановится на вот такой картинке
ПОЗДРАВЛЯЮ, ВЫ В ОТЛАДКЕ.
Можете просто нажать F5 или значок проигрывания и наслаждаться мигающим светодиодом!
На этом у меня всё! Можно было бы ещё рассказать про настройку IntelliSense, но во-первых такого добра и так навалом, а во-вторых проблема уже частично решается плагином Makefile Tools, хоть пока и неидеально, но для начала хватает.
Читайте также: