- This topic has 5 replies, 2 voices, and was last updated 3 years, 8 months ago by
.
-
Posts
-
As mbedtls is derived from PolarSSL and mbedtls is already part of the arm-eabi BSP (com.sysprogs.arm.stm32).
Could you add this as an optional Embedded Framework in the VisualGDB project properties?
I can add the files myself, but I fear it may break in later BSP releases.
Best regards,
Hi,
No problem. We have rechecked this and indeed the STM32 SDKs contain a ready-to-use version of mbedTLS. We have updated our STM32 BSP generator internally and will include it in the next STM32 BSP release.
You can also add it to the latest 2021.02 BSP by extracting the following file into the BSP directory: https://sysprogs.com/files/tmp/mbedtls.7z
Awesome – thank you.
The next step will be getting FreeRTOS+TCP and all the porting layers added as well 🙂
No problem. You can easily add 3rd-party packages into VisualGDB by following the file structure in the %LOCALAPPDATA%\VisualGDB\EmbeddedEFPs\Profiler directory. Simply create another subdirectory containing one or more embedded frameworks described in the EFP.XML file and VisualGDB will pick them up and let you reference them from VisualGDB Project Properties.
You can use our open-source BSP Generators as a starting point.
We can also do everything for you, including research, implementation and testing via our consulting services. Feel free to reach out to our sales if you would like to get a quote.
Nice to know, but it will be easier for us, to just submodule the packages in every repository, then.
The purpose of having you add it to the BSPs, is that it will be installed on all PCs when VisualGDB is installed. It just helps manage a lot of 3rd party libraries.
No worries. We usually try to make sure our BSPs contain the libraries that are included in the original vendor-supplied SDKs and used by a sufficiently large number of SDK examples. This ensures that the libraries have been tested in that specific environment and will usually work seamlessly.
Integrating additional libraries would require considerable ongoing porting and testing effort, so instead of doing it on our side, we focus on providing convenient GUI so that our users could do it in their environments.
If you have a non-trivial project structure, we would advise trying out the new Advanced Embedded CMake Project Subsystem. CMake projects decouple device-level and toolchain-level settings from library-level settings, so you can very easily maintain a repository of reusable libraries compatible with multiple devices.
You can read more about Advanced Embedded CMake projects in the following pages:
- You must be logged in to reply to this topic.