Создание и изменение конфигураций
В дополнение к встроенным конфигурациям отладки и выпуска можно создать несколько конфигураций сборки для решения. Например, можно создать конфигурацию тестирования для внутренних сборок тестирования и настроить различные типы сборок, которые можно распространять для разных клиентов.
Создание конфигураций сборки
Диалоговое окно Диспетчер конфигураций служит для выбора или изменения существующих конфигураций сборки, а также для создания новых.
Чтобы открыть диалоговое окно Configuration Manager, в Обозреватель решений щелкните правой кнопкой мыши узел решения, чтобы открыть контекстное меню решения, а затем выберите Configuration Manager.
Вы также можете открыть Configuration Manager , щелкнув раскрывающийся список на панели инструментов Visual Studio, которая позволяет выбрать текущую конфигурацию (например, отладку или выпуск).
Существует два уровня конфигурации, конфигурация решения и конфигурация проекта. Конфигурация решения — это то, что вы выбираете при переключении активных конфигураций с помощью панели инструментов в Visual Studio. Конфигурация проекта — это конкретная конфигурация для каждого проекта.
В диалоговом окне Диспетчер конфигураций в раскрывающемся списке Активная конфигурация решения можно выбрать конфигурацию сборки для всего решения, изменить существующую или создать новую конфигурацию. Вы можете использовать раскрывающийся список «Активная платформа решения», чтобы выбрать платформу , предназначенную для конфигурации, изменить существующую или добавить платформу. Если вы добавляете платформу решения, она должна поддерживаться по крайней мере одним из проектов.
В области Конфигурации проектов перечислены все проекты в решении. Для каждого проекта можно выбрать конфигурацию и платформу для конкретного проекта, изменить существующие или создать новую конфигурацию или добавить новую платформу из списка платформ, поддерживаемых Visual Studio. Кроме того, можно установить флажки, которые указывают, включается ли конкретный проект при использовании конфигурации на уровне решения для сборки или развертывания решения.
Visual Studio не применяет никаких требований, которые вы выбрали в этом диалоговом окне, для платформы решений. Например, вы не можете задать все платформы проектов x86 на то, когда активная платформа решения имеет x64 значение, поэтому не забудьте избежать путаницы и выбрать платформы проектов, соответствующие платформе решения по возможности.
Задание свойств на основе конфигураций
Чтобы задать свойства на основе конфигураций, в обозревателе решений откройте контекстное меню для проекта и выберите пункт Свойства.
Большинство свойств проекта не зависят от конфигурации или платформы, но некоторые из них. Для конфигурации выпуска можно указать, что код оптимизирован при построении решения, а для конфигурации отладки можно указать, что DEBUG символ условной компиляции определен. Вы также можете выбрать предупреждения, которые нужно отключить или повысить до ошибок, в зависимости от конфигурации или платформы, а также управлять определенными параметрами, влияющими на некоторые параметры компилятора, Арифметическое переполнение, выравнивание файлов и параметр компилятора /deterministic .
На страницах свойств проекта страницы с параметрами, зависящими от конфигурации и платформы, имеют раскрывающиеся списки, позволяющие выбрать конфигурацию и платформу, к которым применяются текущие значения параметров.
Большинство свойств проекта не зависят от конфигурации или платформы, но некоторые из них. Для конфигурации выпуска можно указать, что код оптимизирован при построении решения, а для конфигурации отладки можно указать, что DEBUG символ условной компиляции определен. Вы также можете выбрать предупреждения, которые нужно отключить или повысить до ошибок, в зависимости от конфигурации или платформы, а также управлять определенными параметрами, влияющими на некоторые параметры компилятора, Арифметическое переполнение, выравнивание файлов и параметр компилятора /deterministic .
Свойства, которые можно задать по-разному на основе конфигурации и платформы, имеют значок шестеренки рядом с ними на странице параметров проекта. Если щелкнуть значок шестеренки, появится меню, которое позволяет выбрать одинаковые или разные значения на основе конфигурации, платформы или обоих.
Дополнительные сведения о параметрах страницы свойств см. в статье Управление свойствами проекта и решения.
Создание конфигурации проекта
При добавлении нового типа сборки создается новая конфигурация проекта. Например, вместо отладки и выпуска можно создать конфигурации разработки, тестирования и рабочей среды.
- Откройте диалоговое окно Диспетчер конфигураций.
- Выберите проект в столбце Проект.
- В раскрывающемся списке Конфигурация для этого проекта выберите Создать. Откроется диалоговое окно Создание конфигурации проекта.
- В поле Имя введите имя новой конфигурации.
- Чтобы использовать значения свойств из существующей конфигурации проекта, в раскрывающемся списке Копировать параметры из выберите конфигурацию. Параметры можно настроить позже на страницах свойств проекта.
- Чтобы одновременно создать конфигурацию на уровне решения, установите флажок Создать новую конфигурацию решения.
Переименование конфигурации проекта
- Откройте диалоговое окно Диспетчер конфигураций.
- В столбце Проект выберите проект, который содержит нужную конфигурацию проекта.
- В раскрывающемся списке Конфигурация для этого проекта выберите Изменить. Откроется диалоговое окно Изменение конфигураций проекта.
- Выберите имя конфигурации проекта, которую требуется изменить.
- Выберите Переименовать, а затем введите новое имя.
Создание и изменение конфигураций сборки на уровне решения
Создание конфигурации сборки на уровне решения
- Откройте диалоговое окно Диспетчер конфигураций.
- В раскрывающемся списке Активная конфигурация решения выберите Создать. Откроется диалоговое окно Создание конфигурации решения.
- В текстовом поле Имя введите имя новой конфигурации.
- Чтобы использовать параметры из существующей конфигурации решения, в раскрывающемся списке Копировать параметры из выберите конфигурацию.
- Если вы хотите одновременно создать конфигурации проекта, установите флажок Создать новые конфигурации проекта.
Переименование конфигурации сборки на уровне решения
- Откройте диалоговое окно Диспетчер конфигураций.
- В раскрывающемся списке Активная конфигурация решения выберите Изменить. Откроется диалоговое окно Изменение конфигураций решения.
- Выберите имя конфигурации решения, которую требуется изменить.
- Выберите Переименовать, а затем введите новое имя.
Изменение конфигурации сборки на уровне решения
- Откройте диалоговое окно Диспетчер конфигураций.
- В раскрывающемся списке Активная конфигурация решения выберите нужную конфигурацию.
- В области Конфигурации проектов для каждого проекта выберите нужную конфигурацию и платформу, а также выберите, требуется ли выполнять его сборку и развертывание.
Связанный контент
- Общие сведения о конфигурациях сборок
- Настройка проектов для целевых платформ
- Создание и очистка проектов и решений в Visual Studio
- Управление свойствами проектов и решений
- Создание и изменение конфигураций (Visual Studio для Mac)
Общие сведения о конфигурациях сборок
Конфигурации сборок требуются для создания проектов с разными параметрами. Например, отладка и выпуск — это конфигурации сборки, а при их создании используются разные параметры компилятора. Одна конфигурация является активной и отображается на панели команд в верхней части интегрированной среды разработки.
Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье Конфигурации сборки в Visual Studio для Mac.
Параметры «Конфигурация» и «Платформа» позволяют определить, где будут храниться выходные файлы сборки. Как правило, когда в Visual Studio выполняется сборка проекта, выходные данные помещаются во вложенную папку проекта с именем активной конфигурации (например, bin/debug/x86). Но это можно изменить.
Вы можете создавать свои конфигурации сборки на уровне решения и проекта. Конфигурация решения определяет, какие проекты включаются в сборку, когда эта конфигурация активна. В сборку будут включены только проекты, указанные в активной конфигурации решения. Если в Configuration Manager выбрано несколько целевых платформ, будут построены все проекты, которые применяются к этой платформе. Конфигурация проекта определяет, какие параметры сборки и компилятора используются при сборке проекта.
Чтобы создать, выбрать, изменить или удалить конфигурацию, можно использовать Configuration Manager. Чтобы открыть его, выберите в строке меню Сборка>Configuration Manager или просто введите Configuration в поле поиска. Можно также использовать список Конфигурации решения на панели инструментов Стандартные, чтобы выбрать конфигурацию или открыть Configuration Manager.
Если вы не можете найти параметры конфигурации решения на панели инструментов и не сможете получить доступ к Configuration Manager, это может быть связано с тем, что вы используете параметры разработки Visual Basic. Дополнительные сведения см. в разделе Управление конфигурациями сборок с применением параметров разработчика Visual Basic.
По умолчанию конфигурации отладки и выпуска включаются в проекты, созданные с помощью шаблонов Visual Studio. Конфигурация Debug поддерживает отладку приложения, а конфигурация Release создает версию приложения, которое можно развернуть. Дополнительные сведения см. в пошаговом руководстве по настройке конфигураций отладки и выпусков. Можно также создать пользовательские конфигурации решений и проектов. Дополнительные сведения см. в разделе Практическое руководство. Создание и изменение конфигураций.
Конфигурации решения
Конфигурация решения указывает, как следует создавать и развертывать проекты в решении. Чтобы изменить конфигурацию решения или определить новую конфигурацию в Configuration Manager, в меню Активная конфигурация решения щелкните Изменить или Создать.
Каждая запись в поле Контексты проекта в конфигурации решений представляет проект в решении. Для каждой комбинацииАктивная конфигурация решения и Активная платформа решения можно задать способ использования каждого проекта.
При определении новой конфигурации решения и выборе поля «Создание конфигураций проектов» проверка Visual Studio создает новую конфигурацию проекта во всех проектах. Аналогичным образом, при определении новой платформы решения и выборе поля «Создание новых платформ проектов» проверка Visual Studio создает новый параметр платформы во всех проектах. Кроме того, если добавить проект, предназначенный для новой платформы, Visual Studio добавляет эту платформу в список платформ решений и делает платформу доступной в качестве варианта во всех проектах. Параметры каждого проекта можно изменить, если платформы не нужны или поддерживаются некоторыми проектами.
Активная конфигурация решения также предоставляет контекст для IDE. Например, если вы работаете над проектом и конфигурация указывает, что он будет создан для мобильного устройства, на панели инструментов отобразятся только элементы, которые можно использовать в проекте мобильного устройства.
Конфигурации проекта
Параметры сборки и компилятора, используемых при сборке проекта определяют конфигурация и целевая платформа. В проекте могут быть разные параметры для каждой комбинации конфигурации и платформы. Чтобы изменить свойства проекта, откройте контекстное меню проекта в обозревателе решений и щелкните Свойства. В верхней части вкладки Сборка конструктора проектов выберите активную конфигурацию, чтобы изменить параметры сборки.
Как Visual Studio связывает конфигурации проектов с конфигурациями решений
При определении новой конфигурации решения и не копируйте параметры из существующего, Visual Studio использует следующие критерии, чтобы связать существующие конфигурации проекта с новой конфигурацией решения. Критерии оцениваются в следующем порядке.
- Если у проекта есть имя конфигурации (имя> платформы конфигурации), соответствующее имени новой конфигурации решения, используется эта конфигурация. В именах конфигураций не учитывается регистр.
- Если у проекта есть имя конфигурации, в котором часть имени конфигурации соответствует новой конфигурации решения, используется ли эта конфигурация, совпадает ли часть платформы.
- Если совпадения по-прежнему нет, используется первая конфигурация, указанная в проекте.
Как Visual Studio связывает конфигурации решений с новыми конфигурациями проекта
При создании конфигурации проекта (в Configuration Manager путем выбора пункта Создать в раскрывающемся меню столбца Конфигурация для этого проекта) и установке флажка Создать новые конфигурации решений Visual Studio ищет конфигурацию решения с таким же именем, чтобы создать проект на каждой поддерживаемой платформе. В некоторых случаях Visual Studio переименовывает существующие конфигурации решения или определяет новые.
Visual Studio использует следующие критерии для связывания конфигураций решений с конфигурациями проекта:
- Если конфигурация проекта не указывает платформу или указывает только одну платформу, будет найдена или добавлена конфигурация решения, имя которой совпадает с именем новой конфигурации проекта. Имя по умолчанию этой конфигурации решения не включает имя платформы; он принимает имя>конфигурации проекта формы
- Если проект поддерживает несколько платформ, для каждой поддерживаемой платформы будет найдена или добавлена конфигурация решения. Имя каждой конфигурации решения включает имя конфигурации проекта и имя платформы, а также имя>платформы конфигурации<>проекта формы.
Как конфигурации влияют на сборку
При построении решения с помощью команды Сборка>Собрать решение, Visual Studio выполняет сборку только активной конфигурации. Все проекты, указанные в этой конфигурации решения, будут построены, и единственной конфигурацией проекта будет только одна из них, указанная в активной конфигурации решения и активной платформе решения, которая отображается на панели инструментов в Visual Studio. Например, Отладка и x86. Другие определенные конфигурации и платформы не создаются.
Если требуется создать несколько конфигураций и платформ в одном действии, можно использовать параметр Сборка>Пакетная сборка в Visual Studio. Для получения доступа к этой функции, нажмите Ctrl+Q, чтобы открыть поле поиска, и введите Batch build . Пакетная сборка доступна не для всех типов проектов. См . инструкции. Создание нескольких конфигураций одновременно.
Связанный контент
- Пошаговое руководство. Сборка приложения
- Компиляция и сборка
- Проекты и решения
- Образец построения C/C++
- Настройка проектов для целевых платформ
- Конфигурации сборки (Visual Studio для Mac)
STM32 fast start. Часть 1 ПО, материалы, Cube MX
В последнее время все чаще сталкиваюсь с холиварами на тему Cube MX и HAL, применительно к контроллерам STM32.
С одной стороны — стоят защитники, которым нравится удобство конфигурирования и читаемость кода.
С другой — приверженцы писать все руками, которым важна скорость работы и бережное использование ресурсов.
Для того, чтобы расставить все точки над i — попробуем написать «Hello world» тремя наиболее часто используемыми путями CMSIS, LL, HAL. Оценим затраты (ресурсы контроллера, объем исполняемого файла, и конечно же время работы разработчика).
Статья будет состоять из нескольких частей:
STM32 fast start. Часть 1 ПО, материалы, Cube MX.
STM32 fast start. Часть 2 Hello World на HAL, настройка отладки в Atollic TrueSTUDIO
STM32 fast start. Часть 3 Hello World на LL
STM32 fast start. Часть 4 Hello World на CMSIS
STM32 fast start. Часть 5 Подведение итогов, сравнение HAL, LL, CMSIS.
Сначала давайте определимся с тем, что же мы собственно будем программировать, то есть найдем подходящее железо.
Идеальным вариантом будет бюджетная плата на STM32F103C8T6 микроконтроллере.
Данную плату можно найти на всем известном сайте по цене от 100 российских рублей.
Искать по ключевым словам: STM32F103C8T6 ARM STM32 Minimum
Для того, чтобы залить прошивку и поиграть с отладкой — так же потребуется программатор
Для начала, да и для дальнейшего использования идеально подойдет китайский клон программатора ST-LINK V2.
Купить можно на том же сайте по цене от 120 российских рублей.
Искать по ключевым словам ST LINK Stlink ST 252dLink V2 Mini STM8 STM32:
Для разработки ПО под STM32 можно использовать различные IDE.
Самые популярные — IAR, Keil, Coocox (Eclipse).
Мы же пойдем по пути, который с недавних пор абсолютно бесплатно и в полном объеме предоставляет сама ST.
Будем использовать Atollic TrueSTUDIO for STM32 или в простонародии «Толик».
Какие плюсы у данного ПО: абсолютно бесплатно, нет ограничения по размеру кода, есть неплохой отладчик, простая установка и настройка.
Минусы: нет авто дополнения кода.
Доступны версии под windows и linux.
Качаем здесь https://atollic.com/resources/download/
С установкой данного ПО проблем возникнуть не должно, все интуитивно понятно, выбираем куда ставить и жмем все время «далее».
После установки можно не запускать, так как помимо самой IDE нужно еще кое что.
Если все таки запустили — просто закрываем.
Так как TrueSTUDIO — это средство разработки и отладки, хотелось бы не собирать проект руками (подключая требуемые библиотеки и прописывая пути), а получить некий преднастроенный файл, в котором можно без лишних заморочек сразу же писать код.
Для этого применяется программа генератор кода Cube MX или в простонародии «Калокуб».
Данное ПО является первым камнем преткновения в холиварах на чем же писать под STM: на регистрах и CMSIS или на HAL.
Защитники первой идеологии приводят такие аргументы: Cube MX генерирует огромный, ненужный объем кода, который к тому же замедляет работу МК.
Защитники второй — заявляют, что автоматически сгенерированный код сокращает время разработки, позволяя разработчику быстрее переключится к сутевой части устройства (к основной логике), отдав рутинную настройку периферии на откуп специализированному ПО (Cube MX).
Как ни странно — обе эти идеологии правдивы и применимы на практике, но только каждая в своих условиях.
Давайте рассмотрим пару примеров:
Пример №1: Требуется разработать устройство, максимально дешевое, так как планируется производство партиями по 100500 шт ежегодно. Естественно, каждый лишний рубль цены устройства — выльется в сотни тысяч рублей затрат на финальном устройстве. При этом в планируемой разработке есть пара тяжелых расчетов и работа с периферией (ADC, SPI, UART) на максимальных скоростях.
Устройство является полностью автономным продуктом, в дальнейшем планируется минимальные изменения за весь срок производства данного оборудования. Срок разработки до получения готового образца — 1-2 года.
Пример №2: Требуется прототип устройства, который возможно заинтересует заказчика и он закажет 100 шт аналогичных устройств для переоборудования своего объекта. Первая планируемая партия должна быть отгружена заказчику через 2 месяца. Размер первой тестовой партии 10 шт.
Точное ТЗ будет корректироваться в процессе работы над проектом, но известно, что в дальнейшем планируется несколько переработок аппаратной части, под которую необходимо оперативно подстраивать всю прикладную логику.
В первом примере идеальным вариантом будет выбор максимально дешевого контроллера и написание аппаратно зависимого, но оптимального кода, где работа с периферией будет организована через обращение к соответствующим регистрам (CMSIS). Разработчик, который занимается данным проектом — должен обладать хорошими или отличными знаниями периферии конкретного семейства МК. В идеале — при попытке разбудить его ночью — должен сразу же назвать адрес требуемого вектора из таблицы векторов прерываний.
Во втором примере — выбор контроллера обусловлен имеющимся в наличии железом, а так же затратами времени для написания функционала требуемого заказчиком. Поэтому скорость работы и оптимизированность самого ПО отходит на второй план. Времени на ручную инициализацию нет, как нет времени и на проработку аппаратных зависимостей.
В таком случае выбирается контроллер, который можно быстро поставить в производство в текущем регионе, на нем делается инициализация с помощью Cube MX, пишется прикладная логика на HAL и прототип передается заказчику для тестирования. Такой проект может вести любой средний разработчик, который постиг навыки работы с целевым языком программирования. Вникание в тонкости работы периферии — практически не требуются.
Как бы это не печально звучало — в реалиях современной разработки устройств в России — пример №1 встречается все реже, передавая эстафету примеру №2.
К обсуждению примеров №1 и №2 вернемся в самом конце цикла статей, а сейчас продолжим с подготовкой рабочего пространства.
На данном этапе сделаем небольшую паузу, зайдем на сайт my.st.com и зарегистрируем на нем учетную запись, так как политика компании ST не позволяет скачивать необходимые материалы без регистрации.
После того, как у нас появился доступ к сайту — скачиваем STM32 Cube MX.
В самом низу страницы есть кнопка выбора версии, нам нужна версия 5.0.0
Попутно, пока мы не ушли отсюда, качаем еще две вещи, которые пригодятся в дальнейшем
https://www.st.com/en/development-tools/stsw-link008.html
Драйвер ST-LINK V2
Установка драйвера, прошивальщика и самого Cub’a не вызывают затруднений, просто соглашаемся со всем и жмем далее.
После полной установки необходимого ПО — можем приступать к созданию проекта.
Для этого запустим Cube MX.
В появившемся окне нажмем на кнопку «ACCESS TO MCU SELECTOR».
На нашей целевой плате установлен микроконтроллер STM32F103C8T6.
Введем его название в строке поиска и двойным щелчком выберем единственный найденный вариант.
В этой же таблице видно основную начинку нашего МК (64 килобайт флеша, 20 килобайт оперативы и пр).
Перед нами появился схематически изображенный корпус контроллера с разведенными в разные стороны ножками.
На данном этапе необходимо обязательно выбрать способ подключения отладчика.
Для этого на вкладке Pinout & Configuration в левом меню выбираем пункт SYS а в нем в выпадающем списке под названием «Debug» устанавливаем значение Serial Wire.
При этом краем глаза замечаем, что программа зарезервировала для отладочных целей два пина на мнемосхеме контроллера.
Еще раз вспоминаем, что мы хотим помигать светодиодом на нашей плате.
Для этого необходимо сначала узнать, к какой именно ножке он подключен.
В этом нам поможет схема электрическая принципиальная:
или более красочная и простая для понимания распиновка платы
Искомый светодиод находится на ножке PC13.
Соответственно, необходимо настроить данный вывод для работы в режиме выхода.
- Находим вывод на мнемосхеме
- Нажимаем на него правой кнопкой мыши, из выпадающего меню выбираем пункт «GPIO_Output»
- Переходим в меню GPIO,
- В списке выбираем PC13
- Заполняем таблицу PC13-TAMPER-RTC Configuration в соответствии со скриншотом, особенно нас интересуют параметры GPIO mode и User Label
Продолжаем настройку проекта, переходим к вкладке Clock Configuration.
На самом деле это одна из важнейших вкладок, которая позволяет настроить параметры тактирования периферии, но пока не будем здесь ничего трогать, так как главная цель на данный момент не в этом.
Переходим к вкладке Project Manager, под вкладка Project.
Обязательно заполняем следующие параметры:
- Имя проекта (лучше использовать только латинские буквы)
- Директорию, в которой будет создан проект (так же лучше использовать только латиницу)
- IDE, в которой планируется работа над проектом (мы планируем использовать TrueSTUDIO)
Спускаемся ниже, под вкладка Code Generator.
Здесь обязательно отмечаем опцию Generate peripheral initialization as pair…
Таким образом получим более структурированный проект, в котором для каждого типа периферии имеется своя пара C и H файлов.
Остался последний шаг. Подвкладка Advanced Settings.
- Выбираем тип библиотеки HAL для всех периферийных модулей
- Собираем проект с текущими настройками
При первоначальном запуске возможно потребуется загрузить актуальную версию библиотеки для выбранного семейства МК.
Даем свое согласие на скачивание файлов:
Идем греть чайник или готовить кофе:
После окончания работы кодо-генератора — сразу же открываем его:
Выбираем любую папку, где Atollic будет хранить рабочее пространство:
При успешном открытии — перед нами предстанет главное окно Atollic TrueSTUDIO for STM.
Общая информация нас мало интересует, поэтому сразу перейдем к дереву файлов.
Найдем там файл main.c и функцию int main(void):
Для самопроверки — попробуем собрать пустой проект
- В меню Project -> Rebuild Project
- Внизу выбрать вкладку Console
- При успешной сборке — должны получить надпись Build Finished
Продолжение — в следующей части.
P.S.: Ранее статью публиковал в своем личном блоге .
Прошивка и отладка STM32 в VSCode под Windows
На хабре уже есть немало информации об отладке МК в VSCode на Linux (тыц, тыц), также было написано как настроить тулчейн для работы под Windows в QT Creator, Eclipse, etc.
Пришло и моё время написать похожую статью, но для VS Code и под Widnows.
Инициализация проекта будет проводиться с помощью STM32CubeMX. Сборкой будет управлять CMake с тулчейном stm32-cmake. В качестве компилятора используется ARM GNU Toolchain. Тестовым стендом является NUCLEO-F446ZE.
Источниками вдохновения послужили:
- Репозиторий stm32-template
- Видео EbeddedGeek
- Видео Matej Blagšič
Предисловие окончено, приступаем к настройке.
Установка необходимых утилит
Для удобства установки будем пользоваться пакетным менеджером Scoop.
Для его установки достаточно прописать в powershell следующие команды:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser; irm get.scoop.sh | iex
Добавим необходимые репозитории
scoop bucket add main scoop bucket add extras
И, наконец, сами программы:
scoop install meson scoop install ninja scoop install cmake scoop install llvm scoop install gcc-arm-none-eabi scoop install stlink scoop install openocd scoop install git
meson, ninja, cmake, llvm и gcc-arm-none-eabi используются для конфигурации и сборки проекта, stlink и openocd являются gdb-серверами, git необходим для подключения различных тулчейнов.
Если у вас уже есть что-то из этого и вы можете вызвать его через консоль (т.е. программа добавлена в path) то советую либо убрать её из скрипта либо удалить у себя, и установить через scoop.
Настройка VS Code
Для работы потребуются установить в VS Code следующие расширения:
- C/C++ Extension Pack
- CMake
- CMake Tools
- Cortex-Debug
- Memory View
- Tasks
- Command Variable Также рекомендую Doxygen Documentation
Инициализация проекта
Открываем CubeMX и создаем проект для нашей платы. Всю периферию оставляем настроенной по умолчанию.
В параметрах проекта (Project Manajer) выбираем Make в качестве тулчейна
В параметрах генератора кода указываем подключение бибилотек только в виде ссылок
Настройка системы сборки
Открываем папку проекта в VS Code и вызываем терминал командой Ctr+~
Скачиваем stm32-cmake
git clone --recurse-submodules -j8 https://github.com/ObKo/stm32-cmake.git
Также потребуются файлы .clang-format , .clang-tidy , fetch_svd.cmake , и CMakeLists.txt из репозитория stm32-template. Для удоства клонируем его в соседнюю директорию.
git clone https://github.com/Dooez/stm32-template.git ../stm32-template
.clang-format , .clang-tidy необходимы LLVM, а fetch_svd.cmake используется для поиска файла описания регистров конкретного микроконтроллера.
Отредактируем CMakeLists.txt под наш проект.
Изменим переменную MCU на STM32F446ZE
set(MCU STM32F446ZE)
По умолчанию «кубик» инициализирует на плате NUCLEO-F446ZE USART3, USB_OTG_FS и несколько GPIO. Добавим библиотеки в проект, для этого необходимо для сборки прописать команду target_link_libraries . Также добавим библиотеку CMSIS и, для уменьшения размеров прошивки, Newlib Nano и NoSys
target_link_libraries($ HAL::STM32::$::RCC HAL::STM32::$::GPIO HAL::STM32::$::UART HAL::STM32::$::CORTEX HAL::STM32::$::LL_USB HAL::STM32::$::PCD HAL::STM32::$::PCDEx CMSIS::STM32::$ STM32::Nano STM32::NoSys )
Чтобы CMake мог увидеть файлы, сгенерированные кубиком, необходимо добавить их в Include Path и явно указать исполняемые c/cpp файлы.
add_executable($ Core/Src/main.c Core/Src/stm32f4xx_it.c Core/Src/stm32f4xx_hal_msp.c ) target_include_directories($ PRIVATE $ $/Core/Inc $/Core/Src )
main.c содержит, собственно, функцию main() , в stm32f4xx_it.c находится функция, которая считает количество срабатываний SysTick , без которой не будут работать такие функции как HAL_Delay() , а в stm32f4xx_hal_msp.c содержится часть инициализации периферии.
Также для уменьшения размера исполняемого файла, добоавим следующие директивы компилятора:
target_compile_options($ PUBLIC -Os -fno-exceptions -fno-rtti)
Настройка проекта под VS Code
Нажимаем сочетание клавиш Ctrl+Shift+P и в появившейся строке находим
Preferences: Open Workspace Settings (JSON)
В создавшемся файле .vscode/settings.json указаны параметры для расширений и корректного отображения кода. Пишем:
< "cmake.generator": "Ninja", "cmake.configureEnvironment": < "CMAKE_EXPORT_COMPILE_COMMANDS": "on" >, "C_Cpp.default.intelliSenseMode": "gcc-arm", "cortex-debug.gdbPath": "arm-none-eabi-gdb", "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools" >
Далее по тому же сочетанию находим Tasks: Configure Task и выбираем cmake build
В создавшийся файл .vscode/tasks.json добавляем задания для прошивки и очистки памяти микроконотроллера с помощью st-flash. Итоговый файл tasks.json выглядит следующим образом:
< "version": "2.0.0", "tasks": [ < "type": "cmake", "label": "CMake: build", "command": "build", "targets": [ "ALL_BUILD" ], "problemMatcher": [], "group": "build" >, < "type": "shell", "label": "flash", "command": "st-flash", "args": [ "--reset", "write", "$/build/$.bin", "0x8000000" ], "options": < "cwd": "$/build" >, "dependsOn": "CMake: build", "problemMatcher": [], "group": < "kind": "build", "isDefault": true >, "detail": "Builds project and flashes firmware." >, < "type": "shell", "label": "erase", "command": "st-flash", "args": [ "--connect-under-reset", "erase" ], "detail": "mass erase of chip" >], "inputs": [ < "id": "workspaceFolderForwardSlash", "type": "command", "command": "extension.commandvariable.transform", "args": < "text": "$", "find": "\\\\", "replace": "/", "flags": "g" > > ] >
Также при желании можно добавить команду для прошивки с помощью OpenOCD
Для STM32F4 она выглядит следующим образом
< "type": "shell", "label": "flash-openocd", "command": "openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c 'program $/build/$.bin verify reset exit' ", "dependsOn": "CMake: build", "problemMatcher": [], "group": < "kind": "build", "isDefault": true >, "detail": "Builds project, connects to the openOCD server and flashes new firmware." >
Далее необходимо сконфигурировать расширение CMake для VS Code
Нажимаем сочетание клавиш Ctrl+Shift+P и в появившейся строке находим
CMake: Configure и выбираем конфигурацию под arm-none-eabi
После конфигурации автоматически сгенерируется файл .vscode/launch.json , рассмотрим его поподробнее:
< "configurations" : [ < "cwd" : "$", "device" : "STM32F446ZE", "executable" : "$/build/$.elf", "name" : "Cortex Debug (generated)", "preLaunchTask" : "CMake: build", "preRestartCommands" : [ "load", "enable breakpoint", "monitor reset" ], "request" : "launch", "runToEntryPoint" : "main", "servertype" : "stutil", "showDevDebugOutput" : "raw", "svdFile" : "$/build/_deps/st-svd-archive-src/STM32F4_svd_V1.8/STM32F446.svd", "type" : "cortex-debug" > ], "version" : "0.2.0" >
svdFile – путь до файла, который необходим, чтобы просматривать регистры периферии МК
«preLaunchTask»: CMake: build – компилирует проект перед прошивкой МК.
preRestartCommands – отправляет команды через GDB при нажатии на кнопку перезапуска отладки
Скрипт fetch_svd.cmake по умолчанию использует в качетсве GDB-сервера stutils. Примеры конфигурации под OpenOCD и JLink можно посмотреть на вики cortex-debug в приложенных ссылках.
Переходим к коду (наконец-то)
Не мудрствуя лукаво, пойдём мигать светодиодом. (и ещё немного поиграемся с выделением памяти). Изменим main() следующим образом
#include "stdlib.h" uint8_t* data; int main(void) < HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART3_UART_Init(); /* USER CODE BEGIN 2 */ data = new uint8_t[16]; uint8_t const_data[16]; for(int i = 0; i < 16; i++)< data[i] = i+1; const_data[i] = i+1; >/* USER CODE END 2 */ /* Infinite loop */ while (1) < HAL_GPIO_TogglePin(LD3_GPIO_Port, LD3_Pin); HAL_Delay(50); >>
Компиляция проекта осуществляется нажатием клавиши F7 либо сочетанием Ctrl+Shift+B . Так как ранее мы в launch.json указали сборку перед прошивкой, то нам будет достаточно нажать F5 и перейти сразу к отладке. Рассмотрим интерфейс:
Первая кнопка осуществляет программный сброс (software reset) устройства
Вторая запускает код (горячая клавиша F5 )
Третья, четвёртая и пятая – «шаг» вперёд к следующей функции, «шаг» вперёд к следующей инструкции (т.е. с погружением) и выполнение код до выхода из функции.
Шестая клавиша осуществляет пересборку проекта и перезапуск прошивки.
А седьмая останавливает отладку.
Окно слева содержит следующие разделы:
- Cortex Registers – регистры процессора
- Cortex Peripherals – регистры периферии (например, там можно смотреть и изменять состоянием регистров GPIO и мигать светодиодом с помощью мышки, хехе)
- Breakpoints – список выставленных прерываний. Отмечу, что у разных микроконтроллеров и отладчиков допустимо различное число брейкпоинтов (Например, у ST-Link V2.1 их всего 6)
- В CallStack можно посмотреть очередь вызова (вплоть до main, что логично)
- Раздел Variables позволяет просматривать как локально объявленные переменные, так и глобальные, например uwTick , показывающую количество милисекунд от момента запуска МК
- В Memory View можно посмотреть в любой доступный раздел памяти МК
Рассмотрим возможности Watch Window (и заодно сравним его с Keil MDK)
Массив const_data был объявлен статически, и его можно посмотреть просто по названию, тут всё как везде
А теперь попробуем посмотреть содержимое динамически выделенного массива:
Здесь, так же как и везде, дебаггер отобразит лишь первый элемент (в кавычках можно увидеть содержимое до первого \0 ). Однако, в отличие от, например, Keil MDK, мы можем явно указать, как именно следует воспринимать данный указатель:
Такая возможность часто бывает необходима не только для динамически выделенных массивов, но и, например, при передаче в функцию указателя на какой-либо буфер.
Также мы можем переопределить этот указатель написав, например, такой запрос:
*(uint16_t*)data@8
Тогда в Watch Window будет показано отображение массива типа short , а не uchar