{"id":6986,"date":"2020-10-20T10:57:50","date_gmt":"2020-10-20T17:57:50","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=6986"},"modified":"2020-11-18T15:32:05","modified_gmt":"2020-11-18T23:32:05","slug":"organizing-bsps-and-other-shared-files-for-embedded-projects","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/documentation\/embedded\/bsps\/","title":{"rendered":"Organizing BSPs and Other Shared Files for Embedded Projects"},"content":{"rendered":"

This page explains how VisualGDB manages the shared files (such as the STM32 HAL drivers) for the barebone embedded devices.<\/p>\n

Unlike Linux-based project where the low-level drivers are included in the Linux image, barebone projects need to be explicitly built with the device-specific startup code and drivers. In order to maximize code reuse, VisualGDB normally places these drivers in a shared location that can be reused between multiple projects. The shared files are grouped into BSPs (Board Support Packages), where each BSP can support multiple devices and boards by the same manufacturer. Additionally to BSPs, shared code can also reside in Framework Packages that could be referenced by projects.<\/p>\n

Warning: the shared file structure shown here does not apply to ESP8266 and ESP32 projects. For more information on projects using ESP-IDF, see this page<\/a> instead.<\/strong><\/p>\n

VisualGDB supports the following strategies for managing the shared code:<\/p>\n

Shared BSPs<\/a>
\nRelocated BSPs<\/a>
\nStand-alone Projects<\/a>
\nFramework Packages<\/a>
\nStand-alone Frameworks<\/a>
\nCustom BSPs<\/a>
\nProject Templates<\/a><\/p>\n

<\/a>Shared BSPs<\/h1>\n

This is the default way of organizing shared embedded code. VisualGDB will automatically download the latest BSPs for the devices you target, and will store them under %LOCALAPPDATA%\\VisualGDB\\EmbeddedBSPs<\/strong>:\"\"<\/a>You can manage the currently installed BSPs (1)<\/strong>, or change the base BSP directory (2)<\/strong> via Tools->VisualGDB->Manage VisualGDB Packages<\/strong>:\"\"<\/a>VisualGDB Custom edition or higher allows installing multiple versions of the same BSP at the same time (3)<\/strong>. On lower editions you can achieve the same effect by manually changing the package ID in the <BSP directory>\\BSP.XML<\/strong> file and moving the BSP into a different subdirectory.<\/p>\n

VisualGDB will automatically download the missing BSP when you open a project that references it. However, if you make any changes to the BSP files, they will be lost next time the BSP is downloaded or updated.<\/p>\n

VisualGDB locates the BSPs by checking the %LOCALAPPDATA%\\VisualGDB\\EmbeddedBSPs\\<target>\\<BSP ID>\\BSP.XML<\/strong> files. Text files with the .bsplink<\/strong> extension inside the target directory are treated as symbolic links to the actual BSP folder. You can manually install, fork, copy or rename\/move BSPs, as long as you follow this convention.\u00a0 Open VisualGDB Package Manager to trigger a rescan of the installed BSPs.<\/p>\n

As long as the project is using a shared BSP, you can change various BSP-related options via VisualGDB Project Properties. E.g. you can switch to a different device, or place all code in RAM:\"\"<\/a><\/p>\n

BSPs are often subdivided into separate frameworks (e.g. STM32 HAL drivers, LL drivers and USB Device Library). You can reference individual frameworks, and tweak their parameters via VisualGDB Project Properties -> Embedded Frameworks:\"\"<\/a><\/p>\n

Different versions of the same BSP (e.g. STM32) may have varying degrees of backward compatibility. If updating a BSP broke down some of your projects, you can always revert to the older BSP version as shown here<\/a>.<\/p>\n

<\/a>Relocated BSPs<\/h1>\n

VisualGDB Custom Edition or higher allows moving the BSPs to an arbitrary location on your computer (e.g. inside a source control checkout). This can be done via the first page of VisualGDB Project Properties of via VisualGDB Package Manager:\"\"<\/a>Relocated BSPs work the same way as the regular BSPs. VisualGDB will remember the new location for a specific BSP on this computer, and will use it for any projects referencing that BSP. Relocating the BSP on one computer will not affect other computers (or other user accounts). You can read more about relocating BSPs in this tutorial<\/a>.<\/p>\n

<\/a>Stand-Alone Projects<\/h1>\n

Stand-alone projects do not reference any BSP. Instead, they include local copies if all relevant BSP files (typically in the ‘BSP’ subdirectory). This considerably increases the project size, but makes it possible to edit the BSP in-place:\"\"<\/a>Note that to reduce the in-place BSP size, VisualGDB will expand and remove all configuration options and frameworks. E.g. if the original BSP contained support for 500 different devices, and a few frameworks, such as the USB Device Library, each supporting several different modes (e.g. USB HID vs CDC classes), the stand-alone project will only include the files used in the current configuration, and the configuration options will be removed.<\/p>\n

Warning: if you want to remove the vendor-supplied files from the project (e.g. STM32 HAL driver), you do not need to convert it to a stand-alone one. Instead, try unreferencing the unneeded frameworks via VisualGDB Project Properties -> Embedded Frameworks.<\/strong><\/p>\n

Stand-alone projects are supported in VisualGDB Custom edition or higher. You can read more about them in our stand-alone project tutorial<\/a>.<\/p>\n

If you are using the Advanced CMake Project Subsystem, you can convert the in-place BSPs from stand-alone projects back into shared BSPs. This will preserve any modifications made to the BSP and will retain its relatively small size. See this section<\/a> for more details.<\/p>\n

<\/a>Framework Packages<\/h1>\n

VisualGDB uses Embedded Framework Packages to store shared code that is compatible with several different BSPs. E.g. the Fast Semihosting\/Profiler<\/strong> package supports most popular device families. Similarly, Test Framework Packages<\/strong> are used to run unit tests directly on the embedded devices. Embedded Framework Packages and Test Frameworks are installed to %LOCALAPPDATA%\\VisualGDB\\EmbeddedEFPs<\/strong> and TestFrameworks<\/strong> directories respectively and can be managed via VisualGDB Package Manager similarly to BSPs.<\/p>\n

<\/a>Stand-Alone Frameworks<\/h1>\n

If you are using the Advanced CMake Project Subsystem, you can fork individual frameworks from the BSP (e.g. STM32 USB Device Library) without cloning the entire BSP, or converting it into a stand-alone project.<\/p>\n

Cloned frameworks are be referenced by relative paths, hence each set of projects can reference its own version of the cloned framework, while using the rest of the frameworks from the original BSP. Note that if you switch to a newer version of the BSP, the cloned framework may no longer be compatible with it until you manually merge it with the newer version from the BSP.<\/p>\n

See this tutorial<\/a> for a detailed step-by-step introduction to stand-alone frameworks.<\/p>\n

<\/a>Custom BSPs<\/h1>\n

You can automatically export an in-place BSP from a stand-alone project<\/a> into a regular shared BSP. This will allow other projects to reference it instead of having a separate copy in each project. The custom BSP will typically only support 1 device and will have a separate ID from the original BSP.<\/p>\n

Creating BSPs from stand-alone projects requires VisualGDB Custom edition or higher and only works with Advanced CMake projects. See this tutorial<\/a> for a detailed overview of this process.<\/p>\n

<\/a>Project Templates<\/h1>\n

Project templates can be used as an easy way to clone projects. Templates created from stand-alone projects include the copy of the in-place BSP. Templates created from regular projects\u00a0 reference the original BSP, but preserve the device type, configuration, and a specific list of referenced frameworks. You can create project templates via File->Export VisualGDB Project Template <\/strong>(requires Custom edition or higher):\"\"<\/a>You can then select the template in the VisualGDB Project Wizard to automatically create a project based on it:\"\"<\/a>See our tutorial on Embedded Project Templates<\/a> for more details.<\/p>\n","protected":false},"excerpt":{"rendered":"

This page explains how VisualGDB manages the shared files (such as the STM32 HAL drivers) for the barebone embedded devices.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[197],"tags":[223],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6986"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=6986"}],"version-history":[{"count":1,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6986\/revisions"}],"predecessor-version":[{"id":6995,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6986\/revisions\/6995"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=6986"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=6986"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=6986"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}