- This topic has 10 replies, 2 voices, and was last updated 7 years, 4 months ago by
.
-
Posts
-
Hi,
since I wanted to and due to several important changes in the mbed-libraries, am compelled to, I wanted to update my code to the most recent official mbed release.
The current VisualGDB BSP for mbed uses the mbed-Version 123 which translates to a mbed 5.2.1 Version. The current Version (except mbed OS 5.5-RC2) is mbed-Version 144 a mbed 5.4.7 release. I now wanted to ask if it would be possible to use the official mbed-cli guide to get mbed 5.4.7 from git, generate a new project and then export this ‘blank’ project into a arm_gcc makefile project, which I then intend to import into VisualGDB. I got the idea from your Project-Wizard and the tutorial I stumbled upon (https://visualgdb.com/tutorials/arm/import/).
If this were possible, it would simplify my current project tremendously.
Best regards,
Chris
Hi,
You can do that, but the VisualGDB will treat the project as a black box. I.e. when you add new files to Solution Explorer, it won’t automatically update your Makefiles and if you want to change some settings like include directories, you will have to manually edit both the Makefiles and the IntelliSense settings in order to change them. You will also need to manually set the preprocessor macros and include directories generated by mbed-cli in the IntelliSense settings, as VisualGDB won’t detect them automatically.
You can try using our mbed BSP generator to build a first-class BSP that will be fully synchronized with Visual Studio, although it may need some adjustment due to changes to mbed codebase since the release it officially supports.
You can try using our mbed BSP generator to build a first-class BSP that will be fully synchronized with Visual Studio, although it may need some adjustment due to changes to mbed codebase since the release it officially supports.
While that would be a possibility, I’m actually not too keen on pushing time into additional software, just to start a project.
The mbed-cli tool actualy does everything I need, just not in a form which VisualGDB understands right now.
I was in hope there would be a build-in option to rather easily transfer the information the mbed-cli deliveres to VGDB. The ‘project.py’ located within the tools folder of the mbed-os sources actualy delivers a necessary information.
Lets say mbed-os is located at C: a soon to be established project is placed at C:\project\ and mbed-os itself is located at C:\mbed-os\. The most simple way to start an empty mbed project for a mbed-supported toolchain would be to set your command-line to C:\project\ and execute: “..\mbed-os\tools\project.py -m NUCLEO_F767ZI -i uvision5 –source . –source ..\mbed-os”.
This then would create a Project-File for (in this case) KEIL µVision5, ready to be used, all necessary information about the mbed-board already set and all necessary mbed-os files set up in the project.
I admit this is practically the exact opposite way of creating a project as a VGDB BSP would do, since it requires to choose a controller/board by hand, knowing what to choose, without selcting one from a precompiled list. Certainly it is possible to pick the necessary information from such a project and move it to VGDB, but that takes time and includes the risk of easily done mistakes.
But still, it is the probably easiest and fastest way to deal with rapid mbed-os updates without relying on, to be frank, waaaaay outdated VGDB BSP’s.
If it would be possible to implement a mechanic in VGDB to diretly use the mbed-cli from the project-wizard it would be possible to easily upgrade to a new mbed-os release without relying on a BSP without having to ue the BSPGenerator, which altough it’s a great tool, is rather inflexible when it comes to the fast and sometimes unpredctable changes of mbed-os. Especialy regarding the upcoming changes in mbed-os 5.5.
Hi,
You can import a project generated by mbed-cli into VisualGDB by first generating a Makefile-based project and then selecting Import->Import a project built with command-line tools. VisualGDB will then not make any assumptions about the project structure and will just run “make” to build the project.
The downside will be that you would need to manually synchronize the list of sources between the Makefiles and the VisualGDB project and also manually set the preprocessor macros and include directories in VisualGDB Project Properties so that VisualGDB IntelliSense could understand the code properly.
Yes, sure I could do that, same thing as with any other makefile.
But I can’t help but feel, this would defeat the advantage of using the VisualGDB Extension, which I’d actually would love to use in combination with the mbed-cli.
But still, thank you for your support.
Hi,
The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.
So with mbed we essentially offer 2 approaches:
- Using our BSP that is verified, tested and maps common mbed features to easily editable embedded frameworks. But it’s updated quarterly as we need to manually keep up with the changes to mbed itself.
- Manually importing an mbed-cli project. This is less intuitive and requires some extra steps, but will still give you access to advanced debug and IntelliSense features and does not force you to use a specific mbed version.
The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.
That would certainly be true for project-files like thos for KEIL’s µVision5 or any other IDE, but what aboutr makefile-projects?
Wouldn’t it be possible to temporarily create a makefile-project, extract the needed settings / information and then move those to a VisualGDB Project?
As I already mentied earlier, this would reduce the comfort of VisualGDB while creating projects (MCU/Board not necissarily know by VGDB beforehand), but would drasticaly increase the flexibility regarding mbed-projects with VisualGDB.
Regardles if this would be possible or not thanks for your POV on this topic and some insights.
Greetings,
Chris
Hi,
The problem with converting an arbitrary Makefile-based project is that different Make-based projects store settings like CFLAGS slightly differently, so extracting them fully and reliably quickly gets too complicated. We have long-term plans for a tool that would reconstruct a project based on build logs (showing all gcc invocations), but it will not work on 100% of projects as Make projects often include custom build steps.
We have checked the internals of cmake-cli and will contribute an exporter module that will construct a VisualGDB project (similar to what it does for IAR projects) if the mbed community is OK with this.
That would be great!
As much as I like to work with mbed for it’s simplicity in regards to choosing an MCU and mostly without further addo getting down to business, I dislike it’s stiffness in regards on how to implement mebd for any non “online ARM mbed compiler” .
We have checked the internals of cmake-cli and will contribute an exporter module that will construct a VisualGDB project (similar to what it does for IAR projects) if the mbed community is OK with this.
Are there already any news on this?
Hi,
We posted on the mbed forum about this (https://developer.mbed.org/forum/mbed/topic/27899/), but did not get any response from the mbed maintainers. Unless they can confirm that they would be interested in accepting the merge request with this feature, it does not make any sense to move on as mbed is rapidly changing and any stand-alone exporter will quickly become incompatible with the mbed build system.
- You must be logged in to reply to this topic.