March 7, 2019 at 02:32 #24108
I have been using the embedded VisualGDB project + mbed for about 2 years, over 5-6 projects. Got some time to start exploring the new mbed project today and a few things stuck out. First off: the addition of the mbed project wizard is a nice step forward in that it uses a standard toolset and makes updating GCC/mbed library versions significantly easier.
Currently, the mbed project is missing some features compared to the embedded project. Most notably for me is the embedded memory explorer isn’t associating to files and the ability to have multiple build profiles (Debug/Release/etc.) without changing the build settings. Are there plans to bring feature parity to the mbed project?
Some additional features to round off some of the rough edges in the project setup:
- The check boxes to enable/disable features and only showing the enabled options in the embedded project are far superior to the enourmous list of configuration options in the mbed project (the easiest way to disable features I’ve found is adding directories to the .mbedignore file)
- Setting the compiler options (e.g. optimisation, c++ standard) took me a little while to work out (mbed cli args: “–profile ./profile_debug.json”). This is going to be needed in almost every project, so a “build settings” like tab in the project properties would be much appreciated
March 7, 2019 at 05:02 #24114
- This topic was modified 2 weeks, 3 days ago by CrzyRndm.
I also can’t figure out how to fully set the C++ standard version for the intellisense engine. Defining -std=c++14/17 as an extra flag in the intellisense enables constexpr and friends, but still leaves “__cplusplus == 199711L” (C++98) which makes std::string_view and other library types show errors.March 10, 2019 at 09:20 #24166
Thanks for your suggestions. The new mbed project subsystem is relatively new and is indeed very basic, compared to the regular embedded workflow. We added it in order to support the latest mbed releases and libraries without needing to convert them into MSBuild, that was error-prone due to the large amount of files, custom steps and board-specific hooks.
We do have plans of making it more usable and appreciate your feedback. We will try to add a graphical editor for common build flags in one of the next preview builds after the upcoming v5.4R3 update next week.
We have rechecked the Embedded Memory Explorer, but could not reproduce any problems. If you could share more details or attach a screenshot, we should be able to suggest how to fix the issue you encountered.
Regarding the build profiles, VisualGDB already supports separate debug and release configurations for mbed projects, automatically applying the debug-only build configuration file for the debug configuration. Are you looking for something different (e.g. multiple debug/release configurations for the same target)?
The __cplusplus version is actually queried directly from g++, hence if you edit the mbed configuration files to add those flags to g++ and reload the project (delete the Build and VisualGDBCache directories if simple reloading doesn’t work), it should get the correct values. If it doesn’t happen, please check the command lines in the VisualGDBCache\<…>\CodeSenseDir\MbedCommandLines.txt file. Do they contain the correct -std setting?March 10, 2019 at 20:03 #24167
The embedded memory explorer was initially displaying all of the allocations without any file links. I believe the cause was missing the “-g” in the command line arguments (also caused debugging to be disassembly only) but cannot be sure at the moment as I was tweaking many build args when it started working again. Are there any other build flags that would assist this tool?
The automatic switch worked fine, but it only works with the default mbed build profiles. I want to provide my own custom build profile (more warnings, lang versions, etc.), so I have to provide extra command line args and those appeared to be being shared (requiring me to manually change the args to switch between debug / release).
I will check and get back to you. I was tweaking the command line a lot that day, so it’s quite possible I got a bad cache
March 15, 2019 at 05:15 #24268
- This reply was modified 1 week, 6 days ago by CrzyRndm.
Back after a few more experiments
- Figured out the intellisense issue: The ARM installer has spaces in the default install directory (both in the location, and the folder it creates). You definitely want to warn about that one (and preferably look at improving your tools to be agnostic to this. It’s not the first time I’ve run into weird bugs because of it). I had previously installed GCC8 in default location and when it linked me to the download page I just reused my existing install without thinking too hard about it.
- Installing mbed “out of source” (i.e. shared code location) doesn’t work (at least on a fresh install). You get to the page where it asks to choose toolchain and target, but the target list never populates. I hope however that is supposed to work co-exists with mbedignore (a clean build with all features takes about 3x longer to complete).
- The find/refresh toolchain button didn’t detect any of my GCC installs (GCC8 in default location, GCC8 under “C/SysGCC/8-2018-q4-major”, or GCC7 under “C/SysGCC/7.2.0”). GCC8 installs are “official”, GCC7 is one of the Sysprogs distributions.
- I can’t add the GCC7 install as a target toolchain. I select it’s …gdb.exe, but it never shows up in the list of selectable toolchains (GCC8 was added first. I suspect some ID is being duplicated)
- GCC8 discovery ran into a few issues when manually selected. GDB version is reported as “GCC (“, and the toolchain file is a LOT smaller than the GCC7 one (not sure how much is intended).
- Python 2.7 was forcibly installed, promptly displaying deprecation warnings on every action (newer version of mbed-cli are apparently 3.x compatible: https://github.com/ARMmbed/mbed-cli/issues/601)
More general feedback
- I can’t find an obvious location to change the project target. I can’t find an obvious way to manage the mbed repo without git directly. (mentioned here: https://sysprogs.com/w/introducing-advanced-mbed-project-subsystem/)
- Having to duplicate build settings (in the profile.json for mbed, again for intellisense in visualGDB) is quite irritating. It would be great if the json profile could be generated when settings are changed (I tweak build settings *a lot* to get the effects I need. Testing the impact of various optimisations, <dis/en>abling warnings and various other features (e.g. -flto). Having to think about what needs to be duplicated will slow down iteration)
- Project refreshes are quite slow, and seem to occur multiple times after project settings are modified (this is probably partly on mbed tooling)
- Build with no/minimal work is much slower (again, I blame mbed tooling for this. Just noting downsides to the change)
- Warnings when compile flags are missing for various support tooling (e.g. the “-g” above). IIRC, the embedded project would detect and prompt a change & rebuild if the relocatable functions flag wasn’t enabled with some tool (probably memory explorer, I use that a lot)
- More configuration warnings in general would be nice, it’s easy to miss something small and end up without an obvious solution (e.g. __cplusplus not set for intellisense, dissasembly only when debugging, no file names in memory explorer, no targets in project creation, …)
I am hopeful about this direction, and will continue to experiment and provide feedback.March 15, 2019 at 05:33 #24273
Forgot to mention, the resources linked from this page are invaluable in learning how to tweak the mbed build (it could be useful to have to help/reference links in the project properties). I’ve not dealt with mbed-cli directly much before so a few things took a while to work out what I actually needed (still unsure if there’s any facility for overriding compiler flags for a single file/directory, but I only required this on rare occasions so will not miss it enormously).
March 16, 2019 at 01:26 #24296
- This reply was modified 1 week, 2 days ago by CrzyRndm.
Thanks for the detailed feedback. It will take us a couple of days to properly process it, come up with hotfixes for easily resolved issues and give time estimates on bigger ones. Please expect an update on this around the middle of the next week.
You must be logged in to reply to this topic.