Visual Studio 2017 — написание и отладка проекта для SoC

С прошлого раза применения Visual Studio 2015 для написания прошивки и отладки под SoC прошло немало времени. 2017-я версия заметно обновилась, появилось много удобных фич, нововведений для C# 8.0, и, что также важно, обросла плюшками для эмбеддерского применения.

Сразу отмечу, что этот материал подходит для версии Visual Studio 2017 не ниже v15.6.7, я же использовал v15.7.1 вначале и далее обновился до v15.7.3 при написании материала.

B62-0

Проект для примера

Для примера возьмём проект RTL00_WEB. Я сделал его форк — RTL00_WEB, тут будут все изменения, а также правки мелких ошибок оригинального проекта. На основе этой прошивки я покажу, что нужно сделать, чтобы его можно было открыть в Visual Studio 2017 как workspace-проект (привет Eclipse! хотя, честно говоря, мне такой подход не очень нравится, но он быстр и в целом достаточно удобен, привыкнуть можно), скомпилировать в WSL (при желании можно использовать и нативные средства для Windows) и запустить отладку.

WSL и gcc-arm-none-eabi

Предполагается, что у вас уже установлен и обновлён WSL. Для компиляции проектов потребуются скачивание и распаковка GNU Arm Embedded Toolchain. Итак, находясь в папке пользователя (при запуске ubuntu), скачиваем в её корень последнюю (на момент написания статьи) версию командой:

$ wget -c https://developer.arm.com/-/media/Files/downloads/gnu-rm/7-2017q4/gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2

Примечание: Ссылку к архиву других версий самостоятельно вытягиваем\копируем со страницы GNU Arm Embedded Toolchain.

Распаковываем:

$ tar jxf gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2

Теперь можно удалить ненужный архив:

$ rm gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2

Вот и всё, подготовка WSL на этом закончена.

Подготовка проекта

Все изменения для открытия проекта в Visual Studio 2017 будут в виде добавления файлов с настройками и командами. Незначительные отличия в других файлах в основном нацелены на исправление ошибок или просто изменение параметров исходного проекта.

Итак, по порядку. В корне проекта обязательно должен быть файл CppProperties.json, он отвечает за основные настройки проекта, пример с поясняющими комментариями:

{
 "configurations": [
 {
 // Указываем настройки среды (важно для IntelliSense)
 "inheritEnvironments": [ "linux-gcc-arm" ],
 "name": "firmware",
 // Здесь указываем директории, которые будут парситься
 "includePath": [
 // Двойная звёздочка в конце пути - парсить всё рекурсивно
 "${workspaceRoot}\\USDK\\component\\**",
 "${workspaceRoot}\\project\\src\\**",
 "${workspaceRoot}\\project\\inc\\**"
 ],
 // Различные объявления и настройки для проекта, которые будут учитываться IntelliSense
 "defines": [
 "CONFIG_PLATFORM_8195A",
 "ARDUINO_SDK",
 "F_CPU=166666666L",
 "M3",
 "GCC_ARMCM3"
 ],
 // Режим работы IntelliSense - ставим GCC для АРМов
 "intelliSenseMode": "linux-gcc-arm",
 "browse": {
 "path": [
 "${workspaceRoot}"
 ],
 "limitSymbolsToIncludedHeaders": false,
 "databaseFilename": ""
 }
 }
 ],
 // Различные объявления путей к тулчейну или J-Link, действуют на все задачи
 "environments": [
 {
 "BUILDTOOLS": "\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Linux\\GNU MCU Eclipse\\Build Tools\\2.9-20170629-1013\"",
 "GCCARMTOOLS": "\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Linux\\gcc_arm\"",
 "JLINKPATH": "C:\\Data\\JLink_V632a",
 "BASHPATH": "C:\\Windows\\sysnative",
 "PATH": "${env.BUILDTOOLS};${env.JLINKPATH};${env.BASHPATH};${env.BUILDTOOLS}\\bin;${env.GCCARMTOOLS};${env.GCCARMTOOLS}\\bin;${env.PATH}"
 }
 ]
}

Далее есть два пути:

Первый: открыть папку в Visual Studio из меню File — > Open -> Folder… (Ctrl+Shift+Alt+O):

B62-1

Или, находясь в директории проекта, ПКМ на пустом месте и в контекстном меню выбираем Open in Visual Studio:

B62-2

И создать шаблоны необходимых файлов .vs\Launch.vs.json и .vs\Tasks.vs.json из контекстного меню, пункты Debug and Launch Settings (ПКМ на бинарном файле) и Configure Tasks (ПКМ на Makefile или любом не компилируемом файле), а далее откорректировать их содержимое (кликабельно):

Второй крайне простой: скопировать папку .vs из другого проекта (из которой нужны только вышеуказанные 2 файла, другие, находящиеся там файлы и папки генерируются и при копировании папки .vs их лучше удалять!) и внести коррективы.

Итак, неважно, каким путём созданы эти файлы, теперь разберём их содержание. Файл Launch.vs.json отвечает за отладку, пример его настройки с комментариями:

{
 "version": "0.2.1",
 "defaults": {},
 "configurations": [
 {
 // Указываем тип отладки и файлы прошивки
 "type": "cppdbg",
 "name": "ram_all.bin",
 "project": "build\\bin\\ram_all.bin",
 "cwd": "${workspaceRoot}",
 "program": "${workspaceRoot}\\build\\obj\\build.axf",
 "MIMode": "gdb",
 "externalConsole": true,
 "inheritEnvironments": [
 "gcc_arm"
 ],
 // Путь к отладчику, указан идущий в комплекте с Visual Studio
 "miDebuggerPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Linux\\gcc_arm\\bin\\arm-none-eabi-gdb.exe",
 "setupCommands": [
 {
 "text": "-environment-cd ${workspaceRoot}/build/obj"
 },
 {
 // Настройки запуска arm-none-eabi-gdb
 "text": "-file-exec-and-symbols build.axf",
 "description": "load file",
 "ignoreFailures": false
 },
 {
 "text": "-enable-pretty-printing",
 "ignoreFailures": true
 }
 ],
 // Настройки подключения к GDB серверу
 "visualizerFile": "${debugInfo.linuxNatvisPath}",
 "miDebuggerServerAddress": "localhost:2331"//,
 // Настройки авто запуска GDB сервера
 //"debugServerPath": "C:\\Data\\JLink_V632a\\JLinkGDBServer.exe",
 //"debugServerArgs": "-select USB -device Cortex-M4 -if SWD -speed 1000 -ir",
 //"serverLaunchTimeout": 3000
 }
 ]
}

Примечание: как можно заметить, настройки автоматического запуска GDB сервера закомментированы, т. к. сервер запускается, но к нему отладчик не подключается. Выяснить причину этого я пока не смог (буду рад, если напишете, в чем проблема в комментариях). Поэтому я просто запускаю GDB сервер из батника JLink-GDBServerM3.bat.

И второй файл Tasks.vs.json отвечает за все возможные задачи, которые будут отображаться для привязанного к задаче файла. Вот так это выглядит в контекстном меню:

B62-3

Содержание файла для проекта RTL00_WEB с комментариями:

{
 // Перечисление задач для всех файлов
 "version": "0.2.1",
 "tasks": [
 // Задачи по сборке проекта
 // Пример объявления задачи как стандартной для сборки проекта
 {
 "taskName": "Build",
 "appliesTo": "Makefile",
 "contextType": "build", // Это важное отличие от других задач
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s -j 10 all'"
 ]
 },
 // Пример объявления задачи как стандартной для очистки проекта
 {
 "taskName": "Clean",
 "appliesTo": "Makefile",
 "contextType": "clean", // Это важное отличие от других задач
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s clean'"
 ]
 },
 // Задачи для J-Link GDB Server
 // Не работает, VS ожидает завершения JLinkGDBServer
 /*{
 "taskName": "Start GDB Server",
 "appliesTo": "Makefile",
 "type": "launch",
 "command": "${env.COMSPEC}",
 "args": [
 "JLinkGDBServer.exe -select USB -device Cortex-M3 -if SWD -speed 1000 -ir"
 ]
 },*/
 // Задачи для J-Link
 {
 "taskName": "Restart SoC",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s reset'"
 ]
 },
 {
 "taskName": "Run in RAM",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s runram'"
 ]
 },
 {
 "taskName": "Run in SDRAM",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s runsdram'"
 ]
 },
 {
 "taskName": "Read Flash",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "JLink.exe -Device Cortex-M3 -If SWD -Speed 1000 USDK\\flasher\\RTL_FFlash.JLinkScript"
 ]
 },
 {
 "taskName": "Write OTA",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s flash_OTA'"
 ]
 },
 {
 "taskName": "Write Boot",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s flash_boot'"
 ]
 },
 {
 "taskName": "Write Flash_All",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 "bash -l -c 'make -s flash_burn'"
 ]
 },
 {
 "taskName": "Make and Write WEBFS",
 "appliesTo": "Makefile",
 "type": "default",
 "command": "${env.COMSPEC}",
 "args": [
 //"bash wsl_flash_webfs.sh",
 "bash -l -c 'make -s flash_webfs'"
 ]
 }
 ]
}

Примечание: как можно заметить, задача запуска GDB сервера закомментированна, т. к. сервер запускается, но Visual Studio ожидает завершения его работы и не даёт исполнять другие задачи. Как изменить логику запуска задачи, я не нашёл (буду рад, если напишете решение в комментариях).

Компиляция

С этим вообще вопросов не должно возникнуть… только если в WSL забыли Pyton установить или пути неверно прописали где-либо. Важный момент, кроме настройки WSL, — при установке Visual Studio 2017 обязательно требуется установить как основной компонент «Разработка для Linux на C++«, так и дополнительные «Инструменты Visual C++ для CMake и Linux» и «Разработка для встроенных платформ и Интернета вещей» (выделено красным на скриншоте ниже):

B62-6

Компиляция аналогична любым другим проектам — вызываем из контекстного меню на Makefile соответствующий пункт:

B62-19

Наблюдаем за компиляцией, если есть ошибки — переходы к ошибочному месту в файле (в Visual Studio 2015 с этим была проблема, т. к. изначально она не заточена под такого рода проекты) работают — двойной клик по первой строке ошибки с именем файла:

B62-7

А если глянуть в диспетчер задач, то можно увидеть силу сборки нативными средствами Linux — CPU используется максимально:

B62-8

Многопоточная сборка проекта за секунды. Вот практически и всё, после компиляции уже прошиваем модуль и радуемся. :)

Прошивка, отладка

На основе модуля RTL-00 вкратце опишу процесс прошивки и отладки. Вначале смотрим на распиновку модуля:

B62-9

Здесь, кроме питания, нас интересуют выводы GPIOE3 (SWDIO), GPIOE4 (SWCLK) и CHIP_EN (nRESET). Подключаем их к соответствующим выводам J-Link, я проверил работу с прошитым в J-Link опенсорс отладчиком x-Link. Для стабильной работы на nRESET добавлена подтяжка 10 кОм к питанию только (+3.3 В). Вот так это выглядит на столе (подтяжка с задней стороны модуля, SMD резистором):

B62-10

Запускаем GDB сервер, к которому сможет обращаться как WSL, так и отладчик Visual Studio с помощью батника JLink-GDBServerM3.bat, подключение к модулю происходит успешно:

B62-11

Переключаемся опять к Visual Studio, теперь прошиваем модуль задачей из контекстного меню на Makefile. Всё проходит успешно:

B62-12

Аналогично можно сразу же зашить WEB образ диска. Вот и всё, модуль автоматически стартанёт залитую в него прошивку.

Для отладки также должен быть запущен заранее GDB сервер. Выбран Startup File командой из контекстного меню на бинарном файле (а также необходимо перепроверить параметры в файле Launch.vs.json, к примеру, значение параметра «name«: «ram_all.bin» должно совпадать с именем выбранного файла):

B62-13

И если никаких ошибок не допустили, то сама отладка начинается простым нажатием на кнопку Start (F5) или из меню Debug -> Start:

B62-14

Подключение к GDB серверу:

B62-15

И вуаля, остановка на бряке с просмотром значений структуры настроек в текущем потоке FreeRTOS:

B62-16

Кликабельно:

Дополнительные вещи можно посмотреть в Debug вкладке меню.

Вывод

Явно проделана большая работа с Visual Studio 2017 для работы с непрофильными проектами Visual Studio (Visual C++, C# и т. д.), стало значительно проще открывать и конфигурировать проекты embedd, MCU или SoC, как в данном случае, более того, использовать нативные средства Linux из WSL для компиляции проекта с максимальной эффективностью без сторонних платных расширений как VisualGDB. Меня это очень порадовало, и, надеюсь, Visual Studio 2017 будет дальше развиваться в этом направлении.

Единственное, чего не хватает пока на эту тему — различных примеров. Есть пара мануалов для открытия и настройки экспортированного проекта Mbed и всё, остальное по крупицам надо собирать и доходить самому.

К слову, из удобных, небольших встроенных фич — Team Explorer, если у вас проект привязан к GitHub, то можно не выходя из Visual Studio 2017 запушить изменения вашего проекта на гит:

B62-18

На этом всё, спасибо, что прочитали! ;)

Ссылки

RTL00_WEB — форк оригинального проекта, готовый для работе в Visual Studio 2017;
Debugging an embedded ARM device in Visual Studio — официальный, краткий мануал для сборки MBED прошивки;
ARM GCC Cross Compilation in Visual Studio — официальный, расширенный мануал для сборки MBED прошивки;
Customizing your Environment with Visual C++ and Open Folder — описание содержания файлов CppProperties.json, Launch.vs.json и Tasks.vs.json;
Configuring launch.json for C/C++ debugging — хоть и для Visual Studio Code, но тоже может пригодится при написании Launch.vs.json;
Using Visual Studio Code for ARM — зарубежный блог со статьями для Visual Studio Code, мало ли, может пригодиться.

Добавить комментарий Отменить ответ

Введите свой комментарий...

Please log in using one of these methods to post your comment:

E-mail (обязательно) (Адрес никогда не будет опубликован)

Имя (обязательно)

Сайт

Для комментария используется ваша учётная запись WordPress.com. ( Выход / Изменить )

Для комментария используется ваша учётная запись Twitter. ( Выход / Изменить )

Для комментария используется ваша учётная запись Facebook. ( Выход / Изменить )

Отмена

Connecting to %s

A_D Electronics

development and research

Visual Studio 2017 — написание и отладка проекта для SoC

Проект для примера

WSL и gcc-arm-none-eabi

Подготовка проекта

Компиляция

Прошивка, отладка

Вывод

Ссылки

Добавить комментарий Отменить ответ

Проект для примера

WSL и gcc-arm-none-eabi

Подготовка проекта

Компиляция

Прошивка, отладка

Вывод

Ссылки

Поделиться ссылкой:

Понравилось это:

Добавить комментарий Отменить ответ